EIP-8025 - Optional Execution Proofs

Created 2025-09-17
Status Draft
Category Core
Type Standards Track
Authors
Requires

Introducing optional execution proofs on the consensus layer

Abstract

Execution proofs enable consensus layer (CL) nodes to perform stateless validation of execution payloads. Altruistic proof-generating nodes generate execution proofs and broadcast them over the CL p2p network. Proof-verifying nodes consume gossiped execution proofs and check payload validity by verifying those proofs. Verification is stateless and constant time with respect to the payload's gas limit and EL state size, so a validator's payload-verification requirements are decoupled from the linear cost of re-execution. The mechanism is fully opt-in and does not change consensus validity rules, allowing the proving stack to mature in production; a separate, future EIP could subsequently propose making execution proofs mandatory once they have matured. This EIP does not introduce incentives for proof-generating nodes; for that reason, they are considered altruistic and the mechanism is opt-in.

Motivation

Today, verifying a beacon block requires re-execution of its execution payload against the execution layer (EL) state — the full set of account and storage trie data. The cost of re-execution scales linearly with the gas limit. This couples a node's resource requirements to the state size and the chain's throughput.

This EIP introduces an opt-in path with the following properties:

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Terminology

This EIP uses the following proof-system terms:

Specification references

The normative specifications for this EIP are maintained alongside the rest of the protocol in the consensus-specs and execution-specs repositories. The sections below summarise the changes; the canonical sources are:

Consensus Layer

This EIP introduces a new execution_proof gossip topic on the consensus-layer p2p network carrying SignedExecutionProof messages, and a ProofEngine interface that beacon nodes use to generate and verify execution proofs. Proof generation and verification are delegated to an external proof node; the ProofEngine is the in-client component that mediates communication with it. A node MAY enable either or both of:

The following diagram summarises how proofs move between the two roles:

Execution-proof flow between proof-generating and proof-verifying nodes via the execution_proof gossip topic

At a high level, the proof lifecycle is:

  1. A prover reacts to a new beacon block, constructs the corresponding NewPayloadRequest, and calls proof_engine.request_proofs(new_payload_request, ProofAttributes(proof_types)) to initiate proof generation for its configured proof_types on the proof node.
  2. The proof node produces an ExecutionProof for each requested type. The prover signs each proof, wraps it in a SignedExecutionProof, and broadcasts it on the execution_proof topic.
  3. Proof-verifying peers receive the gossip message, run the gossip validation rules, then call proof_engine.verify_execution_proof on the inner ExecutionProof to confirm payload validity.

This lifecycle uses the execution-validation window introduced by EIP-7732, which defers execution validation until the next beacon block and provides additional time for proof generation.

Sync support requirement. Independent of the request/produce/verify loop above, every proof-aware node MUST retain valid proofs for canonical-chain blocks back to the finalised checkpoint so that peers syncing or filling gaps can backfill them via ExecutionProofsByRange and ExecutionProofsByRoot (see Req/resp domain for the protocol details).

Proof types and containers

The consensus layer introduces a small set of new types and constants to identify proofs, bound their size, and route gossip signatures:

Name Value
ProofType uint8
MAX_PROOF_SIZE 409600 (= 400 KiB)
MAX_EXECUTION_PROOFS_PER_PAYLOAD uint64(4)
DOMAIN_EXECUTION_PROOF DomainType('0x0D000000')

MAX_PROOF_SIZE is set at 400 KiB as a network-bandwidth budget: at the gossip target of one proof per (payload, proof_type) and the cap of MAX_EXECUTION_PROOFS_PER_PAYLOAD = 4 proof types per payload, the worst-case in-flight proof bandwidth per slot is 4 × 400 KiB = 1.6 MiB — of a similar order to existing per-slot blob-sidecar traffic. This bounds steady-state traffic. Provers using systems that naturally produce larger proofs are expected to apply proof compression (recursion, succinct wrappers) before gossiping.

