If Bitcoin already existed, why did the world need Ethereum?
Not because Bitcoin failed. Because after it proved one thing could work, people saw a much larger possibility.
In 2009, Bitcoin enabled strangers to maintain a record of digital assets together—without a bank, clearinghouse, or central database. It proved that a network could agree on a history of who owns what and who transferred what to whom.
The breakthrough was not merely a coin. It was distributed consensus: computers that do not fully trust one another can still follow public rules and reach sufficiently stable agreement on one record. Bitcoin, however, is primarily designed for secure, robust value transfer; its scripting system is deliberately specialized and constrained.
That does not mean “Bitcoin cannot be programmed.” It can express conditions such as multisignature spending and timelocks. The more accurate statement is this: Bitcoin provides specialized validation rules built around digital cash. Early builders of more complex applications often had to invent a new protocol, launch a new chain, or move the complex logic back onto a central server.
What was missing was a general layer for shared programs
Imagine three needs: funds that move only when two of three people approve; a crowdfunding system that continuously records each participant’s share; and a market where anyone can exchange two digital assets under the same rules. These systems must remember more than balances. They must preserve rules, conditions, and changing application state.
Vitalik Buterin’s 2013 proposal replaced “every application reinvents a blockchain” with a new idea: build one general-purpose blockchain computer, then let applications deploy their programs to it. That was the heart of Ethereum’s original vision.
Bitcoin: a digital-cash ledger
Narrow the central question: which unspent outputs may be spent, by whom, and under what conditions?
- 01Core state centers on unspent transaction outputs (UTXOs) and ownership
- 02More specialized scripts and a deliberately narrower attack surface
- 03The primary job is reliable value transfer
Ethereum: a general shared state machine
Expand the question: after a valid set of transactions, what should every account, program, and piece of data become?
- 01State includes balances, code, and contract storage
- 02Developers can deploy reusable programs
- 03One foundation supports many application rules
Ethereum was not born overnight
It began as a proposal to generalize the blockchain, became a formal protocol and developer community, and only then became a live network.
“Birth” describes at least three distinct events: the idea was proposed, the protocol was defined, and the network began operating. Keeping them separate reveals how Ethereum moved from an idea to public infrastructure.
- Whitepaper circulated Vitalik proposed a general platform for smart contracts and decentralized applications.
- Public introduction The project reached a broader audience at the Bitcoin conference in Miami.
- Protocol formalized Gavin Wood’s Yellow Paper supplied a technical definition of the EVM and protocol.
- Ether sale The public sale funded early protocol, client, and ecosystem development.
- Frontier launched The genesis block was created and the first Ethereum mainnet release began operating.
The whitepaper answered “why”; the Yellow Paper answered “exactly how”
The whitepaper described the vision: a blockchain with a built-in general programming capability for smart contracts and decentralized applications. The Yellow Paper turned that vision into an implementable, mutually testable specification: how accounts are represented, how transactions change state, how the EVM executes instructions, and how different clients determine whether a block is valid.
Nor was this the work of one person. Vitalik Buterin proposed the early overall vision; Gavin Wood and others advanced the formal specification and client implementations; multiple co-founders, developers, and an early open-source community turned the proposal into a working network.
This step is essential for a public network. A conventional online service can let one company declare, “our server is the answer.” Ethereum has no such authoritative server, so the rules themselves must be precise enough for software written by different teams to compute the same result.
The “world computer” is both a vision and an engineering constraint
The 2015 Frontier launch announcement described a censorship-resistant “world computer” that anyone could program and pay for as they used it. That did not imply unlimited computing power. Quite the opposite: for independent nodes to recompute and verify execution, it must be deterministic, bounded, and measurable. That is why Ethereum needs the EVM, transaction ordering, gas, and consensus.
From shared accounting to shared computation
The shortest path to understanding the world computer begins with “state” and “state transition.”
State is the system’s complete memory of the world at a given moment. A transaction is a signed instruction asking the system to change that memory according to its rules.
In a minimal banking program, state might say “Alice has 10; Bob has 3.” The input is “Alice sends Bob 2.” After the execution rules check the signature, balance, and ordering, the result is “Alice has 8; Bob has 5.” Ethereum scales up this idea: its state also includes account nonces, contract code, and the data stored by each contract.
This simple-looking formula contains Ethereum’s entire skeleton. S is the previously accepted state; T is the deterministically ordered set of transactions; the EVM defines the state-transition rules every execution client must follow; and S′ is the candidate state after execution.
State-transition lab
Choose a request, then follow how an intention becomes a new state that independent nodes can verify.
- Alice
- Bob
- TimeVault
- Alice
- Bob
- TimeVault
Step 1: Alice’s wallet signs the request with her private key. The key itself never leaves the wallet.
What does “world computer” actually mean?
It is one logical computer—not one physical computer.
Ethereum’s technical documentation offers a precise mental model: the network has one canonical virtual computer, the EVM. Each execution node maintains the state it needs and verifies state changes under the same rules.
“One” means that, logically, the network recognizes one canonical history and state. It does not mean a central machine is hidden somewhere. In the physical world, many operators run different client implementations. Starting from the same prior state and processing the same ordered transactions, protocol-compliant implementations should reach the same result.
Execution and consensus solve different problems
The execution layer answers: “Given this prior state and these transactions, what is the result?” The consensus layer answers: “Which block and transaction order constitute the canonical history?” If two transactions try to spend the same balance, the one executed first changes the outcome. The network must therefore compute and agree on ordering.
Ethereum now uses proof-of-stake consensus: validators propose and attest to blocks, and economic rewards and penalties shape behavior. Execution clients recompute transactions under EVM rules. Later lessons will examine consensus and the EVM separately; for now, keep their jobs distinct.
Let four nodes compute the same request
Nodes do not average their answers. Each one verifies the same deterministic result.
same prior state + same ordered transactions + same EVM rules → same new state
All four machines independently reach the same state commitment, so each can verify the block’s execution result.
A world computer needs four essential parts
Shared state
Gives programs a jointly recognized memory that persists into the next call.
Deterministic rules
The same input must produce the same output, or independent nodes cannot verify one another.
Consensus ordering
When requests conflict, the network must know which executes first and which history is valid.
Gas metering
Sets costs and limits for computation and storage, preventing infinite loops from exhausting network resources.
What role does ETH play in this computer?
ETH is not “stock in the Ethereum company.” It is the network’s native asset, with at least two foundational uses: users pay ETH for execution resources consumed when changing state, and validators stake ETH as economic collateral for consensus security. Ethereum therefore created not only computation rules, but an economic system that decides who requests computation, who pays for scarce resources, and who bears a cost for honest verification.
Keep two more terms separate: gas measures computational work; the transaction fee is the actual amount paid in ETH after gas usage and fee parameters are applied. Calling gas simply a “miner fee” confuses units with money and no longer fits a proof-of-stake Ethereum.
Smart Contracts: Public Rules on Ethereum
They are neither “smart” nor able to interpret legal agreements. They are deterministic programs that execute exactly as specified when called.
A developer compiles a program into EVM bytecode and deploys it to a contract address. The code and its persistent storage become part of Ethereum’s state; users can then submit transactions that call its functions.
The idea of a “smart contract” predates Ethereum. Ethereum’s major advance was turning it into a general-purpose, public, and composable platform capability: developers no longer needed to launch a separate blockchain for every new set of contract rules.
A vending machine is a useful starting analogy: it displays a price, accepts an input, checks its conditions, and produces a predictable result. An onchain program is even more transparent—any validating node can re-execute it—but also more constrained. It cannot freely read a website, secretly query a company database, or perform unlimited computation for free.
Run an Onchain Vending Machine
Rule: each item costs 1 ETH. If the payment is sufficient and stock is greater than zero, the balance, inventory, and ownership records are updated atomically.
require(payment >= 1 ETH) PASS require(stock > 0) PASS stock = stock - 1 owner[item#42] = Alice
Success: Both checks pass. Stock changes from 2 to 1, and ownership of item#42 is assigned to Alice. The related state changes either all take effect or none of them do.
- Sufficient payment and available stock: both checks pass, so inventory and ownership are updated together.
- Underpayment: a condition fails and the application state reverts; the gas already consumed is still charged.
- Out of stock: a condition fails, so the payment transfer and ownership update revert together.
“Code Is Law” Is a Dangerous Oversimplification
A contract faithfully executes its bytecode—not the intent in its developer’s mind. Incorrect rules, permission flaws, and unsafe external data can all be executed just as faithfully. Real-world projects also commonly use upgradeable proxies, multisignature governance, emergency pauses, and frontend access controls. A more accurate statement is: onchain code provides publicly verifiable execution rules, but people must still judge whether those rules are fair, secure, and complete.
What Ethereum Can—and Cannot—Do
Ethereum’s advantage is not faster computation. It is allowing multiple parties to verify the same result without depending on a single operator.
If only one person needs to trust the result of a computation, an ordinary server will usually be faster, cheaper, and more private. The higher cost of onchain computation may be worthwhile only when multiple parties must share the same state and no single party should have unilateral power to rewrite it.
Conventional Cloud Service
Ethereum
Should This Go Onchain?
Choose a scenario. The important question is not simply “Can it go onchain?” but “Which smallest part is worth verifying together?”
Recommendation: settle onchain. Multiple parties need to verify asset ownership and transfer rules. The interface, search, and analytics can remain offchain.
- Digital asset settlement: core ownership records and transfer rules are well suited to onchain execution.
- 4K video transcoding: this computation-heavy task belongs offchain.
- Private medical records: store them encrypted offchain; place access records or hash commitments onchain only when useful.
- Market-price insurance: contract settlement and oracle inputs form a hybrid system.
Traits of Work That Belongs Onchain
Multiple parties share the same asset or rules; participants span different organizations or countries; unilateral deletion or alteration would harm others; or the system requires public auditability, composability, or permissionless access. Tokens, decentralized exchanges, lending positions, and decentralized autonomous organization (DAO) treasuries each exhibit some of these traits.
Work That Should Not Run Directly in the Mainnet EVM
Video rendering, machine-learning training, large-file storage, private raw data, and high-frequency low-value operations are generally poor fits. These workloads can run offchain while result commitments, ownership, settlement, or dispute rules remain onchain. Layer 2 systems, zero-knowledge proofs, and data-availability solutions can shift this boundary further, but they cannot make scarce resources magically free.
Five Common Misconceptions, Corrected
Without these boundaries, the “World Computer” metaphor can make your mental model less accurate rather than more useful.
“Ethereum Is One Giant Cloud Server”
There is no central host machine. Many independent nodes maintain agreement on the state and rules of one canonical virtual machine.
“Every Node in the World Executes Every Transaction”
Not every device connected to the network performs execution. Validating nodes execute transactions as required, while light clients and ordinary users can use less resource-intensive forms of verification.
“Smart Contracts Act on Their Own”
A contract has no built-in alarm clock or background thread. It must be triggered by a transaction or another contract call before it executes its rules.
“A Decentralized Application Runs Entirely Onchain”
Frontends, images, indexes, and notifications commonly remain offchain. A decentralized application’s (dapp’s) degree of decentralization depends on its entire dependency chain, not on the presence of a single contract.
“A Blockchain Is Faster and Cheaper Than a Server”
Replicated verification inherently adds cost. Ethereum optimizes for verifiability, resistance to single-party control, and open access—not single-machine performance.
“Immutable” Does Not Mean “Never Changes”
Valid transactions continually update Ethereum’s state. What is difficult to alter is confirmed history; upgrades and governance can still change the rules that apply in the future.
The Entire Lesson in Six Statements
If you can explain these six layers in order, you understand the basic structure behind the “World Computer.”
Now Check Your Understanding
Each question tests a boundary that is easy to misunderstand. There is no penalty for a wrong answer—the explanation is what matters.
1. What is the most accurate meaning of the “World Computer”?
Answer: B. Physically, the network contains many nodes and client implementations. Logically, they verify the same state-transition rules and canonical history.
2. What is the most important division of responsibility between the consensus layer and the execution layer?
Answer: C. Execution answers “What is the result?” Consensus answers “Which ordered history does the network accept?”
3. Can a smart contract wake itself up at 9:00 a.m. each day and retrieve a weather webpage?
Answer: A. A contract executes only when called. External facts must be brought onchain, and the data source itself introduces new trust and security considerations.
4. Why does the EVM need gas?
Answer: B. Gas measures the work performed by EVM instructions and prevents infinite loops or cheap abuse from exhausting the resources of validating nodes.
5. Which architecture best describes a mature dapp?
Answer: C. Onchain and offchain components can work together. The key is identifying which state must be verified jointly by multiple parties.
Print note: the answer and explanation for each question appear directly below its choices.
Key Terms and Primary Sources
For now, this lesson asks only that you build a conceptual map. Later chapters will explore each of these terms in greater depth.
State STATE
Ethereum’s complete valid data at a given moment, including account information, balances, contract code, and contract storage. Valid transactions continually update this state.
State Transition STATE TRANSITION
The process of starting from an old state S, executing one transaction—or an ordered group of transactions T—according to the protocol rules, and producing a new state S′.
Ethereum Virtual Machine EVM
The virtual execution environment that defines how smart-contract bytecode runs and how Ethereum’s state changes. Different execution clients implement the same specification.
Smart Contract SMART CONTRACT
A program deployed into Ethereum’s state. It executes when called by a transaction or another contract and can read or update the onchain state accessible to it.
Consensus CONSENSUS
The rules and processes through which distributed participants agree on the canonical block history. Ethereum currently uses proof-of-stake consensus.
Gas RESOURCE METER
A unit that measures the computational resources required by EVM operations. Gas places a limit on execution and reduces the risk of infinite loops and network abuse. Gas measures work; the final transaction fee is calculated from actual gas usage and fee parameters, then paid in ETH.
Continue Reading
-
01
Ethereum Whitepaper — A Next-Generation Smart Contract and Decentralized Application PlatformThe original vision. Ethereum.org notes that the document no longer fully represents today’s protocol.
-
02
ethereum.org — Technical intro to EthereumAn official technical introduction to Ethereum as a “single canonical computer,” including nodes, transactions, ETH, and smart contracts.
-
03
ethereum.org — Ethereum Virtual MachineExplains the move from a distributed ledger to a distributed state machine and introduces the state-transition model Y(S, T) = S′.
-
04
Ethereum Foundation Blog — Ethereum LaunchesThe July 30, 2015 announcement of the Frontier mainnet launch and its “World Computer” vision.
-
05
ethereum.org — History of EthereumAn official historical overview spanning the initial idea in 2013 through the genesis block in 2015.
-
06
ethereum.org — OraclesWhy deterministic contracts cannot directly access offchain data, and the new problems introduced by oracles.
-
07
EIP-3675 — Upgrade consensus to Proof-of-StakeThe core specification for Ethereum’s transition from proof of work to proof of stake.
-
08
ethereum.org — Introduction to smart contractsDefines smart contracts, traces the concept’s origins, and explains the basic model in which transactions trigger contract execution.
-
09
ethereum.org — Gas and feesHow gas measures computational work, and how it differs from the transaction fee paid in ETH.