Skip to content

Proposal: Delayed State Root for Sub-Second Block Times #236

@frisitano

Description

@frisitano

Describe the feature

In the context of sub-second block times, computing the state root at the end of the block introduces latency that is difficult to predict. This unpredictability forces us to be conservative during payload construction to ensure we can meet timing constraints, often resulting in fewer transactions per block to accommodate a buffer for state root computation.

To address this, we propose introducing a delayed state root mechanism. By decoupling state root computation from the critical path of payload building, we can improve performance and unlock more efficient transaction processing.

However, this change presents several downstream considerations, particularly with respect to zk proving. Specifically, we need a reliable mechanism to associate the state diff of a block’s execution with the state root declared in the subsequent block.

Proposal
Introduce a delayed state root model: The payload produced for block n will not include the state root directly. Instead, the state root will be computed after execution and only reflected in block n+1.

Use extra_data for linkage: We can leverage the extra_data field to encode a serial hash of the state diff from the prior block’s execution, creating a verifiable link between the state transition and the declared state root.

ZK Proving Considerations: This model would require that zk provers be able to verify that the state root claimed in block n+1 is the result of executing the state diff from block n. This may involve changes to the proof structure or witness format to incorporate such linkage.

Benefits
Enables more efficient payload building by removing a major source of latency from the critical path.

Improves stability of sub-second block times.

Potentially simplifies block building under high load conditions.

Open Questions
What are the trade-offs in terms of proof complexity and client implementation?

How do we ensure backward compatibility with existing consensus and execution APIs?

Are there more robust alternatives to using extra_data for linking state diffs?

Additional context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    Status

    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions