Networking spec starts here…

This document contains the consensus-layer networking specification for ePBS.

The specification of these changes continues in the same format as the network specifications of previous upgrades, and assumes them as pre-requisite.

Table of contents

The gossip domain: gossipsub

Some gossip meshes are upgraded in the fork of ePBS to support upgraded types.

Topics and messages

Topics follow the same specification as in prior upgrades.

The beacon_block topic is modified to also support block with bid and new topics are added per table below.

The derivation of the message-id remains stable.

The new topics along with the type of the data field of a gossipsub message are given in this table:

Name	Message Type
builder_bid	SignedBuilderBid
execution_payload	ExecutionPayload
execution_attestation	ExecutionAttestation [New in ePBS]

Global topics

ePBS introduces new global topics for blob sidecars.

beacon_block

The type of the payload of this topic changes to the (modified) SignedBeaconBlockWithBid found in ePBS spec. Specifically, this type changes with the replacement of SignedBuilderBid to the inner BeaconBlockBody.

In addition to the gossip validations for this topic from prior specifications, the following validations MUST pass before forwarding the signed_beacon_block on the network. Alias block = signed_beacon_block.message, signed_bid = block.body.signed_builder_bid, bid = signed_bid.message, header = bid.header.

New validation:

• [REJECT] The block's execution header timestamp is correct with respect to the slot – i.e. header.timestamp == compute_timestamp_at_slot(state, block.slot).
• [REJECT] The bid pubkey is a valid builder in state.
• [REJECT] The builder has sufficient balances to pay for the bid.
• [REJECT] The builder signature, signed_bid.signature, is valid with respect to the bid.pubkey.

execution_payload

This topic is used to propagate execution payload.

The following validations MUST pass before forwarding the execution_payload on the network, assuming the alias payload = execution_payload:

• [IGNORE] The hash tree root of the payload matches the hash tree root of a payload header received previously on the beacon_block topic

execution_attestation

This topic is used to propagate signed execution attestation.

The following validations MUST pass before forwarding the execution_attestation on the network, assuming the alias data = execution_attestation.data:

• [IGNORE] data.slot is within the last ATTESTATION_PROPAGATION_SLOT_RANGE slots (within a MAXIMUM_GOSSIP_CLOCK_DISPARITY allowance) – i.e. data.slot + ATTESTATION_PROPAGATION_SLOT_RANGE >= current_slot >= data.slot (a client MAY queue future attestations for processing at the appropriate slot).
• [REJECT] The validator index is within the execution committee in get_execution_committee(state, data.slot)
• [IGNORE] The execution payload being voted for (data.execution_hash) has been seen (via both gossip and non-gossip sources) (a client MAY queue execution attestations for processing once payload is retrieved).
• [REJECT] The signature of execution_attestation is valid.

builder_bid

This topic is used to propagate signed builder bids.

The following validations MUST pass before forwarding the signed_builder_bid on the network, assuming the alias bid = signed_builder_bid.message:

• [REJECT] The signed builder bid pubkey, bid.pubkey, exists in state.
• [IGNORE] The signed builder bid value, bid.value, is less than builder's balance in state.
• [IGNORE] The signed builder header timestamp is correct with respect to next slot – i.e. header.timestamp == compute_timestamp_at_slot(state, current_slot + 1).
• [IGNORE] The signed builder header parent block matches one of the chain tip(s) in the fork choice store. Builder may submit multiple bids corresponding to various forks.
• [REJECT] The builder signature, signed_bid.signature, is valid with respect to the bid.pubkey.

Transitioning the gossip

See gossip transition details found in the Altair document for
details on how to handle transitioning gossip topics for this upgrade.

The Req/Resp domain

Messages

ExecutionPayloadByHash v1

Protocol ID: /eth2/beacon_chain/req/execution_payload_by_hash/1/

The <context-bytes> field is calculated as context = compute_fork_digest(fork_version, genesis_validators_root):

fork_version	Chunk SSZ type
EPBS_FORK_VERSION	epbs.EXECUTION_PAYLOAD

Request Content:

(
  List[HASH, MAX_REQUEST_PAYLOAD]
)

Response Content:

(
  List[EXECUTION_PAYLOAD, MAX_REQUEST_PAYLOAD]
)

Design decision rationale

TODO: Add

---

Validator spec starts here…

ePBS – Honest Validator

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

Introduction

This document represents the changes to be made in the code of an "honest validator" to implement ePBS.

Prerequisites

This document is an extension of the Deneb – Honest Validator guide.
All behaviors and definitions defined in this document, and documents it extends, carry over unless explicitly noted or overridden.

All terminology, constants, functions, and protocol mechanics defined in the updated Beacon Chain doc of ePBS. are requisite for this document and used throughout.
Please see related Beacon Chain doc before continuing and use them as a reference throughout.

Beacon chain responsibilities

All validator responsibilities remain unchanged other than those noted below. Namely, proposer normal block production switched to using SignedBeaconBlockWithBid and attester with an additional duty to submit ExecutionAttestation

Block proposal

Constructing the BeaconBlockBody

To obtain an signed builder bid, a block proposer building a block on top of a state must take the following actions:

• Listen to the builder_bid gossip subnet
• Filter the bids where where bid.header.parent_hash matches head.payload.block_hash
• Select the best bid (the one with the highest value) and set body.bid = signed_builder_bid

Consensus attesting reminds unchanged

Consensus attestation aggregation reminds unchanged

Payload timeliness attestation

Some validators are selected to submit payload timeliness attestation. The committee, assigned index, and assigned slot for which the validator performs this role during an epoch are defined by get_execution_committee(state, slot).

A validator should create and broadcast the execution_attestation to the global execution attestation subnet at SECONDS_PER_SLOT * 3 / INTERVALS_PER_SLOT seconds after the start of slot

Construct payload timeliness attestation

Next, the validator creates signed_execution_attestation

• Set execution_attestation.slot = slot where slot is the assigned slot.
• Set execution_attestation.block_hash = block_hash where block_hash is the block hash seen from the block builder reveal at SECONDS_PER_SLOT * 2 / INTERVALS_PER_SLOT
• Set execution_attestation.validator_index = validator_index where validator_index is the validator chosen to submit. The private key mapping to state.validators[validator_index].pubkey is used to sign the payload timeliness attestation.
• Set signed_execution_attestation = SignedExecution(message=execution_attestation, signature=execution_attestation_signature), where execution_attestation_signature is obtained from:

def get_execution_attestation_signature(state: BeaconState, attestation: ExecutionAttestation, privkey: int) -> BLSSignature:
    domain = get_domain(state, DOMAIN_PAYLOAD_TIMELINESS_COMMITTEE, compute_epoch_at_slot(attestation.slot))
    signing_root = compute_signing_root(attestation, domain)
    return bls.Sign(privkey, signing_root)

Broadcast execution attestation

Finally, the validator broadcasts signed_execution_attestation to the global execution_attestation pubsub topic.