EIP-7862: Delayed State Root

Abstract

This proposal introduces a mechanism to decouple state root computation from block validation by deferring the execution layer's state root reference by one block. Each block's ExecutionPayload contains the post-state root of the previous block rather than its own, enabling validators to attest to a block's validity without waiting for state root computation.

Motivation

The primary advantage of this proposal is asynchronous state root computation. In the current Ethereum protocol, blocks must compute and include their own post-state root before validators can attest to them. This requirement creates a bottleneck for block production, as the expensive state root computation must complete within critical path.

By deferring the state root reference by one block, validators can attest to blocks based on transaction execution alone, without waiting for the state root calculation. This allows state root computation to be pipelined during idle slot time, potentially enabling higher block gas limits and accelerating the timeline for real-time zero-knowledge proving of Ethereum blocks.

Specification

Header Changes

The block header structure is modified to support delayed state root computation:

The key change is:

1. state_root: Now represents the post-state root of block n-1 instead of block n

A block header MUST include the delayed state_root to be considered valid under this EIP. The state_root MUST match the post-state root after applying the parent block's execution.

Chain State Tracking

The blockchain object is extended to track the last computed state root:

This additional field is used to verify the delayed state root claimed in subsequent blocks. The last_computed_state_root acts as a critical chain state reference that MUST be updated after each block execution to ensure proper state progression.

Block Validation

Header validation is modified to verify the delayed state root:

State Transition

The state transition function applies a block to the chain with delayed state root computation:

During block processing:

1. Clients MUST validate the block's structure including the delayed state root
2. Transaction execution proceeds normally
3. State root computation happens after execution and is stored for the next block
4. The computed state root MUST be available before the next block for validation

Fork Activation

Upon activation at block F:

The activation block F MUST contain the post-state root of its parent block F-1. This is achieved by initializing chain.last_computed_state_root to the current state root before processing block F. From block F+1 onwards, the normal delayed root scheme applies where each block contains the post-state of its parent.

Rationale

Latency Reduction

The separation of state root computation from block validation removes the primary latency bottleneck in block production and validation. Proposers and builders no longer need to compute the state root within the same slot, enabling faster block building and validation.

This latency reduction is particularly important in the context of Proposer-Builder-Separation, where builders compete on construction speed. By removing state root computation from the critical path, builders can allocate more time to transaction ordering optimization.

Throughput Improvements

The time currently spent on same-slot state root computation can be repurposed for:

1. Higher gas limits: Additional execution capacity without increasing slot times
2. Faster slot times: Reduced slot duration while maintaining the same gas limit
3. Enhanced MEV extraction: More time for builders to optimize block construction

Zero-Knowledge Proving Compatibility

Merkle root computation is particularly expensive for ZK proving systems due to the non-ZK-friendly nature of the Keccak hash function. Without delayed state roots, real-time SNARK proofs would require:

1. State root proving within sub-second timeframes after block construction
2. Integration with the MEV pipeline's tight timing constraints
3. Unrealistic computational requirements for current proving systems

With delayed state roots, ZK proofs can be generated during the ~12 second window between blocks, making real-time proving feasible with current technology. This change is likely necessary for Ethereum's transition to ZK-based verification.

Backwards Compatibility

This EIP requires a hard fork and is not backwards compatible. Clients that do not implement this change will reject blocks with delayed state roots as invalid.

Security Considerations

Light Client Impact

Light clients must adapt to the one-slot delay in state root availability:

1. Proof availability: State proofs for block n become available only after block n+1 is produced
2. Latency tolerance: Most light client protocols already accommodate proof generation delays
3. Security model: The security guarantees remain unchanged; only the timing of proof availability shifts

Chain Reorganization Handling

During chain reorganizations:

1. Clients MUST recompute state roots for all blocks in the new canonical chain
2. The delayed nature of state roots does not affect the reorganization logic
3. State root validation continues to enforce chain integrity across reorganizations

Copyright

Copyright and related rights waived via CC0.