Recency Caveat
This skill distills Mastering Ethereum (2018) and is a 2018 snapshot. Several specifics have since changed:
- The Merge (2022) replaced Proof-of-Work (Ethash) with Proof-of-Stake; "Casper" shipped as Casper-FFG + LMD-GHOST ("Gasper"). Any PoW/mining/difficulty-bomb detail is historical.
- EIP-1559 (2021) changed the gas market (base fee + tip), superseding the simple "sender picks a gas price" model described here.
- SafeMath is now built into Solidity 0.8+ (checked arithmetic by default).
- ENS / Whisper / Swarm / Parity / testnets all changed: Whisper→Waku, Swarm spun out, Parity (OpenEthereum) discontinued, modern client diversity = Geth, Nethermind, Besu, Erigon + separate consensus clients.
Durable value is the architecture and reasoning; time-sensitive specifics are flagged [DATED 2018: …] throughout the skill.
Key Principle
Ethereum is "a deterministic but practically unbounded state machine, consisting of a globally accessible singleton state and a virtual machine that applies changes to that state" (Chapter 1). Its groundbreaking move is combining "the general-purpose computing architecture of a stored-program computer with a decentralized blockchain, thereby creating a distributed single-state (singleton) world computer" (Chapter 1). Two properties carry the entire design:
- Deterministic — every node, replaying the same transactions, must reach the identical state. This forces external data in through oracles, and is why on-chain randomness is hard.
- Practically unbounded — the EVM executes "code of arbitrary and unbounded complexity," so a program could run forever (Chapter 1).
Why This Matters
Bitcoin's only state transition is coin ownership; Ethereum generalizes the tracked state to an arbitrary key–value store plus executable code, with the blockchain recording how that memory changes over time (Chapter 1). That single generalization is what makes smart contracts possible — everything else follows from "track any state, run programs over it under consensus."
But Turing-completeness is power-as-liability, not a feature. Turing (1936) proved the halting problem is unsolvable: you cannot decide in advance whether an arbitrary program halts. Because every node must validate every transaction by executing the contracts it calls, a contract that loops forever is a DoS on the whole network — and there is no operator to reset it: "An unresponsive printer can be turned off and turned back on again. That is not possible with a public blockchain" (Chapter 1). The value isn't being Turing complete (the simplest known Turing-complete machine has 4 states, 6 symbols); it's safely constraining it (Chapter 1).
Good Examples
- Gas as the economic answer to the halting problem. Instead of asking "will this halt?" (undecidable), the EVM asks "has it run out of prepaid budget?" (trivially decidable). Each EVM instruction has a predetermined gas cost; the transaction prepays an upper bound; execution halts the moment consumed gas exceeds available gas (Chapter 1). The EVM is "quasi-Turing-complete" — every execution is capped at a finite number of steps by available gas (Chapter 13). Gas's economics are deliberately decoupled: it is bought only inside a transaction, only with ether, at a sender-chosen price, unused gas refunded — pricing computation independently of ether's exchange rate (Chapter 1).
[DATED 2018: sender-chosen gas price superseded by EIP-1559 base fee + tip.] - Specification, not implementation. Bitcoin has a reference implementation (bitcoind); Ethereum has a reference specification — "a mathematical description... in the Yellow Paper" — so multiple independent clients (Geth, Parity) interoperate (Chapter 1). The standard is the source of truth; clients are interchangeable.
[DATED 2018: Parity discontinued; modern clients = Geth, Nethermind, Besu, Erigon.] - Two account types. An EOA (externally owned account) is human-controlled, backed by a private key. A contract account holds code that runs whenever it receives a transaction (Chapter 1). A pure EOA→EOA value transfer does not practically invoke the EVM; only contract-touching transactions trigger EVM-computed state updates — drawing the line between value transfer and computation (Chapter 13).
Counterpoints
- Treating immutability as in-place upgradability. Deployed code is immutable, but the platform is not. The practical rule: design for deploy-new-and-migrate, not in-place patching — "You must be prepared to deploy new ones, migrate users, apps, and funds, and start over" (Chapter 1). Assuming you can patch a bug in place is the root design error.
- Assuming gas costs track reality automatically. Tangerine Whistle and Spurious Dragon repriced underpriced I/O-heavy opcodes after DoS attacks (Chapter 1) — gas costs must track real resource use or they become an attack surface.
- Forgetting the EVM is single-threaded and isolated. "The Ethereum world computer is single-threaded, like JavaScript" (Chapter 13); it is "completely virtual" with no system/hardware interface, which is why contracts can't read external state and need oracles (Chapter 13).
Key Quotes
"Ethereum is a deterministic but practically unbounded state machine, consisting of a globally accessible singleton state and a virtual machine that applies changes to that state." — Antonopoulos & Wood, Chapter 1
"An unresponsive printer can be turned off and turned back on again. That is not possible with a public blockchain." — Antonopoulos & Wood, Chapter 1
"The EVM is the part of Ethereum that handles smart contract deployment and execution." — Antonopoulos & Wood, Chapter 13
Rules of Thumb
- When reasoning about any Ethereum behavior, ask first: is this constrained by consensus, and does it consume gas? Computation is the part that can fail and demands defensive code.
- The five recurring themes to apply everywhere: (1) power-as-liability — generality must be bounded; (2) determinism→imported trust — external data must come via oracles; (3) spec-over-implementation — trust the Yellow Paper, not one client; (4) self-custody & irreversibility — no undo, no custodian; (5) security-by-maturity — reuse battle-tested code, don't reinvent primitives.
- Never write a contract that assumes an external party can pause, reset, or patch it after deployment.
- Treat any "SHA-3"/PoW/gas-price detail as potentially
[DATED 2018]and verify against the current protocol.
Related References
- Cryptography — Keys, Addresses & the One-Way Trap - how EOAs are derived from keys
- Wallets & Key Management — HD Wallets, Mnemonics & Self-Custody - self-custody of the keys behind accounts
- EVM Internals — Stack Machine, State, Gas, and Bytecode - the stack machine that gas meters
- Transactions — Ethereum's Sole Canonical State-Change Input - the sole trigger of state change