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

# Eth2 networking call #2 2020/01/29

[Quick contemporaneous notes by Ben Edgington]

[Agenda](https://github.com/ethereum/eth2.0-pm/issues/124) - quite a few detailed updates are attached to the agenda directly, so worth a look.

## Opening

No one previously requested the recording, so not recording this one.

## Updates

**Raul/Protocol Labs**
Update on gossipsub, peer scoring, Noise, QUIC, multiselect 2.0: see [here](https://github.com/ethereum/eth2.0-pm/issues/124#issuecomment-579740557) for detail and links.

Team updates on Noise implementations
- JVM libp2p needs to be updated to latest Noise spec
- Python, implementation by end February expected
- Nim, only preliminary work done so far.

Peer scoring. Raul can provide a draft of their current thinking on request.

**Felix Lange**
Discovery v5 update. Second audit of the crypto has been performed. No issues found.

It was suggested to add Noise protocol, but Felix believes there are no big advantages to using it in this protocol, so not changing the construction now - considered sufficiently secure. Maybe a future upgrade.

Topic index [discussion on GitHub](https://github.com/ethereum/devp2p/issues/136). Still unsolved, but some researchers are working on it. Confident there will be a solution.

Felix would like to make an "official" list of implementations of discv5. See links in the chat, below.

Q: how to handle changes to the spec and notifying people. Spec minor version numbers? There is a version number on the spec.

Q: Eth2 ENR entries. Tracking ENR entries in devp2p repo - what will the Eth2 ones look like? Info [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure), but note difference between interop and mainnet. Eth1 [chain identity](https://github.com/skylenet/discv4-dns-lists) - can do something similar for Eth2 by additing a network differentiator to the ENR.

## Issues with testnets

### Sync

**Adrian/Lighthouse**
Initially grouped peers into groups of known chains (same finalised block). Tracking exactly who is sending you bad data has been difficult. Lots of logic added to handle edge cases, such as when peers don't send you the number of blocks you expect. Adding termination message.

**Jacek/Nimbus**
Because of skip slots there are very few assumptions you can make about what the peer may send you. TCP does not guarantee ordering which complicates. May need to buffer data for a while before you can decide if it is valid or not. Dealing with bad data inevitably makes the code complex and gives limited optimisation opportunity.

There is an inherent race condition. E.g. in block range request, the head root is sent along with the request, but that may change during processing. The best grouping for peers may be the head fork version (which is not yet defined) to ensure we are on the same chain. There are heuristics that help if peers are not too far apart in sync status. Perhaps simplify the protocol by defining head fork version in a meaningful way. Or [Proto] include more roots up to the head in status messages.

[Adrian] If a finalised epoch ends on a skip slot this can lead to interesting behaviour.

[Danny] adding the ENR value largely takes care of finding the right peer groupings.

[Jacek] do we need to keep the head root field in the beacon blocks by range request? [Adrian] Not super important, but we use it for grouping. Could modify the response to make this unnecessary. Happy to see this go. **Jacek to create issue with a view to simplifying**. What about head root in the status message? [Adrian] Yes, this is useful for grouping peers. Would root at slot-minus-(say)-4 be a more stable quantity to group by? Further discussion... getting a bit detailed...

[Jacek] We should try a testnet hard fork at some point. [Danny] And test node upgrades, like change p2p version.

## Clock synchronisation

**Alex Vlasov**
Clock disparity can be used to attack the network. Can relatively cheaply attack, without needing ether. Many OS distributions use NTPpool; an attacker can set up Byzantine participants in NTPpool. Alex has written an analysis and draft proposal on defending against this. Byzantine tolerant clock exchange protocol. (Vitalik has also written about this.) The proposal adds time info to blocks (and potentially attestations) then uses a known algorithm to assess the correct time. Note that there is a circular dependency between beacon chain and clock synchronisation, which may amplify faults. A separate Byz fault tolerant clock protocol would be ideal, but complex. Working on cataloguing the various faults/threat model.

Links:
- https://hackmd.io/GnJ_Cf4FSZW-BZImH8KF1w
- General thoughts, why clock sync is important. https://hackmd.io/X-uvqwe8TkmR-CJqMdfn6Q
- an issue about NTP-level Sybil-like attack https://github.com/ethereum/eth2.0-specs/issues/1592
- a draft proposal how to solve it https://hackmd.io/GnJ_Cf4FSZW-BZImH8KF1w

Is this a systemic threat? Yes, if most nodes use the same source of time, e.g. NTPpool (would affect the whole Internet, not only Ethereum 2, unless Eth2 nodes attach to a two-faced clock server.) Would be ideal if we could all use GPS time or similar.

## Rate limit response code

[PR #1577](https://github.com/ethereum/eth2.0-specs/pull/1577). [Jacek] Don't see a need for this; could be solved on the client side. How does this proposal make the network more efficient?

### Attestation aggregation and/or subnets

[Protolamda] Working with Protocol Labs on making naive aggregation more efficient. Check what aggregates other peers know and don't send them overlapping attestations. Can more efficiently fill subtrees of aggregations. Should try this on testnets (after formalising/simulating).

[Nicolas L] Sounds like something we tried previously. He has code to simulate this; will send to Protolambda.

[Protolambda] Putting together some tools for testing networking. Written in Go; a bit hacky. Finds nodes; has discv5; has RPC code to start sync or initiate response.

## Closing

Out of time!

## Chat log highlights

From danny to Everyone: 01:05 PM
QmXroMferbScqPeFb99xVieDc6bohKBV4VfWYNkxVZnV2k
https://gateway.ipfs.io/ipfs/QmXroMferbScqPeFb99xVieDc6bohKBV4VfWYNkxVZnV2k

From Adrian Manning to Everyone: 01:11 PM
Thanks Raul, I'll reach out to about rust impl stuff offline :)

From danny to Everyone: 01:16 PM
https://github.com/ethereum/devp2p/issues/136

From Shahan Khatchadourian to Everyone: 01:22 PM
https://github.com/PegaSysEng/discovery
(still being worked on ^)

From Zahary Karadjov to Everyone: 01:22 PM
https://github.com/status-im/nim-eth/tree/master/eth/p2p/discoveryv5

From Adrian Manning to Everyone: 01:22 PM
github.com/sigp/rust-libp2p (discv5 branch)

From Alex Stokes to Everyone: 01:23 PM
https://github.com/ethereum/trinity/tree/master/p2p/discv5
^^ python impl in trinity

From danny to Everyone: 01:23 PM
https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure

From fjl to Everyone: 01:24 PM
https://github.com/skylenet/discv4-dns-lists

From danny to Everyone: 02:08 PM
https://hackmd.io/GnJ_Cf4FSZW-BZImH8KF1w
General thoughts, why clock sync is important. https://hackmd.io/X-uvqwe8TkmR-CJqMdfn6Q
an issue about NTP-level Sybil-like attack https://github.com/ethereum/eth2.0-specs/issues/1592
a draft proposal how to solve it https://hackmd.io/GnJ_Cf4FSZW-BZImH8KF1w

From danny to Everyone: 02:20 PM
https://github.com/ethereum/eth2.0-specs/pull/1577