A Ledger Is Already a State Machine

The part overview asked the question this whole book turns on: how do untrusting strangers agree on the state of a shared world computer — and what does it cost to run one? Before we can answer it for Ethereum, we need one lens that makes every later chapter legible. This page installs it.

The lens is this: a blockchain is a state machine. Not “like” a state machine — it is one, in the precise, boring, computer-science sense of the term. Once you see a plain payment ledger as a state machine, Ethereum stops looking like a new invention and starts looking like the same machine with a more powerful transition rule. Everything the rest of the book builds — accounts, the EVM, gas, consensus — is either part of the state, part of the transition function, or part of the machinery that makes strangers agree on which one to run next.

What a state machine actually is

Strip away the blockchain for a moment. A state machine, formally, is three things:

1. A state — a snapshot of everything the system currently knows. Call it S.
2. A set of inputs — the events that can happen. Call each one a transaction tx.
3. A transition function — a rule that takes the current state and one input and produces the next state. Write it S' = apply(S, tx).

That is the entire definition. You feed the machine a state and a transaction; it hands you back a new state. Feed the new state the next transaction; get another state. A blockchain is nothing more than this loop run forever, over an agreed sequence of transactions:

   S₀ ──apply(tx₁)──▶ S₁ ──apply(tx₂)──▶ S₂ ──apply(tx₃)──▶ S₃ ── ⋯

   S₀ : the genesis state (the world at block zero)
   txₙ: the n-th transaction in the agreed order
   Sₙ : the state after applying the first n transactions

The ethmini companion crate for this book states it in the same words, right at the top of its state module:

//! A blockchain is, formally, a **state machine**: a current state, plus a rule
//! for turning one state into the next given a transaction. Bitcoin's state is a
//! set of unspent outputs; Ethereum's is a map from address to account.
//! Everything else (blocks, consensus, the peer-to-peer network) exists only to
//! agree on *which* sequence of transactions to feed this function, and in what
//! order.

Read that last sentence twice, because it is the shape of the whole book. There are only two hard problems. One is the transition function — what does apply do? The other is agreement — which transactions, in which order, does everyone feed it? Blocks, mining, staking, and the peer-to-peer network are all in service of the second question. Accounts, the EVM, and gas are all in service of the first.

The simplest possible machine: a payment ledger

Now put a blockchain back, but the plainest one imaginable — a pure payment ledger, no contracts, no programmability. What are the three pieces?

• The state is just who owns what: a map from account to balance.

  S = { alice: 100, bob: 0, carol: 25 }

• A transaction moves value: “send v from X to Y”.

• The transition function debits the sender and credits the receiver, after checking the sender can afford it:

  apply(S, "alice sends 30 to bob"):
      require  S[alice] ≥ 30            (can't spend what you don't have)
      S[alice] := S[alice] − 30         → 70
      S[bob]   := S[bob]   + 30         → 30

Apply it and the state advances by exactly two edited numbers:

   before: { alice: 100, bob:  0, carol: 25 }
              │ apply("alice sends 30 to bob")
              ▼
   after:  { alice:  70, bob: 30, carol: 25 }

That is a complete, if minimal, blockchain state machine. Bitcoin is a more careful version of this idea (its state is a set of unspent coins rather than a balance map — we cover that contrast in Bitcoin’s Deliberate Limits and again in depth in Accounts and State), but the skeleton is identical: a shared state, transactions that move value, and a rule that produces the next state. Money on a blockchain is the smallest interesting state machine there is.

Here is the same machine as a few lines of the book’s companion crate — a real, tested transition:

use ethmini::{WorldState, Transaction};

// S₀ : the genesis state — alice funded with 100, everyone else at 0.
let mut state = WorldState::genesis(&[(alice, 100)]);

// tx : "alice sends 30 to bob", the 0th transaction alice has ever sent.
let tx = Transaction::transfer(alice, /* nonce */ 0, bob, 30);

// apply(S, tx) -> S′ : the transition function, run once.
state.apply(&tx).unwrap();

assert_eq!(state.balance(&alice), 70); // debited
assert_eq!(state.balance(&bob),   30); // credited

WorldState::apply is the transition function. Everything else in this book — every opcode, every gas rule, every consensus mechanism — is a more elaborate version of, or a support system for, that one method.

Why the function must be deterministic

Here is where a shared ledger stops resembling a normal program. On your laptop, a function can read the clock, ask for a random number, or depend on how much memory happens to be free. A blockchain’s transition function can do none of these, and the reason is the entire point of the book.

