Proposal: Delay stateRoot Reference to Increase Throughput and Reduce Latency
By: Charlie Noyes, Max Resnick
Introduction
Right now, each block header includes a stateRoot
that represents the state after executing all transactions within that block. This design requires block builders and intermediaries (like MEV-Boost relays) to compute the stateRoot
, which is computationally intensive and adds significant latency during block production.
This proposal suggests modifying the Ethereum block structure so that the stateRoot
in block n
references the state at the beginning of the block (i.e., after executing the transactions in block n - 1
, rather than the state at the end of the block).
By delaying the stateRoot
reference by one block, we aim to remove the stateRoot
calculation from the critical path of block verification at the chain tip, thereby reducing L1 latency and freeing up capacity to increase L1 throughput.
Technical Specification (High-Level)
When validating block n
, nodes ensure that the stateRoot
matches the state resulting from executing block n-1
(i.e., the pre-state root of block n
).
To be clear, there is no change to exeuction ordering. Transactions in block n
are still applied to the state resulting from block n-1
.
Motivation
stateRoot
calculation and verification is unnecessary work on the critical path of block production. A builder cannot propose a block on MEV boost without first calculating the stateRoot
and the attestation committee cannot verify a block without computing the stateRoot
to compare with the proposed stateRoot
. stateRoot
calculation itself accounts for approximately half of time spent by all consensus participants working at the tip. Moreover, whatever latency implications the stateRoot
calculation imposes are paid twice on the critical path: once at the block building stage and then again during verification.
-
- When block builders submit blocks to relays, they are required to provide the calculated
stateRoot
. From surveying three of the four largest builders, each spends on average only 40%-50% of their time actually building each block, and the rest onstateRoot
calculation.
- When block builders submit blocks to relays, they are required to provide the calculated
-
- When MEV-Boost relays recieve blocks from builders, they are supposed to verify their correctness. In Flashbots’ relay, also approximately half of the ~100ms (p90) verification time is spent on the
stateRoot
calculation.
- When MEV-Boost relays recieve blocks from builders, they are supposed to verify their correctness. In Flashbots’ relay, also approximately half of the ~100ms (p90) verification time is spent on the
-
- When validators receive a new block, or when non-MEV-Boost validators (“home builders”) produce a block, they are also required to re-verify its execution and its
stateRoot
. Commodity hardware Reth nodes spend approximately 70% of its time in live-sync on thestateRoot
(remainder on execution).
- When validators receive a new block, or when non-MEV-Boost validators (“home builders”) produce a block, they are also required to re-verify its execution and its
These participants - builders, relays, and validators - are highly latency sensitive. They operate under tight timing constraints around slot boundaries (particularly with the incresaing prevalence of timing games).
The latency introduced by stateRoot
verification at the tip is unnecessary and removing it could allow us to improve the health of the block production pipeline, and network stability.
Benefits of Delaying the stateRoot
- Higher L1 throughput, because the time currently spent verifying the
stateRoot
can be re-allocated to execution.stateRoot
verification would be pipelined to occur in parallel with the next slot (i.e. during time that nodes are currently idle). Bandwidth requirement increases and state growth would also need to be acceptable before activating a throughput increase. - Time saved by pipelining the
stateRoot
could also be allocated towards lowering slot times - improving L1 Ethereum UX, and likely resulting in tighter spreads for users of decentralized exchanges. - Builders and relays avoid an unnecessary latency speedbump. Both are highly latency-sensitive actors. We want to minimize the sophistication it takes to be a relay or validator. Removing
stateRoot
latency from the critical path of block verification means they will no longer have to worry about optimizing it, improving the health and efficiency of the block production pipeline.
Potential Downsides and Concerns
Impacted Applications
- Light Clients and SPV Clients
- Impact: These clients rely on the latest
stateRoot
to verify transactions and account balances without downloading the entire blockchain. A one-block delay introduces a latency in accessing up-to-date state information. Cross-chain communication protocols (like bridges that utilize light clients) would also experience this delay. -
- Consideration: We do not see an obvious issue with light clients being delayed by a single block.
- Stateless Client Protocols
- Impact: Stateless clients rely on the latest
stateRoot
to verify transaction witnesses. A one-block delay could affect immediate transaction validation. -
- Consideration: If these clients can tolerate a one-block delay, the impact may be minimal. This aligns with ongoing discussions in the statelessness roadmap.
Rationale
Why This Approach?
- Efficiency: Removing
stateRoot
computation from the critical path significantly reduces block verification time. - Simplicity: The change is straightforward in terms of protocol modification, affecting only the placement of the
stateRoot
reference. This is backwards-compatible with the existing block production pipeline (i.e., native building and MEV-Boost). Other proposals which include execution pipelining, like ePBS, are significantly broader in scope and complexity. Delaying thestateRoot
is a simpler change we can make with immediate benefit and little risk. - Minimal Disruption: While some applications may be affected, we think most (all?) can tolerate a one-block delay without significant issues. We should collect feedback from application developers to validate this.
Backwards Compatibility and Transition
- Hard Fork Requirement: This change is not backwards compatible and would require a network hard fork.
- Application Adaptations: Affected applications (light clients, Layer 2 solutions, stateless clients) may need to adjust their protocols or implementations.
Request for Feedback
We invite the community to provide feedback on this proposal, particularly:
- Feasibility: Are there technical challenges that might impede the implementation of this change?
- Upside: How much throughput will we be able to eke out from pipelining
stateRoot
calculation, and reallocating the time to exeuction? - Affected Applications: We don’t obviously see a class of widely used applications which would be affected. We hope any developers whose applications do depend on same-block
stateRoot
will let us know.
Next Steps
We plan to formalize this proposal into an EIP for potential inclusion in Pectra B.
Acknowledgements
Thanks to Dan Robinson, Frankie, Robert Miller, and Roman Krasiuk for feedback and input on this proposal.