Optional proofs, a way to check blocks without re-execution

Strawmap Hegotá (2027) · optional proofs

This is an opt-in feature that lets a consensus layer node confirm the validity of the transactions in a block using cryptographic proofs made by other nodes, without re-executing them itself. Only the nodes that want it turn it on, and the consensus rules do not change.

Why it is needed

Today, to verify a beacon block, a validator must re-execute the bundle of transactions inside it (the execution payload) against the entire execution layer (EL) state. It needs every account and all storage data, and the cost of re-execution grows in proportion to the gas limit. So as the gas limit rises or the state grows, the hardware bar for becoming a validator rises with it. Optional proofs separate the nodes that produce proofs from the nodes that check them. The checking side can confirm whether a payload is valid within a fixed amount of time, even without EL state. However, because proof systems are still maturing, they are not made mandatory from the start. Only the nodes that want it turn it on, building operating experience and metrics on the real network. At this stage, checking nodes keep re-executing too and use proofs only as a supplementary signal. Nodes that produce proofs receive no reward, so participation is treated as voluntary. Strawmap places this item in the Hegotá slot, but at the ACDC call 189 on October 15, 2026, EIP-8025 was dropped from the Hegotá candidates. Support from consensus layer client teams fell short of the bar, and experiments continue on a separate branch.

How it works

  1. Provers produce and publish proofs An active validator with proof generation mode turned on becomes a prover. It hands the payload of a new block to an external proving node to produce a proof, signs it, and broadcasts it on the execution_proof gossip topic.
  2. A proof is bound to a specific block A proof contains a root value that points to which payload it is for, plus a chain ID and a schema ID. This prevents proofs from another chain or another fork from being reused. Each proof is up to 400 KiB, and up to 4 are allowed per payload.
  3. Checking nodes use it as a supplementary signal A node with checking mode turned on verifies the proofs it receives with ProofEngine. Once a set number of valid proofs has been collected, the payload is treated as proof-verified. The number has not been decided yet, re-execution continues, and fork choice does not depend on proofs.
  4. Time margin and storage Because EIP-7732 defers execution verification to the next beacon block, there is time to produce proofs. Nodes that handle proofs keep proofs up to the finalized checkpoint so that syncing peers can fetch them.

Related EIPs

← Roadmap