A blockchain isn’t run on one computer. It’s run on thousands, by strangers who don’t trust each other, each holding their own copy of the state and each applying the same transactions independently. This is a replicated state machine: the same machine, evaluated redundantly, everywhere.

   the SAME agreed transaction stream, fed to every node:

   node A:  S₀ ─apply(tx₁)▶ S₁ ─apply(tx₂)▶ S₂ ─ ⋯ ─▶ Sₙ
   node B:  S₀ ─apply(tx₁)▶ S₁ ─apply(tx₂)▶ S₂ ─ ⋯ ─▶ Sₙ
   node C:  S₀ ─apply(tx₁)▶ S₁ ─apply(tx₂)▶ S₂ ─ ⋯ ─▶ Sₙ
                                                        │
                              all nodes MUST land on the identical Sₙ

For this to work, apply must be deterministic: given the same state and the same transaction, it must produce bit-for-bit the same next state on every machine, forever. If node A computes alice: 70 and node B computes alice: 71 from the same starting point and the same transaction, the network has forked — there is no longer one shared world, but two, and the strangers no longer agree. The one thing a blockchain exists to provide — a single agreed state — is gone.

So determinism is not a nice-to-have; it is the load-bearing property of the whole design. Every feature Ethereum adds must preserve it. This is why:

• there is no floating-point arithmetic in the EVM (its rounding varies across hardware),
• a contract cannot read the wall clock or a true random number (each node would see a different one),
• and gas — the subject of Ether as Fuel — must be charged by a rule every node computes identically, down to the last unit.

Every one of those constraints traces back to a single sentence: every node must compute the identical next state, or the network cannot agree.

Under the hood — checking agreement with one number

If two nodes must arrive at the identical state, how do they check that they did, without shipping their entire multi-gigabyte state to each other and comparing byte by byte? They compress the whole state into a single fixed-size fingerprint — a state root — and compare only that.

ethmini builds a deliberately simple version: serialize every account in a fixed, sorted order and hash the bytes.

/// A single 32-byte fingerprint of every account, balance, nonce, and
/// storage slot. Change anything and the root changes; change nothing
/// and it stays identical.
pub fn state_root(&self) -> [u8; 32] { /* sort accounts, then hash */ }

The property that makes this useful is the property of any good hash: it changes if anything in the state changed, and stays identical if nothing did. So two nodes that computed the identical Sₙ will compute the identical root — and if a single balance differs by one unit anywhere, their roots diverge and the disagreement is caught immediately, by comparing 32 bytes instead of the entire world.

This is only a first sketch. Real Ethereum uses a Merkle-Patricia trie, which yields the same all-or-nothing fingerprint plus efficient proofs about individual accounts and cheap incremental updates. We build up to that in State and Tries. For now, hold the idea: agreement over a huge shared state is checkable with one small number, precisely because the transition function is deterministic.

By the numbers — how much redundant computation

The determinism requirement means the same transaction is executed by every full node — the computation is deliberately, massively redundant. That redundancy is the cost side of the book’s central question.

   Say the network has          ~8,000 reachable full nodes  (order of magnitude)
   A simple transfer costs             1 unit of "work" to apply
   Times every node re-running it: 8,000 units of work for ONE transfer

   You are not paying for computation. You are paying for AGREEMENT —
   for thousands of strangers to independently confirm the same result.

This is why a “world computer” is astronomically more expensive per operation than a laptop, and why gas has to exist. You are not buying CPU cycles; you are buying a globally-agreed answer. Node counts vary over time and by measurement method; treat 8,000 as an order-of-magnitude figure, not a precise census.

The convergence requirement

Determinism guarantees that if every node applies the same transactions in the same order, they all land on the same state. It does not, by itself, get them to agree on what that order is. Two nodes could each be perfectly deterministic and still hold different worlds — simply because they saw two conflicting transactions arrive in different orders, or one saw a transaction the other never did.

Call the thing we actually need convergence: thousands of mutually untrusting strangers must not merely be capable of computing the same state — they must reliably end up choosing the same transaction sequence to compute over, with no central coordinator telling them which one is canonical.

   determinism  →  same inputs, same order  ⇒  same state   (a property of apply)
   convergence  →  everyone agrees on WHICH inputs, in WHICH order   (the hard part)

Determinism is a property of the transition function and is comparatively easy: write apply carefully and forbid the non-deterministic tricks above. Convergence is the genuinely hard problem, because there is no trusted authority to declare the canonical order — that is what “untrusting strangers” means. It is solved by consensus (proof-of-work, then proof-of-stake), the subject of the Consensus part.

