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](../altair/p2p-interface.md#transitioning-the-gossip) 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)`:

[1]: # (eth2spec: skip)

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