Skip to content
Financial Context Wiki

State Root

A state root is Ethereum's compact commitment to the post-block world state. Learn how nodes compute it, what account and storage proofs establish, and what the root cannot guarantee.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

A state root is a 32-byte cryptographic commitment in an Ethereum block header to the world state after that block has been processed. The world state maps addresses to accounts. Each account commits to its nonce, balance, storage root, and code hash; each contract’s storage root in turn commits to that account’s storage slots.

The root is a digest, not a downloadable snapshot. It lets nodes compare independently computed results and lets a verifier check an account or storage proof against a trusted block. The root alone cannot reconstruct the state, prove that state data is available, establish that a block is final, or show that a contract is economically safe.

“State root” is protocol-specific. Ethereum currently commits its execution-layer state with a modified Merkle-Patricia trie. Other networks may use different state models, encodings, hash functions, or authenticated data structures, so equal terminology does not make their roots or proofs interchangeable.

How it works

An execution client starts with the parent block’s state, validates and executes the new block under the active protocol rules, and applies the resulting account and storage changes. Schematically:

S_n = Υ(S_(n-1), B_n)

Here S_(n-1) is the parent state, B_n is all protocol-defined processing for the new block, and S_n is the resulting state. The client deterministically encodes that state in the state trie and computes its root hash. A valid block header must contain the same result; a mismatch means the block is invalid for that client.

In Ethereum’s state trie, the path for an account is derived from the address, while the encoded account contains the nonce, balance, storage root, and code hash. Contract code is referenced by its hash, and each contract has a separate storage trie. This nesting means a changed storage slot can change the contract’s storage root, then the encoded account, and finally the global state root.

The state root is distinct from the transactions root and receipts root in the same block header. The transactions root commits to ordered transaction data; the receipts root commits to execution receipts. None can substitute for another.

EIP-1186 defines eth_getProof, which can return an account proof and requested storage proofs for a specified block. A verifier still needs an authenticated block hash or state root, the correct trie and encoding rules, and an appropriate confirmation or finality policy.

Example

Suppose one transaction transfers ETH from Alice to Bob. Correct execution can change Alice’s nonce and balance, Bob’s balance, and the fee recipient’s balance. If the transaction calls a contract, storage slots and the contract’s storage root may also change. These updates lead to a new global state root even though most accounts were untouched.

Two honest clients that begin from the same parent state and process the same valid block under the same rules should compute the same root. If one client credits the wrong amount or uses the wrong trie encoding, its root will differ from the header and it must reject the block rather than silently accepting its local state.

To verify Bob’s balance without downloading the entire world state, a verifier can obtain the block header and an account proof. Recomputing the proof path shows whether the encoded account is consistent with that header’s state root. It does not prove that the selected header is canonical or finalized; that comes from the verifier’s chain and finality checks.

Risks

  • Untrusted root: A valid proof against an attacker-selected or stale root proves the wrong reference point. Bind the root to a verified block hash, chain ID, and block number.
  • Reorganizations and finality: A proof can be correct for a block that later leaves the canonical chain. Match confirmation depth or finality to the application’s loss tolerance.
  • Encoding mistakes: Address hashing, RLP encoding, nibble paths, embedded nodes, and storage-key handling must follow the exact protocol rules. A generic binary Merkle-proof library is not enough.
  • Missing data: A root commits to state but does not make trie nodes, historical state, or proof-generation services available. Pruned nodes may be unable to serve old proofs.
  • Overstated assurance: Root agreement detects inconsistent execution; it does not audit contract logic, authenticate oracle inputs, secure an RPC endpoint, guarantee asset value, or prevent compromised keys from authorizing transactions.

Common misconceptions

  • The state root stores every account balance. It is a fixed-size commitment to an encoded trie; the underlying trie data must be obtained separately.
  • Matching state roots prove that two nodes have identical databases. They commit to the same logical world state under the protocol rules, but clients may store, index, prune, or cache that state differently.
  • A different state root identifies the bad transaction. It reveals disagreement in the final committed state, not where the divergence began; clients must trace execution to diagnose it.
  • A valid account proof proves finality and safety. It proves consistency with one root. Chain selection, finality, data freshness, contract behavior, and economic risk remain separate questions.

Sources

Navigation

Search the wiki...