EIP-7886: Delayed execution

Abstract

---

This proposal introduces a mechanism to make execution blocks statically verifiable through minimal checks that only require the previous state, without requiring execution of the block's transactions. This enables validators to attest to a block's validity without completing its execution.

Motivation

---

The primary advantage of this proposal is asynchronous block validation. In the current Ethereum protocol, blocks must be fully executed before validators can attest to them. This requirement creates a bottleneck in the consensus process, as attestors must wait for execution results before committing their votes, limiting the network's throughput potential.

By introducing a mechanism where execution payloads can be reverted rather than invalidating the entire block, execution is no longer an immediate requirement for validation. Instead, a block's validity can be determined based on its structural correctness and the upfront payment of transaction fees by senders. This allows attestation to happen earlier in the slot, independent of execution, potentially enabling higher block gas limits and significant throughput improvements across the network.

Specification

---

Header Changes

The block header structure is extended to support delayed execution:

The key changes are:

1. pre_state_root: Represents the state root before execution (checked against the post-execution state of the parent block)
2. parent_receipt_root: Receipt root from the parent block (deferred execution output)
3. parent_bloom: Logs bloom from the parent block (deferred execution output)
4. parent_requests_hash: Hash of requests from the parent block (deferred execution output)
5. parent_execution_reverted: Indicates whether the parent block's execution was reverted

A block header MUST include all these fields to be considered valid under this EIP. The pre_state_root MUST match the state root after applying the parent block's execution. The parent execution outputs MUST accurately reflect the previous block's execution results to maintain chain integrity.

Chain State Tracking

The blockchain object is extended to track execution outputs for verification in subsequent blocks:

These additional fields are used to verify the deferred execution outputs claimed in subsequent blocks. The last_transactions_root, last_receipt_root, last_block_logs_bloom, last_requests_hash, and last_execution_reverted act as critical chain state references that MUST be updated after each block execution to ensure proper state progression. When a block's execution is reverted due to a gas mismatch, the last_execution_reverted field is set to True, which affects the base fee calculation of subsequent blocks.

Block Validation

Static validation is performed separately from execution. In this phase, all checks that can be done without executing transactions are performed:

This validation function enforces several requirements:

1. Clients MUST validate that the block's parent execution outputs match the chain's tracked last execution outputs.
2. The pre_state_root MUST match the current state root to ensure proper state transition.
3. All transactions MUST be statically validated for signature correctness and transaction type-specific requirements (EIP-1559, EIP-4844, etc.).
4. Sender accounts MUST be externally owned accounts (EOAs) or have valid delegation support (EIP-7702).
5. Senders MUST have sufficient balance to cover maximum possible gas fees plus transaction value.
6. Transaction nonces MUST be correct and sequential per sender.
7. Total inclusion gas (using the maximum of intrinsic gas and EIP-7623 floor cost) MUST not exceed the block's declared gas_used.
8. Total blob gas MUST match the declared blob_gas_used.
9. Withdrawal trie root MUST match its respective header field.

When calculating inclusion gas, the implementation uses the maximum of the regular intrinsic gas cost and the EIP-7623 calldata floor cost, which ensures proper accounting for calldata gas regardless of execution outcome.

Block Execution with State Snapshots

After a block passes static validation, execution proceeds with the pre-charged transaction senders:

During block execution:

1. Clients MUST create a block-level snapshot before any transaction execution occurs. This happens after handling the system contracts from EIP-4788 and EIP-2935.

2. Maximum fees MUST be deducted from sender balances upfront by:

3. Transactions are executed sequentially until executing a transaction would cause the block to exceed the gas limit.

4. After execution, clients MUST verify that the total gas used matches the declared gas_used in the block header.

5. If the actual gas used doesn't match the declared value, clients MUST:

   • Set execution_reverted to True
   • Roll back to the snapshot taken before execution
   • Reset all execution outputs (receipts, logs, etc.)
   • Return zero gas used

