Ethereum 2.0 Networking Specification

[arnetheduck]

This PR consolidates the work done by various teams and community towards a unified Ethereum 2.0 networking specification. In particular, this it consolidates the RPC-Interface.md and the libp2p-standardization.md documents into a single unified libp2p-based network specification.

Highlights of the PR include:

• Concrete libp2p protocol selection for interop and mainnet, including transports, protocol negotiation and payload encoding
• Broadcast for beacon blocks, attestations as well as a simplified request/response protocol for block recovery
• Design rationale section summarising past discussions

This PR is the result of a collaborative effort between the Lighthouse, Nimbus and Protocol Labs teams.

It is a continuation of, and replaces #1281.

[Mikerah]

Some Questions/Comments:

• Since we are already taking into account Noise, we should also take into account onion routing.
• If we move to QUIC, would we still need two separate protocols for peer discovery (UDP-based Discv5) and peer communication (TCP)?

[dryajov]

counterpoint, how to reliably handle interdependent endpoints (are there any?). If endpoint A also needs endpoint B upgraded, there is no mechanism to do that reliably with this approach.

[raulk]

The plan is to group A and B in the discovery layer under protocol "families/suites/manifests" -- which represent aggregations of finer-grained protocols under one logical unit. that way we get the best of both worlds: upgraded peers can advertise/negotiate newer versions of a given operation, while continuing to serve older peers by supporting the former versions too.

while we could consider a mechanism to expose machine-readable metadata that specifies that A depends on B, I believe that's beyond scope. in practice, it should be enough to:

1. specify that in the RFC/EIP that introduces A.
2. potentially grouping A and B under a protocol family that can be atomically advertised.
3. allowing peers to incur in a runtime error when they encounter a peer that supports A but not B.

[raulk]

Cross-referenced from #1335.

[dryajov]

In theory, I like the elegance of REST like endpoints, but in practice they might be as ambiguous as semver.

For example, how does the client know which protocol the other peer speaks? This isn't easy to do if every endpoint is versioned independently and the client relies on libp2p internals such as identify and multistream/multiselect to signal which versions the other end supports, which right now (AFAIR), isn't possible without probing each endpoint explicitly.

[raulk]

For example, how does the client know which protocol the other peer speaks?

We have planned to address that in the discovery layer, but we're deferring defining the exact mechanism because it's irrelevant until mainnet. There's an idea here though: https://github.com/ethereum/eth2.0-specs/pull/1328/files#diff-9e07d955515655364c9a5f28c94f5627R236

[raulk]

Opened an issue to track this: #1335, and added a checklist item to the Open Points comment below: #1328 (comment).

[hwwhww]

Since topics are plain UTF-8 strings, does it make sense to have a map of code -> encoding, so that we can save some space in these topics? e.g., ssz is 1 and ssz_snappy is 2, so the topics are /beacon_attestation/1 and /beacon_attestation/2 .

[arnetheduck]

if we do this, we have a higher-value target in beacon_attestation - ie one could imagine having a fourcc here where the first three chars are topic and the last is encoding or something like this. that said, if we get stream compression, that should take care of it.

Also, we're sending SSZ - it's not the most bandwidth-friendly format out there already.. not sure this will make a practical difference.

all that said, if there's strong support, I'm fine with indices too.

[raulk]

Open points 💬

To keep things tidy, this comment will canonically track open points that (1) emerge from the discussion AND (2) are not immediately solvable.

We specify a follow-up action for each, in order to make them actionable.

• ETH1 and ETH2 cross-compatible encoding of ENRs (RLP vs SSZ): ETH1 and ETH2 cross-compatible ENRs (RLP and SSZ) devp2p#107
• Networking: protocol advertisement in discv5: Networking: protocol advertisement in discv5 #1335

[arnetheduck]

• Since we are already taking into account Noise, we should also take into account onion routing.

onion routing generally adds significant overhead and latency. this would need consideration before adding - numbers?

• If we move to QUIC, would we still need two separate protocols for peer discovery (UDP-based Discv5) and peer communication (TCP)?

clients will likely implement alternative peer discovery mechanisms regardless as discv5 is explicitly limited to UDP - a no-go in many networks (and browsers).

that said, for core validating nodes in the network, it is reasonable to expect a stable networking setup with UDP access and there discv5 will do the job.

It's going to take a while for QUIC to be deployed and generally accepted / implemented - in this spec and for this reason, we explicitly chose to not stray into QUIC territory (the door remains open for clients to experiment with it)

[djrtwo]

Great work everyone!
Merging this to serve as stable target for libp2p interop experiments going on. Fully expect this to iterate as we get our hands dirty but this is an excellent starting point.