update networking spec
This commit is contained in:
parent
4b25239617
commit
9e10f58299
|
@ -14,7 +14,7 @@
|
||||||
- [Gossip domain](#gossip-domain)
|
- [Gossip domain](#gossip-domain)
|
||||||
- [Topics and messages](#topics-and-messages)
|
- [Topics and messages](#topics-and-messages)
|
||||||
- [Shard blob subnets](#shard-blob-subnets)
|
- [Shard blob subnets](#shard-blob-subnets)
|
||||||
- [`shard_blob_{subnet_id}`](#shard_blob_subnet_id)
|
- [`shard_block_{subnet_id}`](#shard_block_subnet_id)
|
||||||
- [Global topics](#global-topics)
|
- [Global topics](#global-topics)
|
||||||
- [`shard_header`](#shard_header)
|
- [`shard_header`](#shard_header)
|
||||||
- [`shard_proposer_slashing`](#shard_proposer_slashing)
|
- [`shard_proposer_slashing`](#shard_proposer_slashing)
|
||||||
|
@ -34,7 +34,7 @@ The adjustments and additions for Shards are outlined in this document.
|
||||||
|
|
||||||
| Name | Value | Description |
|
| Name | Value | Description |
|
||||||
| ---- | ----- | ----------- |
|
| ---- | ----- | ----------- |
|
||||||
| `SHARD_BLOB_SUBNET_COUNT` | `64` | The number of `shard_blob_{subnet_id}` subnets used in the gossipsub protocol. |
|
| `SHARD_BLOCK_SUBNET_COUNT` | `64` | The number of `shard_block_{subnet_id}` subnets used in the gossipsub protocol. |
|
||||||
|
|
||||||
## Gossip domain
|
## Gossip domain
|
||||||
|
|
||||||
|
@ -44,22 +44,22 @@ Following the same scheme as the [Phase0 gossip topics](../phase0/p2p-interface.
|
||||||
|
|
||||||
| Name | Message Type |
|
| Name | Message Type |
|
||||||
|----------------------------------|---------------------------|
|
|----------------------------------|---------------------------|
|
||||||
| `shard_blob_{subnet_id}` | `SignedShardBlob` |
|
| `shard_block_{subnet_id}` | `SignedShardBlock` |
|
||||||
| `shard_header` | `SignedShardBlobHeader` |
|
| `shard_block_header` | `SignedShardBlockHeader` |
|
||||||
| `shard_proposer_slashing` | `ShardProposerSlashing` |
|
| `shard_proposer_slashing` | `ShardProposerSlashing` |
|
||||||
|
|
||||||
The [DAS network specification](./das-p2p.md) defines additional topics.
|
The [DAS network specification](./das-p2p.md) defines additional topics.
|
||||||
|
|
||||||
#### Shard blob subnets
|
#### Shard block subnets
|
||||||
|
|
||||||
Shard blob subnets are used to propagate shard blobs to subsections of the network.
|
Shard block subnets are used by builders to make their blobs available after selection by shard proposers.
|
||||||
|
|
||||||
##### `shard_blob_{subnet_id}`
|
##### `shard_block_{subnet_id}`
|
||||||
|
|
||||||
Shard block data, in the form of a `SignedShardBlob` is published to the `shard_blob_{subnet_id}` subnets.
|
Shard block data, in the form of a `SignedShardBlock` is published to the `shard_block_{subnet_id}` subnets.
|
||||||
|
|
||||||
```python
|
```python
|
||||||
def compute_subnet_for_shard_blob(state: BeaconState, slot: Slot, shard: Shard) -> uint64:
|
def compute_subnet_for_shard_block(state: BeaconState, slot: Slot, shard: Shard) -> uint64:
|
||||||
"""
|
"""
|
||||||
Compute the correct subnet for a shard blob publication.
|
Compute the correct subnet for a shard blob publication.
|
||||||
Note, this mimics compute_subnet_for_attestation().
|
Note, this mimics compute_subnet_for_attestation().
|
||||||
|
@ -69,11 +69,19 @@ def compute_subnet_for_shard_blob(state: BeaconState, slot: Slot, shard: Shard)
|
||||||
slots_since_epoch_start = Slot(slot % SLOTS_PER_EPOCH)
|
slots_since_epoch_start = Slot(slot % SLOTS_PER_EPOCH)
|
||||||
committees_since_epoch_start = committees_per_slot * slots_since_epoch_start
|
committees_since_epoch_start = committees_per_slot * slots_since_epoch_start
|
||||||
|
|
||||||
return uint64((committees_since_epoch_start + committee_index) % SHARD_BLOB_SUBNET_COUNT)
|
return uint64((committees_since_epoch_start + committee_index) % SHARD_BLOCK_SUBNET_COUNT)
|
||||||
```
|
```
|
||||||
|
|
||||||
The following validations MUST pass before forwarding the `signed_blob` (with inner `message` as `blob`) on the horizontal subnet or creating samples for it.
|
The following validations MUST pass before forwarding the `signed_block` on the horizontal subnet or creating samples for it.
|
||||||
- _[IGNORE]_ The `blob` is not from a future slot (with a `MAXIMUM_GOSSIP_CLOCK_DISPARITY` allowance) --
|
|
||||||
|
We define some aliases to the nested contents of `signed_block`:
|
||||||
|
```python
|
||||||
|
block: ShardBlock = signed_block.message
|
||||||
|
signed_blob: SignedShardBlob = block.signed_blob
|
||||||
|
blob: ShardBlob = signed_blob.message
|
||||||
|
```
|
||||||
|
|
||||||
|
- _[IGNORE]_ The `block` is not from a future slot (with a `MAXIMUM_GOSSIP_CLOCK_DISPARITY` allowance) --
|
||||||
i.e. validate that `blob.slot <= current_slot`
|
i.e. validate that `blob.slot <= current_slot`
|
||||||
(a client MAY queue future blobs for processing at the appropriate slot).
|
(a client MAY queue future blobs for processing at the appropriate slot).
|
||||||
- _[IGNORE]_ The `blob` is new enough to be still be processed --
|
- _[IGNORE]_ The `blob` is new enough to be still be processed --
|
||||||
|
@ -81,36 +89,49 @@ The following validations MUST pass before forwarding the `signed_blob` (with in
|
||||||
- _[REJECT]_ The shard should have a committee at slot --
|
- _[REJECT]_ The shard should have a committee at slot --
|
||||||
i.e. validate that `compute_committee_index_from_shard(state, blob.slot, blob.shard)` doesn't raise an error
|
i.e. validate that `compute_committee_index_from_shard(state, blob.slot, blob.shard)` doesn't raise an error
|
||||||
- _[REJECT]_ The shard blob is for the correct subnet --
|
- _[REJECT]_ The shard blob is for the correct subnet --
|
||||||
i.e. `compute_subnet_for_shard_blob(state, blob.slot, blob.shard) == subnet_id`
|
i.e. `compute_subnet_for_shard_block(state, blob.slot, blob.shard) == subnet_id`
|
||||||
- _[IGNORE]_ The blob is the first blob with valid signature received for the `(blob.proposer_index, blob.slot, blob.shard)` combination.
|
- _[IGNORE]_ The block is the first block with valid signature received for the `(block.proposer_index, blob.slot, blob.shard)` combination.
|
||||||
- _[REJECT]_ As already limited by the SSZ list-limit, it is important the blob is well-formatted and not too large.
|
- _[REJECT]_ The blob is not too large, the data MUST NOT be larger than the SSZ list-limit, and a client MAY be more strict.
|
||||||
- _[REJECT]_ The `blob.body.data` MUST NOT contain any point `p >= MODULUS`. Although it is a `uint256`, not the full 256 bit range is valid.
|
- _[REJECT]_ The `blob.body.data` MUST NOT contain any point `p >= MODULUS`. Although it is a `uint256`, not the full 256 bit range is valid.
|
||||||
- _[REJECT]_ The proposer signature, `signed_blob.signature`, is valid with respect to the `proposer_index` pubkey.
|
- _[REJECT]_ The block proposer signature, `signed_block.signature`, is valid with respect to the `proposer_index` pubkey.
|
||||||
- _[REJECT]_ The blob is proposed by the expected `proposer_index` for the blob's slot
|
- _[REJECT]_ The blob builder exists and has sufficient balance to back the fee payment.
|
||||||
|
- _[REJECT]_ The blob builder signature, `signed_blob.signature`, is valid with respect to the `builder_index` pubkey.
|
||||||
|
- _[REJECT]_ The block is proposed by the expected `proposer_index` for the block's slot
|
||||||
in the context of the current shuffling (defined by `blob.body.beacon_block_root`/`slot`).
|
in the context of the current shuffling (defined by `blob.body.beacon_block_root`/`slot`).
|
||||||
If the `proposer_index` cannot immediately be verified against the expected shuffling,
|
If the `proposer_index` cannot immediately be verified against the expected shuffling,
|
||||||
the block MAY be queued for later processing while proposers for the blob's branch are calculated --
|
the block MAY be queued for later processing while proposers for the block's branch are calculated --
|
||||||
in such a case _do not_ `REJECT`, instead `IGNORE` this message.
|
in such a case _do not_ `REJECT`, instead `IGNORE` this message.
|
||||||
|
|
||||||
#### Global topics
|
#### Global topics
|
||||||
|
|
||||||
There are two additional global topics for Sharding, one is used to propagate shard blob headers (`shard_header`) to
|
There are two additional global topics for Sharding.
|
||||||
all nodes on the network. Another one is used to propagate validator message (`shard_proposer_slashing`).
|
|
||||||
|
|
||||||
##### `shard_header`
|
One is used to propagate shard block headers (`shard_block_header`) to all nodes on the network.
|
||||||
|
Another one is used to propagate shard proposer slashings (`shard_proposer_slashing`).
|
||||||
|
|
||||||
Shard header data, in the form of a `SignedShardBlobHeader` is published to the global `shard_header` subnet.
|
##### `shard_block_header`
|
||||||
|
|
||||||
The following validations MUST pass before forwarding the `signed_shard_blob_header` (with inner `message` as `header`) on the network.
|
Shard header data, in the form of a `SignedShardBlockHeader` is published to the global `shard_block_header` subnet.
|
||||||
- _[IGNORE]_ The `header` is not from a future slot (with a `MAXIMUM_GOSSIP_CLOCK_DISPARITY` allowance) --
|
Shard block headers select shard blob bids by builders, and should be timely to ensure builders can publish the full shard block timely.
|
||||||
i.e. validate that `header.slot <= current_slot`
|
|
||||||
|
The following validations MUST pass before forwarding the `signed_block_header` (with inner `message` as `header`) on the network.
|
||||||
|
|
||||||
|
We define some aliases to the nested contents of `signed_block_header`:
|
||||||
|
```python
|
||||||
|
block_header: ShardBlockHeader = signed_block_header.message
|
||||||
|
signed_blob_header: SignedShardBlobHeader = header.signed_blob_header
|
||||||
|
blob_header: ShardBlobHeader = signed_blob_header.message
|
||||||
|
```
|
||||||
|
|
||||||
|
- _[IGNORE]_ The header is not from a future slot (with a `MAXIMUM_GOSSIP_CLOCK_DISPARITY` allowance) --
|
||||||
|
i.e. validate that `blob_header.slot <= current_slot`
|
||||||
(a client MAY queue future headers for processing at the appropriate slot).
|
(a client MAY queue future headers for processing at the appropriate slot).
|
||||||
- _[IGNORE]_ The `header` is new enough to be still be processed --
|
- _[IGNORE]_ The header is new enough to be still be processed --
|
||||||
i.e. validate that `compute_epoch_at_slot(header.slot) >= get_previous_epoch(state)`
|
i.e. validate that `compute_epoch_at_slot(blob_header.slot) >= get_previous_epoch(state)`
|
||||||
- _[IGNORE]_ The header is the first header with valid signature received for the `(header.proposer_index, header.slot, header.shard)` combination.
|
- _[IGNORE]_ The header is the first header with valid signature received for the `(block_header.proposer_index, blob_header.slot, blob_header.shard)` combination.
|
||||||
- _[REJECT]_ The shard should have a committee at slot --
|
- _[REJECT]_ The `shard` MUST have a committee at the `slot` --
|
||||||
i.e. validate that `compute_committee_index_from_shard(state, header.slot, header.shard)` doesn't raise an error
|
i.e. validate that `compute_committee_index_from_shard(state, blob_header.slot, blob_header.shard)` doesn't raise an error
|
||||||
- _[REJECT]_ The proposer signature, `signed_shard_blob_header.signature`, is valid with respect to the `proposer_index` pubkey.
|
- _[REJECT]_ The proposer signature, `signed_shard_block_header.signature`, is valid with respect to the `block_header.proposer_index` pubkey.
|
||||||
- _[REJECT]_ The header is proposed by the expected `proposer_index` for the block's slot
|
- _[REJECT]_ The header is proposed by the expected `proposer_index` for the block's slot
|
||||||
in the context of the current shuffling (defined by `header.body_summary.beacon_block_root`/`slot`).
|
in the context of the current shuffling (defined by `header.body_summary.beacon_block_root`/`slot`).
|
||||||
If the `proposer_index` cannot immediately be verified against the expected shuffling,
|
If the `proposer_index` cannot immediately be verified against the expected shuffling,
|
||||||
|
@ -124,6 +145,6 @@ Shard proposer slashings, in the form of `ShardProposerSlashing`, are published
|
||||||
|
|
||||||
The following validations MUST pass before forwarding the `shard_proposer_slashing` on to the network.
|
The following validations MUST pass before forwarding the `shard_proposer_slashing` on to the network.
|
||||||
- _[IGNORE]_ The shard proposer slashing is the first valid shard proposer slashing received
|
- _[IGNORE]_ The shard proposer slashing is the first valid shard proposer slashing received
|
||||||
for the proposer with index `proposer_slashing.signed_header_1.message.proposer_index`.
|
for the proposer with index `proposer_slashing.signed_reference_1.message.proposer_index`.
|
||||||
The `slot` and `shard` are ignored, there are no per-shard slashings.
|
The `slot` and `shard` are ignored, there are no per-shard slashings.
|
||||||
- _[REJECT]_ All of the conditions within `process_shard_proposer_slashing` pass validation.
|
- _[REJECT]_ All of the conditions within `process_shard_proposer_slashing` pass validation.
|
||||||
|
|
Loading…
Reference in New Issue