The EVM: Ethereum's World Computer

Last lesson we said Ethereum doesn’t just move money around — it runs programs. Smart contracts, tokens, whole applications, all living on the chain. Which raises an annoying follow-up question that most explainers conveniently skip:

Where do those programs actually run?

Your laptop runs programs on its CPU. A website runs on a server somewhere. But a smart contract isn’t on anyone’s particular machine — it belongs to the whole network. So Ethereum needs a computer that everyone runs, that nobody owns, and that always agrees with itself. That computer is the EVM, and this lesson is the tour.

One Computer, a Thousand Copies

Before we explain it, a gut check.

The EVM (Ethereum Virtual Machine) is a virtual machine: a computer defined by rules, not by hardware. A virtual machine is a piece of software that pretends to be a CPU — it has its own instruction set, its own memory model, its own notion of what a “step” is — and any real computer can run it by following those rules. Java works this way; so do game-console emulators. The point is portability: write the rules once, and every machine that follows them behaves identically.

Ethereum takes that idea and makes it social. There is conceptually one EVM, but its state is replicated across every node on the network. Think of it as a giant shared spreadsheet — a Google Doc the size of the planet — that thousands of people have open at once. Nobody edits a cell by hand. The document only changes when a rule-following edit is submitted and everyone applies that same edit. Because they all start from the same document and apply the same edits by the same rules, they all end up looking at the same document. One computer, a thousand identical copies.

World State: What the Computer Remembers

A computer without memory is a very expensive paperweight. The EVM’s memory is called the world state.

The world state is the complete set of everything the EVM remembers at a given moment: every account and all of its data. For each account that means:

• its balance (how much ETH it holds),
• for contract accounts, the code that runs when you call it,
• and that contract’s storage (its private, persistent variables — a token contract’s “who owns how much” table lives here).

If the EVM is a game console, the world state is the save file. Press the button (send a transaction) and the save file updates. Reboot a node from scratch, replay every save up to now, and you land on the exact same save file as everyone else.

A Transaction Is a State Transition

Here’s the single most important sentence in this entire lesson, so we’ll put it in code:

newState = EVM(oldState, transaction)

That’s the whole model. A transaction is an instruction submitted to the network (“send 3 ETH from A to B”, or “call this contract’s mint function”). The EVM takes the old world state plus that transaction and computes a new world state. Nothing more mystical than that: a transaction is a state transition — a recipe for turning one save file into the next.

And the EVM is a state machine: a system that sits in some state and moves to a new, fully-determined state when an input arrives. (Light switch: states “on” and “off”, input “flip”. Same idea, slightly more accounts.)

The magic word is deterministic. Deterministic means no surprises, ever: the same starting state plus the same transaction produces the exact same new state — on every node, every time, forever. No randomness, no “depends on the weather,” no “works on my machine.” That property is the bedrock that lets thousands of strangers agree without trusting each other.

Play with one below. Step a few preset transactions through the machine and watch the world state go from before to after. Try a plain ETH transfer first (watch two balances change), then a contract call (watch the contract’s stored number change), then hit reset and run the same sequence again — note that you get the identical result. That repeatability is determinism, live.

A transfer, worked step by step

Say the world state has account A holding 10 ETH and account B holding 2 ETH. A signs and broadcasts the transaction “send 3 ETH to B.” The EVM does the obvious arithmetic against the old state:

The new world state is “A: 7, B: 5.” Two cells in the giant spreadsheet changed; nothing else moved. (We’re ignoring the small fee for now — that’s the next lesson.) Every node that applies this transaction to that same old state lands on A: 7, B: 5. No exceptions, because there’s no room for any.

Why Every Node Re-Runs Everything (Gas Preview)

Here’s the part that sounds absurd until it clicks: every node independently re-executes every transaction. Your node doesn’t take some other node’s word for the new balances. It downloads the transaction, runs it through its own EVM, computes the result itself, and checks that everyone else got the same thing.

Picture thousands of meticulous accountants, each handed the same stack of receipts, each redoing every single sum by hand, then comparing answers. Wildly redundant — and that redundancy is the security. To cheat, you wouldn’t fool one accountant; you’d have to fool the majority of them simultaneously, all running identical, deterministic rules. Good luck.

But re-running everything has a cost, and it points straight at the next concept:

Bytecode and Being Turing-Complete

Nobody writes raw EVM instructions by hand (well, almost nobody, and they need a hug). Developers write contracts in high-level languages like Solidity or Vyper — readable code with functions, variables, and if-statements. A compiler then translates that down into EVM bytecode: a long string of low-level opcodes, the tiny primitive instructions the EVM actually executes (ADD, SSTORE, JUMP, and friends). Bytecode is to Solidity what machine code is to the C you’d write on your laptop — the same logic, ground down into steps a machine can chew.

The EVM is also Turing-complete. Turing-complete means it can, in principle, express any computation you can describe — loops, branches, arbitrary logic — given enough resources. That’s powerful: it’s why Ethereum can host genuinely complicated programs, not just “move coin from X to Y.”

The catch with Turing-completeness is the halting problem: a sufficiently expressive machine can write programs that loop forever, and you can’t always tell in advance whether one will. The EVM’s fix is gas (again): every step costs gas, a transaction carries a finite gas budget, and when the budget runs dry, execution halts. So the EVM is Turing-complete with a meter — it can express anything, but it can’t run anything for free or forever.

This is a deliberate contrast with Bitcoin Script, Bitcoin’s on-chain language, which is intentionally not Turing-complete. Bitcoin Script has no unbounded loops on purpose — less expressive, but easier to reason about and harder to footgun. Ethereum chose the opposite trade: maximal expressiveness, fenced in by gas.

Blocks Put the Transactions in Order

One last piece. newState = EVM(oldState, transaction) is great for one transaction — but thousands fly in every minute, and order matters. (If A has 10 ETH and tries to send 8 ETH to both B and C, which one goes through depends entirely on which is processed first.) So the EVM needs a single, agreed ordering.

That’s the job of blocks. Transactions are batched into a block; blocks are placed in a strict sequence, each one cryptographically linked to the one before it (the chain in “blockchain”). Apply the blocks in order, the transactions inside each block in order, and every node walks the same path from the genesis state to today’s state — and lands on the same world state. Determinism handles each step; block ordering handles the sequence of steps.

The Big Picture

Key Takeaways

We’ve talked a lot about “accounts” holding balances — but how does an account actually work? Ethereum’s answer (the account model) is strikingly different from Bitcoin’s coins-in-a-jar approach (the UTXO model). Next up: accounts vs UTXO, and why Ethereum picked the model it did.