Accounts and global state

Wonder

1. Why does tracking wealth as a collection of unspent outputs make it difficult to write general-purpose programs?
2. What mechanical consequence follows from allowing any transaction to read and write the entire network’s storage?
3. How does an account-based model change the cost of verifying history compared to a UTXO set?

Explore

1. Bitcoin tracks value as unspent transaction outputs, or UTXOs. Each transaction consumes specific inputs and creates new outputs; validation checks only the coins being spent (lesson 2.2.1). This model is local and discrete. Ethereum, launched in July 2015 by Vitalik Buterin and co-founders including Gavin Wood, adopts an account-based state machine. Every address holds a balance that updates in place. The network’s entire history compresses into a single global state object: the current balances of all accounts and the storage slots of all deployed contracts.
2. In this model, two account types exist: externally owned accounts (EOAs), controlled by private keys, and contract accounts, controlled by code. An EOA initiates transactions; a contract executes logic only when invoked. The state transition function takes the current global state and a transaction, then produces a new global state. Because every node computes this transition deterministically from the same starting point, consensus emerges without trust. This structure makes general-purpose computation possible, as any account can hold arbitrary data in its storage.
3. The expressiveness of the account model enables complex applications like decentralized exchanges and lending protocols. A contract can hold billions in value and execute intricate logic based on global conditions. However, this power introduces fragility. Since state is mutable and shared, a single bug in one contract’s code can drain its entire balance or corrupt linked contracts. The re-entrancy vulnerability exploited in The DAO hack (June 2016) demonstrated how a local flaw could impact the global state, leading to a community-driven fork.
4. State growth is an inherent consequence of this design. Bitcoin’s UTXO set also grows, but each entry is small and is deleted when spent; Ethereum’s contract storage accumulates. Every `SSTORE` operation adds data that persists indefinitely unless explicitly zeroed (which still costs gas). This unbounded growth makes running a full node increasingly heavy in terms of disk space and memory. Nodes must maintain the entire global state to validate transactions, creating a trade-off between computational expressiveness and verification cost.
5. The Ethereum Yellow Paper formalizes this as a deterministic state transition function. The EVM processes instructions on a stack machine, where operations like `ADD` or `SLOAD` modify the local execution context while potentially updating the global account storage. This architecture allows for Turing completeness but requires gas to ensure termination. Every operation consumes gas, preventing infinite loops and bounding the computational cost of any single transaction relative to the block’s gas limit.
6. Open a block explorer like Etherscan and inspect a recent contract interaction. Observe the ‘Storage’ tab on the contract page; it lists key-value pairs that constitute the account’s persistent state. Note how these values change after each transaction involving that address. This view reveals the concrete reality of global state: code is not just executed but stored, with its data persisting across transactions and growing over time.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• G. Wood, 'Ethereum: A Secure Decentralised Generalised Transaction Ledger' (Yellow Paper, 2014)
• V. Buterin, 'Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform' (2013/2014)
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023)