Rollup State Root

Overview

What it means in plain English

A rollup state root is a cryptographic commitment summarizing the rollup's account, contract, and storage state after a defined batch. The rollup submits roots to a settlement or verification contract together with batch references, proofs, or challenge data. A validity proof can demonstrate that a new root follows correctly from the prior one, while an optimistic system allows disputed roots to be challenged.

How it works and why it matters

A rollup state root commits to the complete logical state produced after executing a sequence of rollup transactions. Small changes to balances, code, or storage should produce a different root. The rollup submits roots to a settlement or verification contract together with batch references, proofs, or challenge data. A validity proof can demonstrate that a new root follows correctly from the prior one, while an optimistic system allows disputed roots to be challenged. The root is compact, but it is not the state itself and cannot restore missing data. Nodes still need transaction data or state differences to reconstruct and serve the rollup. Integrators must bind the root to the correct rollup, block, batch, and settlement status before treating it as finalized.

Implementations of Rollup State Root need deterministic encoding and version-aware validation. For Rollup State Root, cross-client tests should cover empty values, boundary cases, upgraded data structures, and reorganization recovery so the same evidence produces the same interpretation across independent systems. Rollup State Root should be tied to a specific network, block hash, protocol version, and state-transition rules. For Rollup State Root, a state value without that context can become ambiguous after a reorganization, upgrade, or replay on another network even when the serialized bytes appear valid. A commitment associated with Rollup State Root proves only what its verification rules establish. For Rollup State Root, commitment integrity, data availability, execution correctness, and historical retrievability are separate properties; a valid root or proof does not by itself guarantee that every application can reconstruct the underlying state.

Worked example

After processing a batch, a rollup computes a compact commitment to its updated balances and contracts. It submits that state root to a settlement contract. Depending on the rollup design, a validity proof or dispute period determines whether the commitment becomes accepted for L1 settlement.

Practical checks and common confusion

A state root is a fingerprint of an entire state, not a payment receipt or a list of customer transfers. To prove a particular balance or transaction, additional witness data or transaction inclusion evidence is needed. Check publication and proof status rather than the root alone.

Learn the related concepts

Segregated Witness (SegWit) Supported Network

Primary documentation

Ethereum: Optimistic Rollups.