Peers advertise their supported proof types via ExecutionProofStatus (see Req/resp domain). The set of proof_types a node speaks is a per-node, dynamic configuration; new proof systems can be added by socialising a new ProofType value out-of-band and rolling it out to consenting operators. Proof-system support is local, opt-in configuration and does not change consensus validity rules. Peers discover which proof types overlap during their ExecutionProofStatus handshake and route requests accordingly.

The top-level gossip message is the SignedExecutionProof:

class SignedExecutionProof(Container):
    message: ExecutionProof
    validator_index: ValidatorIndex
    signature: BLSSignature

Its inner ExecutionProof couples a serialised proof blob to the proof system and guest program it was generated against, and to the public input that identifies the payload it certifies:

class ExecutionProof(Container):
    proof_data: ByteList[MAX_PROOF_SIZE]
    proof_type: ProofType
    public_input: PublicInput


class PublicInput(Container):
    new_payload_request_root: Root
    successful_validation: bool
    chain_config: ChainConfig

The fields play the following roles:

Proof engine interface

The ProofEngine interface encapsulates the proof-system-specific logic so that the consensus layer stays agnostic of which proof system is in use. It acts as a payload-validity oracle for the beacon node, and its API shape is modelled on the Engine API to allow for seamless integration into the protocol. The ProofEngine is realised as an in-client component that maintains its own proof state and delegates the cryptographic work of proof generation and verification to an external proof node, mirroring the way the ExecutionEngine delegates payload execution to the EL client. The interface comprises four operations and a ProofAttributes type:

def verify_execution_proof(
    self: ProofEngine,
    execution_proof: ExecutionProof,
) -> bool: ...


def notify_new_payload(
    self: ProofEngine,
    new_payload_request: NewPayloadRequest,
) -> None: ...


def notify_forkchoice_updated(
    self: ProofEngine,
    head_block_hash: Hash32,
    safe_block_hash: Hash32,
    finalized_block_hash: Hash32,
) -> None: ...


@dataclass
class ProofAttributes:
    proof_types: Sequence[ProofType]


def request_proofs(
    self: ProofEngine,
    new_payload_request: NewPayloadRequest,
    proof_attributes: ProofAttributes,
) -> Root: ...

These operations decompose into three concerns:

Beacon-chain state transition

EIP-8025 extends process_block to forward execution payload processing to both the execution engine and the proof engine, and introduces a new process_execution_proof handler for incoming proofs.

process_block is modified to pass PROOF_ENGINE to process_execution_payload:

def process_block(state: BeaconState, block: BeaconBlock) -> None:
    process_block_header(state, block)
    process_withdrawals(state, block.body.execution_payload)
    # [Modified in EIP8025]
    process_execution_payload(state, block.body, EXECUTION_ENGINE, PROOF_ENGINE)
    process_randao(state, block.body)
    process_eth1_data(state, block.body)
    process_operations(state, block.body)
    process_sync_aggregate(state, block.body.sync_aggregate)

process_execution_payload is modified to additionally notify the proof engine of the new payload after the execution engine has accepted it. This hook lets the proof engine learn of each new payload so it can associate it with the proofs that certify it as they arrive over gossip:

def process_execution_payload(
    state: BeaconState,
    body: BeaconBlockBody,
    execution_engine: ExecutionEngine,
    proof_engine: ProofEngine,
) -> None:
    ...
    # Verify the execution payload is valid via ExecutionEngine
    assert execution_engine.verify_and_notify_new_payload(
        NewPayloadRequest(...)
    )

    # [New in EIP8025]
    # Notify ProofEngine of the new execution payload
    proof_engine.notify_new_payload(NewPayloadRequest(...))
    ...

A new process_execution_proof handles a SignedExecutionProof once it has passed gossip validation. It re-checks that the prover is active in the current state, verifies the BLS signature under DOMAIN_EXECUTION_PROOF, and delegates cryptographic verification to the proof engine:

