Eth2 networking call #6 2020/09/09

--- tags: eth2network description: Notes from the Eth2 networking working group call image: https://benjaminion.xyz/f/favicon-96x96.png --- # Eth2 networking call #6 2020/09/09 [Quick contemporaneous notes by Ben Edgington] [Agenda](https://github.com/ethereum/eth2.0-pm/issues/180). Recording available from Danny. ## Seqno/Sig/Key omit plan for gossipsub Three fields in gossipsub that are optional. (See [this issue](https://github.com/ethereum/eth2.0-specs/issues/1981).) But enforcing the omission requires a softfork. So far clients have not been enforcing it, but we should do that in a couple of weeks. NB the spec also needs to be updated to state that we do not use these fields. Also the gossipsub spec needs to document the flags that are configurable to enable this. [Proto] We should go ahead with the spec change. How to handle empty values - e.g. sending empty PeerID rather than omitting it? Would be clearer to enforce omitting the fields completely. Note that protobuf is very flexible and is also forward-compatible and allows for any fields to be defined. We would prefer to be as strict as possible about message contents and reject any unrecognised data. Does this mean that we're not really using protobuf? In principle, it does. [RaulK] Need to continue to keep these fields in the gossipsub spec, but implementations can set their configurations to prohibit any use of these fields. Then clients using them would be blacklisted by peer scoring. Summary: Plan to omit fields and update spec is "go". All clients should begin to enforce this within the next couple of weeks. Conversation about protobuf conformance to be moved to an issue. ## gossipsub v1.1 param progress Documents: - https://hackmd.io/@ZbFzvXM_R4miXFVdjZis8A/topic-params - https://docs.google.com/spreadsheets/d/1y0DalL4PVBodg1wLlvXjJcnbItwmSmiHdd4z2TTYiNY/edit#gid=0 [Ben, Sigma Prime] Still testing different scoring parameters on Medalla. Trying to assign meaningful scores to honest peers on Medalla (postive scoring side). Also testing attack scenarios on TestGround (negative scoring side). Hope to conclude this within a week. How to score listen-only clients? Should be fine, as long as the client is participating in the gossip. This participation is not considered to be an undue burden [Danny]. [RaulK] There exists a set of RPC endpoints that allow clients to obtain network information. The Go implementation has a gossipsub tracer that allows clients to listen for events. [New module](https://github.com/libp2p/specs/pull/292) for gossipsub for spam-protection. A circuit-breaker that compares peer activity with healthy network expected activity. Peers that exceed expected parameters end up throttled. Complements peer scoring. This mechanism seems to be working well in the FileCoin network. It may be used optionally within each local node; it does not need to be added to the whole network. [Jacek] Trying to prioritise gossip handling: blocks > aggregates > others. [RaulK] Should be possible to configure the module accordingly if the messages are separated by topic. Different policies can be assigned per topic. ## Migrate gossip message-id to not use Base64 Suggestion to use bytes rather than Base64. [Danny] This probably makes sense to change in the next 7 days. No one opposed the change. Q. Should we try to shorten the massage ID? Currently it is the full hash. Seems a reasonable way to reduce traffic. We use a lot of messages! **Action: [Proto] to add this to the gossipsub issue.** ## discv5.1 DoS vector exists in v5.0. [Mikhail] Related to the random packet sent by the node to establish a session for the first time. (1) Clients answer these packets which amplifies the attacks, (2) most clients are not correctly checking the correctness of the RLP data (Lighthouse excepted). Also attacker can cheaply send a random remote PeerID, forcing the honest peer to expensively hash data. Mitigation: rate limit requests/second. Lighthouse does this and it seems to be an efficient countermeasure. But in v5.1 the SHA256 CPU consumption attack vector is also mitigated. (But it's probably good still to rate-limit, to protect against unknown attacks.) Can these be back-ported to v5.0? This is basically equivalent to upgrading to v5.1. Note that v5.0 and v5.1 are not compatible. Main concern is how to test this... Should we do it now, or in 3-4 months? General preference for sooner rather than later. What would happen to Medalla if we started updating to 5.1 for discovery? Would need bootnodes with both versions for some period of time. **Action: let's implement v5.1, definitely for mainnet; discuss how to introduce to Medalla.** [Age] Some client is sending invalid discv5 messages (more than 5 nodes back). [Jacek] What's the plan for yamux? Could we just drop it from the spec? [Danny] The idea is that yamux is a better protocol that we should migrate to over time. [Jacek] But QUIC obsoletes all our current protocols. Other client teams are happy to drop yamux. Clients may use it if they wish, even if it is dropped from the spec. [Jacek] Also hanging in the spec is multiselect 2.0. This is still WIP at Protocol Labs. It has limited benefits for Eth2, since we can optimistically open streams with the assumed protocol. **Action: Remove multiselect 2.0 from the spec since it's not available yet, but keep discussion alive.** ## Closing remarks and plans for next call or other organizational items Danny's Internet connection was failing... we came to a swift end. ## Chat log highlights From danny to Everyone: 03:19 PM : https://hackmd.io/@ZbFzvXM_R4miXFVdjZis8A/topic-params https://docs.google.com/spreadsheets/d/1y0DalL4PVBodg1wLlvXjJcnbItwmSmiHdd4z2TTYiNY/edit#gid=0 From Raúl Kripalani to Everyone: 03:24 PM : not sure if folks have seen this new extension: https://github.com/libp2p/specs/pull/292 i can give a 101 if you’d like From Raúl Kripalani to Everyone: 03:35 PM : btw — the Filecoin network is now running on Noise as the primary handshake ;-) TLS as fallback; and SecIO has been removed entirely From Mikhail Kalinin to Everyone: 03:53 PM : what do you think about adding ratelimiting as a recommendation in discv5.1 spec? From Jonathan Rhea to Everyone: 03:55 PM : might be worth considering... it's a great fail safe measure. perhaps we should succinctly write down our recommendations and let people review?