Helpful context:

In 1982, Lamport, Shostak, and Pease published “The Byzantine Generals Problem” in ACM TOPLAS. The paper posed a puzzle: how can geographically distributed generals coordinate an attack when some of them might be traitors sending conflicting messages? The question was purely theoretical - a way to formalize the problem of reaching consensus in the presence of arbitrary (Byzantine) failures. The paper showed that if more than 1/3 of participants are traitors, consensus is provably impossible - at least in the synchronous, message-passing model they analyzed.

The paper sat dormant for 26 years. Then in 2008, an unknown person or group publishing under the name Satoshi Nakamoto released a 9-page whitepaper titled “Bitcoin: A Peer-to-Peer Electronic Cash System.” It solved the Byzantine generals problem in a completely different way - not by limiting traitors, but by making betrayal economically irrational. Instead of authenticating identity, Bitcoin authenticated work: to participate in the consensus process, you had to burn real electricity. The Nakamoto consensus showed that Lamport’s impossibility result was about one model of Byzantine fault tolerance, not all of them.

The ideas in blockchain - Merkle trees, hash pointers, proof-of-work, and the incentive structures that make them work - each have histories that predate Bitcoin by decades. Ralph Merkle described Merkle trees in his 1979 dissertation. Proof-of-work was proposed by Cynthia Dwork and Moni Naor in 1992 as a mechanism to combat email spam. Adam Back independently invented it again as Hashcash in 1997. What Nakamoto did was combine these pieces in a way that made a new thing: a system that multiple mutually-suspicious parties can use to agree on a shared history, without trusting any central authority.

Cryptographic Building Blocks

Hash functions as commitments. A cryptographic hash function maps arbitrary-length input to a fixed-length digest. Three properties matter: collision resistance (computationally infeasible to find $x \neq y$ with $H(x) = H(y)$), preimage resistance (given $H(x)$, can’t find $x$), and second-preimage resistance (given $x$, can’t find $y \neq x$ with $H(y) = H(x)$). These properties make a hash a commitment: once you publish $H(x)$, you’re committed to $x$ without revealing it. Bitcoin uses SHA-256; Ethereum uses Keccak-256 (a variant of SHA-3).

Hash pointers. A hash pointer is a (pointer, hash) pair: it points to some data and includes a cryptographic hash of that data. If anyone tampers with the data, the hash changes and the pointer is no longer valid. Chain hash pointers together and you get a tamper-evident log. To change any record, you must change all subsequent hashes - every modification cascades forward and is detectable.

Merkle trees. A binary tree where each leaf contains a hash of a data block, and each internal node contains $H(\text{left} | \text{right})$. The root hash commits to the entire dataset. Key property: to prove that a specific transaction is in a tree of $n$ leaves, you need only $O(\log n)$ hashes - the “Merkle proof” or authentication path, consisting of the sibling hashes along the path from leaf to root. A lightweight Bitcoin client (“SPV client”) can verify that a transaction was included in a block by downloading only 30-odd hashes rather than every transaction in the block. This was essential to Nakamoto’s design for mobile and low-resource nodes.

Digital signatures. A signature scheme (Gen, Sign, Verify) lets Alice sign a message $m$ to produce $\sigma = \text{Sign}(sk, m)$, which anyone can verify with $\text{Verify}(pk, m, \sigma) = 1$. Unforgeability: an adversary with $pk$ and many $(m, \text{Sign}(sk, m))$ pairs cannot produce a valid signature on any new message. Bitcoin uses ECDSA over the secp256k1 curve. Every transaction is a statement “I transfer $X$ coins from address $A$ to address $B$” signed by the private key corresponding to $A$. The address is the public key (or more precisely, its hash, which is shorter). No identity, no accounts, just keys.

The Blockchain Data Structure

A blockchain is a linked list of blocks where each block contains a header and a body. The header includes: the hash of the previous block, the Merkle root of all transactions in this block, a timestamp, a nonce, and a difficulty target. The body is the list of transactions.

The chain property: block $i$ contains $H(\text{block}_{i-1})$. So the hash of block $n$ transitively commits to the entire history. To change any transaction in block $k < n$, you must change block $k$ (altering its hash), which invalidates block $k+1$’s header, requiring you to recompute block $k+1$, then $k+2$, all the way to the tip. Immutability is not a property of any single block - it is an emergent property of the chain, and it depends on how much work is piled on top.