def process_execution_proof(
    state: BeaconState,
    signed_proof: SignedExecutionProof,
    proof_engine: ProofEngine,
) -> None:
    proof_message = signed_proof.message

    # Verify prover is an active validator
    validator = state.validators[signed_proof.validator_index]
    assert is_active_validator(validator, get_current_epoch(state))

    domain = get_domain(state, DOMAIN_EXECUTION_PROOF, compute_epoch_at_slot(state.slot))
    signing_root = compute_signing_root(proof_message, domain)
    assert bls.Verify(validator.pubkey, signing_root, signed_proof.signature)

    # Verify the execution proof
    assert proof_engine.verify_execution_proof(proof_message)

process_execution_proof is invoked outside the beacon-block state-transition function and produces no on-chain state change: it is the operational hook that lets a node decide whether to treat a gossiped proof as a valid validity signal for an execution payload. Proof storage is managed by the ProofEngine; retention is bounded by proof_serve_range (see Req/resp domain): clients MUST retain proofs for canonical-chain blocks back to the finalised checkpoint so they can serve ExecutionProofsByRange and ExecutionProofsByRoot requests.

Proof gossip

Execution proofs are gossiped over a new global topic, execution_proof, carrying SignedExecutionProof messages. Each rule below is a libp2p gossipsub validation rule, following the same [IGNORE] / [REJECT] conventions used by the other beacon-node gossip topics. With proof = signed_execution_proof.message:

These rules compose with the existing gossipsub peer-scoring machinery: a peer relaying messages that hit [REJECT] is downscored by the same mechanism that scores misbehaviour on any other CL gossip topic. The [IGNORE] rules bound steady-state bandwidth — once a node has a valid proof for a given (new_payload_request_root, proof_type), additional proofs for the same tuple are dropped silently, regardless of who signs them.

Req/resp domain

Three req/resp protocols let peers backfill, target, and coordinate proof state:

Clients MUST serve both range and root requests for any block on the canonical chain whose slot is in proof_serve_range — defined as [finalized_checkpoint.slot, current_slot]. Peers unable to reply respond with 3: ResourceUnavailable and MAY be descored. The shape of these protocols composes with existing sync flows: a node syncing forward over blocks pulls proofs by range; a node patching a specific gap pulls them by root.

Discovery

Discovery is extended with a new Ethereum Node Record (ENR) key, eproof, encoded as a uint8. A node is considered proof-aware if the field is present and non-zero, allowing other peers to filter for proof-aware peers during discovery. This mirrors the existing pattern used to advertise data-column awareness in Fulu via the cgc ENR field and is intentionally cheap: no fork or fork-version bump is required for a node to start (or stop) advertising proof support.

Prover lifecycle

The prover lifecycle is illustrated below:

Prover lifecycle: SSE-driven flow between beacon node, prover, and proof node

A prover's flow, as detailed in the prover guide referenced above, is fully event-driven:

  1. Subscribe to two SSE event streams at startup:
  2. Block events from the beacon node, signalling that a new valid beacon block has been received.
  3. Proof-completion events from the proof node.
  4. On a Block event, fetch the full BeaconBlock via RPC, construct the corresponding NewPayloadRequest, choose the ProofAttributes (set of proof_types the prover wants to generate), and call proof_engine.request_proofs(...). The returned root is used to track the request.
  5. On a proof-completion event matching a tracked root, fetch the completed ExecutionProof from the proof node, sign it under DOMAIN_EXECUTION_PROOF, wrap it in a SignedExecutionProof, and broadcast on the execution_proof gossip topic.

The signing helper is:

def get_execution_proof_signature(
    state: BeaconState, proof: ExecutionProof, privkey: int
) -> BLSSignature:
    domain = get_domain(state, DOMAIN_EXECUTION_PROOF, compute_epoch_at_slot(state.slot))
    signing_root = compute_signing_root(proof, domain)
    return bls.Sign(privkey, signing_root)

The prover role is scoped to the optional-proof phase. If a future EIP were to make execution proofs mandatory, proof generation would plausibly move into block production, at which point the prover role and the optional gossip topic could be deprecated in favour of in-block proof commitments.

Execution Layer

This EIP introduces a stateless execution guest and prover-side logic that constructs the guest input. The prover runs the guest over private StatelessInput bytes. The proof exposes StatelessValidationResult as public output. This output binds the proof to the payload request and execution schema.

A proof-verifying node accepts the execution-layer result only if:

