Eth2 networking call 1

[djrtwo]

Call 0

Meeting Date/Time:

Meeting Date/Time: Wednesday 2019/12/18 at 13:00 GMT

Meeting Duration:

1.25 hours

Agenda

1. Opening
2. Updates
   • Whiteblock overview of gossipsub test results (pre-formal-writeup)
   • Writeup on gossipsub sims from Harmony
   • Initial aggregation model work from proto
   • Status of Noise implementations/integrations
3. Spec items
   • attnets field added to ENR for phase 0
   • content addressed messages for gossipsub
     • ensure clients using native pubsub callback for validation
   • handshake message
   • how often to send status
4. Discussion of items that are under-{researched, tested, resourced} and plan of action
   • validator privacy
     • use of tor/sphinx/onions
     • feasibility of obfuscation through multiple nodes, fake subnet subscriptions, etc
     • use of ZKPs as proof to join privileged subnet but without leaking val id
5. Open discussion
6. Closing remarks and plans for next call or other organizational items

[Mikerah]

On the topic of validator privacy, I started working on this sphinx spec for use in libp2p. It's a current work in progress. The rational, though, is that modern network layer anonymity protocols use this packet format as their foundation. Moreover, it is implemented in many blockchain projects.

[AgeManning]

Discussion about moving to content addressed messages for gossipsub: ethereum/consensus-specs#1528

[mcdee]

A handshake message with some base configuration/state information would be useful, described at ethereum/consensus-specs#1531

[Nashatyrev]

Did a write up on Gossip simulation: https://hackmd.io/ZMBsjqdqSAK026iFFu_2JQ

[protolambda]

https://notes.ethereum.org/@protolambda/Hytd28rAH
^ Put this together as a start for writing the setup / strategy code for a gossip based attestation aggregation model, to see how far we could get with just gossip based aggregation. Going to implement it on top of the Harmony Kotlin simulation code

[arnetheduck]

9:21 AM] arnetheduck: we have one such change lined up: we currently require that block requests send at least one response_chunk - we'll likely be proposing that this requirement be dropped
[9:24 AM] arnetheduck: consider a block range request: it might end up with no blocks because it's slot-based: currently if the request selects an empty range, there's no way to respond "correctly" - it can be resolved either by having no response_chunk or having a special "no data" error code, or potentially including a "null" marker in a "success" chunk. the first option seems the easiest and most consistent.

[benjaminion]

Quick meeting notes here