2019-12-04 Eth2 Networking Call #0

2019-12-04 Eth2 Networking Call 0.txt

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