At a high level, proof generation follows this flow:

  1. A host, usually a stateful execution-layer client, executes or constructs the block while recording the account, storage, code, and ancestor-header data used during execution.
  2. The host builds an ExecutionWitness and combines it with the Engine API request, chain ID, and transaction public keys.
  3. The host serializes this StatelessInput as schema-prefixed SSZ bytes.
  4. A prover runs the guest program on the serialized StatelessInput.
  5. The guest validates the witness and executes the payload against witness-backed state. It then returns StatelessValidationResult.

Stateless input and output

The top-level guest input is private prover input:

class StatelessInput:
    new_payload_request: NewPayloadRequest
    witness: ExecutionWitness
    chain_id: U64
    public_keys: Tuple[Bytes, ...]

The guest output is public:

class StatelessValidationResult:
    new_payload_request_root: Hash32
    successful_validation: bool
    chain_id: U64
    schema_id: U16

At this level:

If the guest cannot decode the input, it returns a failed result with sentinel values. The request root, chain ID, and schema ID are all zero in this result. If validation fails after decoding, the result retains the decoded request root, chain ID, and schema ID.

The NewPayloadRequest commits to the payload, blob versioned hashes, parent_beacon_block_root, and typed execution requests. The versioned_hashes field carries the versioned hashes introduced by EIP-4844. The typed deposit, withdrawal, and consolidation requests are specified by EIP-6110, EIP-7002, and EIP-7251, respectively. Builder deposit and exit requests are specified by EIP-8282. The block_access_list field in ExecutionPayload is the block-level access list defined by EIP-7928.

class NewPayloadRequest:
    execution_payload: ExecutionPayload
    versioned_hashes: Tuple[VersionedHash, ...]
    parent_beacon_block_root: Root
    execution_requests: ExecutionRequests


class ExecutionPayload:
    parent_hash: Hash32
    fee_recipient: Address
    state_root: Root
    receipts_root: Root
    logs_bloom: Bloom
    prev_randao: Bytes32
    block_number: Uint
    gas_limit: Uint
    gas_used: Uint
    timestamp: U256
    extra_data: Bytes
    base_fee_per_gas: Uint
    block_hash: Hash32
    transactions: Tuple[Bytes, ...]
    withdrawals: Tuple[Withdrawal, ...]
    blob_gas_used: U64
    excess_blob_gas: U64
    block_access_list: Bytes
    slot_number: U64

The execution requests are represented as typed containers, matching the consensus-layer specs:

class DepositRequest:
    pubkey: Bytes48
    withdrawal_credentials: Bytes32
    amount: U64
    signature: Bytes96
    index: U64


class WithdrawalRequest:
    source_address: Address
    validator_pubkey: Bytes48
    amount: U64


class ConsolidationRequest:
    source_address: Address
    source_pubkey: Bytes48
    target_pubkey: Bytes48


class BuilderDepositRequest:
    pubkey: Bytes48
    withdrawal_credentials: Bytes32
    amount: U64
    signature: Bytes96


class BuilderExitRequest:
    source_address: Address
    pubkey: Bytes48


class ExecutionRequests:
    deposits: Tuple[DepositRequest, ...]
    withdrawals: Tuple[WithdrawalRequest, ...]
    consolidations: Tuple[ConsolidationRequest, ...]
    builder_deposits: Tuple[BuilderDepositRequest, ...]
    builder_exits: Tuple[BuilderExitRequest, ...]

The remaining top-level field defines the witness consumed by the guest:

class ExecutionWitness:
    state: Tuple[Bytes, ...]
    codes: Tuple[Bytes, ...]
    headers: Tuple[Bytes, ...]

The ExecutionWitness fields have the following roles:

Guest validation

The guest entry point decodes schema-prefixed SSZ input and runs stateless payload validation. It always serializes a result, including for invalid input.

def _default_failed_stateless_output() -> StatelessValidationResult:
    return StatelessValidationResult(
        new_payload_request_root=Hash32(b"\0" * 32),
        successful_validation=False,
        chain_id=U64(0),
        schema_id=U16(0),
    )


