Merkle trees and

Blockchains

Dor Cohen
 Alice and Bob
• Bob stores a set of items for Alice.
• Alice keeps a single value.
• Alice can validate the Items returned to her.
 Basics - Cryptographic Hash
• Arbitrary Input size.
• Output size is fixed.
• H(x) is easy to compute.
• But finding any x, x’ s.t. H(x) = H(x’), should be
computationally hard.

• The output should also appear “random”.

 First Solution
• Alice keeps the hash of the entire set.

H( , , )
 Validation Of An Item
Bob sends all of the items to Alice.
Alice computes the hash of the items.
Alice compares the result to the value she has saved.
H( , , )

H( , , )
 Problems With First Solution
• Bob must send Alice the entire set for validation.
OK
?
 Problems With First Solution
• Bob must send Alice the entire set for validation.
• Denote m to be the size of the set.
• We have O(m) network traffic for validating a single item.
• Can we do better?
 Validating An Item
Bob sends Alice an item d and a logarithmic size proof.
Alice computes a function of the item and proof.
Alice compares the result to the value she has saved.d Proof
ce86b7dde40...

F( , )
 Merkle Tree
H(H1,4,H5,8) Merkle root

H(H1,2,H3,4) H(H5,6,H7,8)

H(d1,d2) H(d3,d4) H(d5,d6) H(d7,d8)

d1 d2 d3 d4 d5 d6 d7 d8
 Validating An Item
Bob sends Alice an item d and a logarithmic size proof.
Alice uses the proof to compute the Merkle root.
Alice compares the result to the root she has saved. d Proof
Merkle root

F( , )
 Alice Computes The Root
Given an item d and H1,H2,H3 hash values
H(H3|| . )

H3 H( . ||H2)

H( . ||H1) H2

d H1
 What If d Isn’t Valid?
Given an item d and H1,H2,H3 hash values
H(H3|| . )

H3 H( . ||H2)

H( . ||H1) H2

d H1
 Blockchain– Full nodes
• Full nodes are nodes in the Blockchain network that store
the entire Blockchain in order to validate new transactions.
• Since Blockchains are decentralized full nodes are very
Block
Header
Block
Header
Block
Header
Block
Header
Block
Header
Block
Header

important to the network.

Transactions list
• 5b3a2…
Transactions list
• 5b3a2…
Transactions list
•
•
5b3a2…
3bc48…
Transactions list
•
•
5b3a2…
3bc48…
Transactions list
• 5b3a2…
Transactions list
• 5b3a2…
• 3bc48… • 3bc48… • 3bc48… • 3bc48…
• cd3a0… • cd3a0… • cd3a0… • cd3a0… • cd3a0… • cd3a0…

No double
spending
here
Motivation - Storing the Blockchain
• The problem is the Blockchain can take up a lot of
memory.
Database size
Bitcoin 149 GB (December 2017)
Ethereum 400 GB (February 2018)

• And these numbers are constantly growing.

• Some devices such as mobile can’t spare that much
space.
 A Block in the Blockchain
• Block’s are consisted of two main parts:
Block Header
• Previous block header’s hash
• Nonce (proof of work)

Transactions list
• 5b3a2…
• 3bc48…
• cd3a0…
 Light Nodes
• Light nodes were created for simple clients who want to
save on storage.
• They only store the chain of block headers.
• They follow the longest chain rule, without validating
transactions.
Block Header Block Header
• Previous block header’s hash • Previous block header’s hash
• Nonce (proof of work) • Nonce (proof of work)

Transactions list Transactions list

• 5b3a2… • 5b3a2…
• 3bc48… • 3bc48…
• cd3a0… • cd3a0…
 Paying With Light Nodes
• Same as full nodes.
 Accepting Payment

Block Header Block Header Block Header Block Head

• Previous block header’s • Previous block header’s • Previous block header’s • Previo
hash hash hash hash
• Nonce (proof of work) • Nonce (proof of work) • Nonce (proof of work) • Nonce
Transactions list Transactions list Transactions list Transaction
• 5b3a2… • 60ce1… • 81ede… • 85fc1a…
• 3bc48…
??? • 93f31… • 5c371… • bd93f…
• cd3a0… • a7082… • 4e41d… • f4798…
 Merkle Root In Header
• Put the Merkle root of transactions in the header.
Block Header
• Previous block header’s hash
• Nonce (proof of work)
• Merkle root
Transactions list
• 5b3a2…
• 3fc48…
• cd3a0…
• 73e7c…
 Merkle Root In Header

• Now light nodes can request transactions from full

nodes, and know that they were from a block.
• Just like Alice did with Bob.
 Forgetting Spent Transactions

• Having the Merkle root in the header has another

interesting perk.
• Freeing storage in full nodes by forgetting transactions
that are already spent.
 Forgetting Spent Transactions
• Suppose that t1,t2,t3 have all been spent.
• We can get rid of most of them.
• Now we’re storing H(t1||t2) in the block
H(H1,2|| H3,4)
instead of t1 and t2.
H(t1||t2) H(t3||t4)

t1 t2 t3 t4
 Forgetting Spent Transactions
• Suppose that t1,t2,t3 have all been spent.
• We can get rid of most of them.
• Now we’re storing H(t1||t2) in the block
instead of t1 and t2. H(H1,2|| H3,4)

H(t1||t2) H(t3||t4)

t3 t4
 Conclusion
• Merkle trees are a smart way to hash.
• They allow for easier storage of Blockchains, allowing
headers to represent the entire block in a concise way.
• They even allows us to forget the transaction IDs of
spent transactions.
Questions?