| Author | Vitalik Buterin |
|---|---|
| Year | 2014 (officially published version) |
| Project | Ethereum |
| License note | Ethereum.org terms apply CC BY 4.0 to its non-code website content; the paper-specific rights notice is not separate on the page. |
| Official source | Ethereum.org whitepaper and original 2014 PDF |
This page is an educational summary and analysis, not a verbatim reproduction. It does not claim authorship of the original paper. The original is attributed to Vitalik Buterin and linked above.
“Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform” proposes a blockchain that can update shared state by running programmable rules. Written by Vitalik Buterin, it extends the idea of a transaction ledger beyond payments: developers could create smart contracts that define how digital assets and records change. Ethereum.org labels the canonical paper as a 2014 publication and cautions that it no longer describes the modern network in full.
Publication and Context
Buterin says he wrote the first draft in San Francisco in November, then made the proposal public in a January 23, 2014 announcement. That distinction matters: 2013 is the draft period, while the official site’s current paper and original PDF are dated 2014. Ethereum’s live network followed on July 30, 2015, with the Frontier release.
The whitepaper is a design proposal, not the later formal implementation specification. Gavin Wood’s Ethereum Yellow Paper supplied a more mathematical protocol description. Reading the two as different documents helps explain why the whitepaper’s goals and examples should not be treated as a complete description of current Ethereum.
Core Idea: A Programmable State Machine
The paper frames a blockchain as a system that takes a current state and a valid transaction, then computes a new state. Bitcoin’s ledger primarily tracks unspent outputs. Ethereum’s proposal instead uses accounts and contract storage, so transactions can update more general data as well as move ether.
That flexibility is the central argument: rather than create a separate chain for every application, a shared network could host many programs that agree on the same state. The paper discusses token systems, financial contracts, identity and reputation, decentralized storage, and autonomous organizations as examples. These are proposed application areas, not guarantees that each will be useful, safe, or decentralized in practice.
Accounts, Contracts, and the EVM
Ethereum’s state includes externally controlled accounts and accounts whose behavior is defined by code. A transaction may transfer value, call a contract, or change contract storage. Nodes that verify the chain must reproduce the prescribed execution and resulting state transition.
The Ethereum Virtual Machine (EVM) is the execution environment for this code. Its deterministic rules allow independent clients to check the same transaction and reach the same result. This is different from saying that every computer runs every application continuously: execution is tied to valid transactions and the rules of each block.
Gas and Its Limits
The paper introduces gas as a way to meter computation and put a bound on how much work a transaction can request. “Turing-complete” describes the range of computations the EVM can express; it does not mean a transaction can run forever. If execution runs out of gas, state changes are reverted, while gas used for the failed work is still charged.
Gas is the computation measure; users pay transaction fees in ETH. The current fee system differs from the original proposal: under EIP-1559, a protocol-set base fee is burned and a priority fee can go to the block’s validator. Ethereum.org’s current documentation explains these mechanics and why actual fees vary with demand.
Applications and Open Questions
The whitepaper’s wide scope was influential, but programmable rules do not remove trust or risk. Contracts can contain bugs; users can lose keys; interfaces and data providers may be centralized; and transactions can face inclusion delays. A contract’s execution follows code and protocol rules, but that alone does not make an application censorship-proof, uninterrupted, or legally self-enforcing.
The paper also predates many systems now associated with Ethereum, including today’s token standards, decentralized finance, non-fungible tokens, and layer-2 networks. Those grew through later work by many teams. Its discussion of proof-of-work reflects the launch-era design. Ethereum switched its consensus mechanism to proof-of-stake in September 2022.
The DAO, Forks, and Governance
The paper treats decentralized autonomous organizations as one possible use for programmable contracts. In 2016, a separate project called The DAO was exploited; the Ethereum community then adopted a hard fork that moved funds into a recovery contract. Some participants continued on the non-forked chain, which became Ethereum Classic. The episode showed that technical rules and community choices can interact during a crisis.
“Code is law” is a slogan associated with later debates about smart contracts; it should not be presented as a direct quotation or a complete rule stated by this whitepaper. The paper describes a technical design, while the DAO response illustrates that networks also have social processes and disagreement.
What the Whitepaper Does Not Describe
- The current proof-of-stake consensus and validator duties.
- Today’s EVM specifications, transaction formats, or fee-market details.
- Modern token standards, rollups, or other layer-2 designs.
- How users, developers, validators, and communities should resolve every dispute.
Why the Paper Still Matters
The paper’s lasting contribution is a clear proposal for a general-purpose blockchain: applications can share a state machine and compose through common execution rules. Its value is historical and conceptual. For current protocol behavior, readers should pair it with up-to-date developer documentation and later specifications rather than assume the 2014 text is an operating manual for Ethereum today.
Social Media Sentiment
A small sample of 2026 discussions in r/ethereum shows support for Ethereum as programmable, composable infrastructure alongside recurring concerns about whether protocol changes and validator economics preserve decentralization. These are forum conversations, not a representative survey, and they do not establish broad public opinion. The long-running DAO discussion also keeps the tension between predictable code and community intervention visible.
Last updated: 2026-10
Related Terms
See Also
- Bitcoin: A Peer-to-Peer Electronic Cash System
- Cosmos: A Network of Distributed Ledgers
- Polkadot: Vision for a Heterogeneous Multi-Chain Framework
Sources
- Buterin, Vitalik. “A Next-Generation Smart Contract and Decentralized Application Platform” (2014), with the original PDF. The primary source; Ethereum.org notes that the historical paper does not fully describe today’s network.
- Ethereum Foundation, “Ethereum: Now Going Public” (January 23, 2014). Buterin’s announcement distinguishes the November 2013 first draft from the public release.
- Ethereum.org Terms of Use. States the site’s default CC BY 4.0 license for non-code content; this is the basis for the license note above.
- Ethereum.org, “Gas and fees: technical overview.” Current explanation of gas limits, failed execution, the burned base fee, and validator tips.
- Ethereum.org, “Proof-of-stake.” Documents the September 2022 transition from proof-of-work.
- Ethereum.org, “Timeline of all Ethereum forks.” Context for the DAO fork and the chain split.
- r/ethereum daily discussion (June 8, 2026) and (August 4, 2026). Small, nonrepresentative sample for the sentiment section.