def run_stateless_guest(input_bytes: Bytes) -> Bytes:
    try:
        stateless_input = deserialize_stateless_input(input_bytes)
    except Exception:
        stateless_output = _default_failed_stateless_output()
    else:
        stateless_output = verify_stateless_new_payload(stateless_input)
    return serialize_stateless_output(stateless_output)

The main validation path first computes the public payload-request commitment. It then validates the header witness and creates a WitnessState. Finally, it uses the same new_payload path as the execution engine.

The reference implementation has one implementation for each fork. Thus, its Amsterdam guest does not compare the payload timestamp with fork activation data. Production implementations MUST perform this comparison.

def compute_new_payload_request_root(
    stateless_input: StatelessInput,
) -> Hash32:
    ssz_npr = _new_payload_request_to_ssz(stateless_input.new_payload_request)
    return Hash32(ssz_npr.hash_tree_root())


def validate_headers(
    encoded_headers: Tuple[Bytes, ...],
) -> Tuple[List[Header | PreviousForkHeader], List[Hash32]]:
    assert len(encoded_headers) <= 256
    headers = [_decode_header(header) for header in encoded_headers]
    block_hashes = [keccak256(header) for header in encoded_headers]
    for i in range(1, len(headers)):
        if headers[i].parent_hash != block_hashes[i - 1]:
            raise Exception("Witness headers are not contiguous")
    return headers, block_hashes


def verify_stateless_new_payload(
    stateless_input: StatelessInput,
) -> StatelessValidationResult:
    new_payload_request_root = compute_new_payload_request_root(
        stateless_input
    )
    witness = stateless_input.witness

    try:
        decoded_headers, block_hashes = validate_headers(witness.headers)
        parent_header = decoded_headers[-1]

        chain_context = ChainContext(
            chain_id=stateless_input.chain_id,
            block_hashes=block_hashes,
            parent_header=parent_header,
        )

        pre_state = WitnessState(
            _node_db=build_node_db(witness.state),
            _state_root=parent_header.state_root,
            _code_db=build_code_db(witness.codes),
        )

        execute_new_payload_request(
            stateless_input.new_payload_request,
            pre_state,
            chain_context,
            transaction_public_keys=stateless_input.public_keys,
        )
        successful_validation = True
    except Exception:
        successful_validation = False

    return StatelessValidationResult(
        new_payload_request_root=new_payload_request_root,
        successful_validation=successful_validation,
        chain_id=stateless_input.chain_id,
        schema_id=U16(STATELESS_INPUT_SCHEMA_ID),
    )

WitnessState is the stateless replacement for a local pre-state database. It serves account, storage, and code reads from the witness and computes the post-state root from the execution diff:

class WitnessState:
    _node_db: Dict[Bytes, Bytes]
    _state_root: Root
    _code_db: Dict[Hash32, Bytes]

    def get_account_optional(self, address: Address) -> Optional[Account]: ...
    def get_storage(self, address: Address, key: Bytes32) -> U256: ...
    def get_code(self, code_hash: Hash32) -> Bytes: ...

    def compute_state_root_and_trie_changes(
        self,
        account_changes: Dict[Address, Optional[Account]],
        storage_changes: Dict[Address, Dict[Bytes32, U256]],
    ) -> Tuple[Root, List[InternalNode]]:
        ...

The payload execution logic performs the normal payload checks before executing the block:

def execute_new_payload_request(
    new_payload_request: NewPayloadRequest,
    pre_state: PreState,
    chain_context: ChainContext,
    transaction_public_keys: Optional[Tuple[Bytes, ...]] = None,
) -> Tuple[BlockDiff, Block]:
    payload = new_payload_request.execution_payload

    if b"" in payload.transactions:
        raise InvalidBlock("Empty transaction in payload")
    if not is_valid_block_hash(
        payload,
        new_payload_request.parent_beacon_block_root,
        new_payload_request.execution_requests,
    ):
        raise InvalidBlock("Invalid block hash")
    if not is_valid_versioned_hashes(new_payload_request):
        raise InvalidBlock("Invalid versioned hashes")

    block = _payload_block(
        payload,
        new_payload_request.parent_beacon_block_root,
        new_payload_request.execution_requests,
    )
    block_diff = execute_block(
        block,
        pre_state,
        chain_context,
        transaction_public_keys=transaction_public_keys,
    )
    return block_diff, block

