P2P Architecture for Lodestar

[Mikerah]

Before opening up a PR for this, I am laying out a proposed architecture for the P2P networking stuff for Lodestar.

Recommended Reading

• High level overview of networking in ETH2.0 by yours truly
• Gossipsub specification
• Proposed ETH2.0 Phase 0 Wire Protocol by Matt Slipper
• Proposed Node services by @wemeetagain

High Level Overview of expected behavior

When a node runs the Lodestar client, the node should act as a host so that other peers in the network can connect to it. These connections can potentially be reused by taking advantage of libp2p's various stream multiplexing libraries. Every node needs to generate its own private/public key pair in order to identify itself in the network. A node needs to be able to handle incoming data streams (AKA messages) in order to process the messages according to the beacon chain protocol. Once the required processing is done, nodes need to propagate messages to other nodes in the network and store any necessary info required for future processing.

P2P stack

The proposed P2P stack is based on the current ideas around networking in ETH2.0 and is subject to change. Currently, it consists of

• Kademlia DHT for peer discovery using UDP
• TCP messaging for all other peer-to-peer messaging
• Bootstrapping for discovery (However, for local testnets, we will be using multicastDNS)
• Gossipsub for message propagation

There are other aspects of the P2P stack that are still undecided:

• Which encryption protocol to use (might need to use secio as TLS 1.3 is currently being spec'd out in libp2p and doesn't have a js implementation)
• Whether to use stream multiplexing (I think we should)

Structure

/p2p - Will contain all of the p2p related code

• server.js - Will contain the p2p service as described by @wemeetagain
• libp2pNode.js - Will define our own libp2p bundle with the required components. Will also be able to create nodes.
• utils.js - Will contain any utility that we need for handling peers,etc
• config.json - Contains all the configuration for our libp2p bundle

It is expected that some p2p functionality will be used by other components and coded into other components directly.

Note about Typescript

We will be needing typescript bindings for p2p communication. We have yet to make a decision about how to go about this. There are several suggestions here.

Since there are a lot of unsolved questions regarding networking in ETH2.0, this is all that I have unfortunately. I can definitely add more details to this issue as I get more feedback.

Any actionable feedback is highly needed. What is unclear/underspecified? What have I left out? Also, it is expected that this issue overlaps with @wemeetagain's work with services.

[wemeetagain]

Related to

It is expected that some p2p functionality will be used by other components and coded into other components directly.

I would take a look at how prysm structures their p2p service and their sync service for some inspiration on how the p2p service could interplay with the rest of the system.

In their conception, the p2p service handles managing the gossipsub and dht machinery: fully configuring them, starting and stopping them.
It then provides some sort of api to listen for certain incoming messages / subscribe to a topic, broadcast messages, or send messages to a specific peer.

The sync service, depending on the sync "strategy" (initial sync vs regular sync), uses the p2p service to subscribe/unsubscribe to various p2p topics/feeds/events, uses the chain service to subscribe to various local chain updates, and relays the necessary data from one to the other.

I think we could follow a similar strategy.

[Mikerah]

After a call with the other eth2.0 teams around networking and the wire protocol, as an interim solution, we will be implementing the hobbits wire protocol and opening up a tcp socket at port 9000 in order to enable cross-client communication. WhiteBlock will be providing a set of peers to connect to.

Another thing that was brought up during the call was testing devp2p. Since all eth1.0 clients have an implementation of devp2p, we should be able to use it as an interim solution as well. The Nimbus team has tested using both a libp2p daemon and their nim implementation of devp2p. I think it might be worthwhile to test devp2p as well.

We will still be using libp2p but in order to get more realistic testing done, we need some simple networking stack. This is when a lot of bugs will come out and will make Lodestar a better client.

[GregTheGreek]

Is this relevant?

[wemeetagain]

I think its resolved