update networking spec

This commit is contained in:
protolambda 2021-06-18 02:48:58 +02:00
parent 4b25239617
commit 9e10f58299
No known key found for this signature in database
GPG Key ID: EC89FDBB2B4C7623
1 changed files with 53 additions and 32 deletions

View File

@ -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.