EIP-7886 Delayed Execution
No call decision · Scaling & data · EIP status Stagnant · created 2025-02-18
Separates block validation from execution so that a validator can check and attest to a block's validity without executing its transactions. The execution result is verified in the next block.
Why it is needed
Today on Ethereum, a validator can vote that a block is valid (attestation) only after executing all the transactions in it. Because it has to wait for execution to finish, a bottleneck forms in the consensus process, and this limits the transaction volume the network can handle. This proposal changes the idea. It accepts a block as valid based only on checks such as whether the block structure is correct and whether the sender of each transaction holds enough funds up front to pay the fee, and it confirms the actual execution later. If the execution result differs from the value declared in the block, only the execution result is reverted instead of invalidating the whole block. This lets attestation happen earlier in the slot, which makes room to raise the block gas limit and greatly increase throughput.
What changes
Today
- A validator can cast an attestation vote only after executing all the transactions in the block
- If the execution result differs from the declared value, the block itself becomes invalid
- Waiting for execution becomes the consensus bottleneck, making it hard to raise the gas limit
After EIP-7886
- The block is attested using only checks that need no execution, such as signature, balance, and nonce
- If the gas declaration is wrong, the block stays valid and only the execution result is reverted
- Attestation happens early and independently of execution, which makes room to raise the gas limit and improve throughput
Who is affected
- Validators: Attestation votes can be cast using only static checks, before block execution finishes.
- Client teams: A hard-fork-level change that requires altering both the block header structure and the validation and execution pipeline.
- Block proposers: If gas_used is declared incorrectly, the block's execution is reverted entirely and the proposer loses the execution layer rewards for that block.
- Users and app developers: In the rare case that block execution is reverted, the state changes of the transactions in that block are not applied, so you need to account for a structure in which receipts and logs are finalized one block later.
In depth
Header changes: pushing the execution result back by one block
The block header gains pre_state_root (the state root before transaction execution), four parent block execution results, namely parent_transactions_root, parent_receipt_root, parent_bloom, and parent_requests_hash, and parent_execution_reverted, which indicates whether the parent execution was reverted. pre_state_root must match the state root after the parent block's execution, and the parent execution result fields must match the chain-tracked last_transactions_root, last_receipt_root, last_block_logs_bloom, last_requests_hash, and last_execution_reverted respectively. The execution result of block N is verified not in block N but in the header of block N+1.
Static validation: what can be checked without execution
validate_block checks, without executing transactions, each transaction's signature and type-specific requirements (EIP-1559, EIP-4844, etc.), that the sender is an EOA or an account with valid delegation code (EIP-7702), that the sender balance is at least the sum of the maximum gas fee and the transfer amount, and that nonces are sequential per sender. Inclusion gas is counted per transaction as max(intrinsic_gas, calldata_floor_gas_cost), that is, the larger of the intrinsic gas cost and the EIP-7623 calldata floor cost. If the sum, total_inclusion_gas, exceeds the header's gas_used, the block is invalid. The total blob gas must exactly match blob_gas_used, and the withdrawals trie root must also match the header value.
Pre-charging mechanism: deduct the maximum fee first
In the execution stage, before processing transactions, deduct_max_tx_fee_from_sender_balance deducts the maximum fee from every sender up front. The maximum fee is computed as tx.gas multiplied by the effective gas price, plus blob gas usage multiplied by the blob gas price. This pre-charge guarantees that the transactions in a block can afford their fees without being executed, and gives validators a basis for proving this before execution. It is compatible with both EIP-1559 dynamic fee transactions and EIP-4844 blob transactions.
Snapshots and execution reversion
After processing the EIP-4788 (beacon root) and EIP-2935 (history storage) system transactions, the client takes a block-level state snapshot before executing user transactions. Transactions run in order, and at the point where adding the next transaction's tx.gas would exceed the block gas limit, execution_reverted is set to True and execution stops. If the actual gas used after execution differs from the header's gas_used, a reversion also occurs. On reversion, state is rolled back to the snapshot, all execution outputs such as receipts, logs and requests are cleared, and gas used is treated as 0. EIP-7685 general-purpose requests are not generated either. Even then, the block itself remains on the chain as a valid block.
Base fee calculation after a reversion
When block execution is reverted, last_execution_reverted in the chain state becomes True, and the next block must reflect this in its header as parent_execution_reverted. In that case, the next block's base fee calculation treats the parent block's gas usage as 0, regardless of the value reported in the header. This design prevents execution that was never actually applied from affecting the fee market, and prevents fee manipulation through false gas reporting.
Data storage burden and attack incentive analysis
Even for a block whose execution was reverted, calldata, EIP-2930 access lists and blob data must be stored by every node for syncing and block validation. So in theory an attack is possible in which a proposer deliberately misreports gas to get the block reverted while putting large data on chain cheaply. The source analyzes this attack as economically unsustainable. A proposer who misreports gas loses all execution layer rewards for that block, and the attack requires block production rights, which are a scarce resource on the consensus layer. The source concludes that the cost of giving up the rewards outweighs the potential gain.
Current status and discussion history
This EIP is a core change that requires a hard fork, and its source status is Stagnant. This means active progress has stopped, and it is not decided whether the content will be revived as is or changed. In the call records, it was discussed at AMA #14 on 08.29, and no decision was made.