Why
Two forks make one machine, and it is worth stating the dependency plainly because the roadmap coverage rarely does. Glamsterdam sets out two chairs: ePBS (EIP-7732) supplies time, because splitting the slot seats the builder as prover and opens an interval between header commitment and payload reveal; BAL (EIP-7928) supplies partition, because a block that declares the state it will touch is a block whose proving work can be sliced across many provers. Neither alone makes a twelve-second proof possible, which is why EIP-8025 sits in Hegotá rather than in Glamsterdam. That much is architecture. The part worth a card is the adjective. These are optional execution proofs, and the option is the whole design: a validator may check a succinct proof of the state transition instead of running the transactions. Proof-checking has to be cheaper than re-execution or nobody takes the option, and if it is cheaper then a rational validator takes it — all of them. At that point the network's ability to notice a prover bug rests entirely on whoever is still paying more to re-execute, which is to say on validators behaving irrationally. Safety that depends on people declining a discount is the same shape this catalogue already recorded in the Aqua card, where quoted depth is real but only for whoever arrives first, and in the note on Tempo, where a single client plus a halt-rather-than-be-wrong posture turns one bug into an outage. The question is not whether the proofs are sound. It is what fraction of the network keeps the capacity to disagree with them.
How it works
Mechanism first, as documented: a validator may verify a block by checking a succinct proof of the state transition rather than re-executing its transactions, with the mainnet state transition function exposed to the execution layer through an EXECUTE precompile in the EIP-8079 draft, and Native Rollups built on the same primitive. Proving is made feasible by the two Glamsterdam pieces above rather than by any change in EIP-8025 itself. Two measurements, both small enough to run without building anything. First, the window. Take a few dozen recent mainnet blocks, prove them with an off-the-shelf zkVM on a rented GPU, and plot wall-clock proving time against gas used. The output is one number and one curve: the largest block that proves inside the interval ePBS opens, and the hardware it took to get there. Set that against Glamsterdam's 200M gas target and the gap either closes or it does not, and if it does not then the option is theoretical and this card's second half is premature. Second, the discount. Price the cost of verifying a proof against the cost of re-executing the same block on a home-spec node. That ratio is the adoption rate, and the adoption rate is the erosion of re-execution coverage, so the interesting output is not the ratio itself but the fraction of stake at which nobody is left to catch a bad prover. One section belongs inside this card rather than beside it: the list. The ePBS card asked which code silently assumes the proposer knows the payload; this one asks the twin question, which code silently assumes somebody actually ran the transactions. Fraud proofs, re-org monitors, block explorers that recompute receipts, and any service that trusts a value because it saw a node produce it are all candidates, and the list is cheap to write now and expensive to write during a testnet.
Update 2026-08-25 — the mechanism, and what the option actually rests on
What a proof asserts. Block execution is one function: newStateRoot = STF(oldStateRoot, block). The proof asserts knowledge of an execution trace carrying the first to the third. Public inputs are the old root, a commitment to the block, and the claimed new root; the witness — full trace, every signature, every storage access — stays inside. Verification is a short function over the public inputs returning true or false in milliseconds.
Why the block hash is not the weak point. The commitment pins which block is under discussion, not what gets checked. The circuit carries a constraint that the hash of the transactions actually executed equals the committed hash, so a prover that ran a different set cannot produce a proof at all. Signature validity, nonce ordering, balance sufficiency and gas accounting all sit inside the state transition function being proven — an invalid transaction cannot be "correctly executed" into a state change.
What proofs do not cover. Correctness, not completeness or fairness. Inclusion is untouched: omitting a transaction yields a perfectly valid proof, which is FOCIL's problem rather than this one. Ordering is untouched, so MEV survives intact. Data availability sits outside the proof entirely — if the payload is never published, "some set hashing to H executed correctly" is true and useless, since nobody can compute a balance or construct an exit proof. On L1 this is moot because payloads propagate; on a validium it is the entire problem, and it is why a forced-exit guarantee reverts to a promise the moment an operator withholds data.
Who actually re-executes. Four groups, one of them robust. Those who need the state anyway — indexers, explorers, exchanges — re-execute at any discount, because proof verification returns one bit while their product is the state itself. Those who distrust the proof system shrink as incident-free years accumulate, so the thin moment arrives late rather than early. Un-upgraded nodes are real but cannot be designed around. Paid watchdogs do not exist in protocol today.
The trouble is that the robust group cannot reject a block. Influencing consensus requires stake, and stake has the sharpest incentive to take the discount. The group with the most durable reason to keep re-executing holds no veto, and the group holding the veto has the strongest reason to stop. Time compounds it: an indexer noticing a mismatch two hours later is noticing after finality, where reversal is a social problem rather than a technical one. Detection is a far weaker guarantee than rejection, so the measurement must be stake-weighted rather than node-counted.
Proof diversity — why it is the strongest candidate fix. Different zkVMs prove the same sentence. Their internals differ completely while their claims are bound to identical public inputs, so outputs need no reconciliation: the answer is already fixed at one newStateRoot, and each proof independently attests to it. If zkVM A carries a bug in, say, its MULMOD circuit, it can produce a passing proof for a wrong root — but zkVM B, to agree, would have to prove a false statement, which a sound system cannot do. Disagreement therefore surfaces mechanically. In consensus it would read roughly:
required = {A, B, C}
valid = count(S in required where Verify_S(oldRoot, blockCommit, newRoot, proof_S))
block valid ⟺ valid ≥ N
Note that newRoot is the same variable throughout the loop, so agreement is structural rather than separately adjudicated. Cost stays a few milliseconds.
Where diversity leaks. Three places, and the third is the interesting one. First, the diversity may be surface-only: client diversity worked because implementations were written independently from a spec, whereas zkVMs frequently share proof-system families, hash and curve implementations, and base libraries — a bug beneath the diversity layer produces the same wrong answer three times. Second, requiring N proofs multiplies proving cost and lets the slowest prover set the pace, so a single system's outage becomes a liveness failure. Third and most important, the same discount dynamic reappears one level down: if one zkVM is meaningfully cheaper, provers concentrate on it and the monoculture returns. Ethereum's ongoing client-diversity concern is the live demonstration that a norm is not a rule. Diversity therefore only works if the protocol names the required systems in consensus — which is a real departure from Ethereum's practice of keeping implementation names out of the protocol — and it makes several verifier implementations consensus-critical, adding attack surface at the verification layer to remove it at the proving layer.
And the aggregation irony. Carrying three proofs per block is heavy, so the practical construction is recursive aggregation: one circuit proves that A, B and C all verified, emitting a single small proof. Elegant, and almost certainly where this goes — except the aggregation circuit is shared code again. The efficient implementation of diversity reintroduces a monoculture at the aggregation layer.
What diversity still cannot catch, and the resulting design. Diversity defends against an implementation bug in one prover. It does not defend against a bug shared by all provers, whether through a common dependency or through an ambiguous specification, because every system proves the same statement about the same spec. Only re-execution is grounded in actually running the thing. The two are complementary rather than alternative:
| one prover wrong | all provers wrong (shared dependency or spec) | |
|---|---|---|
| Proof diversity | caught | not caught |
| Mandatory sampled re-execution | caught | caught |
Sampling a small random subset of validators per slot — the machinery attestation committees already use — keeps cost low while making "nobody re-executes" structurally impossible.
Measurement added to this card. Alongside the window and the discount, a third number: the shared-dependency graph across candidate zkVMs. Diversity is only worth what the independence beneath it is worth, and that overlap is computable today from public dependency manifests. Nobody publishes it.