For this part, the payload is a single constraint you should carry into every later chapter: every design choice Ethereum makes must preserve convergence. A feature that lets two honest nodes reach different states from the same block, or that makes it too expensive for strangers to check each other’s work, is not an optimization — it is a break in the one guarantee the system exists to provide. When we reach the EVM, gas metering, and the fee market, ask of each: does this keep untrusting strangers converging on one world? If the answer is ever no, that feature cannot ship.

The architect’s lens

The state-machine framing is the single most important idea in this book, so it earns the lens.

• Why does it exist? Because “a blockchain” is a sprawling thing — networking, cryptography, economics, virtual machines — and you need one mental model that makes all of it fit together. “A replicated, deterministic state machine that strangers converge on” is that model.
• What problem does it solve? It tells you where every component lives. Anything Ethereum does is either part of the state, part of the transition function apply, or part of the consensus machinery that decides which transactions feed apply next. Nothing falls outside those three buckets.
• What are the trade-offs? The model buys clarity by hiding the hardest part — convergence — inside the phrase “the agreed order.” That word “agreed” is doing enormous work, and consensus is where the real cost and complexity live.
• When should I avoid it? When you’re reasoning about the peer-to-peer gossip layer or raw cryptographic primitives (signatures, hashes) in isolation — those are plumbing beneath the machine, not states or transitions, and forcing them into the frame obscures more than it reveals.
• What breaks if I remove it? You lose the throughline. Without it, accounts, the EVM, gas, and consensus look like four unrelated systems instead of four answers to one question: how do untrusting strangers agree on the state of a shared world computer?

The question this sets up

We have established the machine. A payment ledger is a state machine whose state is who owns what and whose transition function moves value. It must be deterministic so replicated nodes agree, and the whole apparatus of consensus exists to make untrusting strangers converge on one transaction order.

But notice how weak that transition function is. It can do exactly one thing: subtract from one balance and add to another. The next chapter, Bitcoin’s Deliberate Limits, shows that Bitcoin makes this narrowness a feature — a small, hard-to-break transition function is a small, hard-to-break attack surface. Then Generalizing the Ledger into a World Computer asks the question that produced Ethereum:

What if apply didn’t just move value — what if it could run arbitrary code submitted by anyone, and the state it edited was general-purpose memory rather than a single balance?

Hold onto the frame — state, transition function, determinism, convergence — because that one substitution (a richer apply, a richer state) is the entire leap from Bitcoin to Ethereum. The rest of the book is spent making that substitution safe, deterministic, and affordable.

Check your understanding

1. State the three ingredients of a state machine, and name what each one is for a plain payment ledger.
2. Why must the transition function be deterministic? Describe concretely what goes wrong if two honest nodes compute different next states from the same transaction.
3. The page distinguishes determinism from convergence. Which one is a property of apply alone, which one requires consensus, and why can’t determinism give you convergence by itself?
4. Give two things the EVM forbids (or must handle specially) that a normal laptop program does freely, and tie each back to the determinism requirement.
5. In the book’s frame, “everything else exists only to agree on which transactions to feed apply, and in what order.” Sort these into state, transition function, or agreement machinery: an account’s balance; the rule that debits a sender; proof-of-stake; a contract’s storage slot; the peer-to-peer gossip network.

Show answers

1. A state S (a snapshot of everything the system knows), a set of inputs/transactions, and a transition function S' = apply(S, tx). For a payment ledger: the state is a map of who owns what (account → balance); a transaction is “move value v from X to Y”; the transition function debits the sender and credits the receiver after checking affordability.
2. Because the machine is replicated — thousands of untrusting nodes each apply the same transactions independently and must land on the identical state. If two honest nodes compute different next states from the same transaction, the network has forked: there are now two disagreeing versions of the world, which destroys the one thing a blockchain exists to provide — a single agreed state.
3. Determinism is a property of apply alone: same state + same transaction + same order ⇒ same result on every machine. Convergence requires consensus: getting mutually untrusting strangers to agree on which transactions, in which order, with no trusted coordinator. Determinism can’t give convergence because two perfectly deterministic nodes can still hold different worlds if they applied different transactions, or the same ones in a different order.
4. Any two of: floating-point arithmetic (rounding varies across hardware); reading the wall clock; drawing a true random number; depending on available memory/timing. Each would make apply produce different results on different machines, breaking determinism and forking the network — so the EVM forbids them or replaces them with rules every node computes identically.
5. State: an account’s balance; a contract’s storage slot. Transition function: the rule that debits a sender. Agreement machinery: proof-of-stake; the peer-to-peer gossip network.