For educational purposes only; not investment advice. Investing may result in loss.
Direct answer
A Merkle tree hashes each data item into a leaf, combines neighboring hashes repeatedly, and produces one top-level Merkle root. The root is a compact commitment to the leaves and to the ordering and hashing rules used to build the tree.
A Merkle proof contains the sibling hash at each level for one leaf. A verifier recomputes the path from that leaf to the root and accepts inclusion only when the result matches a trusted root. The verifier therefore does not need the other leaves or the full dataset.
The commitment is about data representation, not truth. A matching root does not show that the source data was accurate, that the data remains available, or that a contract, bridge, oracle, or market is safe. The verifier must obtain the root and the leaf under an authenticated protocol and understand the tree’s domain-separation, ordering, and odd-leaf rules.
Merkle trees appear in several designs. Bitcoin places a Merkle root for block transactions in each block header; Ethereum uses a modified Merkle-Patricia Trie for state and other authenticated structures. These systems share a construction idea but have different encodings, proof formats, update rules, and security assumptions, so their proofs are not interchangeable.
How it works
First, the system defines a deterministic leaf encoding and hash function. It then hashes each leaf, hashes pairs of child values into parent nodes, and repeats until one root remains. A proof must include the leaf position or direction information when the verifier cannot infer it from the protocol.
For a balanced binary tree, a proof for one of 1024 leaves needs about 10 sibling hashes because each level doubles the covered range. The exact size depends on the tree shape, hash length, duplicate-leaf policy, and any multiproofs or compressed proof format.
The core relationship can be written as parent = Hash(left || right) and root = fold(parent, leaves). The notation is schematic: protocols may prefix leaf and internal-node hashes, use a different arity, or encode keys in a trie. A proof demonstrates consistency with the specified construction; it does not authenticate a root that the verifier has not independently trusted.
In a blockchain, the root is committed by a block header, state record, or contract. A light client or application can request a leaf and its authentication path, recompute the root, and then apply the protocol’s confirmation, finality, freshness, and availability rules. Hash verification alone does not replace those rules.
Example
Suppose a block contains 1024 transactions and uses a binary transaction tree. A transaction can be accompanied by about 10 sibling hashes rather than transmitting the other 1023 transactions. The verifier still needs the relevant block header and a rule for how the transaction was encoded and positioned.
If a proof fails, investigate the leaf bytes, byte order, tree padding, root source, and block status before concluding that the transaction is absent. A valid proof for an unfinalized or stale root may be technically correct while no longer representing the canonical chain state.
For an application that displays a balance or reward, separate proof validity from the economic result. The displayed amount can still be affected by fees, price changes, slippage, contract permissions, withdrawal limits, or an unavailable data source. A Merkle proof verifies membership in a commitment; it does not guarantee a redeemable amount.
Risks
The main technical risks are ambiguous encodings, hash-function misuse, second-preimage or collision weaknesses, incorrect sibling ordering, and accepting a root from an untrusted or stale source. Domain separation between leaves and internal nodes helps prevent structural ambiguity but must be implemented consistently.
Operational risks sit outside the hash calculation. A bridge, oracle, sequencer, exchange, or contract administrator may publish, delay, censor, or replace the root; a data-availability failure may prevent users from obtaining the leaf or proof; and a chain reorganization may invalidate a proof tied to an earlier block.
Before relying on a proof, identify who authenticates the root, how freshness and finality are checked, how missing or odd leaves are handled, and whether users can recover their data independently. Limit authorization and exposure when the loss from a bad root, compromised signer, unavailable data, or protocol upgrade cannot be bounded.
Common misconceptions
Myth 1: A matching root proves that the data is true
It proves only that the supplied leaf is consistent with the committed root under the stated construction. If an oracle or operator committed an incorrect value, the proof faithfully verifies the wrong value.
Myth 2: A Merkle proof makes the whole system trustless
The verifier still trusts the hash function, encoding rules, root-authentication path, and the system that supplies the data. Consensus, finality, availability, and governance remain separate security questions.
Myth 3: Every blockchain uses the same Merkle tree
Bitcoin transaction trees, Ethereum’s modified Merkle-Patricia Trie, and application-specific trees differ in layout and proof rules. A proof format from one protocol cannot be assumed to work in another.
Myth 4: A short proof guarantees a cheap or safe transaction
Proof size reduces data transfer, but verification gas, storage reads, network congestion, contract bugs, and withdrawal or liquidation risks can still dominate the outcome.
Related topics
Sources
- Blockchain Technology Overview - NIST (accessed: 2026-08-21)
- Merkle Trees - Bitcoin.org (accessed: 2026-08-21)
- Merkle Patricia Trie - Ethereum Foundation (accessed: 2026-08-21)