-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add initial libp2p standardization #935
Changes from 2 commits
22d4496
b83a7c4
bbca108
7818183
c7fea5f
c33bdfd
bff71b6
3c87754
feb3b5e
ae6d30f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,123 @@ | ||
ETH 2.0 Networking Spec - Libp2p standard protocols | ||
=== | ||
|
||
# Abstract | ||
|
||
Ethereum 2.0 clients plan to use the libp2p protocol networking stack for | ||
mainnet release. This document aims to standardize the libp2p client protocols, | ||
configuration and messaging formats. | ||
|
||
# Libp2p Protocols | ||
|
||
## Gossipsub | ||
|
||
#### Protocol id: `/meshsub/1.0.0` | ||
|
||
*Note: Parameters listed here are subject to a large-scale network feasibility | ||
study* | ||
|
||
The [Gossipsub](https://github.com/libp2p/specs/tree/master/pubsub/gossipsub) | ||
protocol will be used for block and attestation propagation across the | ||
network. | ||
|
||
### Configuration Parameters | ||
|
||
Gossipsub has a number of internal configuration parameters which directly | ||
effect the network performance. Clients can implement independently, however | ||
we aim to standardize these across clients to optimize the gossip network for | ||
propagation times and message duplication. Current network-related defaults are: | ||
|
||
``` | ||
( | ||
// The target number of peers in the overlay mesh network (D in the libp2p specs). | ||
mesh_size: 6 | ||
// The minimum number of peers in the mesh network before adding more (D_lo in the libp2p specs). | ||
mesh_lo: 4 | ||
// The maximum number of peers in the mesh network before removing some (D_high in the libp2p sepcs). | ||
mesh_high: 12 | ||
// The number of peers to gossip to during a heartbeat (D_lazy in the libp2p sepcs). | ||
gossip_lazy: 6 // defaults to `mesh_size` | ||
// Time to live for fanout peers (seconds). | ||
fanout_ttl: 60 | ||
// The number of heartbeats to gossip about. | ||
gossip_history: 3 | ||
// Time between each heartbeat (seconds). | ||
heartbeat_interval: 1 | ||
) | ||
``` | ||
|
||
### Topics | ||
|
||
*The Go and Js implementations use string topics - This is likely to be | ||
updated to topic hashes in later versions - https://github.com/libp2p/rust-libp2p/issues/473* | ||
|
||
For Eth2.0 clients, topics will be sent as `SHA2-256` hashes of the topic string. | ||
|
||
There are two main topics used to propagate attestations and beacon blocks to | ||
all nodes on the network. | ||
|
||
- The `beacon_block` topic - This topic is used solely for propagating new | ||
beacon blocks to all nodes on the networks. | ||
- The `beacon_attestation` topic - This topic is used to for propagate | ||
AgeManning marked this conversation as resolved.
Show resolved
Hide resolved
|
||
aggregated attestations to subscribing nodes (typically block proposers) to | ||
be included into future blocks. Attestations will be aggregated in their | ||
respective subnets before publishing on this topic. | ||
|
||
Shards will be grouped into their own subnets (defined by a shard topic). The | ||
number of shard subnets will be defined via `SHARD_SUBNET_COUNT` and the shard | ||
`shard_number % SHARD_SUBNET_COUNT` will be assigned to the topic: | ||
`shard{shard_number % SHARD_SUBNET_COUNT}`. | ||
AgeManning marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
### Messages | ||
|
||
Messages sent across gossipsub are fixed-size length-prefixed byte arrays. | ||
Each message has a maximum size of 512KB (estimated from expected largest uncompressed | ||
block size). | ||
|
||
The byte array is prefixed with a unsigned 64 bit length number encoded as an | ||
djrtwo marked this conversation as resolved.
Show resolved
Hide resolved
|
||
`unsigned varint` (https://github.com/multiformats/unsigned-varint). Gossipsub messages therefore take the form: | ||
``` | ||
+--------------------------+ | ||
| message length | | ||
+--------------------------+ | ||
| | | ||
| body (<1M) | | ||
| | | ||
+--------------------------+ | ||
``` | ||
|
||
The body of the message is an SSZ-encoded object. For the `beacon_block` topic, | ||
this will be a `beacon_block`. For the `beacon_attestation` topic, this will be | ||
an `attestation`. | ||
AgeManning marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
## Eth-2 RPC | ||
|
||
#### Protocol Id: `/eth/serenity/beacon/rpc/1` | ||
|
||
The [RPC Interface](./rpc-interface.md) is specified in this repository. | ||
|
||
## Identify | ||
|
||
#### Protocol Id: `/ipfs/id/1.0.0` (to be updated to `/p2p/id/1.0.0`) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep so, the protocols that come with libp2p have their own protocol IDs. Currently (to my knowledge) these are hard coded and not customisable. I'd have to make a pr to libp2p or rewrite the protocol to change the naming. (For rust-libp2p). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You should be able to customise all of these protocol IDs. Doing so will segregate your network from the IPFS or libp2p public networks at the protocol level, such that even if peers happen to cross-connect, they will share no protocols in common, and therefore, won't be able to interact via streams. Ideally you'll override the protocol ID as low as in |
||
|
||
The Identify protocol (defined in go - [identify-go](https://github.com/ipfs/go-ipfs/blob/master/core/commands/id.go) and rust [rust-identify](https://github.com/libp2p/rust-libp2p/blob/master/protocols/identify/src/lib.rs)) | ||
allows a node A to query another node B which information B knows about A. This also includes the addresses B is listening on. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What's the relationship to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep, temporary placeholder. This is currently what lighthouse is using in place of a proper discovery protocol. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Let's add an explicit note that this is a placeholder There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm working on discv5 at the moment. Currently, I think this protocol may still be useful for NAT traversal and can be fed into the discv5 protocol. Potentially we don't need it at all. I'll add a placeholder note for now. |
||
|
||
This protocol allows nodes to discover addresses of other nodes to be added to | ||
peer discovery. It further allows nodes to determine the capabilities of all it's connected | ||
peers. | ||
|
||
### Configuration Parameters | ||
|
||
The protocol has two configurable parameters, which can be used to identify the | ||
type of connecting node. Suggested format: | ||
``` | ||
version: `/eth/serenity/1.0.0` | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 👍 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, to my knowledge, this is currently not the case in rust-libp2p. I'll make a PR to make these configurable. |
||
user_agent: <client name and version> | ||
``` | ||
|
||
## Discovery | ||
|
||
#### Protocol Id: `/eth/serenity/disc/1.0.0` | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the current plan for discv5 is to use an independent transport. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, agree. This entire document will be updated with discv5 soon. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I thought there was a plan to implement discv5 as a libp2p protocol? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm currently working on this. My current plan is to mimic mDNS in the integration into libp2p. In this case, there will be no protocol id, but will allow implementations to use the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. it would be nice to have at least the ability to run discv5 over other transports - what would that look like, in this setup? |
||
|
||
The discovery protocol to be determined. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I asked about the topic hash in the issue. It seems not finalized yet, but shouldn't be a big issue.