---
tags: eth2network
description: Notes from the Eth2 networking working group call
image: https://benjaminion.xyz/f/favicon-96x96.png
---

# Eth2 networking call #1 2019/12/18

[Quick contemporaneous notes by Ben Edgington]

[Agenda](https://github.com/ethereum/eth2.0-pm/issues/111)

## Discussion

### Gossipsub simulation [Daniel/Whiteblock]

Whiteblock has analysed the Go gossipsub implementation. Report due in a couple of weeks.

Bottom line: found libp2p's gossipsub performed as intended; maximum message delivery time of 4.5s (with imposed high latency of 400ms) which is less than the block time; no resource starvation was observed. Will study the Rust implementation next.

### Gossipsub simulation [Anton/Harmony]

Performed large scale gossipsub simulations. [Write-up here](https://hackmd.io/ZMBsjqdqSAK026iFFu_2JQ). In "aggressive" environments delivery time can be large (10-20s) due to default heartbeat being one second. Suggests decreasing heartbeat period to 300ms or less. Could play with "D" parameter to reduce overall traffic: current settings result in 5-6x traffic overhead.

### Aggregation model [Protolambda]

Work in progress on aggregation strategies [here](https://notes.ethereum.org/@protolambda/Hytd28rAH). Planning to test the strategies by implementing in Kotlin on top of Harmony's simulation framework.

### Noise implementation

There is currently only one integration of noise into libp2p2. Are there any blockers to implementing into libp2p? Unknown: **Danny to follow up with RaulK**.

## Spec items

### Add attestation subnets to ENR

PR has been merged adding attestation subnets to the ENR. Tells participants their long-term assignment to subnets. In v0.9.x, to be released asap. Generally backward compatible. No other substantive changes.

### Content addressing of messages

[Under review](https://github.com/ethereum/eth2.0-specs/issues/1528), a modification to the pubsub ID of messages. This affects how things are cached.

NB We need to ensure to use the native pubsub callback for validation (not work around it :eyes:)

[Q] Why use Base 64? Using Base64 since the gossipsub header must be a string. This may not be necessary, but Base64 makes the code easier, so leave as-is for now.

### "From" field in gossipsub

[Dmitriy] Anonymisation of "from" field in gossipsub? Most implementations populate this with the originator. Should we allow it to be empty?

[Q] Why is the from field there? Anonymity was not originally required. But Eth2 changes this. Also, it is used to do self-checks: to see if a message comes from myself. And to generate message IDs (concatenation of from and sequence number), but we're nixing that in the above.

We believe it is safe to rewrite "from" to be empty or junk. But it is hardcoded in most implementations.

Proposal - **move discussion into an issue**.

### Handshake/Hello message

[Proposal](https://github.com/ethereum/eth2.0-specs/issues/1531) to add a "Hello" message. General view that it needs more research: how does it fit in with our other protocols? Do we really need this other info? **Danny to follow up on this.**

### How often to send status?

[Issue here](https://github.com/ethereum/eth2.0-specs/issues/1533). Current assumption is to send periodically during syncing, but not required afterwards. Could be useful for a node to know if it needs to resync. Do we need to specify a frequency? This could be covered by a note, rather than spec change. The "am I synced" question is difficult to answer in general! Different clients have different processes.

Conclusion: allow clients to implement in their own way. Worth checking how other teams are implementing this.

### Requests for missing blocks

[Reference](https://github.com/ethereum/eth2.0-pm/issues/111#issuecomment-567024836). When requesting blocks it is possible there is no block in the range. There is no way to represent this currently. Can only give an error, but it isn't really an error.

Allowing there to be no chunks in the response could be a workaround. [Detailed conversation ensues... relationship with compression is interesting.] **Jacek to open an issue.**

Another option: include block height in addition to the slot? But block height is not currently a concept in the spec.

Hsiao-Wei's suggestion (below). We would prefer to avoid introducing Union types into the spec. Also need to deal with case of malicious peers.

## Overview on Validator Privacy

Specific privacy protocols are not destined for Phase0, but under research, and we are eager to find solutions.

### Use of tor/sphinx/onions

Would induce latencies, but interesting to look at.

[Nicolas] Mixing p2p protocol with Tor is different from normal Tor usage, and heavyweight. How much of the protocol could it be useful to put onto something like Tor?

[Mikerah] Sphinx is a packet format. Offers network layer anonymity (e.g. Lightning is using it). Everything on the network would be a Sphinx packet. Will be looking into it further. [Q] Does it introduce high latency? There is a trade-off between latency, bandwidth and anonymity. **Mikerah to update on next call**

### Obfuscation of validator ID or use of ZKPs

Validators leak a lot of information, and are probably easy to de-anonymise. [Nicolas] Could hide the link between the wallet ID and the signing key, e.g. by using a new key each time.

[Mikerah] ZKPs are not scalable at the networking layer. Might be better to use statistical methods/probablistic anonymity. But not all ZKPs are heavyweight, in which case they may suffice.

Any other items people are concerned about? [Silence...] Bring items up in the discord as they occur.

## Wrap-up

[Proto] What do people think about EthStats/network explorer (in addition to the block explorers)? EthStats uses data optionally uploaded by clients. Very useful for a test network. Polkadot nodes push testnet information (e.g. peer info) - good for debugging. **Protolambda to make an issue**

Second week of January for next call.

## Chat log highlights

From danny to Everyone: 01:02 PM
: https://github.com/ethereum/eth2.0-pm/issues/111

From Nicolas Liochon to Everyone: 01:07 PM
: What are the parameters for the test? Number of nodes, number of connection per node?

From jason to Everyone: 01:08 PM
: hi all jason here. i'm at whiteblock with daniel at whiteblock
we had 95 nodes with connections randomly generated using the Barabasi-Albert model

From danny to Everyone: 01:10 PM
: https://hackmd.io/ZMBsjqdqSAK026iFFu_2JQ

From Daniel Choi to Everyone: 01:10 PM
: Hi Nicolas, we varied the Barabasi-Albert’s degree of connectivity from 2, 6, 12, and 16.

From danny to Everyone: 01:15 PM
: https://notes.ethereum.org/@protolambda/Hytd28rAH

From danny to Everyone: 01:22 PM
: https://github.com/ethereum/eth2.0-specs/pull/1535

From Dmitriy Ryajov to Everyone: 01:24 PM
: one thing that I haven’t heard discussed is the “from” field in gossipsub, that gives away the originator
what’s the suggested approach to anonymize that?

From Mikerah to Everyone: 01:34 PM
: One way can be to have gossipsub in an onion-routed network so that each node in the network only knows the previous node in the path and the next node in the path.
With the addition of omitting the "from" field completely

From danny to Everyone: 01:36 PM
: https://github.com/ethereum/eth2.0-specs/issues/1531

From Hsiao-Wei Wang to Everyone: 02:00 PM
: Can `List[Union[null, BeaconBlock]]` format solve this problem?

From kevin.mh.chia to Everyone: 02:12 PM
: Reference for onion address in multiaddr: https://github.com/multiformats/multiaddr/blob/master/protocols.csv#L18-L19

From danny to Everyone: 02:23 PM
: https://ethstats.net/