A light wallet can confirm that a transaction is in a block without downloading the block. The structure that makes this possible is a hash tree, and it is one of the few genuinely elegant pieces of the design.
Hashing pairs upward produces one summary
Start with a list of items and hash each one. Then hash the results in pairs, and hash those results in pairs, continuing until a single value remains.
That final value is the root, and it depends on every item in the list. Changing any item changes its hash, which changes its parent, and the alteration propagates all the way up.
The root is therefore a compact commitment to the entire set, small enough to place in a block header regardless of how many transactions the block contains.
A proof is the path, not the data
To show that a particular item is in the set, you supply the item and the sibling hash at each level between it and the root.
The verifier hashes upward using those siblings and compares the result with the root they already trust. A match proves membership.
The number of hashes needed grows with the depth of the tree, so doubling the number of items adds only one step. Sets of any practical size need a proof of a few dozen values.
Light clients rely on this directly
A wallet that tracks only block headers holds the roots without holding the contents, which is a tiny fraction of the full data.
When it needs to confirm a payment, it requests the transaction and its path from a node and checks the result against the header it already has.
The node cannot fabricate a proof, because doing so would require finding data that hashes to the committed root. The wallet gets a real guarantee while trusting the node only to supply data, not to tell the truth about it.
Trees appear throughout the stack
Blocks commit to their transactions this way, and account-based chains use a related structure to commit to the whole state so a balance can be proved without the state database.
Token distributions use the same idea, publishing a root and letting each recipient supply a proof when claiming, which keeps the on-chain cost independent of the list length.
Rollups, bridges and light-client protocols all lean on it for the same reason: a commitment small enough to store cheaply, with proofs small enough to verify on chain.
What the proof does not tell you
Membership proofs establish that an item is in a committed set. They say nothing about whether that set was the correct one.
A light client still has to obtain honest headers, which is why header verification and chain selection remain the harder part of the problem.
Proving absence is also awkward, since showing something is missing requires an ordered structure and a proof about neighbouring entries rather than a simple path upward.