Eth2 networking call #3 2020/03/04

--- tags: eth2network description: Notes from the Eth2 networking working group call image: https://benjaminion.xyz/f/favicon-96x96.png --- # Eth2 networking call #3 2020/03/04 [Quick contemporaneous notes by Ben Edgington] [Agenda](https://github.com/ethereum/eth2.0-pm/issues/131) ## Update New release of spec is coming. To include fork version issues and anything else from this call. [Raul] 1. Noise has been simplified to XX handshake. A good general simplification. 2. Taskforce is working on hardening gossipsub. Not expecting protocol-level changes at this time, only behavioural changes (e.g. inputs to peer-scoring). Spec to be updated by April 1. 3. Multiselect 2.0. Haven't had bandwidth to update spec, but have had lots of discussions. 1.0 should be good enough for now, with pipelining and optimisation. Talk to Raul if any doubts about how to implement this. Go and Rust implementations already contain this pipelining. [Felix] Still working on rebasing Go discv5 in Geth onto master branch - aim to be done in 1-2 weeks. Figuring out topic index is ongoing. Proto has been working on a [network REPL](https://github.com/protolambda/rumor) to help with debugging. Will gather feedback from EthCC participants. Herman is building a network crawler on top of it. ## Discussion ### Fork version proposal The spec does not contain information on our intended use of ForkVersion. The plan is to increase the FV every time a manual/hard fork is made. Saves us from having to think about it. Note, we can validate signatures only from current and previous FVs, so two forks in quick succession could be a problem. Would prevent us from seeing slashable behaviour from before the first fork. Could hardcode a FV/block number in the client as a forced reset of the weak subjectivity period. "A sequence of domains kind of becomes the ChainID". FV can be used to find peers. But if it becomes too cumbersome, could introduce a ChainID as a separate entity. In Eth1, a CRC hash of the fork block numbers (inc. Genesis) is used to identify the chain: ForkID. Clients know which ForkIDs they are compatible with. Older nodes cannot find newer nodes, but this is OK - they need to be updated anyway. In Eth2, using FV basically has the same effect. Eth1's approach is a retro-fit. But need to take care that FVs are not duplicated across chains if they evolve in parallel. [Jacek] What's the downside of introducing a ChainID? Only that it might be redundant. Felix recommends not using ChainID: it's a pain to manage in Eth1. Need a 3rd-party registry of previously taken network IDs. Suggestion: don't just increment FV, but find unique identifiers: e.g. random bytes; git commit of the spec... **Action: Danny will make a "coherent and complete" proposal for further discussion.** [Jacek's PR](https://github.com/ethereum/eth2.0-specs/pull/1624), "Add fork version to topic". Seems like a good idea; plan to merge. When clients are approaching a fork, some preparation will be required. ### ENR See [agenda](https://github.com/ethereum/eth2.0-pm/issues/131#issuecomment-594313516) item. Discv5 is used to get ENRs. Connect to libp2p via TCP, Noise handshake, etc. A node knows the ENR of its peer. But a node with only incoming connections does not know the ENR of the originating node. We really want to know the ENR of all nodes we are connected to. How about collecting the ENR when nodes connect by TCP? [Felix] Thinking of a similar change in Eth1. Hack it into RLPx. Getting the ENR directly from the node is the best way to ensure it is totally up to date. Q. Should we inject the ENR into the routing table when found this way? [Felix] Shouldn't be a problem if it is well-formed (e.g. drop Tor Onion addresses). [Age] Only really need the bitfield for the subnets from the ENR at this time. Could be sent via Status message instead. [Felix] Or define a protocol message for relaying ENR updates to peers. If the bitfield is the only thing we need, then may be best just to share it separately. [Jacek] Seems worthwhile not to have this in discv5, but to allow peers to communicate metadata directly. [Felix] ENRs are quite limited in space: 300 bytes. [Raul] See two different requirements for ENR (1) discovery, tradeoff between consistency of info in the ENR and in the DHT (2) Is there a use for an authenticated protocol that contains the ENR? ENR could contain static info, but not changing info. Prefer false-positives over false-negatives in discovery. Authenticated "Hello" could contain ENR. Other discovery mechanisms for the future such as mDNS. [Felix] Note that ENRs are authenticated already. [Felix] In the end, just sending over the ENR seems like a reasonable starting point. Known size helps to stop spamming by other nodes. [Danny] Specific message with only ENR as SSZ payload. [Felix] Putting some network protocol version info into the ENR is probably a good idea. Best to know this info before establishing a connection. [Age] Simply adding bitfield to the Status fixes his issue. [Felix] But inserting the whole ENR helps you to add it to your routing table, which may be good for the network. **Action: Age to convert this into an issue on GitHub.** ### Noise protocol Incompatibilities between Rust Noise and Go Noise observed by Lighthouse. Has just been patched. Go version has been updated to the spec. Rust version is spec conforming. So both should now interoperate. **Action: Age will discuss with Raul after the call**. The issue is around length-prefixing the payload. Seems like Nim Noise does not support more than uint16 max payload size. **Action: Giovanni to open issue in the repo**. ### Topics Q to Felix: how far away are topics? Felix has found some researchers via Raul. Now scoping some work for them to solve the theoretical problems (e.g. topic radius estimation). There is a bit of history to building indexes with statistical techniques. This is an exciting development. Can help with sybil protection by analysing "network density". Avoids having to add proof of work to the network protocol. There is an RFC about a DHT that uses this kind of mechanism. Bottom line: progress is slow for a solution to the topic index. Difficult to say when it will be done. [Jacek] Topics are assumed important for Eth2 since we do really need to connect to subnets of the network. What's the backup plan? [Danny] ENRs with bloomfilters (or other accumulator) for the subprotocols and random sampling provide a way to do this. [Felix] If topics are critical then we need to double down on this. [Danny] We are seeking external engineers/researchers to study this if anyone is interested. We don't have a better plan B than random sampling. ## Wrap-up Will do next call in 2 or 3 weeks. TBD.