A concrete example
Two competing blocks may both be at height 900,000. Their hashes distinguish them.
In context
An inclusion proof supplies the hashes along one branch, allowing a verifier to reconstruct the root without downloading every transaction. For four leaves A, B, C and D, proving A requires its sibling B and the combined hash of C and D. This reduces the amount of data needed for the inclusion check.
The related mechanism, visually
- 01A, B, C, D
- 02Four leaf hashes
- 03AB and CD
- 04Root R
Read these as connected concepts, not necessarily consecutive steps.
Read the explanation
A block groups transactions with metadata. Its header commits to information such as the previous block and a summary of included transactions. In a binary Merkle tree, leaf hashes are combined in pairs until one root remains. Changing a leaf changes the hashes on its path to the root. A proof supplies the sibling hashes needed to rebuild that path.
Put the mechanism into context
Label four transactions A, B, C and D. Compute AB = H(H(A)||H(B)) and CD = H(H(C)||H(D)), then R = H(AB||CD). To prove B, supply H(A) and CD, together with their left/right positions. You do not need to supply C and D separately.
Apply it in the workshop →What this mechanism does not guarantee
An inclusion proof only has meaning relative to a root you trust or verify. It does not by itself establish that the block is canonical, that every transaction is valid, or that the data remains available. Different chains use different tree structures and encodings. The four-leaf example below illustrates the principle rather than specifying every Bitcoin or Ethereum detail.
Explore the full explanation
Block anatomy and Merkle trees
A block contains transactions and metadata.