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.
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.
The block header structure is modified to support delayed state root computation:
The key change is:
state_root: Now represents the post-state root of block n-1 instead of block nA 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.
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.
Header validation is modified to verify the delayed state root:
The state transition function applies a block to the chain with delayed state root computation:
During block processing:
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.
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.
The time currently spent on same-slot state root computation can be repurposed for:
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:
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.
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.
Light clients must adapt to the one-slot delay in state root availability:
n become available only after block n+1 is producedDuring chain reorganizations:
Copyright and related rights waived via CC0.