The genesis block (block 0) is hardcoded - it has no previous block to point to. Bitcoin’s genesis block, mined by Nakamoto on January 3, 2009, contains a message in its coinbase transaction: “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.” This served as a timestamp and as Nakamoto’s commentary on what Bitcoin was for.

UTXO model. Bitcoin tracks coins not as account balances but as Unspent Transaction Outputs. Each transaction consumes some UTXOs (inputs, each signed by the private key of the owner) and creates new UTXOs (outputs, each locked to a new public key hash). The UTXO set is the complete current state of the ledger - it contains every spendable coin. To spend a coin, you must spend the entire UTXO and create change back to yourself. This stateless design - each UTXO is independently verifiable - avoids global state contention and makes parallel verification straightforward.

Consensus via Proof of Work

The double-spend problem. Alice has 1 BTC. She sends it to Bob (for goods) and simultaneously broadcasts a conflicting transaction sending the same coin to Carol (herself, under a different key). Both transactions are valid according to Alice’s key. The network must pick one. Without a central authority, how do mutually-suspicious strangers agree on which transaction came first?

Nakamoto consensus. To add a new block, you must find a nonce such that:

$$H(\text{block header} | \text{nonce}) < \text{target}$$

Since SHA-256 is pseudorandom, finding such a nonce requires, on average, $2^{256} / \text{target}$ hash evaluations. The difficulty target is adjusted every 2016 blocks (approximately two weeks) so that blocks arrive at one per ten minutes on average, regardless of total network hash rate. As of 2024, the Bitcoin network performs roughly $500 \times 10^{18}$ hashes per second. Finding a valid block is a lottery where each ticket costs one hash computation.

The longest chain rule: all participants accept the chain with the most cumulative proof-of-work as the valid chain. If two miners find valid blocks simultaneously (a fork), the network splits temporarily. The fork resolves when one chain grows longer - everyone switches to it, and the orphaned block’s transactions return to the mempool. Honest miners always extend the longest chain they know of.

51% attack. To rewrite history - say, to cancel a payment already buried 6 blocks deep - an attacker must redo the PoW for that block and all six subsequent blocks faster than the honest network adds new blocks. If the attacker controls fraction $\alpha$ of total hash rate and the honest network controls $1 - \alpha$, the attacker’s chain grows at rate $\alpha$ and the honest chain grows at rate $1 - \alpha$. For $\alpha < 0.5$, the honest chain overtakes the attacker’s chain exponentially fast. For $\alpha > 0.5$, the attacker can (in expectation) outrun the honest network indefinitely. This converts Byzantine fault tolerance into a physical resource argument: attack cost equals wasted electricity plus forfeited block rewards.

Selfish mining. A more subtle attack: a miner who finds a block withholds it, mining privately on their own chain while the public network mines on the old tip. When the public chain catches up to within one block of the private chain, the attacker releases their chain. Honest miners, seeing a longer chain, discard their recent block and switch - wasting that work. A pool with roughly 33% of hash rate can profit from this strategy, earning a disproportionate share of block rewards relative to their honest share. Eyal and Sirer published this attack in 2013. Nakamoto had assumed all miners follow the protocol. Selfish mining shows that rational miners can profit by deviating, which is a meaningful problem for the economic security model.

Discomfort check. “Proof of Work is secure against 51% attacks” - but 51% of what, exactly? Of the hash rate of whoever is currently mining. This depends on hardware economics and energy prices. A sudden breakthrough in ASIC efficiency or a collapse in electricity costs for one actor could shift the balance. Additionally, PoW security in the long run requires that block rewards keep honest mining profitable. Bitcoin’s block reward halves every 210,000 blocks (roughly every four years) - 6.25 BTC in 2020, 3.125 BTC after April 2024. As rewards shrink toward zero, security depends entirely on transaction fee revenue. Whether fee markets can sustain mining incentives is an open and genuinely unresolved question.

Proof of Stake

PoW’s energy consumption is enormous - Bitcoin uses roughly 100 - 150 TWh per year, comparable to a small country. This motivated a different Sybil defense: Proof of Stake, where the right to participate in consensus is proportional to locked-up capital rather than burned electricity.

Mechanics. Validators lock up (“stake”) cryptocurrency as collateral. The protocol selects validators to propose and attest to blocks, weighted by stake. If a validator cheats - for instance, signing two conflicting blocks for the same slot - the protocol “slashes” them: a portion of their stake is burned and they are ejected. The key economic argument: attacking the chain requires controlling a large stake, and a successful attack destroys the value of that stake.

