Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
2019-12-04 Eth2 Networking Call #0
2019-12-04 - Eth2 Networking Call 0
Agenda: https://github.com/ethereum/eth2.0-pm/issues/106
——
Intro:
No one took complete ownership of networking,
—> busy
—> no p2p
—> call to tackle that
Frequency of the call, maybe every 3 weeks
First call: enumerate the problems and take note of the state
Example: validator privacy
——————
1. Aggregation
Did someone fully implement the naive aggregation spec already, feedback on it?
- Artemis
- Trinity, PR (but not tested)
- issue with validators having to recreate attestation if they are not included in the next block
issue due to attestation including crosslinks that fails
Research on sophisticated strategies
- Concerns about Handle as it has to maintain a list of current validators (privacy issue)
- Q of number of aggregates
- Q on finality
- Heuristic tree aggregation: https://notes.ethereum.org/9Ijj2RkuRiqQYB9NOfY_9Q
——————
2. Gossipsub
Rather than benchmarking, would prefer to already have a formalisation
—> academics? papers?
Raoul:
—> Episub: https://github.com/libp2p/go-libp2p-pubsub/issues/233
Q: How do you find peers of certain capabilities?
Bootstrapping by finding a single peer
and then collaborative peer exchange with that peer redirecting you to
peers it knows that subscribe to that topic
(under review)
Filecoin testnet within days
Whiteblock, bench on gossipsub
Daniel Choi
Q on extended message queues
Raul:
- how can a node know that its message is being dropped
- or when a peer is slow
Simulation - Anton
- built on JVM-libp2p
- (?)
- Results
- When honest peers, ~7 intermediate hops for message distribution
- Spreadsheet: https://docs.google.com/spreadsheets/d/1QvYio6ALnjrEYmsgZMTuK-ktIZzeRbqIOvPrU4b-Cl0/edit?pli=1#gid=0
- With 90% of bad peers, messages are not propagated
(bad peer: peer that acts as gossipsub peer but drops all messages)
- Optimization TODO:
- Diminishing traffic overhead
- Increase fault tolerance
- —> write-up + repo + results (already have)
- repo: https://github.com/libp2p/jvm-libp2p/blob/0a77fc2ac9b8d29ecef02858809135b0160c27a0/src/test/kotlin/io/libp2p/simulate/gossip/Simulation1.kt#L89
———————————
3. State of Noise in your language,
Implementing in libp2p?
- Belma, JS implementation in typescript finished yesterday https://github.com/NodeFactoryIo/js-libp2p-noise
- Age, in the process of integrating Noise into Rust-libp2p
- Mikhail, integrated in JVM-libp2p v0.2.0 https://github.com/libp2p/jvm-libp2p/releases/tag/0.2.0
- Hww, Python not started
- Nim, roadmap: https://github.com/status-im/nim-libp2p/issues/10
- libp2p steady progress, not switched yet
- Noise, not yet
Raul: Add your name to the following issue
if you are working on Noise: https://github.com/libp2p/specs/issues/232
—————————————————
Multiselect 2.0
https://github.com/libp2p/specs/pull/227
——————————————————
Snappy, any issue?
——————————————————
TLS 1.3: any production ready implementation you are aware of?
Apparently not https://en.wikipedia.org/wiki/Transport_Layer_Security
—————————————————
Disc v5 - Felix
State: no update to spec for a month
—> seems to be fine except for the 3 issues opened on Github
- hard to audit the security as the spec is not explicit on key management
- currently researching on topic index specifically radius estimation
- considering to add: Transport Pre-negotiation
Q: DOS resistance?
- Adding anything complicated right now is not a good idea
- Wrong time?
- Add something like PoW as optional feature or part of the ENR
https://github.com/ethereum/devp2p/issues/122
Basic idea: Discovery is random walking the DHT
-> the more you can restrict the subset, the less you have to walk
and the less the application layer has to do to test the peer once connected
Shahan: mechanism to ask for more peers?
Long discussion:
- key message: was important to keep discovery separated from the rest of the network stack
- bitfields if we can have 64 shards
- what if other projects (EF1, filesharing) also uses DiscV5 and the DHT has a lot of “uninteresting” node
Simulation on the java side
Note: a lot of emerging behaviours in the system as it’s not point-to-point connections
Specific implementation timings, table maintenance, lookups might skew things
Dmitry: Use ns3 to run isolated simulation
Felix: note that Jannik had sim in Omni++ https://github.com/jannikluhn/sharding-netsim
R, testing at scale: https://github.com/ipfs/testground/
D: Any orchestrated multi client testnet will be using Discv5
—> for starter static list of peers (?)
Next time in 2 weeks
- ZKP
- validator privacy
- discussion on public testnet (?)
https://github.com/ethereum/devp2p/issues/83
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.