Did you know?
Did you know? A cryptographic proof showing that one record belongs to a blockchain data set cannot, by itself, prove that a different record is missing. Inclusion and non-inclusion ask opposite questions, and they need different evidence.
Imagine Alicia is organising a fictional school science exhibition. The club publishes a commitment to its registration list. Kai Kai shows a valid Merkle proof that Alicia’s entry is included. Tricia asks whether the club has an entry for a student named Noor. Kai Kai waves Alicia’s inclusion proof again. It still proves Alicia’s entry, but it says nothing about Noor. A trustworthy-looking hash path cannot answer a question it was not designed to answer.
Quick answer: an inclusion proof links a specified item or key-value entry to a committed root. To establish that a different key is absent, a verifier needs an authenticated non-membership method suited to the data structure and a trusted root for the relevant state. Ethereum’s Merkle-Patricia tries can support absence proofs through authenticated paths, but an ordinary unrelated inclusion proof cannot do that job.
Chapter navigation
- 1. State the claim before selecting the proof
- 2. How a basic Merkle inclusion proof works
- 3. Why Alicia’s presence says nothing about Noor’s absence
- 4. Some structures can support non-membership with ordering
- 5. Ethereum uses Merkle-Patricia tries for state
- 6. What a trie absence proof looks for
- 7. A root supplied by an attacker is not enough
- 8. Absence at block 100 is not absence forever
- 9. An absent storage slot is not every kind of application-level absence
- 10. No matching event in an explorer search is not a proof of absence
- 11. Inclusion of assets does not prove that liabilities are missing
- 12. Fictional science-club registry: which evidence answers which question?
- 13. Why proving a negative needs a defined universe
- 14. What changing the tree does to proofs
- 15. What an inclusion proof is good for
- 16. Three-learner proof exercise: do not guess the hidden leaves
- 17. A short verification checklist
- 18. The evidence standard: answer precisely, not confidently
- Reader questions
- Primary references
1. State the claim before selecting the proof
An inclusion claim says that a particular value is part of a committed collection at a specified version. A non-inclusion claim says that a particular key has no entry in a defined committed structure at that same version. Neither is the same as proving that the data source was truthful or that the collection includes every real-world item it should have included.
A reader should ask what exact object is being proved, which root is being used, who authenticated that root, and whether the data structure has a documented rule for looking up or excluding the relevant key. Cryptographic correctness starts with a precise question.
2. How a basic Merkle inclusion proof works
A Merkle tree combines hashes of records into a compact root commitment. A proof for one leaf supplies the relevant neighbouring hashes needed to reconstruct its path to the published root. If the reconstructed root matches the trusted commitment, the leaf is included according to the tree’s stated construction.
The proof need not list all other leaves. This is a major efficiency advantage when verifying one record among many. It is also the limitation: the omitted parts of the tree remain undisclosed by that one path. The proof does not enumerate every student, every transaction or every asset in the collection.
3. Why Alicia’s presence says nothing about Noor’s absence
Suppose the exhibition list contains Alicia, Kai Kai and possibly Noor. A valid inclusion proof for Alicia only shows that a leaf representing her entry exists at its prescribed position or key. It does not show the other leaves or the entire set. Noor could be present elsewhere in the structure without changing the validity of Alicia’s proof.
If Tricia asks whether Noor is missing, the class needs a proof designed to answer that question. Reusing the first proof is a mismatch between evidence and claim. The trick in the worksheet is not a difficult hash calculation; it is recognizing the logical gap.
4. Some structures can support non-membership with ordering
An authenticated sorted set may support a non-membership argument by proving appropriate neighbouring elements and that no element can lie between them, under its verified ordering and completeness rules. A sparse tree or authenticated dictionary can support a direct absence path for a requested key. The exact method depends on how keys, positions and commitments are defined.
A random pair of neighbouring-looking screenshots is not a cryptographic non-membership proof. The verifier needs an authenticated structural rule that excludes the queried key, not just the absence of a name in two photos. A proof designed for one data structure is not automatically transferable to another.
5. Ethereum uses Merkle-Patricia tries for state
Ethereum’s execution state commits accounts through a modified Merkle-Patricia trie. Each account can in turn commit its contract storage through another trie. Paths in these structures are derived from specified keys, and nodes use branch, extension and leaf forms. This lets a verifier follow an authenticated route toward the requested account or storage key.
The resulting root belongs to a specific blockchain state. An ordinary successful membership path ties a requested key-value record to that root. Absence needs a path whose structure proves that the requested key does not exist there. Understanding the difference is essential when using light clients or checking storage outside a full node.
6. What a trie absence proof looks for
EIP-1186 describes how an eth_getProof response should provide enough nodes when an account or storage value does not exist. The verification path follows the requested key until it reaches a branch with a missing child or value, or a leaf whose remaining path differs from the queried key. Those authenticated nodes can establish that this exact key is absent from the committed trie.
That is different from merely failing to find a result on a website. An explorer’s empty search response could mean the index is delayed, the filters are wrong or the service is broken. A checked trie path against an authenticated root can provide stronger evidence about the specified key and state.
7. A root supplied by an attacker is not enough
Suppose a malicious server invents a tree that conveniently omits Noor, then supplies a non-membership proof against its invented root. The proof could be mathematically consistent with that root. But unless the root is authenticated as the correct commitment for the intended blockchain and relevant block, the server has not established the claim users wanted to know.
This is why a proof is never just a list of hashes. The verifier needs the intended chain, a trustworthy block header or another legitimate commitment source, the key-encoding rules and correct proof verification. Without the root’s provenance, an elegant-looking proof may be answering the wrong question.
8. Absence at block 100 is not absence forever
A non-membership proof is usually version-specific. Noor might be absent from the exhibition registry at block 100 but registered by block 105. Both statements can be true: absence in the earlier state and presence in the later state. To claim that a key has never been present requires a much broader historical analysis than a snapshot proof.
Readers should state the block or committed version whenever they make a negative claim. The same caution applies to permissions, account balances and certificate-revocation records. An answer without a time reference may be misleading even if the cryptographic evidence was valid when collected.
9. An absent storage slot is not every kind of application-level absence
Ethereum contract storage has precise EVM rules for default zero values and data encoding. A proof that a particular raw storage position lacks a separately stored value or resolves to zero does not, by itself, show that a human account is unregistered in an application’s business logic. The contract may compute its status from other keys, events or external inputs.
Verifying the state of a Solidity mapping, dynamic array or proxy contract requires knowing the correct storage layout and key derivation. A storage proof for an unrelated slot does not answer the question. As with an inclusion proof, the cryptography authenticates a narrow encoded fact, not a guessed interpretation.
10. No matching event in an explorer search is not a proof of absence
An activity feed may show no transfer with a particular label. That empty list might arise because the search filters are too narrow, the indexer is behind or the event was emitted by a different contract. Ethereum transaction receipts are committed in a receipts trie, but a proof about one receipt is not a proof that no other transaction in a block emitted a relevant log.
To make a complete claim about all events in a defined set of blocks, an analyst must establish the scope and completeness of the records searched. This may require inspecting each relevant authenticated receipt or using another documented authenticated index. Merely clicking “no results” is not enough.
11. Inclusion of assets does not prove that liabilities are missing
Proof-of-reserves systems can demonstrate that particular assets or account balances were included in a committed data set, depending on how the proof is designed. But inclusion of selected assets does not establish that no debts, omitted accounts or other obligations exist. The completeness of liabilities is a separate and difficult accounting and verification problem.
A stronger public statement must explain who collected the records, how the data set was defined, how omitted items would be detected and what independent audit or attestation covers. A Merkle root can securely commit the information it was given; it cannot force an operator to provide every real-world liability in the first place.
12. Fictional science-club registry: which evidence answers which question?
The table below is an original teaching exercise with imaginary registrations. It contrasts a commitment at block 100 with an updated commitment at block 105. Alicia has a membership proof for block 100, Noor joins only by block 105, and a query for a different absent student uses the authenticated trie path rather than simply checking a search screen.
Ask the pupil to distinguish the membership claim from the non-membership claim and to name the block for each. Then ask whether the school registry itself accurately reflects every student who attended. Even the best cryptographic proof cannot establish completeness of an off-chain registration process without additional evidence.
| Fictional evidence | Committed version | Claim supported | Claim not supported |
|---|---|---|---|
| Alicia’s membership path | Block 100 | Alicia’s entry is included in that committed set | Noor is missing from the set |
| Noor’s verified absence path | Block 100 | Noor’s specific key is absent at block 100 | Noor never registered later |
| Noor’s later inclusion path | Block 105 | Noor’s entry is included in the later set | Every real student attended |
| Explorer search returns no results | Unknown | Interface found no matching display record | Authenticated non-membership |
| A Merkle proof to an invented root | Untrusted root | Internally matches its supplied root | Correct canonical chain state |
13. Why proving a negative needs a defined universe
The statement “Noor does not appear in this committed key-value map at block 100” has a defined object, time and lookup rule. The statement “Noor has never attended any science event anywhere” has none of those boundaries in the cryptographic data structure. The second conclusion does not follow from the first.
A strong learner should replace vague negative claims with precise ones: which key, which set, which root and which observation time? This habit applies well beyond blockchain to archives, school attendance, research databases and legal evidence. Showing that a record was not found in one system is not proving that it never existed.
14. What changing the tree does to proofs
A properly constructed cryptographic Merkle commitment changes when the committed data change. A valid proof from an older root cannot usually be presented as a matching proof for a newer root after entries have been inserted, deleted or modified. That sensitivity makes the root useful as a compact integrity commitment.
But the fact that the root changed does not tell readers why, who authorised the change or whether the underlying real-world data were accurate. Historical state proofs need to be tied to their own roots rather than silently relabelled as current. Verification should preserve the provenance of both the proof and its intended version.
15. What an inclusion proof is good for
An inclusion proof is excellent for questions such as “Is this signed transaction part of the committed list?” or “Does this storage path lead to the stated value under this state root?” It can reduce the amount of data a verifier must download. That practical advantage is why hash commitments and Merkle proofs are widely used in blockchain infrastructure.
The sensible lesson is not that inclusion proofs are weak. It is that they are specialized. A microscope can show a cell in one field of view without proving the absence of a cell anywhere else in the laboratory. Good evidence is powerful when asked the question it was built to answer.
16. Three-learner proof exercise: do not guess the hidden leaves
Alicia receives an authenticated inclusion proof for her club entry at block 100. Kai Kai receives a complete, correctly verified absence path for Noor’s registry key against the same block-100 root. Tricia receives a later root and an inclusion proof for Noor at block 105. All three pieces of evidence may be valid because their claims and state versions differ.
Then change the problem: the block-100 absence proof is attached to an unauthenticated root from an unknown website. Does Kai Kai still have an independently verified conclusion? No. The proof’s internal consistency is not enough without trusted commitment provenance. The learners must write a two-sentence answer naming the key and the root they used.
17. A short verification checklist
Identify the exact inclusion or absence claim. Name the relevant chain and committed data structure. Record the account, storage key or leaf position. Obtain a verified root from the appropriate header or authenticated record. Use a proof method that actually supports the requested claim. Check the result against the documented key encoding, then state the block and limits of the conclusion.
Finally, separate technical membership from external truth. A committed attendance record may faithfully include an incorrect name; a truthful on-chain event may describe a request that was never completed off-chain. The scope of a cryptographic proof is the integrity of specified encoded information under a trusted commitment.
18. The evidence standard: answer precisely, not confidently
An inclusion proof can verify that something is there. Non-inclusion needs its own structure and proof, and even a valid absence proof is anchored to a particular committed state. A plain search result, a screenshot and an unrelated valid Merkle path are weaker evidence for a specific missing-record claim.
Ask what is shown, what is not shown, which version is committed and what independent checks tie the proof to that commitment. This step-by-step approach turns a complicated cryptographic topic into a habit of disciplined reasoning: never stretch one narrow fact into a conclusion the evidence cannot support.
Reader FAQs
Can a Merkle inclusion proof show that another record is absent?
No. It proves its own specified membership claim. Absence requires a suitable non-membership argument against the relevant trusted commitment.
Does Ethereum support proofs of non-existent account or storage keys?
Its Merkle-Patricia trie structure can support absence paths. EIP-1186 documents how account and storage proof responses should handle missing keys.
Why is an empty explorer search not enough?
The search could be incomplete, filtered incorrectly, stale or on the wrong chain. It is not automatically a cryptographic absence proof.
Can a record be absent in one block and present later?
Yes. Commitments are state- or version-specific. A valid absence claim at one block does not prove absence forever.
Does a Merkle proof establish that real-world registration data are true?
No. It authenticates specified data against a commitment; the accuracy and completeness of the original records require separate evidence.
Can a storage proof establish that a contract’s business account is unregistered?
Only with the correct contract semantics, storage layout and relevant authenticated state. A raw slot’s absence or zero value may not directly answer the business question.
Primary sources and further reading
- Ethereum: Merkle-Patricia Trie and Authenticated State
- EIP-1186: Account and Storage Proofs Including Missing Keys
- Why a Merkle proof cannot establish the original claim is true
- Proof of reserves is not proof of solvency
- Why a light client needs a trusted starting point
- Why an RPC answer needs independent verification
- Why historical event logs differ from current state
- How Blockchain Works: beginner’s reading route
Evidence note: All school registrations and named participants are fictional illustrations, not public student records or actual on-chain proofs. EIP-1186 describes an interface for account/storage proofs and is marked stagnant as a proposal; implementation support varies. The relevant chain, block, root, data structure and proof method must be verified before relying on any live absence claim.