Ethereum
Ethereum Whitepaper: From Bitcoin's Limitations to a World Computer
In late 2013, a nineteen-year-old named Vitalik Buterin circulated a whitepaper proposing a new kind of blockchain. It was not a faster Bitcoin or a more private Bitcoin. It was a proposal to turn a blockchain into a programmable computing platform — a world computer, as he called it, where decentralized applications could run without any central point of control or failure.
The Ethereum whitepaper is denser and more ambitious than Satoshi's nine-page paper. It begins with a careful analysis of Bitcoin's design, identifies the constraints that limit what can be built on it, then proposes a radically different architecture. Understanding how Vitalik got from Bitcoin to Ethereum explains why Ethereum looks the way it does.
The Problem: Bitcoin Script's Deliberate Limitations
Bitcoin includes a simple scripting language that specifies the conditions under which a transaction output can be spent. Most outputs use a standard script: "this output can be spent by whoever can produce a valid signature for this public key." But Bitcoin Script supports other conditions — multiple signatures, time locks, hash preimage reveals — enabling basic smart contracts.
So why build Ethereum at all?
Vitalik's analysis identified five properties that Bitcoin Script deliberately lacks, each of which limits what you can build on it.
Lack of Turing-completeness. Bitcoin Script cannot express arbitrary computation. Loops are absent. The language is intentionally simple to prevent complex, unpredictable execution. This is safe but limiting.
Value-blindness. A Bitcoin script cannot specify that an output pays a precise amount in response to another event. An output is either spendable or not; scripts cannot express partial spends or conditional amounts based on external inputs.
Lack of state. Bitcoin UTXOs are binary — either unspent or spent. A script cannot maintain ongoing state across multiple transactions. This makes it impossible to build multi-step contracts, subscription payments, or protocols that evolve over time.
Blockchain-blindness. Bitcoin scripts cannot access blockchain data like the current block number, timestamp, or the balance of another address. This prevents contracts that depend on external conditions within the chain.
Lack of internal account balances. Bitcoin has no native concept of accounts with balances. Every transaction must explicitly reference previous unspent outputs. Building applications that track user balances requires complex off-chain bookkeeping.
The Ethereum Approach: A Generalized State Machine
Ethereum's answer to Bitcoin's limitations is conceptually simple: instead of a ledger of coin transfers, make the blockchain a generalized state machine. The state is a large mapping of addresses to account objects. Transactions are state transitions. The network's job is to agree on which sequence of transactions has occurred, and therefore what the current state is.
This reframe is profound. Bitcoin tracks who owns which unspent outputs. Ethereum tracks the entire state of all accounts and all smart contracts simultaneously, updating that state with every block.
Accounts: External and Contract
Ethereum has two types of accounts. External accounts are controlled by private keys — these are what users interact with directly, sending transactions and signing messages. Contract accounts are controlled by their code. They have no private key; they execute when triggered by a transaction or another contract call.
Every account, regardless of type, has four fields: a nonce (a counter preventing replay attacks), an ether balance, a storage root (the root hash of a key-value store unique to that account), and a code hash (for contract accounts, the hash of the EVM bytecode that governs the account's behavior).
This unified account model is cleaner than Bitcoin's UTXO model for complex applications. A decentralized exchange can track every user's balance in a contract's storage. A lending protocol can maintain loan positions across multiple blocks without external coordination.
The EVM: A Sandboxed World Computer
The Ethereum Virtual Machine is the runtime that executes smart contract code. It is a stack-based virtual machine, intentionally isolated from the host system — contracts cannot access the network, the file system, or any external resources except through explicitly defined blockchain operations.
The EVM operates on 256-bit integers, reflecting the size of cryptographic hashes and elliptic curve private keys. It has three types of storage: a stack (ephemeral, used during execution), memory (byte-addressable, also ephemeral), and storage (persistent key-value pairs that live in the account's storage trie between transactions).
EVM bytecode is deterministic: given the same starting state and the same transaction, every node in the network will compute the same resulting state. This determinism is what makes consensus possible — all nodes can independently verify that a block's state transition is correct.
gas-solving-the-halting-problem">Gas: Solving the Halting Problem
Turing-complete computation creates an immediate problem: how do you prevent a contract from running forever, consuming all the network's resources? This is the halting problem — there is no general algorithm to determine in advance whether a given program will terminate.
Ethereum's solution is gas. Every EVM operation has a gas cost, calibrated roughly to the computational resources it consumes. Arithmetic is cheap; storage writes are expensive. A transaction specifies a gas limit — the maximum amount of gas the sender is willing to consume — and a gas price, denominated in ether, that the sender will pay per unit of gas consumed.
If execution runs out of gas before completion, all state changes are reverted, but the gas is still consumed. This makes running an infinite loop expensive and self-limiting. The miner collects the gas fees regardless of whether the transaction succeeds.
Gas prices float based on demand. When the network is congested, users bid higher gas prices to get their transactions included quickly. This market mechanism allocates scarce block space to the transactions willing to pay the most for it — later reformed by EIP-1559, which introduced base fees and burning, but the fundamental gas model is described in the original whitepaper.
Applications the Whitepaper Envisions
The whitepaper dedicates substantial space to demonstrating what Ethereum enables. Several categories stand out.
Token systems. A contract can maintain a ledger mapping addresses to balances, implementing transfer and approval logic. This simple structure is the foundation of all ERC-20 tokens — and the entire DeFi ecosystem built on top of them.
Financial derivatives. A contract can encode a derivative contract between two parties, using an oracle to feed in asset prices and automatically settling based on price movement at a future date. No broker required.
Identity and reputation systems. Contracts can store reputation scores, attestations, and identity claims that are verifiable without a central authority.
Decentralized file storage. While Ethereum itself does not store files, the whitepaper sketches how a contract could coordinate decentralized storage with cryptographic proofs of file retention.
Decentralized autonomous organizations. A DAO is a contract that holds assets and executes decisions based on shareholder voting, encoded entirely in contract logic. The whitepaper explicitly proposes DAOs as a form of organization without traditional legal structure.
The Ethereum State Transition Function
The heart of Ethereum's design is formally expressed as a state transition function: given the current world state and a valid transaction, produce the new world state. Every block applies this function to each transaction in sequence. The starting state plus all the transactions in a block deterministically produce the ending state.
The state is stored in a modified Merkle Patricia trie — a data structure that combines the efficient lookup of a Patricia trie with the Merkle tree's property of being provable with short proofs. The root of this trie is stored in every block header. Changing any account state would change the root; the root is embedded in the block, which is covered by proof-of-work (later proof-of-stake). This links every account state to the chain's security.
What the Whitepaper Got Wrong (and Right)
The whitepaper is a vision document, not a precise specification. Some details changed significantly between the whitepaper and the actual Ethereum mainnet launch in 2015. The gas costs were recalibrated. The specific opcodes evolved. The account model was refined.
More significantly, the whitepaper underestimated the complexity of making the EVM efficient and secure. Years of security research exposed subtle reentrancy vulnerabilities (the DAO hack), integer overflow bugs, and gas estimation problems that the original design did not fully anticipate.
But the core insight held. A blockchain as a generalized state machine, with accounts maintaining persistent state and a virtual machine executing arbitrary code, proved to be an extraordinarily productive abstraction. By mid-2023, Ethereum's contracts held tens of billions of dollars in value across lending protocols, exchanges, NFT platforms, and DAOs — all running on the world computer Vitalik sketched in late 2013.
Reading the Whitepaper Today
The Ethereum whitepaper is readable in a sitting. It assumes familiarity with Bitcoin but explains Ethereum from first principles. For anyone building on Ethereum — writing contracts, auditing code, designing protocols — reading the original whitepaper provides essential context for why the design makes the choices it does.
The limits Vitalik identified in Bitcoin Script were not bugs; they were deliberate design choices reflecting Satoshi's conservative security philosophy. Ethereum chose the opposite tradeoff: maximum expressiveness, trusting that gas, deterministic execution, and open-source auditability would keep the system safe. That bet has been substantially vindicated, with the ongoing work of the Ethereum ecosystem continuously refining and extending the world computer the whitepaper first described.