Eth2 networking call #0 2019/12/04

--- tags: eth2network description: Notes from the Eth2 networking working group call image: https://benjaminion.xyz/f/favicon-96x96.png --- # Eth2 networking call #0 2019/12/04 [Quick contemporaneous notes by Ben Edgington] [Agenda](https://github.com/ethereum/eth2.0-pm/issues/106) ## Discussion ### Aggregation Current spec has "naive" aggregation. What implementations of this do we have? Any feedback? Artemis and Trinity have implemented but not tested yet at scale. [HWW] has some concerns about what happens if an attestation is not included within the slot: there is a rebroadcast which amplifies network load. Danny seeking further feedback. More sophisticated strategies, such as Handel, or ad-hoc trees? Concerns around privacy with Handel. What is the latest thinking? [SK] Work on integrating Handel is currently paused. [NL] On privacy, there are multiple proposals: Dankrad has something practical. Some work done on [separating the wallet from the IP address](https://ethresear.ch/t/anonymity-a-zkp-to-remove-the-mapping-ip-address-wallets-public-key-of-a-validator/6049). [DR] Intuition: unless we hit a roadblock with naive aggregation, we'll move forward, but that doesn't preclude moving to new strategy later. Slot time of 12s should be sufficient; Handel could reduce this. Dfinity uses bullet proofs for a privileged validator network to anonymise. Unlikely to get these kinds of things into Ph0. [NL] Goal of Handel is for very large scale aggregation, enabling fast finality. Our current finality target of ~12 mins is achievable in many other ways. [DR] Max committee size if all Eth is staked is ~2000, and we are not aiming for fast finality, so naive may be OK. [NL] Handel is good for 2000. Faster finality should remain a goal! [Proto] [Ad hoc tree structure](https://notes.ethereum.org/9Ijj2RkuRiqQYB9NOfY_9Q) work is on hold. ### Gossipsub benchmarking Thinking about formalising Gossipsub - are there academics who would be interested? [RK] A paper is already drafted on this! Not ready yet to circulate, but soon. [RK] Gossipsub is a base protocol on which you can build other routing strategies, e.g. [Episub](https://github.com/libp2p/go-libp2p-pubsub/issues/233). Filecoin will be using this functionality. They will have a testnet RSN. Whiteblock has been running some benchmarks. Feedback: looks like message queues are being over saturated. [DC] Looking to change MQ size and re-run benchmarks to verify if it is the root cause of message drops. Yet to run tests with network impairments - still quite a bit to do. [RK] MQ size ought to be adaptable; there is a PR in flight to implement this via healthchecks on peers. [AM] Note that this is Go-specific. Rust doesn't have queues. [DR] Is there a good way to find out if the MQ is the root cause? [RK] Yes, increase log-level. [AN] Updates on [Gossipsub simulation](https://docs.google.com/spreadsheets/d/1QvYio6ALnjrEYmsgZMTuK-ktIZzeRbqIOvPrU4b-Cl0/edit?pli=1#gid=0). Built on JVM libp2p. Simulates a network of 10,000 nodes. Simulating block distribution. Checking different configs, such as number of peers. Currently building random (ideal) topology. Each node connected to ~20 peers randomly. First test: if some nodes don't propagate incoming messages. Initial results: only honest peers, everything works very well, with at most 7-8 hops, 5-6x traffic overhead compared to a tree-like topology. With half of nodes not propagating, gossip mechanism comes into play. With 90% bad nodes, messages are barely propagated. There are optimisation opportunities: (1) reduce traffic overhead; (2) increase fault tolerance. Will create a write-up and share repo. [MK] The simulation platform is extensible. [Proto] is planning to build on it to test aggregation strategies. ### Items marked "mainnet" in spec Status updates on a few things. Noise implementations. Is the libp2p spec for Noise sufficient/stable? [RK] Two things coming: handshake (something), and padding. Otherwise happy with the spec. [BG] Noise in TypeScript is done and under review. [AM] Lighthouse: in process of building into Rust libp2p. Progress is slow, but no blockers. [SK] JVM libp2p Noise is now in the 0.2.0 release, closely matches the spec. [HWW] Not done yet. [Z] Nim is still using the libp2p daemon. Work on native libp2p is underway, but Noise not done. [RK] Please put your github ID in the [issue below](https://github.com/libp2p/specs/issues/232) so you can be added to the interest group. Multi-stream select 2.0. [RK] Aiming to lock down [something](https://github.com/libp2p/specs/pull/227) to build a reference implementation around the end of this week. Yamux. Anyone working on it? [AM] It comes for free in Rust libp2p. [Otherwise silence.] Snappy. Any blockers? [MR] Sometimes (rarely) gives weird errors. ### TLS 1.3 and QUIC We're probably not going to target this right now. ### discv5 [FL] Status: no updates to spec for a couple of months, can be considered stable apart from a few open issues. (1) Spec should be more explicit about session key management (minor point). (2) Topic index, specifically radius estimation. (3) Considering adding transport negotiation. DoS resistance? [FL] Adding anything complicated right now is not a good idea. Feels wrong to add, say, PoW directly into protocol. Needs more research. E.g. alternative DHT designs. Use cases. How long to update an ENR? At what point does this begin to break the protocol if it is done too quickly? [FL] The rate you update your ENR doesn't matter. Other nodes will pull your record periodically. [DR] Eth2 protocol is divided into short- and long-lived (shard) committees. [FL] The "let's talk" packet could be useful for this. [SK] Question: the connection between gossipsub and discovery - is there a way to request more peers (in case I don't already have a peer with the capability I need)? [FL] Need to avoid naively just getting peers from peers since it is too easy to attack. Need to ask a lot of nodes to spread risk. Dedicated DHT-based discovery is better for this. [DR] Should advertising shards be in the ENR? [FL] Size was arbitrarily set at 300 bytes. These are constantly exchanged, so need to be small. 64 shards as a bit-field should be fine. Discussion around topic discovery - discv5 is intended not to be Ethereum specific; topic discovery is designed to distinguish nodes you are interested in on the large scale across many applications. [FL] What's available in the ENR currently: basic ones in the spec; the Eth1 eth protocol version; lightclient protocol (LES) placeholder. Nothing Eth2 related. But can be added to. Suggest managing our spec for this wthin the Eth2 spec repo. [MK] is looking into discv5 simulation, in particular subnets. [FL] Would also be good to run on Whiteblock platform across multiple clients. Note that simulating one implementation alone may not be sufficient: there is a lot of emergent behaviour. [Discussion of tools for interop simulation...] [FL] Very close now to releasing DNS discovery as an alternative to DHT. Not required for Eth2, but may be interesting at some point. It's an alternative to discv5 - having multiple ways to find peers adds robustness. [DR] Confirms that any public multi-client testnets will use discv5, not static peering. ## Round-up Should do next call in 2 weeks. There's enough to talk about. Felix is happy to talk to anyone about discv5! ## Chat log highlights From danny to Everyone: 01:03 PM https://github.com/ethereum/eth2.0-pm/issues/106 From Nicolas Liochon to Everyone: 01:06 PM On validator privacy, a proposal made 2 months ago: https://ethresear.ch/t/anonymity-a-zkp-to-remove-the-mapping-ip-address-wallets-public-key-of-a-validator/6049 From Mikerah Quintyne-Collins to Everyone: 01:07 PM On validator privacy, I'm currently planning a series of experiments to see if any off-the-shelf anonymous protocols are sufficient. Also, this post from a while back: https://ethresear.ch/t/considerations-for-network-level-validator-privacy-in-proof-of-stake/6422 From Marin Petrunic to Everyone: 01:11 PM Has anyone defined new api endpoint for obtaining attestation to aggregate? From Raúl Kripalani to Everyone: 01:22 PM https://github.com/libp2p/go-libp2p-pubsub/issues/233 From Me to Everyone: 01:26 PM Proto's heuristic tree aggregation: https://notes.ethereum.org/9Ijj2RkuRiqQYB9NOfY_9Q From Mikhail Kalinin to Everyone: 01:37 PM Initial results with jvm-libp2p simulation: https://docs.google.com/spreadsheets/d/1QvYio6ALnjrEYmsgZMTuK-ktIZzeRbqIOvPrU4b-Cl0/edit?pli=1#gid=0 From Anton Nashatyrev to Everyone: 01:44 PM https://github.com/libp2p/jvm-libp2p/blob/0a77fc2ac9b8d29ecef02858809135b0160c27a0/src/test/kotlin/io/libp2p/simulate/gossip/Simulation1.kt#L89 Here is the main entry to simulator From Belma Gutlić to Everyone: 01:47 PM https://github.com/NodeFactoryIo/js-libp2p-noise From zahary to Everyone: 01:48 PM Our roadmap: https://github.com/status-im/nim-libp2p/issues/10 Dmitry can elaborate From Mikhail Kalinin to Everyone: 01:49 PM jvm-libp2p noise: https://github.com/libp2p/jvm-libp2p/releases/tag/0.2.0 From Raúl Kripalani to Everyone: 01:51 PM https://github.com/libp2p/specs/issues/232 https://github.com/libp2p/specs/pull/227 From danny to Everyone: 01:56 PM https://en.wikipedia.org/wiki/Transport_Layer_Security From danny to Everyone: 02:03 PM https://github.com/ethereum/devp2p/issues/122 From Dmitriy Ryajov to Everyone: 02:31 PM on the topic of simulation, it would be really good to use something like ns3 to run isolated simulations of different subsystems and also to simulate the whole Eth2 network setup so for example, discv5 and gossipsub in isolation, but then building a network simulation of how the whole eth2 network would behave under specific scenarios From Mamy to Everyone: 02:33 PM Jannik’s repo: https://github.com/jannikluhn/sharding-netsim From Raúl Kripalani to Everyone: 02:38 PM Re: testing at scale, we have just added network simulation (latency, network on/off, jitter) to the interplanetary testground. This is what we’re using to perform comparative testing and to validate new IPFS and libp2p releases: https://github.com/ipfs/testground/