Ethereum’s Casper FFG. Ethereum transitioned from PoW to PoS in “The Merge” in September 2022. Its finality mechanism (Casper FFG) works in epochs of 32 slots. Validators vote on checkpoint blocks. When two-thirds of the total staked ETH votes to justify a checkpoint, it is justified; when two consecutive checkpoints are justified, the earlier is finalized. A finalized block cannot be reverted without destroying more than one-third of the total stake. Compare this to PoW, where finality is probabilistic - a block buried 6 deep is “probably” final, but the probability approaches 1 asymptotically, never reaching it.

The nothing-at-stake problem. In PoW, miners can only extend one chain at a time (their hardware works on one chain head). In a naive PoS without slashing, validators could sign every fork simultaneously at zero marginal cost - there is nothing at stake on the wrong fork. Slashing is the mechanism that makes this costly: sign two conflicting blocks, get slashed. Slashing is what makes PoS’s security arguments work, and why Ethereum’s slashing conditions are carefully specified in the protocol.

LMD-GHOST fork choice. Ethereum’s fork choice rule is not “longest chain” but Latest Message Driven - Greedy Heaviest Observed SubTree: follow the subtree with the most recent validator votes (attestations) supporting it, weighted by stake. This is more resistant to certain attacks that target the longest-chain rule.

Smart Contracts and the EVM

Bitcoin’s scripting language is deliberately limited - it can express transfers and basic conditions (multisig, timelocks) but is not Turing-complete. In late 2013, Vitalik Buterin, then 19 years old, proposed adding a general-purpose execution environment to blockchain. His argument: a blockchain is not just a ledger but a decentralized state machine, and arbitrary programs deployed on it inherit blockchain’s trust properties. Ethereum launched on July 30, 2015.

The EVM (Ethereum Virtual Machine). A stack-based virtual machine where every full node executes every transaction and must agree on the result. Contracts are programs compiled to EVM bytecode and stored at blockchain addresses. They have persistent storage (a key-value map), an ETH balance, and code. A transaction to a contract address triggers its code; the result is recorded in the new state root.

Gas. Every EVM opcode costs a fixed amount of “gas.” A transaction specifies a gas limit (maximum gas it may consume) and a gas price (ETH per unit of gas). If execution runs out of gas, it reverts - all state changes roll back, but the gas fee is still paid. Gas serves two purposes: it prevents infinite loops (you run out of gas) and prices computation proportionally to cost. The block gas limit caps total computation per block.

The DAO hack. In 2016, The DAO was a decentralized venture fund holding approximately $150M in ETH. Its withdrawal function had a reentrancy vulnerability: the contract sent ETH to the caller before updating its internal balance. An attacker called withdraw, and inside the ETH transfer callback, called withdraw again recursively - draining roughly $60M before the balance check was ever reached. The Ethereum community faced a choice: let “code is law” stand, or hard-fork the chain to reverse the theft. The majority voted to fork and restore the DAO victims' funds. A minority held to the principle that blockchain history is immutable by design and continued the original chain - now called Ethereum Classic (ETC). The DAO hack remains the most philosophically divisive event in Ethereum’s history, and the reentrancy pattern it exploited is still one of the most common smart contract vulnerabilities.

Mechanism Design in Blockchain

Blockchain systems are mechanism design problems: how do you write rules so that self-interested participants, acting in their own interest, collectively produce a desirable outcome?

Block rewards and halvings. Bitcoin creates new coins per block - the coinbase reward - as the miner’s incentive to spend electricity on PoW. The supply schedule is encoded in the protocol: the reward halves every 210,000 blocks, converging to a total supply of 21 million BTC. No authority controls it; it is enforced by every node independently verifying the coinbase transaction.

MEV (Maximal Extractable Value). Miners and validators choose which transactions to include in a block and in what order. On Ethereum, this creates an opportunity: if a large trade is visible in the mempool before inclusion, a validator can insert their own transaction first - buying before the large buy pushes the price up, then selling immediately after. This “front-running” was estimated at several billion dollars per year in extractable value as of 2023. MEV is a hidden tax on users and a structural distortion of the fee market. It has given rise to a dedicated infrastructure layer (MEV-Boost, Flashbots) that tries to make MEV extraction more transparent and less harmful.

