What Is a Merkle Tree in Blockchain?

What Is a Merkle Tree?

A Merkle tree is a cryptographic data structure that makes it possible to compactly and reliably verify the integrity of a large dataset without having to check the entire dataset.

Merkle Tree Structure

A tree is built from hashes — unique fixed-length values obtained by processing source data with a hash function. First, individual data blocks or transactions are hashed — the resulting values form the “leaves” of the tree. The hashes are then combined in pairs and hashed again. The process is repeated until only one value remains — the Merkle Root. Let’s look at each stage separately.

Leaf Nodes

Leaf nodes are the lowest level of a Merkle tree. They contain cryptographic hashes of the source data, such as transactions on a blockchain. Each transaction is processed through a hash function, producing a fixed-length hash.

If we denote the transactions as Tx1, Tx2, Tx3, and Tx4, the leaf nodes can be represented as follows:

H1 = Hash(Tx1) H2 = Hash(Tx2) H3 = Hash(Tx3) H4 = Hash(Tx4)

Even the slightest change to the original transaction will change its hash, making it possible to detect a breach in data integrity.

Parent Nodes and Branches

At the next level, the hashes of child nodes are combined in pairs and hashed again. This creates the parent nodes:

H12 = Hash(H1 || H2) H34 = Hash(H3 || H4)

Here, || denotes concatenation — the sequential combination of two values. This process is repeated at each level of the tree. As a result, each parent node is cryptographically linked to all the data located below it.

Together, these links form the branches of the Merkle tree. They make it possible to construct a Merkle Proof and confirm the presence of a specific element in a dataset using only a subset of hashes rather than all the source data.

Merkle Root

At the top of the tree is a single hash that represents the entire dataset and serves as its cryptographic fingerprint. It is formed by hashing the two child nodes from the previous level.

Merkle Root = Hash(H12 || H34)

Any change to the source data changes the corresponding leaf hash, then the parent nodes, and ultimately the root itself. This makes it possible to quickly verify the integrity of the data represented by the Merkle tree.

How Does a Merkle Tree Work?

A Merkle tree sequentially combines and hashes data until multiple source values are reduced to a single hash — the Merkle Root. In Bitcoin, the tree is built using transaction TXIDs: hashes are combined in pairs and hashed again, and the process is repeated until a single value is obtained.

Let’s look at a simplified example with four transactions — A, B, C, and D.

1. Obtain the leaf hashes. The hash of each transaction is used. Let’s denote the four leaf values as H(A), H(B), H(C), and H(D).
2. Combine the hashes in pairs. Adjacent values are combined in a specified order: first H(A) + H(B), then H(C) + H(D). The order matters: rearranging the hashes will change the result of subsequent hashing.
3. Calculate the parent hashes. Each resulting pair is hashed: H(AB) = Hash(H(A) || H(B)) H(CD) = Hash(H(C) || H(D))

   Here, || denotes concatenation — the sequential combination of two values.

4. Combine the parent hashes. The resulting H(AB) and H(CD) are also combined in the specified order: H(AB) || H(CD)
5. Calculate the Merkle Root. The result is hashed again: Merkle Root = Hash(H(AB) || H(CD))

Thus, the four original values are reduced to a single root hash. In Bitcoin, this Merkle Root is recorded in the block header.

Schematically, the process looks like this:

What Happens When There Is an Odd Number of Transactions?

Bitcoin has a separate rule for situations where a hash is left without a pair at a certain level of the tree. It is combined with a copy of itself and then hashed. The official Bitcoin guide describes this rule for both the original TXIDs and intermediate levels of the tree.

For example, for three TXIDs:

In other words, the last unpaired hash C is duplicated to form a pair.

Importantly, duplicating the last unpaired hash is a rule for constructing Merkle trees in Bitcoin, not a universal property of all Merkle trees. Other protocols and implementations may use different methods for handling an odd number of elements.

What Is a Merkle Proof?

A Merkle Proof is a way to confirm that a particular transaction or other element belongs to a dataset represented by a specific Merkle Root.

The entire tree is not required for verification. The hash of the element being verified and several neighboring hashes needed to reconstruct the path to the root are sufficient. For example, to confirm transaction A in a four-element tree, H(A), H(B), and H(CD) are required.

The root obtained during verification is compared with the known Merkle Root. If the values match, the element’s inclusion in the corresponding dataset is considered confirmed.