During transaction processing, supplied public keys are verified before deriving sender addresses:

def recover_sender_from_public_key(
    chain_id: U64,
    tx: Transaction,
    public_key: Bytes,
) -> Address:
    if public_key != recover_transaction_public_key(chain_id, tx):
        raise InvalidSignatureError
    return _sender_address_from_public_key(public_key)

Optimized guests can avoid full public-key recovery. They MUST still verify that the supplied key validates the transaction signature. The key MUST also match the recovery ID or y-parity bit.

Host-side input construction

On the host side, build_stateless_input receives the data gathered during block execution or construction and packages them for the guest:

def build_stateless_input(
    block: Block,
    *,
    execution_witness: ExecutionWitness,
    execution_requests: ExecutionRequests,
    block_access_list: BlockAccessList,
    chain_id: U64,
) -> StatelessInput:
    ...

    payload = ExecutionPayload(
        ...,
        block_access_list=Bytes(rlp.encode(block_access_list)),
        slot_number=header.slot_number,
    )

    new_payload = NewPayloadRequest(
        execution_payload=payload,
        versioned_hashes=tuple(versioned_hashes),
        parent_beacon_block_root=header.parent_beacon_block_root,
        execution_requests=execution_requests,
    )

    return StatelessInput(
        new_payload_request=new_payload,
        witness=execution_witness,
        chain_id=chain_id,
        public_keys=tuple(public_keys),
    )

The execution witness is built from the block-level read/write tracker and pre-state trie data. ELs already use this tracker to construct block access lists (BALs). Conceptually, witness construction:

  1. collects the parent header and any older ancestors touched by BLOCKHASH.
  2. collects pre-state bytecode reads.
  3. captures account and storage trie nodes needed for all reads and writes.
  4. captures potential sibling nodes that branch compression requires during post-state root calculation.
def build_execution_witness(
    block_state: BlockState,
    expected_post_state_root: Root,
    pre_state_accounts_data: Trie[Address, Optional[Account]],
    pre_state_storages_data: Dict[Address, Trie[Bytes32, U256]],
    blockchain_headers: Optional[List[Bytes]] = None,
) -> ExecutionWitness:
    ancestor_headers = get_witness_ancestors(
        blockchain_headers if blockchain_headers is not None else [],
        block_state.oldest_ancestor_offset,
    )
    codes = get_witness_codes(block_state.code_reads, block_state.pre_state)

    incr_storage_mpts = _build_pre_state_storage_mpts(pre_state_storages_data)
    incr_account_mpt = _build_pre_state_account_mpt(
        pre_state_accounts_data, incr_storage_mpts
    )

    all_storage_accesses = _collect_storage_accesses(block_state)
    _capture_pre_state_storage_nodes(incr_storage_mpts, all_storage_accesses)
    _apply_storage_writes(incr_storage_mpts, block_state.storage_writes)

    all_dirty_accounts = _get_all_dirty_accounts(block_state)
    _capture_pre_state_account_nodes(
        incr_account_mpt,
        block_state.account_reads,
        all_dirty_accounts,
    )
    _apply_account_writes(
        incr_account_mpt,
        incr_storage_mpts,
        block_state,
        all_dirty_accounts,
    )

    assert mpt_root(incr_account_mpt) == expected_post_state_root

    accessed_nodes = _collect_accessed_nodes(
        incr_account_mpt, incr_storage_mpts
    )

    return ExecutionWitness(
        state=tuple(sorted(accessed_nodes.values())),
        codes=tuple(codes),
        headers=tuple(ancestor_headers),
    )

SSZ encoding

The host serializes a StatelessInput by prefixing the SSZ bytes with a two-byte schema ID. The high byte identifies the fork, and the low byte identifies the schema revision. Amsterdam revision 1 uses schema ID 0x1501.

