Part I · 2 — Concepts and the trilemma
Four ideas underpin every blockchain: the chaining that gives immutability, the Byzantine generals problem that consensus solves, the trilemma that constrains every design, and the transaction model that defines state. Master them and the rest of the compendium falls into place.
2.1 Chaining and immutability
Each block carries the hash of the previous block in its header. Because the hash (Part II of Crypto) changes completely with any change to the input, changing an old block changes its hash — which invalidates the pointer of the following block, and the next, in a cascade.
Tampering with history, then, would require recomputing every subsequent block and still outpacing the work of the entire honest network — economically infeasible. Hence immutability.
Immutability is not absolute. It is practical resistance to tampering, not mathematical impossibility: a coordinated hard fork can rewrite history (like the 2016 The DAO fork on Ethereum). The guarantee is economic and social, not just cryptographic.
Within each block, transactions are summarized in a Merkle tree — a structure of hashes that lets you prove a transaction is in the block without downloading the entire block. It is what makes light clients viable.
2.2 The Byzantine generals problem
Why is consensus hard? The Byzantine generals problem (Lamport, 1982) is the canonical metaphor: several generals surround a city and must agree on whether to attack or retreat, communicating only through messengers — knowing that some generals may be traitors sending contradictory messages. How do you reach a reliable agreement despite malicious participants?
A blockchain faces exactly this: nodes scattered across the world, some honest, some malicious, must agree on the same order of transactions without a coordinator. A system is Byzantine fault tolerant (BFT) if it reaches consensus even with a fraction of nodes acting arbitrarily. Bitcoin's innovation (2008) was to solve this at open scale, with incentives — the subject of Part II (under construction).
The practical consequence is finality: when a transaction becomes irreversible. It can be probabilistic (in Bitcoin, each additional block makes it exponentially more secure) or deterministic (in BFT systems, a finalized block never comes back).
2.3 The scalability trilemma
The central trade-off of every blockchain design, articulated by Vitalik Buterin: it is easy to have two of the three properties below — hard to have all three at the same time.
- Decentralization — anyone can participate and validate with modest
hardware (no barrier to entry).
- Security — resisting costly attacks (controlling the network must cost a lot).
- Scalability — high transaction throughput.
Bitcoin and Ethereum L1 prioritize decentralization + security, sacrificing scalability (hence 7–15 TPS). Very fast chains tend to sacrifice decentralization (few powerful validators). It is this trilemma that the L2 layers (Part III) try to work around — scaling without giving up the security of the L1.
2.4 Transaction models and wallets
There are two ways to represent the state of the ledger:
| Model | How it works | Used by |
|---|---|---|
| UTXO | the balance is the set of "unspent outputs"; each tx consumes some and creates others (like banknotes) | Bitcoin |
| Account | each address has a balance and storage, updated with each tx (like a bank account) | Ethereum |
In both, identity is a key (Part II of Crypto): the address derives from a public key; spending requires signing with the private one. A wallet does not hold coins — it holds keys. Losing the private key means losing the funds, with no recovery: the brutal flip side of having no central authority to "reset the password".
Dense reference: complete vocabulary, properties, CAP/FLP, tx models and network topology in
02-fundamentals. End of Part I. The Part II — Consensus (under construction) opens the black box: Proof of Work, Proof of Stake, and how Byzantine agreement actually happens.