-
Notifications
You must be signed in to change notification settings - Fork 933
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 spec for data propagation #975
Changes from 1 commit
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,59 @@ | ||
ETH 2.0 Networking Spec - Data Propagation | ||
=== | ||
|
||
# Abstract | ||
|
||
This specification describes how data will be propagated ("gossiped") on the network among Ethereum 2.0 nodes. | ||
|
||
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL”, NOT", “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. | ||
|
||
# Dependencies | ||
|
||
This specification assumes familiarity with the [RPC Interface](./rpc-interface.md) and [Beacon Chain](../core/0_beacon-chain.md) specifications. | ||
|
||
# Specification | ||
|
||
## Pubsub | ||
|
||
Ethereum 2.0 uses a publish/subscribe ("pubsub") construction to propagate information throughout the network. In pubsub applications, nodes tag the messages they send with a topic. Only the nodes interested in that topic will process the message. This allows nodes to decide for themselves which information they are interested in. | ||
|
||
There are a variety of network-based pubsub implementations available. `libp2p` includes three: `floodsub`, `gossipsub`, and most recently `EpiSub`. `gossipsub` is currently the most likely implementation to be adopted as the official standard, however this may change as a result of performance testing. Given these conditions, **this specification makes no assumptions about the underlying pubsub implementation.** | ||
|
||
## Shard Subnets | ||
|
||
Topics involving single shards are mapped to "subnets." A shard's subnet is calculating by calculating `shard_number % SHARD_SUBNET_COUNT`. Grouping shards into subnets as described confers the following benefits: | ||
|
||
- Shards using smaller amounts network traffic are grouped with shards with more network traffic, thus increasing the stability of the network by reducing the likelihood that less-used shareds will be eclipsed. | ||
mslipper marked this conversation as resolved.
Show resolved
Hide resolved
|
||
- The existence of the `SHARD_SUBNET_COUNT` creates a quality-of-service parameter that we can tweak to ensure the health over the network. | ||
|
||
We expect that over time `SHARD_SUBNET_COUNT` will be increased to equal the total number of shards. | ||
|
||
## Encoding | ||
|
||
Messages are serialized using SSZ unless otherwise noted. | ||
|
||
## | ||
mslipper marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
## Propagated Data | ||
|
||
### Beacon Blocks | ||
|
||
**Topic:** `beacon/blocks` | ||
|
||
**Body:** | ||
|
||
``` | ||
( | ||
block_root: HashTreeRoot | ||
) | ||
``` | ||
|
||
Notifies interested nodes that a new beacon block has been created. Nodes are expected to use one of the RPC APIs (Method ID `12`, for example) to fill out the block header and block body. | ||
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. Gossiping of full blocks is the current expected behavior rather than multiple rounds of comms via RPC 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. Roger, will update. |
||
|
||
### Attestations | ||
|
||
**Topic:** `attestations/${subnet}` | ||
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 do you think about having |
||
|
||
**Body:** SSZ-serialized `Attestation` object. Note that the `Attestation` is not included in a container, and is passed over the wire directly. | ||
|
||
Notifies interested nodes that a new Attestation has been created. |
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.
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.
Does the shard grouping here mean, shards with the same
shard_id % SHARD_SUBNET_COUNT
are "grouped" together?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.
yeah, just a way to batch shards into "subnets" in the case that there would be too few nodes in a subnet if we do the natural thing -- one subnet per shard.
so you can imagine there are
SHARD_COUNT
shards, where each has a unique number from0..SHARD_COUNT
called theshard_id
. here we introduce asubnet_id
-- if you are curious about a particular shardS
you can computeS % SHARD_SUBNET_COUNT
to get thesubnet_id