6.3 KiB

Raw Blame History

Ethereum 2.0 Sharding -- Network specification

Notice: This document is a work-in-progress for researchers and implementers.

Introduction
New containers
Gossip domain
- Topics and messages

Introduction

The specification of these changes continues in the same format as the Phase0 and Altair network specifications, and assumes them as pre-requisite. The adjustments and additions for Shards are outlined in this document.

New containers

ShardBlobBody

class ShardBlobBody(Container):
    # The actual data commitment
    commitment: DataCommitment
    # Proof that the degree < commitment.length
    degree_proof: BLSCommitment
    # The actual data. Should match the commitment and degree proof.
    data: List[BLSPoint, POINTS_PER_SAMPLE * MAX_SAMPLES_PER_BLOCK]

The user MUST always verify the commitments in the body are valid for the data in the body.

ShardBlob

class ShardBlob(Container):
    # Slot and shard that this blob is intended for
    slot: Slot
    shard: Shard
    body: ShardBlobBody
    # Proposer of the shard-blob
    proposer_index: ValidatorIndex

This is the expanded form of the ShardBlobHeader type.

SignedShardBlob

class SignedShardBlob(Container):
    message: ShardBlob
    signature: BLSSignature

Gossip domain

Topics and messages

Following the same scheme as the Phase0 gossip topics, names and payload types are:

Name	Message Type
`shard_blob_{shard}`	`SignedShardBlob`
`shard_header`	`SignedShardHeader`
`shard_proposer_slashing`	`ShardProposerSlashing`

The DAS network specification defines additional topics.

Shard blobs: `shard_blob_{shard}`

Shard block data, in the form of a SignedShardBlob is published to the shard_blob_{shard} subnets.

The following validations MUST pass before forwarding the signed_blob (with inner message as blob) on the horizontal subnet or creating samples for it.

[REJECT] blob.shard MUST match the topic {shard} parameter. (And thus within valid shard index range)
[IGNORE] The blob is not from a future slot (with a MAXIMUM_GOSSIP_CLOCK_DISPARITY allowance) -- i.e. validate that blob.slot <= current_slot (a client MAY queue future blobs for processing at the appropriate slot).
[IGNORE] The blob is new enough to be still be processed -- i.e. validate that compute_epoch_at_slot(blob.slot) >= get_previous_epoch(state)
[IGNORE] The blob is the first blob with valid signature received for the (blob.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.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 blob is proposed by the expected proposer_index for the blob's slot in the context of the current shuffling (defined by parent_root/slot). 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 -- in such a case do not REJECT, instead IGNORE this message.

Shard header: `shard_header`

Shard header data, in the form of a SignedShardBlobHeader is published to the global shard_header subnet.

The following validations MUST pass before forwarding the signed_shard_header (with inner message as header) on the network.

[IGNORE] The header is not from a future slot (with a MAXIMUM_GOSSIP_CLOCK_DISPARITY allowance) -- i.e. validate that header.slot <= current_slot (a client MAY queue future headers for processing at the appropriate slot).
[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)
[IGNORE] The header is the first header with valid signature received for the (header.proposer_index, header.slot, header.shard) combination.
[REJECT] The proposer signature, signed_shard_header.signature, is valid with respect to the proposer_index pubkey.
[REJECT] The header is proposed by the expected proposer_index for the block's slot in the context of the current shuffling (defined by parent_root/slot). If the proposer_index cannot immediately be verified against the expected shuffling, 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.

Shard proposer slashing: `shard_proposer_slashing`

Shard proposer slashings, in the form of ShardProposerSlashing, are published to the global shard_proposer_slashing topic.

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 for the proposer with index proposer_slashing.signed_header_1.message.proposer_index. The slot and shard are ignored, there are no per-shard slashings.
[REJECT] All of the conditions within process_shard_proposer_slashing pass validation.

6.3 KiB Raw Blame History