class ProtocolFork(IntEnum):
    ...
    Amsterdam = 0x15


STATELESS_INPUT_SCHEMA_FORK_INDEX = ProtocolFork.Amsterdam
STATELESS_INPUT_SCHEMA_REVISION = 0x01
STATELESS_INPUT_SCHEMA_ID = (
    STATELESS_INPUT_SCHEMA_FORK_INDEX << 8
) | STATELESS_INPUT_SCHEMA_REVISION
STATELESS_INPUT_SCHEMA_ID_SIZE = 2
STATELESS_INPUT_SCHEMA_ID_BYTES = STATELESS_INPUT_SCHEMA_ID.to_bytes(
    STATELESS_INPUT_SCHEMA_ID_SIZE,
    "big",
)


def serialize_stateless_input(
    stateless_input: StatelessInput,
) -> Bytes:
    ssz_obj = stateless_input_to_ssz(stateless_input)
    return Bytes(
        STATELESS_INPUT_SCHEMA_ID_BYTES + bytes(ssz_obj.encode_bytes())
    )


def deserialize_stateless_input(data: Bytes) -> StatelessInput:
    if len(data) < STATELESS_INPUT_SCHEMA_ID_SIZE:
        raise ValueError("Stateless input is missing schema id")
    schema_id = int.from_bytes(
        data[:STATELESS_INPUT_SCHEMA_ID_SIZE],
        "big",
    )
    if schema_id != STATELESS_INPUT_SCHEMA_ID:
        raise ValueError(
            f"Unsupported stateless input schema id: 0x{schema_id:04x}"
        )
    ssz_obj = SSZStatelessInput.decode_bytes(
        data[STATELESS_INPUT_SCHEMA_ID_SIZE:]
    )
    return ssz_to_stateless_input(ssz_obj)

The guest output is an SSZ-encoded SSZStatelessValidationResult. Its schema_id field reports the exact input schema that the guest executed.

The progressive containers and lists follow EIP-7688. Progressive lists and progressive byte lists do not use fixed capacity constants. The schema keeps these fixed bounds and vector sizes:

Bound Value
MAX_EXTRA_DATA_BYTES 32
MAX_WITNESS_HEADERS 256
MAX_BYTES_PER_CODE 2**16
MAX_BYTES_PER_HEADER 2**10
MAX_BYTES_PER_WITNESS_NODE 2**10
PUBLIC_KEY_BYTES 65

The SSZ schema mirrors the dataclasses:

class SSZWithdrawal(Container):
    index: uint64
    validator_index: uint64
    address: ByteVector[20]
    amount: uint64


class SSZExecutionPayload(
    ProgressiveContainer(active_fields=[1] * 19)
):
    parent_hash: Bytes32
    fee_recipient: ByteVector[20]
    state_root: Bytes32
    receipts_root: Bytes32
    logs_bloom: ByteVector[256]
    prev_randao: Bytes32
    block_number: uint64
    gas_limit: uint64
    gas_used: uint64
    timestamp: uint64
    extra_data: ByteList[MAX_EXTRA_DATA_BYTES]
    base_fee_per_gas: uint256
    block_hash: Bytes32
    transactions: ProgressiveList[ProgressiveByteList]
    withdrawals: ProgressiveList[SSZWithdrawal]
    blob_gas_used: uint64
    excess_blob_gas: uint64
    block_access_list: ProgressiveByteList
    slot_number: uint64


class SSZDepositRequest(Container):
    pubkey: ByteVector[48]
    withdrawal_credentials: Bytes32
    amount: uint64
    signature: ByteVector[96]
    index: uint64


class SSZWithdrawalRequest(Container):
    source_address: ByteVector[20]
    validator_pubkey: ByteVector[48]
    amount: uint64


class SSZConsolidationRequest(Container):
    source_address: ByteVector[20]
    source_pubkey: ByteVector[48]
    target_pubkey: ByteVector[48]


class SSZBuilderDepositRequest(Container):
    pubkey: ByteVector[48]
    withdrawal_credentials: Bytes32
    amount: uint64
    signature: ByteVector[96]


