World State (Global State Root)

The World State is not stored directly in blocks. Instead, each block header contains a state root, a single hash (e.g., a Merkle-Patricia Trie root) that cryptographically commits to the entire global state. This allows any node to efficiently prove the existence and validity of an account's balance or smart contract storage without downloading the entire state.

Unlike a simple ledger of transactions, the World State is a mapping of account addresses to their current state. For Ethereum-like systems, this includes:

• Nonce: Number of transactions sent from the account.
• Balance: Amount of native currency (e.g., ETH).
• Storage Root: Hash of the account's contract data (for smart contracts).
• Code Hash: Hash of the contract's immutable bytecode.

The World State is a mutable database that changes with every block. It is derived by sequentially applying the transactions in a block to the previous state. It is ephemeral; only the transaction history and the resulting state roots are permanently stored on-chain. Full nodes maintain a local copy of the current state for validation.

The trie structure of the World State enables light clients to operate. A light client can query a full node for a specific account's data along with a Merkle proof. By hashing the provided data and checking it against the known state root in a block header, the client can verify the data's authenticity without trusting the node.

A key challenge is state bloat, where the size of the World State grows indefinitely as more accounts and contracts are created. Solutions include:

• State Pruning: Discarding old, unreferenced state data while preserving cryptographic proofs.
• Stateless Clients: Clients that verify blocks using proofs without storing the state.
• State Expiry: Archiving inactive state after a period.

It is crucial to distinguish the World State from the blockchain (transaction history).

• History: An immutable, append-only log of all transactions (the chain of blocks).
• World State: The mutable, current outcome of executing that entire history. The state root in each block header links the immutable history to its resulting state.

The world state root is a core component of block validation. Each new block header contains the state root after applying its transactions. Validators recompute this hash; a mismatch indicates an invalid state transition, causing the block to be rejected. This mechanism ensures all nodes agree on a single, canonical global state without transmitting the entire state data.

Light clients, which don't store the full state, rely on the state root for trust. They can request Merkle proofs (or Verkle proofs) from full nodes. These proofs cryptographically demonstrate that a specific account balance or storage value is part of the committed global state, as defined by the root hash in a trusted block header.

Bridges and orcles use state roots to verify events or data on another chain. A light client bridge on Chain A can verify the state root of Chain B, then prove that a specific transaction was included and that its resulting state change is canonical. This is more secure than trusting a multisig for state attestations.

New nodes can sync faster using snapshots. Instead of replaying all historical transactions, they download a serialized world state (accounts, storage) tagged with its state root. They verify the snapshot's integrity by recomputing the root hash, ensuring they start from a valid, recent state.

Future scaling designs like stateless clients push state storage off-chain. Here, the state root is essential. Blocks come with witness data (Merkle proofs) for the touched state. Clients only need the block header and witness to validate transactions, verifying all proofs against the expected post-block state root.

In Ethereum, the world state is a Merkle Patricia Trie (MPT). The stateRoot in the block header is the root hash of this trie, which encodes all accounts (balance, nonce, codeHash, storageRoot). Any change to an account's state alters the root hash, providing a tamper-evident summary of the entire network state.

A cryptographic data structure used to efficiently and securely verify the contents of large datasets. The World State root is the Merkle root (or hash) of this tree.

• Leaves represent individual account states (balance, nonce, storage, code).
• Any change to a single leaf propagates up, changing the root hash.
• Enables light clients to verify state inclusion without downloading the entire chain.

The specific Merkle Patricia Trie data structure used in Ethereum to store the World State. It's a modified Merkle tree optimized for key-value mapping and efficient updates.

• Keys are 160-bit addresses (or storage keys).
• Values are RLP-encoded account states.
• Provides cryptographic commitment to the entire state while allowing for partial traversal and proof generation.

Each block header contains the stateRoot field, which is the cryptographic hash of the World State trie root after applying all transactions in that block.

• This creates a state commitment for that specific block height.
• Any node can cryptographically prove the state of an account at a past block by providing a Merkle proof against this root.

A blockchain state model where the World State is a mapping of account addresses to their state (balance, nonce, etc.). This contrasts with the UTXO model used by Bitcoin.

• Ethereum uses this model for both Externally Owned Accounts (EOAs) and Contract Accounts.
• The World State trie directly stores these account objects, making balance and nonce queries straightforward.

The deterministic function that defines how the World State changes from block to block. It takes the previous state, a block of transactions, and the block metadata as input, and outputs a new state root.

• Executing all transactions in order applies the function.
• All honest nodes applying the same transactions must compute the identical new state root, ensuring consensus.

Different modes for storing World State history.

• Archive Node: Stores the historical World State for every single block. Essential for deep historical queries but requires massive storage (multi-terabyte).
• Pruned Node: Only stores the current World State and recent history, discarding older state tries. This is the standard mode for most nodes, requiring far less storage.