Add spec for data propagation #975
Conversation
|
|
||
| ### Attestations | ||
|
|
||
| **Topic:** `attestations/${subnet}` |
There was a problem hiding this comment.
What do you think about having ${subnet}/ as the prefix?
Co-Authored-By: mslipper <me@matthewslipper.com>
| ) | ||
| ``` | ||
|
|
||
| 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.
Gossiping of full blocks is the current expected behavior rather than multiple rounds of comms via RPC
There was a problem hiding this comment.
Roger, will update.
Co-Authored-By: mslipper <me@matthewslipper.com>
|
safe to close @mslipper ? |
|
|
||
| ## 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: |
There was a problem hiding this comment.
| 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: | |
| Topics involving single shards are mapped to "subnets". A shard's subnet is calculated by `shard_number % SHARD_SUBNET_COUNT`. Grouping shards into subnets as described confers the following benefits: |
There was a problem hiding this comment.
Grouping shards into subnets as described confers the following benefits
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.
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 from 0..SHARD_COUNT called the shard_id. here we introduce a subnet_id -- if you are curious about a particular shard S you can compute S % SHARD_SUBNET_COUNT to get the subnet_id
|
|
||
| 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 shards will be eclipsed. |
There was a problem hiding this comment.
Shards using smaller amounts network traffic are grouped with shards with more network traffic
Sorry, could you elaborate more on this? Does it assume smaller amounts networks are always grouped with more the ones with more traffic?
|
|
||
| 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 shards will be eclipsed. |
There was a problem hiding this comment.
yeah, how will this work given that % will produce a uniform distribution b/t namespaces?
|
safe to close @mslipper ? |
|
Safe to close. |
This PR introduces the topics used to propagate data through the ETH 2.0 network. I only included beacon blocks and attestations for now. I've also not made any prescriptions around the specific pubsub implementation we use.