6. The block itself remains valid, but execution outputs are not applied to the state.

7. General purpose requests as defined in EIP-7685 are skipped when execution is reverted.

8. The execution outputs (last_transactions_root, last_receipt_root, last_block_logs_bloom, last_requests_hash, last_execution_reverted) are updated in the chain state based on the execution results, and will be verified in subsequent blocks.

Execution SHALL be stopped and the payload reverted after exceeding the block gas limit:

Rationale

---

Deferred Execution Outputs

The core innovation of deferring execution outputs to the next block enables static and stateful validation without requiring immediate execution. The pre_state_root provides a cryptographically verifiable starting point for validation, while parent execution outputs create a chain of deferred execution results that maintains the integrity of the blockchain state.

This approach eliminates the execution bottleneck in the validation pipeline by allowing validators to attest to a block's validity based on its structure and the pre-charged transaction fees, without waiting for execution results.

Pre-Charging Mechanism

Pre-charging senders with the maximum possible fees before execution provides a crucial guarantee that transactions have sufficient balance to be included in the block. This mechanism is compatible with existing fee models, including EIP-1559 dynamic fee transactions and EIP-4844 blob transactions.

By tracking sender balances and nonces during validation, the protocol can enforce transaction validity without execution, enabling earlier block attestation.

State Snapshot Architecture

The block-level snapshot mechanism provides a way to revert execution when necessary. This approach allows clients to roll back the entire block's execution if the actual gas used does not match the declared gas in the header, without invalidating the block structure itself.

This provides two key benefits:

1. It allows validators to attest to blocks before execution is complete
2. It ensures execution is eventually performed correctly, with economic penalties for incorrect gas declarations

Execution Reversion Handling

When a block's execution is reverted due to gas mismatch:

1. The block itself remains valid and part of the canonical chain
2. The last_execution_reverted flag is set to True in chain state
3. The next block must include this flag as parent_execution_reverted
4. Base fee calculations for subsequent blocks use 0 as parent gas used when parent execution was reverted

Backwards Compatibility

---

This EIP requires a hard fork, as it alters the block validation and execution process.

Security Considerations

---

Execution Correctness Guarantees

The protocol ensures execution correctness through these primary mechanisms:

1. Deferred execution outputs MUST match in subsequent blocks, creating a chain of verifiable execution results.
2. State rollback MUST occur if the actual gas used doesn't match the declared value, providing an economic incentive for correct gas declaration.
3. The parent_execution_reverted flag ensures that blocks acknowledge when parent execution has been reverted, maintaining chain integrity.
4. Static and stateful validation guarantees that all transactions are properly authorized and senders have sufficient funds for maximum fees.

Base Fee Dynamics with Reverted Execution

When a block's execution is reverted, the next block's base fee calculation treats the parent's gas used as zero, regardless of what was declared in the header. This ensures that base fee adjustments remain responsive to actual chain usage, and prevents manipulation of the fee market through incorrect gas declarations.

Data Availability and Economic Incentives

Block proposers MUST declare correct gas usage or lose transaction fees when execution is reverted. This aligns incentives for correct gas declaration and ensures execution integrity.

Even when a block's execution is reverted due to incorrect gas declaration, the transaction data (calldata, EIP-2930 access lists, and blob data) MUST still be stored by all nodes for syncing and block validation purposes. This requirement creates a potential attack vector where malicious actors could attempt to place large amounts of data on-chain at a reduced cost by intentionally invalidating blocks through incorrect gas declarations.

However, this attack is not economically sustainable for several reasons:

1. Block proposers who invalidate blocks through incorrect gas declarations lose all execution layer rewards associated with the block.
2. The attack requires control of block production, which is a scarce resource in the consensus layer.

The economic costs of forgoing block rewards significantly outweigh any potential benefits, making such attacks financially impractical under normal network conditions.

Copyright

---

Copyright and related rights waived via CC0.