Ethereum: A Secure Decentralised Generalised Transaction Ledger (Yellow Paper)

Authors	Wood, Gavin
Year	2014
Project	Ethereum
License	Creative Commons BY-SA 4.0
Official Source	https://ethereum.github.io/yellowpaper/paper.pdf

This page is an educational summary and analysis of an official whitepaper or technical paper, written for reference purposes. It is not a verbatim reproduction. CryptoGloss does not claim authorship of the original work. All intellectual property rights remain with the original author(s). The official document is linked above.

“Ethereum: A Secure Decentralised Generalised Transaction Ledger” — universally known as the Ethereum Yellow Paper — is a formal mathematical specification authored by Gavin Wood, Ethereum co-founder and future founder of Polkadot, first published in 2014. While Buterin’s original whitepaper described what Ethereum would do, the Yellow Paper specifies exactly how it does it, using formal mathematical notation suitable for multiple independent implementations.

The Yellow Paper remains a living document. Though updated over the years by the Ethereum Foundation, it is one of the most technically dense and referenced documents in all of blockchain. Every Ethereum client implementation (Geth, Nethermind, Besu, Erigon) is ultimately an implementation of the Yellow Paper’s specification.

> PDF hosting: The Yellow Paper is available at ethereum.github.io/yellowpaper/paper.pdf and its source is maintained at github.com/ethereum/yellowpaper.

Publication and Context

When Buterin’s Ethereum whitepaper was released in 2013–2014, it was visionary but informal — describing ideas, not implementation details. Wood stepped in to write the formal complement. The Yellow Paper’s April 2014 publication defined the Ethereum system rigorously enough that independent teams could build compatible clients without ambiguity.

Wood himself went on to lead the development of Solidity (the first high-level Ethereum language) and the Whisper and Swarm protocols before departing to found Parity Technologies and later the Web3 Foundation (Polkadot).

The Yellow Paper’s formalism draws on:

Modified Merkle Patricia Tries for all state storage
RLP (Recursive Length Prefix encoding) for serialization
Keccak-256 hashing (a variant of SHA-3)
secp256k1 ECDSA for signatures
Gas accounting formulas defined as mathematical functions

Core Design: The World State and State Transition

The Ethereum system is defined as a world state σ — a mapping from 160-bit Ethereum addresses to account objects. Each account contains:

Nonce (transaction count or contract deployment count)
Balance (in Wei, the smallest ETH denomination)
Storage root (Merkle root of account’s persistent storage)
Code hash (hash of the account’s bytecode, or the empty hash for EOAs)

The state transition function Υ(σ, T) = σ’ maps a prior world state and a transaction to a new world state. The Yellow Paper specifies Υ formally in every detail, including:

Signature verification
Nonce validation
Gas prepayment deduction
Contract creation vs. message call routing
EVM execution
Gas refunds
Coinbase payment

The Ethereum Virtual Machine (EVM)

The Yellow Paper’s central contribution is the formal specification of the EVM — a 256-bit stack-based virtual machine with a specific instruction set (opcodes), gas costs per opcode, and well-defined memory and storage models.

Key properties:

Property	Specification
Architecture	Stack-based, 256-bit word size
Stack depth	Maximum 1024 items
Memory	Byte-addressable, expands in 32-byte words, quadratic memory cost
Storage	Persistent key-value store, 256-bit keys and values
Gas model	Every opcode has a defined gas cost; execution halts at gas limit
Turing-completeness	Yes — with gas as the halting mechanism

Gas is the mechanism preventing infinite loops — every opcode consumes gas, and execution halts if gas is exhausted. The Yellow Paper specifies the exact gas costs for each opcode (though these have been updated through EIPs over the years).

Sections of the Yellow Paper

Section	Content
§1–2	Introduction; blockchain paradigm
§3	Conventions, notation (mathematical definitions)
§4	Blocks, state, transactions
§5	Gas and payment
§6	Transaction execution
§7	Contract creation
§8	Message call
§9	Execution model (EVM specification)
§10	Blocklevel state transition function
§11	Mining (original PoW spec; now superseded)
§12	Block finalization
Appendices	Opcode table; RLP encoding; Patricia trie; opcodes and gas costs

Legacy

The Yellow Paper’s influence is immeasurable. It:

Made competing client implementations possible (essential for Ethereum’s decentralization)
Formalized the EVM in a way that enabled formal verification of smart contracts
Introduced gas pricing as a mechanism for Turing-completeness safety, now universal in EVM-compatible chains
Created the conceptual infrastructure that the entire EVM ecosystem (BSC, Polygon, Avalanche C-Chain, and hundreds more) is built on

Gavin Wood later used the same formal specification approach for Polkadot’s runtime (now formalized in WebAssembly).

Related Terms

Research

Wood, G. (2014, updated 2024). Ethereum: A Secure Decentralised Generalised Transaction Ledger. ethereum.github.io/yellowpaper.

— The primary source. Appendix H (virtual machine specification) and Appendix G (opcode gas costs) are the definitive technical references.

Hildenbrandt, E., et al. (2018). KEVM: A Complete Formal Semantics of the EVM. IEEE CSF.

— Computer-verified formal semantics of the EVM derived from the Yellow Paper.

Luu, L., Chu, D.-H., Olickel, H., Saxena, P., & Hobor, A. (2016). Making Smart Contracts Smarter. CCS 2016.

— Early analysis of EVM security vulnerabilities; motivated by the Yellow Paper’s formalism.