class SSZBuilderExitRequest(Container):
    source_address: ByteVector[20]
    pubkey: ByteVector[48]


class SSZExecutionRequests(
    ProgressiveContainer(active_fields=[1] * 5)
):
    deposits: ProgressiveList[SSZDepositRequest]
    withdrawals: ProgressiveList[SSZWithdrawalRequest]
    consolidations: ProgressiveList[SSZConsolidationRequest]
    builder_deposits: ProgressiveList[SSZBuilderDepositRequest]
    builder_exits: ProgressiveList[SSZBuilderExitRequest]


class SSZNewPayloadRequest(Container):
    execution_payload: SSZExecutionPayload
    versioned_hashes: ProgressiveList[Bytes32]
    parent_beacon_block_root: Bytes32
    execution_requests: SSZExecutionRequests


class SSZExecutionWitness(Container):
    state: ProgressiveList[ByteList[MAX_BYTES_PER_WITNESS_NODE]]
    codes: ProgressiveList[ByteList[MAX_BYTES_PER_CODE]]
    headers: SSZList[ByteList[MAX_BYTES_PER_HEADER], MAX_WITNESS_HEADERS]


class SSZStatelessInput(Container):
    new_payload_request: SSZNewPayloadRequest
    witness: SSZExecutionWitness
    chain_id: uint64
    public_keys: ProgressiveList[ByteVector[PUBLIC_KEY_BYTES]]


class SSZStatelessValidationResult(Container):
    new_payload_request_root: Bytes32
    successful_validation: boolean
    chain_id: uint64
    schema_id: uint16

Rationale

Path to low-resource validation

This step moves the network measurably closer to low-resource validation. Stateless, constant-time payload verification breaks the coupling between a node's hardware requirements and the gas limit or state size, lowering the floor for who can meaningfully run a node and improving decentralisation.

Build operational experience

The central design choice is to deploy execution proofs as an opt-in feature. Stateless validation, the witness format, and the proof system itself are maturing, but we need operational experience before making execution proofs load-bearing. Treating execution proofs as a non-critical artefact lets the stack mature on a live network — proof sizes, generation latency, verifier throughput, gossip behaviour, prover diversity — without placing any of that on the path of fork choice or attestation. A bug, outage, or poor parameter choice is contained to the nodes that opted in; it cannot fork the chain or affect validators that did not subscribe.

Backwards Compatibility

This EIP is fully opt-in and does not change consensus validity rules. Validators that do not enable either mode see no change to their behaviour, their bandwidth, or their attestation duties. Nodes that opt in additionally subscribe to the proof gossip topic, advertise themselves via the eproof ENR field, and may run a prover; this affects only their local resource profile.

Test Cases

Conformance tests are maintained in the canonical specification repositories:

Reference Implementation

Security Considerations

Gossip surface. Proofs are carried over a new gossipsub topic with payload size bounded by MAX_PROOF_SIZE. Validation, anti-DoS rate limits, and peer scoring for invalid proofs follow the same patterns as other CL gossip topics; a misbehaving peer is bounded and can be downscored.

Soundness and consensus implications. This EIP does not wire proof verification into fork choice or any other consensus rule: process_execution_proof runs outside the beacon-block state-transition function. A forged proof therefore cannot fork the chain, slash a validator, or otherwise affect consensus state — its effect is bounded to a verifying node's local view of payload validity.

Liveness and critical-path latency. Proof generation and verification are off the attestation hot path. Validators must not delay block validation or attestation production while waiting for a proof; if a proof is missing or late, the node attests using the fork choice determined by the execution engine's re-execution of payloads.

Verifier–prover decentralisation asymmetry. Stateless, constant-time payload verification lowers the resource floor for validators, but proof generation itself remains demanding: a prover must hold the full EL state used during execution and run a non-trivial proving stack whose cost scales as O(n log² n) in the size n of the witnessed computation. If the proportion of verifying-only nodes grows faster than the proportion of nodes able to generate proofs, the set of actors who maintain the full EL state and produce proofs may become more concentrated even as overall validator participation broadens.

Copyright

Copyright and related rights waived via CC0.