Merge pull request #1534 from ethereum/enr-bitfield
Add ENR shard bitfield
This commit is contained in:
Danny Ryan
GitHub
commit
1f06026bf7
|
|
@ -53,10 +53,10 @@ It consists of four main sections:
|
|||
- [The discovery domain: discv5](#the-discovery-domain-discv5)
|
||||
- [Integration into libp2p stacks](#integration-into-libp2p-stacks)
|
||||
- [ENR structure](#enr-structure)
|
||||
- [Attestation subnet bitfield](#attestation-subnet-bitfield)
|
||||
- [Interop](#interop-5)
|
||||
- [Mainnet](#mainnet-5)
|
||||
- [Topic advertisement](#topic-advertisement)
|
||||
- [Interop](#interop-6)
|
||||
- [Mainnet](#mainnet-6)
|
||||
- [Design decision rationale](#design-decision-rationale)
|
||||
- [Transport](#transport-1)
|
||||
|
|
@ -557,6 +557,14 @@ The Ethereum Node Record (ENR) for an Ethereum 2.0 client MUST contain the follo
|
|||
|
||||
Specifications of these parameters can be found in the [ENR Specification](http://eips.ethereum.org/EIPS/eip-778).
|
||||
|
||||
#### Attestation subnet bitfield
|
||||
|
||||
The ENR MAY contain an entry (`attnets`) signifying the attestation subnet bitfield with the following form to more easily discover peers participating in particular attestation gossip subnets.
|
||||
|
||||
| Key | Value |
|
||||
|:-------------|:-------------------------------------------------|
|
||||
| `attnets` | SSZ `Bitvector[ATTESTATION_SUBNET_COUNT]` |
|
||||
|
||||
#### Interop
|
||||
|
||||
In the interoperability testnet, all peers will support all capabilities defined in this document (gossip, full Req/Resp suite, discovery protocol), therefore the ENR record does not need to carry Eth2 capability information, as it would be superfluous.
|
||||
|
|
@ -569,13 +577,11 @@ On mainnet, ENRs MUST include a structure enumerating the capabilities offered b
|
|||
|
||||
### Topic advertisement
|
||||
|
||||
#### Interop
|
||||
|
||||
This feature will not be used in the interoperability testnet.
|
||||
|
||||
#### Mainnet
|
||||
|
||||
In mainnet, we plan to use discv5’s topic advertisement feature as a rendezvous facility for peers on shards (thus subscribing to the relevant gossipsub topics).
|
||||
discv5's topic advertisement feature is not expected to be ready for mainnet launch of Phase 0.
|
||||
|
||||
Once this feature is built out and stable, we expect to use topic advertisement as a rendezvous facility for peers on shards. Until then, the ENR [attestation subnet bitfield](#attestation-subnet-bitfield) will be used for discovery of peers on particular subnets.
|
||||
|
||||
# Design decision rationale
|
||||
|
||||
|
|
@ -764,9 +770,9 @@ The prohibition of unverified-block-gossiping extends to nodes that cannot verif
|
|||
|
||||
### How are we going to discover peers in a gossipsub topic?
|
||||
|
||||
Via discv5 topics. ENRs should not be used for this purpose, as they store identity, location, and capability information, not volatile [advertisements](#topic-advertisement).
|
||||
In Phase 0, peers for attestation subnets will be found using the `attnets` entry in the ENR.
|
||||
|
||||
In the interoperability testnet, all peers will be subscribed to all global beacon chain topics, so discovering peers in specific shard topics will be unnecessary.
|
||||
Although this method will be sufficient for early phases of Eth2, we aim to use the more appropriate discv5 topics for this and other similar tasks in the future. ENRs should ultimately not be used for this purpose. They are best suited to store identity, location, and capability information, rather than more volatile advertisements.
|
||||
|
||||
## Req/Resp
|
||||
|
||||
|
|
|
|||
|
|
@ -197,8 +197,8 @@ The beacon chain shufflings are designed to provide a minimum of 1 epoch lookahe
|
|||
Specifically a validator should:
|
||||
* Call `get_committee_assignment(state, next_epoch, validator_index)` when checking for next epoch assignments.
|
||||
* Join the pubsub topic -- `committee_index{committee_index % ATTESTATION_SUBNET_COUNT}_beacon_attestation`.
|
||||
* If any current peers are subscribed to the topic, the validator simply sends `subscribe` messages for the new topic.
|
||||
* If no current peers are subscribed to the topic, the validator must discover new peers on this topic. If "topic discovery" is available, use topic discovery to find peers that advertise subscription to the topic. If not, "guess and check" by connecting with a number of random new peers, persisting connections with peers subscribed to the topic and (potentially) dropping the new peers otherwise.
|
||||
* For any current peer subscribed to the topic, the validator simply sends a `subscribe` message for the new topic.
|
||||
* If an _insufficient_ number of current peers are subscribed to the topic, the validator must discover new peers on this topic. Via the discovery protocol, find peers with an ENR containing the `attnets` entry such that `ENR["attnets"][committee_index % ATTESTATION_SUBNET_COUNT] == True`.
|
||||
|
||||
## Beacon chain responsibilities
|
||||
|
||||
|
|
@ -443,7 +443,11 @@ Where
|
|||
|
||||
## Phase 0 attestation subnet stability
|
||||
|
||||
Because Phase 0 does not have shards and thus does not have Shard Committees, there is no stable backbone to the attestation subnets (`committee_index{subnet_id}_beacon_attestation`). To provide this stability, each validator must randomly select and remain subscribed to `RANDOM_SUBNETS_PER_VALIDATOR` attestation subnets. The lifetime of each random subscription should be a random number of epochs between `EPOCHS_PER_RANDOM_SUBNET_SUBSCRIPTION` and `2 * EPOCHS_PER_RANDOM_SUBNET_SUBSCRIPTION]`.
|
||||
Because Phase 0 does not have shards and thus does not have Shard Committees, there is no stable backbone to the attestation subnets (`committee_index{subnet_id}_beacon_attestation`). To provide this stability, each validator must:
|
||||
|
||||
* Randomly select and remain subscribed to `RANDOM_SUBNETS_PER_VALIDATOR` attestation subnets
|
||||
* Maintain advertisement of the randomly selected subnets in their node's ENR `attnets` entry by setting the randomly selected `subnet_id` bits to `True` (e.g. `ENR["attnets"][subnet_id] = True`) for all persistent attestation subnets
|
||||
* Set the lifetime of each random subscription to a random number of epochs between `EPOCHS_PER_RANDOM_SUBNET_SUBSCRIPTION` and `2 * EPOCHS_PER_RANDOM_SUBNET_SUBSCRIPTION]`. At the end of life for a subscription, select a new random subnet, update subnet subscriptions, and publish an updated ENR
|
||||
|
||||
## How to avoid slashing
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue