eth2.0-specs/specs/sharding/p2p-interface.md

Ethereum 2.0 Sharding -- Network specification

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

Table of contents

• Introduction
• Constants
  • Misc
• Gossip domain
  • Topics and messages
    • Shard blob subnets
      • shard_blob_{subnet_id}
    • Global topics
      • shard_blob_header
      • shard_blob_tx
      • shard_proposer_slashing

Introduction

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

Constants

Misc

Name	Value	Description
SHARD_BLOB_SUBNET_COUNT	64	The number of shard_blob_{subnet_id} subnets used in the gossipsub protocol.

Gossip domain

Topics and messages

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

Name	Message Type
shard_blob_{subnet_id}	SignedShardBlob
shard_blob_header	SignedShardBlobHeader
shard_blob_tx	SignedShardBlobHeader
shard_proposer_slashing	ShardProposerSlashing

The DAS network specification defines additional topics.

Shard blob subnets

Shard blob subnets are used by builders to make their blobs available after selection by shard proposers.

shard_blob_{subnet_id}

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

def compute_subnet_for_shard_blob(state: BeaconState, slot: Slot, shard: Shard) -> uint64:
    """
    Compute the correct subnet for a shard blob publication.
    Note, this mimics compute_subnet_for_attestation().
    """
    committee_index = compute_committee_index_from_shard(state, slot, shard)
    committees_per_slot = get_committee_count_per_slot(state, compute_epoch_at_slot(slot))
    slots_since_epoch_start = Slot(slot % SLOTS_PER_EPOCH)
    committees_since_epoch_start = committees_per_slot * slots_since_epoch_start

    return uint64((committees_since_epoch_start + committee_index) % SHARD_BLOB_SUBNET_COUNT)

The following validations MUST pass before forwarding the signed_blob, on the horizontal subnet or creating samples for it. Alias blob = signed_blob.message.

• [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 still be processed -- i.e. validate that compute_epoch_at_slot(blob.slot) >= get_previous_epoch(state)
• [REJECT] The shard blob is for an active shard -- i.e. blob.shard < get_active_shard_count(state, compute_epoch_at_slot(blob.slot))
• [REJECT] The blob.shard MUST have a committee at the blob.slot -- 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 -- i.e. compute_subnet_for_shard_blob(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.
• [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 builder exists and has sufficient balance to back the fee payment.
• [REJECT] The blob signature is valid for the aggregate of proposer and builder, signed_blob.signature, i.e. bls.FastAggregateVerify([builder_pubkey, proposer_pubkey], blob_signing_root, signed_blob.signature).
• [REJECT] The blob is proposed by the expected proposer_index for the blob's slot and shard, 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, the blob 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.

Global topics

There are three additional global topics for Sharding.

• shard_blob_header: co-signed headers, to be included on-chain, and signaling builders to publish full data.
• shard_blob_tx: builder-signed headers, also known as "data transaction".
• shard_proposer_slashing: slashings of duplicate shard proposals

shard_blob_header

Shard header data, in the form of a SignedShardBlobHeader is published to the global shard_blob_header subnet. Shard blob headers select shard blob bids by builders, and should be timely to ensure builders can publish the full shard blob before subsequent attestations.

The following validations MUST pass before forwarding the signed_blob_header on the network. Alias header = signed_blob_header.message

• [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 still be processed -- i.e. validate that compute_epoch_at_slot(header.slot) >= get_previous_epoch(state)
• [REJECT] The shard header is for an active shard -- i.e. header.shard < get_active_shard_count(state, compute_epoch_at_slot(header.slot))
• [REJECT] The header.shard MUST have a committee at the header.slot -- i.e. validate that compute_committee_index_from_shard(state, header.slot, header.shard) doesn't raise an error
• [IGNORE] The header is the first header with valid signature received for the (header.proposer_index, header.slot, header.shard) combination.
• [REJECT] The blob builder exists and has sufficient balance to back the fee payment.
• [REJECT] The header signature is valid for the aggregate of proposer and builder, signed_blob_header.signature, i.e. bls.FastAggregateVerify([builder_pubkey, proposer_pubkey], blob_signing_root, signed_blob_header.signature).
• [REJECT] The header is proposed by the expected proposer_index for the blob's header.slot and header.shard 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, the blob 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_blob_tx

Shard data-transactions, in the form of a SignedShardBlobHeader is published to the global shard_blob_tx subnet. These shard blob headers are signed solely by the blob-builder.

The following validations MUST pass before forwarding the signed_blob_header on the network. Alias header = signed_blob_header.message

• [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 still be processed -- i.e. validate that compute_epoch_at_slot(header.slot) >= get_previous_epoch(state)
• [REJECT] The shard header is for an active shard -- i.e. header.shard < get_active_shard_count(state, compute_epoch_at_slot(header.slot))
• [REJECT] The header.shard MUST have a committee at the header.slot -- i.e. validate that compute_committee_index_from_shard(state, header.slot, header.shard) doesn't raise an error
• [IGNORE] The header is the first header with valid signature received for the (header.builder_index, header.slot, header.shard) combination.
• [REJECT] The blob builder exists and has sufficient balance to back the fee payment.
• [IGNORE] The header fee SHOULD be higher than previously seen headers for (header.slot, header.shard), from any builder. Propagating nodes MAY increase fee increments in case of spam.
• [REJECT] The header signature is valid for ONLY the builder, signed_blob_header.signature, i.e. bls.Verify(builder_pubkey, blob_signing_root, signed_blob_header.signature). The signature is not an aggregate with the proposer.
• [REJECT] The header is designated for proposal by the expected proposer_index for the blob's header.slot and header.shard 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, the blob 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_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.proposer_index. The proposer_slashing.slot and proposer_slashing.shard are ignored, there are no repeated or per-shard slashings.
• [REJECT] All of the conditions within process_shard_proposer_slashing pass validation.