Accounts, State & the World Computer

The Foundations part made a promise: Ethereum is not a ledger that moves coins, it is a world computer — a single shared machine whose current state everyone agrees on. This part is where we make that word “state” concrete. Before an opcode runs, before a gas unit is priced, before a single hash is computed over a trie, there has to be a thing being computed on. That thing is the world state, and its shape is the first design decision Ethereum makes that Bitcoin never had to.

So this part answers the front half of the book’s question — how do untrusting strangers agree on the state of a shared world computer — by asking what that state even is. The answer is not “a pile of coins.” It is a mutable, addressable map that every node must hold identically and advance in lockstep. Getting that map right is what the next five pages build, one layer at a time.

The whole part in one line: to run a shared world computer, untrusting strangers must agree not on a pile of coins but on the current value of a mutable, addressable state — and keeping that agreement is not free.

Why a programmable ledger needs a different shape

Bitcoin keeps no balances. Its entire state is the UTXO set — a pile of discrete, unspent coins, each spendable exactly once. A transaction consumes some coins and creates new ones; the old coins vanish. There is no row anywhere that says alice: 50. That model is beautiful for money and useless for a computer, because a computer needs somewhere to remember things between operations — and a UTXO is designed to be forgotten the instant it is spent.

Ethereum flips this around. Its state is a single global map, one entry per account:

   BITCOIN                              ETHEREUM
   ───────                              ────────
   a SET of coins                       a MAP of address → account

   spend  = destroy coins,              transfer = edit two rows
            create new coins                       in place

   balance is DERIVED                   balance is STORED
   (sum the coins you can unlock)       (a number in your account row)

   no per-program memory                every account can carry
   (coins are forgotten)                persistent storage (it remembers)

The move from set to map, and from derived to stored, is the whole part in miniature. A map with mutable, persistent values is exactly the substrate a program needs: a token whose balances change, a market whose order book evolves, a vote whose tally grows. The account model is not a stylistic preference — it is the minimum viable substrate for programmability. And the moment state becomes both shared and mutable, you inherit a new set of hard problems — ordering, replay, determinism — that Bitcoin’s stateless coins never posed. The rest of this part is the bill for that expressiveness.

What “state” means in this book

Throughout this book, state means persistent, shared, mutable data: it survives between transactions, every node holds the identical copy, and transactions change it in place. Hold all three properties at once. Persistence is what lets a contract remember; sharing is what lets strangers agree; mutability is what lets the world move. Bitcoin’s UTXO set has none of them in this strong sense — a coin is created once and spent once, never edited. This trio is the substrate the EVM (a later part) runs on, and the thing gas (also later) charges you to change.

The four building blocks this part covers

The part is a ladder. Each page establishes one idea the next one stands on:

1. The contrast — why accounts, stated against UTXOs, so the account model’s costs (nonces, ordering, no free parallelism) are visible as deliberate trades, not accidents.
2. The two kinds of account — an Ethereum account is either an Externally Owned Account (EOA), controlled by a private key (a wallet), or a contract account, controlled by code. That single split is what makes “programs on a ledger” possible.
3. The account record — every account is four fields: nonce, balance, storageRoot, codeHash. Four fields, and the entire world-computer idea is hiding in which four.
4. The global state map — assemble every account into one map, address → account. That map is the world state: the complete, agreed-upon snapshot of the machine at a point in time.
5. The state-transition function — the rule that takes one world state, applies a transaction, and produces the next. This is what “advancing the world computer” means, formally: stateₙ → stateₙ₊₁.

   address ──▶ ┌───────────────────────────────┐
               │ nonce        (txs sent so far) │   ← the ACCOUNT RECORD
               │ balance      (wei held)        │      (page 4)
               │ storageRoot  (contract memory) │
               │ codeHash     (contract code)   │
               └───────────────────────────────┘

   { addr₁ → account, addr₂ → account, … }         ← the WORLD STATE MAP
                                                       (page 5)

   stateₙ ──apply(tx)──▶ stateₙ₊₁                    ← the STATE TRANSITION
                                                       (page 6)

Read those three pictures top to bottom and you have the whole part: a record, a map of records, and a rule for advancing the map.

The roadmap

Read the pages in order — each row builds on the one above it.

#	Page	The idea it establishes	Depends on
2	Two Ledgers: UTXO vs the Account Model	Why Ethereum stores a mutable map of balances instead of a pile of coins — and what parallelism and privacy that costs	Foundations
3	Two Kinds of Account: EOAs and Contracts	The split between key-controlled wallets and code-controlled contracts — the door to programmability	Page 2
4	Inside an Account: nonce, balance, storageRoot, codeHash	The four fields of one account record, and why each earns its place	Page 3
5	The World State: A Map of address → account	How individual accounts assemble into one global, agreed-upon state	Page 4
6	State Transitions: Advancing the World Computer	The rule that turns one world state into the next when a transaction is applied	Page 5
900	Revision: Accounts, State & the World Computer	Everything above, condensed into recall prompts and one worked trace	All of the above

Where this part points next: once you have a state and a rule for changing it, the natural questions are how is that state stored and proven? — the State & Tries part — and what actually runs inside a transition and what does it cost? — the EVM and gas parts. This part gives all of them their subject.

The thread

How do untrusting strangers agree on the state of a shared world computer? This part answers the state clause. Bitcoin lets strangers agree on a set of coins by making each spend a local, order-free question of “does this coin exist and may I unlock it?” Ethereum asks for more — a mutable, programmable state — and so it must ask strangers to agree on something harder: not just which transactions happened, but the current value of every account after replaying them all, in the same order, to the same result. That agreement is what a “world computer” requires and what the rest of the book pays for. A record, a map of records, and a deterministic rule for advancing the map: get those three right and every stranger, starting from the same state and the same transactions, computes the identical next state. That is agreement, and it is the foundation everything else in this book is built on.

Check your understanding

1. In one sentence, what does the word state mean in this book, and which three properties must it have at once?
2. Bitcoin’s state is a set and Ethereum’s is a map. Restate that difference in terms of how each represents “Alice’s balance” and how each changes it during a transfer.
3. Name the four building blocks this part covers, in the order the pages present them.
4. Why is the account model called “the minimum viable substrate for programmability” rather than just a design preference?
5. Using the book’s question, state which clause this part answers and what “agreement” concretely requires of every node.

Show answers

1. State means persistent, shared, mutable data: it survives between transactions (persistent), every node holds an identical copy (shared), and transactions change it in place (mutable). All three must hold at once.
2. Bitcoin (set): Alice’s balance is derived — the sum of the unspent coins her keys can unlock; a transfer destroys whole coins and creates new ones (including her change). Ethereum (map): her balance is stored directly as a number in her account row; a transfer edits two rows in place, debiting her and crediting the recipient.
3. (1) The UTXO/account contrast; (2) the two kinds of account — EOAs vs contracts; (3) the account record’s four fields — nonce, balance, storageRoot, codeHash; (4) the global state map, address → account; and (5) the state-transition function that advances it.
4. Because a program is nothing without memory: it needs a cell of state that persists between calls, is shared so every node agrees on its value, and mutates in place. UTXOs provide none of these by design (coins are created once, spent once, and forgotten), so accounts are not a nicer option — they are the smallest structure that can hold evolving program state at all.
5. This part answers the state clause of how do untrusting strangers agree on the state of a shared world computer? Agreement concretely requires that every node, starting from the same world state and replaying the same transactions in the same order, computes the identical next state — the current value of every account, not just the list of what happened.