The Ethereum Virtual Machine (EVM) powers every smart contract and transaction on the Ethereum blockchain. While much attention is given to writing Solidity code, few developers dive into how the EVM actually manages state at a system level. In this article, we explore Ethereum’s “world state” — a critical concept that underpins the integrity and consistency of the entire network.
We’ll walk through the architecture of an Ethereum block, trace data structures from the block header down to individual contract storage, and examine how the Go Ethereum (Geth) client implements core operations like SSTORE and SLOAD. By the end, you'll have a clearer picture of how your smart contract data is stored, retrieved, and secured within Ethereum’s global state.
👉 Discover how blockchain state management powers decentralized applications
Ethereum Architecture Overview
To understand Ethereum’s world state, we begin with the structure of a block. Each block contains a header and a set of transactions, but it's the block header that holds the cryptographic commitments to the network’s current state.
The block header includes several key fields:
- Prev Hash: The hash of the previous block, ensuring chain continuity.
- Timestamp: Unix time when the block was created.
- Gas Limit & Gas Used: Define computational capacity and actual usage.
- State Root: A Merkle root hash representing the global state after all transactions in the block are executed.
- Transaction Root: Root of the Merkle Patricia Trie containing all transactions.
- Receipt Root: Root of the trie storing transaction receipts.
These roots enable efficient verification without downloading full data — a cornerstone of blockchain scalability and security.
Let’s focus on the State Root, which represents Ethereum’s “world state.” This single 256-bit hash commits to every account and its data across the network.
What Is the World State?
Ethereum’s world state is not stored directly as a database. Instead, it’s represented as a Merkle Patricia Trie (MPT) — a cryptographically secure data structure that maps Ethereum addresses to account states.
Each node in the trie is hashed, so any change to an account propagates upward and changes the final State Root. This ensures immutability and tamper-evidence: even a one-wei balance change alters the entire chain’s state fingerprint.
The world state consists of two layers:
- Account State: Maps addresses to account objects.
- Storage State: For contract accounts, maps storage slots to values.
This hierarchical hashing allows light clients to verify specific account data using Merkle proofs — a vital feature for decentralized trust.
Structure of an Ethereum Account
Every Ethereum account — whether externally owned (EOA) or contract-based — is defined by four fields:
- Nonce: Transaction counter for EOAs; number of contracts created for contract accounts.
- Balance: Account balance in wei (1 ETH = 10¹⁸ wei).
- Code Hash: Hash of the contract bytecode. For EOAs, this is the hash of an empty string.
- Storage Root: Root of another Merkle Patricia Trie that stores the contract’s internal data.
These fields are implemented in Geth via the StateAccount struct in core/types/state_account.go. The Storage Root field is particularly important — it links each contract to its private key-value storage space.
Diving Into Storage: The Storage Root
Just like the global state uses a trie, each contract has its own storage trie rooted at Storage Root. This trie maps 256-bit storage slot keys to 256-bit values.
Keys are typically Keccak-256 hashes of variable positions (e.g., keccak256(slot) for mappings), while values are RLP-encoded. Changes to any storage slot alter the Storage Root, which then cascades up to update the global State Root.
This design ensures that:
- Any storage modification affects the block’s final state hash.
- Full nodes can prove storage contents to light clients.
- Rollbacks and state diffs are possible via journaling mechanisms.
👉 Explore how smart contract storage impacts blockchain performance
From StateDB to StateAccount: Geth’s Internal Architecture
Geth manages state transitions during transaction execution using three core components:
1. StateDB
The main interface for querying and modifying state. It holds active stateObjects and handles commits to the underlying trie database.
2. stateObject
Represents a mutable in-memory version of an account during execution. It wraps a StateAccount and tracks pending changes.
3. StateAccount
Immutable representation of an account’s consensus state — corresponds directly to the on-chain format.
During execution, when a new contract is created, StateDB.createObject() initializes a blank stateObject with an empty StateAccount. This becomes the foundation for storing data via EVM opcodes.
How SSTORE Works in Geth
The SSTORE opcode writes data to contract storage. Here’s how it works in Geth:
- The EVM pops two values from the stack:
loc(key) andval(value). - Calls
StateDB.SetState(addr, loc, val). - If no
stateObjectexists for the address, one is created. - The operation checks if the value has changed and records the change in a journal for potential rollback.
- Updates
dirtyStorage, a map of modified slots (common.Hash → common.Hash).
dirtyStorage holds transient changes during transaction execution. It ensures that subsequent reads return the latest value — even within the same transaction.
This mechanism supports complex logic where a contract may read after writing to the same slot.
How SLOAD Retrieves Data
The SLOAD opcode reads from storage:
- Pops
loc(storage key) from the stack. - Calls
StateDB.GetState(addr, loc). Looks up the value in this order:
- First:
dirtyStorage(latest in-memory changes) - Then:
pendingStorage(committed but not yet finalized) - Finally:
originStorage(original state from trie)
- First:
This prioritization ensures correctness: recent writes take precedence over persistent storage.
If no prior write occurred, Geth fetches the value from the underlying Merkle trie using the Storage Root.
State Finalization and Commitment
At the end of a transaction or block:
- All
dirtyStorageentries are flushed. - The storage trie is updated.
- The new
Storage Rootis computed. - The global
State Rootis recalculated and included in the next block header.
This process guarantees that only valid, executed transactions affect the world state — maintaining consensus across all nodes.
Frequently Asked Questions (FAQ)
Q: What is Ethereum’s world state?
A: It’s a global mapping of all accounts and their data, cryptographically secured via a Merkle Patricia Trie. The state root in each block header commits to this structure.
Q: How does changing storage affect the block?
A: Any SSTORE operation modifies the contract’s storage trie, changing its root hash. This propagates up to alter the global state root, ensuring every state change is reflected in the blockchain.
Q: Why use Merkle Patricia Tries instead of regular databases?
A: MPTs allow secure, verifiable partial proofs. Light clients can confirm account balances or storage values without downloading the full chain — essential for decentralization.
Q: What happens to storage during a transaction rollback?
A: Geth uses a journal system to track changes. If execution reverts, it restores values from snapshots in originStorage, effectively undoing all writes.
Q: Can two contracts share storage?
A: No — each contract has its own isolated storage trie. However, delegate calls let one contract execute code from another while preserving the caller’s storage context.
Q: Is contract storage permanent?
A: Yes — unless explicitly deleted via SSTORE(0), data remains on-chain forever. This permanence is why careful storage design is crucial in smart contracts.
Understanding Ethereum’s world state reveals how decentralization meets data integrity. From block headers down to individual storage slots, every layer relies on cryptographic commitments and efficient data structures.
Whether you're auditing contracts or optimizing gas usage, knowing how SSTORE and SLOAD interact with Geth’s state management gives you a deeper edge in Web3 development.
👉 Learn how real-time state updates drive blockchain innovation