4.4.5.Optional execution proofs

Draft EIP-8025 proposes an opt-in execution-proof network. It does not replace execution-layer validation, affect fork choice, or change validator duties. Proof-generating validators publish proofs as a public service. Proof-verifying nodes use a valid proof as an extra local signal and still re-execute the payload.

The proposal depends on ePBS and stateless execution work. It has no target fork in the pinned sources.

Roles and lifecycle

A node may enable proof generation, proof verification, both, or neither.

1. A generating node receives a valid beacon block and builds the matching Engine API NewPayloadRequest.
2. Its ProofEngine asks an external proof node to generate one or more configured proof types.
3. The proof node completes the work out of band. The validator signs each result and publishes a SignedExecutionProof.
4. A verifying node runs the network checks and asks its proof engine to check the proof system, guest program, payload binding, result, and chain configuration.

The generator listens to beacon-block and proof-completion event streams. request_proofs returns the hash-tree root of the payload request so the generator can match an asynchronous result to its request.

Proof objects and limits

At the stated maximum, four proof types can add up to 1.6 MiB of proof data for one payload. A proof system whose output is larger must compress it before publication.

SignedExecutionProof:
  message: ExecutionProof
  validator_index: ValidatorIndex
  signature: BLSSignature

ExecutionProof:
  proof_data: ByteList[400 KiB]
  proof_type: uint8
  public_input:
    new_payload_request_root: Root
    successful_validation: bool
    chain_config: ChainConfig

new_payload_request_root binds the proof to all data in the payload validation request. successful_validation must be true. chain_config binds the result to the expected chain ID and fork settings. The validator index and signature identify an active validator that signed this exact proof under the execution-proof domain.

Proof engine boundary

The beacon client owns a ProofEngine adapter with four operations:

verify_execution_proof(proof) -> bool
notify_new_payload(request)
notify_forkchoice_updated(head, safe, finalized)
request_proofs(request, proof_types) -> request_root

Payload and fork-choice notices let the proof engine bind proofs to known payloads and prune proofs that are no longer in its serving range. Verification runs outside the beacon state transition and produces no on-chain state change.

The execution guest consumes private StatelessInput. This input contains the payload request, an execution witness, the chain configuration, and transaction public keys. It exposes StatelessValidationResult as public output. A verifier accepts the result only when:

• the proof verifies for the expected proof system and guest program;
• successful_validation is true;
• the request root equals the hash-tree root of the local NewPayloadRequest; and
• the chain configuration equals the verifier's expected configuration.

Gossip

The proposed global execution_proof topic carries SignedExecutionProof.

A receiver needs the payload identified by new_payload_request_root. It may queue a proof until that payload arrives. It forwards only the first valid proof for each (new_payload_request_root, proof_type) pair, and gives each validator one attempt for each such pair.

Before forwarding, the receiver checks:

• the validator index names an active validator;
• the signature is valid under DOMAIN_EXECUTION_PROOF;
• proof_data is not empty and does not exceed 400 KiB;
• the proof type has a configured verifier;
• the public result names the expected payload and chain; and
• proof-engine verification succeeds.

A rejected proof affects normal gossipsub peer scoring. An ignored duplicate does not. Nodes must rate-limit proof verification because a validly signed message can still cause costly cryptographic work.

Recovery and peer capability

The proposal defines three consensus Req/Resp methods.

ExecutionProofsByRange requests (start_slot, count, proof_types) and returns matching signed proofs. It supports sequential backfill.

ExecutionProofsByRoot requests block roots and proof types and returns the matching signed proofs. It supports targeted repair.

ExecutionProofStatus exchanges (block_root, slot, proof_types). The block and slot identify the peer's latest proof-verified block. The proof-type list advertises its current local support. A dialing node sends this status when it first connects to a proof-aware peer.

A proof-aware node retains proofs for canonical blocks from the finalized checkpoint slot through the current slot. It serves range and root requests inside that interval. If it cannot serve a request, it returns 3: ResourceUnavailable and may lose peer score.

The proposed ENR eproof field is a uint8. Presence with a nonzero value marks a proof-aware node. The status exchange, not the ENR bit, tells a peer which proof types overlap.

Failure boundaries

A missing, late, or invalid proof never makes a payload invalid under this draft. Validators must not wait for proof generation or verification before they attest. The execution client remains the authority for payload validity. The proof network can fail without changing consensus state.

The source leaves these points open or inconsistent:

• the number k of valid signed proofs needed for a local “proof-verified” result is not set;
• the proof object has no slot or time field, and the draft gives no separate clock check beyond binding it to a known payload request;
• proof-type numbers and their guest programs are set outside the protocol;
• no incentive or required prover set exists;
• no numeric proof-verification rate or queue bound is set;
• the EIP links to companion consensus and execution revisions that are not the repository's pinned reference revisions; and
• the formal gossip bullets use positive conditions where their explanations describe missing payloads and duplicates. This page follows the explanatory intent, but a later draft must correct the normative conditions.

These gaps prevent an interoperable deployment claim.