# Merkle Trees The question this note answers: how do you prove one item is in a set without showing the whole set? The construction is pleasingly simple. Hash pairs of items. Then hash the pairs of hashes. Keep going until one hash remains — the root. ```text root / \ h12 h34 / \ / \ tx1 tx2 tx3 tx4 ``` The root now commits to everything below it: change any leaf and the root changes. And here's the useful part — to prove `tx3` is included, you don't need the whole tree. You provide `tx4` and `h12`, and anyone holding the root can recompute the path and check. That's a logarithmic proof for a dataset of any size. ## Why blockchains lean on this Once you have cheap inclusion proofs, a lot of doors open: - A block header can carry one transaction root instead of every transaction. Verifying inclusion no longer requires downloading the block. - Light clients can hold just the headers and check proofs against them — this is what makes "verify without storing everything" possible at all. - Ethereum extends the idea to its entire state: a Merkle-Patricia trie commits to every account and every storage slot, so one 32-byte `state_root` in each header stands for the whole world state. - Rollups post state roots to L1, and fraud proofs and validity proofs argue about transitions between those roots. If you want the compact framing: a Merkle root is a commitment. It binds you to a dataset without revealing or transmitting the dataset, and most of blockchain's "verify, don't trust" machinery turns out to be commitments plus proofs against them, arranged in careful order. ## Where this matters - [[03 Blocks, Hashes, and History]] — Merkle roots inside block structure - [[02 Cryptographic Primitives]] — commitments as a general tool - [[09 Scaling - Rollups and Data Availability]] — state roots as the interface between layers