KoinlyticsA Merkle tree is what happens when you hash pairs of hashes, then hash those hashes, and so on until you get one hash at the top. That top hash (the root) summarizes every leaf. Change any leaf and the root changes. This is the data structure that makes blockchains scalable to verify.
The construction
- Start with your data: transactions, accounts, whatever.
- Hash each item. These are the leaves.
- Pair adjacent leaves and hash the pair. That is the next level.
- Repeat until one hash remains. That is the Merkle root.
The killer feature: proofs
To prove a specific transaction is in a block of 1,000,000 transactions, you don't need to send all million. You send the transaction plus the log2(1,000,000) �?^ 20 sibling hashes along its path to the root. The verifier recomputes the root; if it matches the published root, the proof is valid.
Where you meet Merkle trees
- Bitcoin block headers (Merkle root of all transactions in the block).
- Ethereum state (a Modified Patricia Merkle Trie, a generalization).
- Light clients (verify without downloading the whole chain).
- Rollup fraud proofs ("here is the disputed state trie node with its Merkle proof").
- Airdrops ("here is your allocation with a proof against the published Merkle root").
Merkle proofs in airdrops
The classic pattern: publish the Merkle root of all eligible addresses and amounts on-chain. Recipients get their leaf and proof from an off-chain server. They submit both to the claim contract, which verifies the proof against the on-chain root and issues the token. This is how Uniswap, Optimism, Arbitrum, and hundreds of other airdrops have shipped: gas cost is O(log n) per claim, not O(n).
Verkle trees are next
Ethereum plans to replace its Merkle Patricia Trie with a Verkle tree (uses vector commitments). Verkle proofs are much smaller than Merkle proofs, which makes stateless clients possible. Every node stops needing the full state; they just verify Verkle proofs.