Eth2 Networking Call 2

[djrtwo]

Call 1

Meeting Date/Time:

Meeting Date/Time: Wednesday 2020/1/29 at 13:00 GMT

Meeting Duration:

1.25 hours

Agenda

1. Opening
2. Updates
   • libp2p from raul
   • discv5 questions, etc with felix
   • Practical issues/hurdles in testnets such as:
     • Sync
     • Attestation aggregation and/or subnets
     • Discovery
   • https://eth2stats.io 🔥 -- any other network monitoring tools in the works?
   • Status of Noise implementations/integrations
3. Spec items
4. Discussion of items that are under-{researched, tested, resourced}
5. Open discussion
6. Closing remarks and plans for next call or other organizational items

[protolambda]

Research related; I am discussing gossipsub and some special propagation behaviors with some folks from Protocol Labs. The goal is to at least reduce the "naive aggregation" technique to a lower upper bound. This could be done by tracking what messages peers have, and not sending subsets of that information. And then send aggregates whenever there are filled subtrees worth of information, instead of sending the individual attestations.

Monitoring related: pyspec types and code are being packaged, and now I am looking into general eth2 monitoring with Dash and Plotly. This is also looking like a nice framework to build network monitor things with in the future.

Spec related:

• Discuss restricting old attestations and blocks from gossip. Also has an interesting relation to fork choice.
• Round of opinions on having proposer index in blocks or not. Having it means that it still needs to be validated, but there are some benefits, and it is up for discussion in the ongoing audit. What do sync/gossip implementers think?

[ericsson49]

I have been working on Clock Synchronization for awhile, which is an example of under-researched topic, in my opinion. And have written a couple of writeups to the moment, which I'm ready to present to others. I'm also working on somewhat higher level topic "Time Considerations of Ethereum 2.0", which includes other problems besides synchronization with the world time standard.

• General thoughts, why clock sync is important. https://hackmd.io/X-uvqwe8TkmR-CJqMdfn6Q
• an issue about NTP-level Sybil-like attack https://github.com/ethereum/eth2.0-specs/issues/1592
• a draft proposal how to solve it https://hackmd.io/GnJ_Cf4FSZW-BZImH8KF1w

[Mikerah]

I won't be on this week's call as I have a few deadlines for submissions approaching.

As for work on validator privacy, the testnets are currently on hold as I am resource constrained. If there's anyone who wants to take this up, I would be willing to help, mentor and provide the scoped out details of what I had planned to do.

Another aspect of validator privacy that I have been working on is threat modelling. As it stands, there isn't an overall threat model of ETH2.0's network (there are some docs here and there that allude to such a model but nothing concrete). In order to assess whether any network-layer validator privacy solution is appropriate, a threat model needs to be determined and any solution needs to be compared against such a model. I'm hoping to have some initial thoughts out on ethresear.ch within the next 2 weeks.

[raulk]

Updates from libp2p, ahead of our call today, on topics that are pertinent to this group:

• gossipsub technical paper, second draft, released: QmXroMferbScqPeFb99xVieDc6bohKBV4VfWYNkxVZnV2k

• gossipsub: currently conceptualising and prototyping peer scoring.

• libp2p noise:

  • spec considered stable: https://github.com/libp2p/specs/tree/master/noise
  • go-libp2p-noise is almost spec-compliant (barring some renames), including XXfallback handshake.
  • Undergoing hardening and comparative testing against SecIO and TLS. See secure-channel testground plan.
  • Protocol Labs has funded NodeFactory to develop js-libp2p-noise.
  • Setting up interoperability tests.
  • Rust not compliant, it was an experimental handshake developed by Parity outside of spec. Needs to be aligned with spec.
  • nim-libp2p, jvm-libp2p, py-libp2p status and spec compliance unknown.

• QUIC:

  • draft-25 released Jan 22nd; it incorporates the result of Google's tests and proposals, and can be considered close to final, at least in terms of protocol changes.
  • quic-go in the process of being updated.
  • now that we're close to final, we expect IPFS to do a big push towards QUIC in the next months.

• multiselect 2.0:

  • unfortunately little progress; the core team has had little capacity to focus on ms2.0, but we expect to do a big push around this in the next weeks because we are very conscious of the downstream ETH2 dependency.
  • for the purposes of ETH2, I consider ms2.0 an optimisation, reducing connection establishment down from 3.5 RTT to 1.5 RTT. For a stable topology, the gains are low.
  • in terms of stream-wise protocol selection, until RPC messages are versioned (i.e. multiple backing protocols IDs), the gains of ms2.0 won't be very visible, as implementations optimistically pipeline protocol selection with the actual payload, if there's only one protocol possible for a stream. Therefore, the cost of protocol selection is amortised in this case.

• working with @protolambda to evaluate changes for selective message propagation/gossip.

[ericsson49]

I've started to work on a kind of a threat model too, to analyze overall beacon chain protocol, including any subprotocols and services (like p2p, clock sync, topic disovery) and attacks against the overall beacon chain protocol. In my cases it's more about Byzantine faults then about privacy. But privacy is important too (I believe they can be use to tolerate some kinds of Byzantine faults, like two-faced clocks and similar).

Such a threat model is also an under-researched topic in my opinion. It's a significant part of my network-level research.

[benjaminion]

My notes from the call.