The size of such a proof grows approximately as O(log n), so a Merkle Proof remains compact even for large datasets.

How Merkle Proof Is Used in Bitcoin: SPV

One practical application of Merkle Proof in Bitcoin is associated with Simplified Payment Verification (SPV). This approach makes it possible to verify that a transaction is included in a block without running a full node or storing all blockchain data.

An SPV client works primarily with block headers. To link a transaction of interest to a specific block, a Merkle Proof is used: it allows the client to check whether the transaction corresponds to the Merkle Root recorded in that block’s header.

At the same time, SPV does not provide the same level of independent verification as a full node: the client does not independently validate all transactions and consensus rules.

Therefore, SPV is a more lightweight method of payment verification, but one that relies on additional security assumptions.

Merkle Trees in Ethereum

Ethereum does not use classic Merkle trees but rather more complex variations of them. Historically, Merkle Patricia Tries have played a key role — structures that combine the properties of a Merkle tree and a prefix tree (trie).
They are used to cryptographically commit to the network state and make it possible to create compact proofs of the presence or absence of specific data. Modern Ethereum also uses other Merkle structures, including for consensus-layer data.

Merkle Trees and Proof of Reserves

In Proof of Reserves (PoR) systems, a Merkle tree can be used to record a set of a platform’s liabilities to users. Balance records are included in the tree, and the resulting Merkle Root serves as a cryptographic fingerprint of this dataset at a specific point in time.
A user receives a Merkle Proof and can independently verify that their record was included in the set of liabilities corresponding to the published root.

However, such verification has limitations. A Merkle Proof only confirms the inclusion of a specific record and does not, by itself, prove:

• the platform’s ownership of the stated assets or their sufficiency to cover liabilities;
• the completeness of all recorded liabilities;
• the timeliness of the published data;
• the confidentiality of user data.

Therefore, the use of a Merkle tree does not replace an independent audit or a transparent Proof of Reserves methodology but serves only as one of the tools for cryptographic data verification.

Advantages of Merkle Trees in Blockchain

Merkle trees simplify the verification of large amounts of data and reduce resource requirements.

1. Efficient data verification. Confirming the inclusion of an element does not require processing the entire dataset.
2. Compact proofs. The size of a Merkle Proof grows approximately as O(log n).
3. Integrity control. A change to the source data results in changes to the associated hashes and the tree root.
4. Resource efficiency. Verification requires less data, computation, and network traffic compared with processing the entire dataset.
5. Scalability. The structure remains efficient when working with a large number of elements.

Disadvantages of Merkle Trees in Blockchain

Despite their efficiency, Merkle trees have several technical limitations.

1. Dependence on the hash function. The reliability of the structure is determined by the cryptographic strength of the algorithm used.
2. Need for additional data. Verifying an element requires a Merkle Proof containing the hashes of neighboring nodes.
3. More complex updates. Changing an element requires recalculating all associated hashes up to the root.
4. Limited scope of proof. A Merkle Proof confirms the inclusion of an element in a specific dataset but not the accuracy of the source data itself.
5. Differences in implementation. Tree construction rules may differ between blockchains and protocols, which must be taken into account during verification.

Merkle Tree, Hash Chain, and Blockchain: Differences

These concepts are related through the use of cryptographic hashes, but they describe different structures and serve different purposes.

Structure	Primary Purpose	How Records Are Linked	Use in Cryptocurrencies
Merkle Tree	Efficient verification of data integrity and inclusion	Multiple elements are hierarchically reduced to a single root hash	Verification of transactions and other datasets
Hash Chain	Sequential linking of data	Each subsequent record is linked to the previous one by a hash	Linking sequential records or blocks
Blockchain	Maintaining and coordinating a distributed ledger	Blocks are linked in sequence according to the rules of a specific protocol	Storing and validating transaction history using consensus mechanisms

Other Applications of Merkle Trees

Beyond blockchain, Merkle structures are used in distributed file systems and content addressing, version control systems such as Git, authenticated databases, and allowlists.

Conclusion

A Merkle tree transforms an ordered set of cryptographic commitments into a single root hash and makes it possible to create compact proofs of inclusion. In cryptocurrencies, this structure enables efficient data verification, but the significance of such proof depends on trust in the verified root, the tree construction rules, and the validation mechanisms of the specific protocol.

This material is for informational purposes only and does not constitute financial or investment advice.