By Kev and Julian. Thanks to Toni and Francesco for their feedback.
Delayed execution is a proposed upgrade to Ethereum that helps to increase the gas limit. Instead of needing to execute the block before attesting, with delayed execution, attesters pass simple checks on the block **and vote for it before executing the transactions. Changing the current EVM with a zkVM is another proposed Ethereum upgrade to increase the gas limit. With a zkVM, attesters only need to verify a succinct proof that the block was validly executed. This post explores the interaction between delayed execution and zkVMs. Note that one of the main goals of delayed execution is to facilitate zkVM proving on Ethereum L1.
We propose assigning the responsibility of proving the correct execution of block n to the builder of that block, but enabling that builder to force-include the proof in the block of slot n+1.
This proposal improves the incentive alignment of proving, especially for so-called “prover killers”. Prover killers are blocks that are specifically built to be expensive to prove, while being relatively cheap to create. They leverage the asymmetry between what the Ethereum protocol charges in gas units for operations and the real-world costs provers incur. If the slot n+1 builder were responsible for proving block n, the builder of slot n may create such a prover killer to grieve the slot n+1 builder. This proposal removes that incentive incompatibility by assigning responsibility for proving block n to the slot n builder.
A special case where improved incentive alignment is helpful is if there is a builder liveness issue. Suppose there is one extremely powerful builder that creates a large block and then goes offline (or a cartel of builders that behaves like this one builder). In that case, it may be infeasible for smaller backup builders to create a proof for the previous block. This knowledge could allow the (cartel of) builder(s) to “hold Ethereum ransom” and extract rents. If the slot n builder is responsible for the proof of slot n, this phenomenon disappears. If a builder goes offline, the block contents are skipped (as described below), and a next-slot builder could build a block that it can self-proof. Therefore, this proposal helps decouple throughput from local building as it benefits block production liveness.
Same-Slot Proof Proposal
-
Slot
n,t=0: The builder of slotnpropagates the beacon block. The execution payload is packaged into a blob and gossiped. -
Slot
n,t=X(Say like t = 2): Attesters statically validate the beacon block as outlined in the delayed execution EIP. -
Slot
n,t=Y(Say like t = 9) (Proof observation deadline): Attesters freeze their view on whether there is a proof available that takes as input the pre-state root and a kzg commitment to a blob and outputs the post-state root. -
Slot
n+1,t=0: The builder of slotn+1includes a proof of correct execution of the previous block if it is available. -
Slot
n+1,t=X: Attesters fully validate blockn. Each attester does so by running the following checks against its local view.- Was the proof of block
navailable at the proof observation deadline? - If so, is the proof correct?
- If so, is the blob corresponding to the kzg commitment in the blob available.
If the attester answered yes to all questions, it votes for block
n+1is it includes the proof of blockn. If the attester answers no to the first question, it votes for the block if either of the following two conditions hold:- No proof was included in the block.
- A correct proof was included with a kzg commitment that corresponds to an available blob.
- Was the proof of block
If no proof for block n was included in block n+1, or the blob data corresponding to the proof was not available, block n+1 should treat the execution of block n as a no-op, meaning the pre-state of block n+1 is identical to the pre-state of block n. This mechanism ensures that both the proof and the payload data are available, guaranteeing security and liveness. As Toni and Francesco argue here, treating the block as a no-op does not expose free data availability, since the block producer forgoes execution rewards to obtain the “free” data availability.
Note that attesters of slot n also fully validate block n-1, and attesters of slot n+1 also statically validate block n+1. Full validation consists of verifying the proof’s correctness and timeliness as described above.
Extra Considerations
The Same-Slot Proof architecture relies on view-merge, a fork-choice gadget described by Francesco in this post. View-merge assumes that the network delay is lower than some constant, Δ. The proof observation deadline should be set at the latest at t = 12 - Δ. If the network delay is smaller than Δ, the builder’s view is a superset of the frozen views of the attesters, meaning that attesters will not force a builder to include a proof that is gossiped after the proof observation deadline, preventing split-view attacks. View-merge is the same fork-choice gadget that underpins designs like MEV-Burn and FOCIL.
Finally, note that the Same-Slot Proof architecture does not depend on whether one or multiple zkVMs are enshrined. If proofs of multiple zkVM proofs are necessary, attesters fully validating a block should check that multiple correct proofs were included in the block, if necessary, according to their local view.