The Ethereum whitepaper proposed a general state machine

Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.

A proposal without a fixed date

Ethereum's founding document circulated among developers in late 2013 and was later hosted in a stable form on ethereum.org, which now states plainly that it 'no longer reflects what Ethereum is today.' Even the precise year is disputed among the project's own contributors, who have noted that the canonical 2013 date attached to the text is contested. What is fixed is the document's ambition rather than its date. The whitepaper proposes to generalise the ledger that the Bitcoin paper describes, extending a payments record into a replicated computer that anyone can program.

Accounts, gas and a general-purpose machine

Bitcoin's state is a set of unspent transaction outputs; the Ethereum proposal replaces this with accounts. The whitepaper defines an account by four fields: a nonce, an ether balance, contract code where present, and storage. Externally owned accounts are controlled by private keys; contract accounts are controlled by their own code, meaning a transaction can trigger further transactions without a person present at each step. Running arbitrary code on a public network raises a specific problem the whitepaper names directly, the halting problem, since 'there is no way to tell, in the general case, whether or not a given program will ever halt.' Its answer is gas, a fee charged per computational step, with a limit set on each transaction to prevent 'accidental or hostile infinite loops or other computational wastage in code.' Gas is a metering device that makes runaway computation costly, not a proof that it is impossible.

What the document does not establish

A whitepaper is a proposal, not an audit. The text describes intended behaviour for a system that had not yet run on a live network, and it frames itself modestly, as 'an alternative protocol for building decentralized applications, providing a different set of tradeoffs,' rather than a proven replacement for anything. It inherits Bitcoin's assumption that honest participants control most of the network's computing power, without which the security model fails, and it adds a further assumption: that gas pricing will make hostile code economically irrational rather than merely expensive. Neither assumption enforces itself from the page. Whether a given deployment upholds them depends on the software actually running, the operators securing it, and the contracts written on top of it.

• Does a specific network still run software matching the account and gas model this proposal describes, or has that model since changed underneath it?
• Is a contract being examined proven safe by some independent review, or merely permitted to run because it stays under the gas limit?
• What assumption about honest majority control does this deployment rely on, and who is actually checking that it holds?

The whitepaper's lasting contribution is conceptual: a general state machine metered by gas, built on the same proof-of-work assumption Bitcoin uses. Treating it as a specification for what exists today skips over a decade of amendment, forking and failure that separates the original proposal from any live network still claiming its name.