Delayed Execution: A Proposal for Glamsterdam
This short note follows a template designed by @timbeiko to propose a headline feature for fork inclusion.
In this document, we propose Delayed Execution (EIP-7886) for inclusion in the Glamsterdam hard fork.
Summary
EIP-7886 introduces a mechanism to decouple block validation from immediate execution. By introducing static, pre-execution checks and allowing the execution outputs to be deferred, validators can attest to block validity without executing every transaction upfront. This offers a path to higher throughput, relieves the critical path of block validation from execution, and gets us closer to real-time proving in zkEVMs.
Detailed Justification
Today, validators must fully execute each block before attesting to it. This design ties block validation directly to execution, creating a bottleneck for scalability.
Delayed Execution introduces asynchronous block validation by separating structural correctness from execution correctness. If execution fails or exceeds the block gas limit, the beacon block is still valid, but the execution payload becomes a no-op (i.e., the state is reverted to what it was before starting transaction execution). This decoupling reduces critical path complexity and allows for faster attestation.
Primary Benefits
zkEVM Compatibility (long-term):
Delayed execution is particularly beneficial for zkEVM-based nodes. Since execution outputs (state root, receipts, logs) are deferred, zkEVMs gain valuable time to generate proofs. This moves us closer to a future where blocks can be validated by verifying succinct proofs instead of re-executing transactions.
Higher Throughput Potential (short-term):
Validators can attest to blocks earlier in the slot and use the remaining slot for execution. Because execution is no longer in the critical path, block gas limits can be safely increased without impacting consensus performance.
Why Now?
The community wants to scale the execution layer. Delayed Execution directly addresses this by relieving the critical path from immediate execution, unlocking potential for higher gas limits or shorter slot times.
At the same time, recent breakthroughs in zk cryptography are making real-time proving of Ethereum blocks increasingly viable. By deferring execution outputs, EIP-7886 gives zkEVMs time they need to generate validity proofsâmoving us closer to a world where nodes can verify proofs instead of executing transactions, reducing hardware requirements and enabling executionless clients.
Compared to Alternatives
Proposals like ePBS (enshrined Payload-Block Separation) also aim to relieve the critical path by giving the network more time to execute blocks. However, ePBS is less effective in doing so and comes at the cost of added complexity: it introduces new enshrined roles (e.g., builders), significantly modifies the fork-choice rule, and adds a new committee, the Payload Timeliness Committee.
In contrast, EIP-7886 localizes most complexity within the execution layer and avoids introducing new actors or changing fork-choice logic. This design makes it easier to adopt and implement, and it aligns directly with the needs of zkEVM-based proving systems by deferring execution outputs.
In contrast to ePBS, delayed execution does not provide more time for blob propagation or remove trust assumptions between validators and relays.
Stakeholder Impact
Positive:
-
Users benefit from increased L1 throughput, as delayed execution enables higher gas limits and more efficient block validation, leading to faster and potentially cheaper transactions on the L1.
-
zkEVM proofers gain critical flexibility: by deferring execution outputs, EIP-7886 gives zk-based provers more time to generate validity proofs. This is a step toward executionless full nodes that validate blocks using succinct proofs instead of re-execution.
Negative:
- Invalid transactions may remain on the canonical chain. Under delayed execution, a block containing invalid or underfunded transactions can still become canonical, with the full EL payloadâand all state updates from itâbeing reverted. While this avoids complex fork-choice changes, it means invalid transactions are visible on-chain without senders paying for them. However, this comes at a significant cost: the proposer forfeits all execution rewards (i.e. priority fees and the MEV-Boost payment) for that block, creating a very strong disincentive against including malformed or unexecutable transactions.
Technical Readiness
EIP-7886 is fully specified in the exectution-specs, with working implementations underway and discussions on the best design ongoing. It is compatible with other proposals such as FOCIL or Block-level Access Lists.
Security & Open Questions
Known Concerns:
- Free DA: While not actually being âfree,â the current design specified in the EIP focuses on not introducing changes to the fork-choice, having staked entities on the EL, or reusing the validator stake on the CL side. Consequently, senders can include transactions without payment, but proposers must forgo the entire block, strongly disincentivizing such behavior.
Open Questions:
- While several different designs were explored, with the âpayload reversionâ one selected as the best option, thereâs still the opportunity to switch to a different design (there are specs for all designs described here).