EIP-1559. Before August 2021, Ethereum used a first-price auction for block space: users bid, miners took the highest bids. First-price auctions are known to be economically inefficient (bidders overbid to be safe). EIP-1559 replaced this with a base fee, algorithmically set by the protocol based on whether the previous block was fuller or less full than target (a PI-controller-like mechanism). Users pay the base fee plus an optional tip to the validator. The base fee is burned - destroyed, not given to validators. This makes ETH slightly deflationary during high-usage periods and makes fee estimation predictable. It is a real-world implementation of a posted price mechanism, automatically adjusted by block fullness.

Automated Market Makers. Decentralized exchanges like Uniswap do not use order books. Instead, they use a constant product formula: for a pool of token X and token Y with reserves $x$ and $y$, maintain

$$x \cdot y = k$$

Trade $\Delta x$ of token X: the new reserve of X is $x + \Delta x$, so the new reserve of Y is $k / (x + \Delta x)$, and the trader receives $y - k/(x + \Delta x)$ of token Y. The price at any moment is $y/x$, and it moves with each trade - larger trades move it more. Liquidity providers deposit both tokens and earn a fraction of each trade’s fee. The mechanism requires no market maker, no order book, and no off-chain coordination. The known inefficiency: “impermanent loss” - if the price of X relative to Y moves significantly, liquidity providers would have been better off simply holding the tokens rather than providing liquidity.

Layer 2 and Scaling

Buterin articulated the blockchain trilemma: a base-layer blockchain cannot simultaneously achieve decentralization, security, and scalability. Decentralization requires many nodes; security requires those nodes to all process all transactions; scalability requires processing many transactions quickly. Base layer blockchains (L1) choose the first two and sacrifice the third - Bitcoin processes 7 transactions per second, Ethereum roughly 15. Scaling comes from Layer 2 systems that inherit L1 security without burdening every L1 node.

Payment channels. Two parties lock funds in an on-chain multisig contract. They then exchange signed “state update” messages off-chain, each reflecting the current balance split. Only the final state is settled on-chain. The Lightning Network for Bitcoin chains these channels into a routed network - Alice can pay Carol by routing through Bob, provided channels exist. Off-chain transactions are instant and nearly free. On-chain settlement happens only when a channel is opened or closed.

Rollups. Execute thousands of transactions off-chain, then post a compressed batch and a validity claim to L1. Two variants exist with fundamentally different trust models:

  • Optimistic rollups post transaction data to L1 with no proof of correctness. A 7-day “challenge window” allows anyone who detects fraud to submit a fraud proof, which the L1 contract verifies. If unchallenged, the batch is accepted. If challenged successfully, the fraudulent sequencer is slashed. Used by Arbitrum and Optimism.
  • ZK-rollups post a succinct zero-knowledge proof that the batch of transactions was executed correctly according to the state transition function. Validity is guaranteed by cryptography - no challenge window needed. Computationally expensive to generate proofs, but verification on L1 is cheap. Used by zkSync and StarkNet.

ZK-SNARKs. A zero-knowledge succinct non-interactive argument of knowledge is a proof system where a prover convinces a verifier that they know a witness $w$ satisfying some circuit $C(w) = 1$, where the proof is: (1) succinct - $O(1)$ or $O(\text{poly} \log |C|)$ size, (2) non-interactive - no back-and-forth after setup, and (3) zero-knowledge - reveals nothing about $w$ beyond $C(w) = 1$. Most zk-SNARK constructions require a one-time trusted setup ceremony to generate public parameters. If the randomness from this ceremony were ever exposed, a forger could construct false proofs. The original Zcash setup involved 6 participants, each contributing randomness and then destroying their portion. Forging proofs would require all 6 to have colluded and retained their secrets. zk-STARKs (scalable transparent arguments of knowledge) avoid trusted setup entirely and rely only on hash functions, but produce larger proofs. The difference in proof size matters a lot for L1 verification cost.

Summary

Mechanism Purpose Key Insight Trade-off
Merkle tree Compact inclusion proofs $O(\log n)$ proof for $n$-element set Read-only after commitment
Proof of Work Sybil-resistant consensus Attack cost = energy cost Massive energy consumption
Proof of Stake Sybil-resistant consensus Attack cost = slashed stake Nothing-at-stake requires slashing
UTXO model Transaction tracking Stateless, parallel verification Complex multi-input transactions
Gas (EVM) Computation pricing Prevents halting, prices resources Fee market volatility
AMM $x \cdot y = k$ Decentralized exchange No order book needed Impermanent loss, price impact
Optimistic rollup L2 scaling Assume valid unless challenged 7-day withdrawal delay
ZK-rollup L2 scaling Cryptographic validity proof Expensive proof generation

Read next: