In a Certificate Transparency log, what does an inclusion proof establish that a consistency proof does not?

## Two proofs, two questions A Certificate Transparency log is a Merkle tree over its entries, and it periodically publishes a **Signed Tree Head** (STH): a signed statement of the tree's size and its **Merkle Tree Hash** — the root of that hash tree. Beware the noun: this root is the top of a hash tree and is unrelated to a root certificate held as a trust anchor. Everything provable about the log is proved against an STH, and the two proof types answer strictly different questions: - **Inclusion proof (audit path).** *Is this one entry in the tree this STH commits to?* Fetched with `get-proof-by-hash` given the leaf hash and a tree size. - **Consistency proof.** *Is the tree this older STH commits to a prefix of the tree this newer STH commits to?* Fetched between two tree sizes. Neither implies the other. You can hold a perfectly valid inclusion proof against an STH from a log that quietly dropped a thousand other entries last week; you can hold a perfectly valid consistency proof from a log that never merged the entry it promised you. ## How an inclusion proof works 1. Fetch an STH with `get-sth` and keep its tree size and Merkle Tree Hash. 2. Compute the `MerkleTreeLeaf` hash for the entry, from the same bytes the log was given. 3. Ask `get-proof-by-hash` for the audit path for that leaf hash at that tree size. 4. Hash upward — leaf with sibling, result with the next sibling, and so on — and compare the final value to the Merkle Tree Hash in the STH. A match means the entry is genuinely in that tree. The proof is small: its length grows with the logarithm of the tree size, which is why this stays cheap for a log holding billions of entries. ## How a consistency proof works Given an older STH at size *m* and a newer one at size *n*, the log supplies the interior node hashes that let you recompute both roots from one shared set of values. If both recomputations match their respective STHs, the first *m* entries are unchanged and the difference is purely appended. This is the proof that makes **append-only** a checkable property rather than a promise. Without it, a log could serve one history to one observer and a rewritten history to another, and no single inclusion proof would reveal it. | | inclusion proof | consistency proof | |---|---|---| | subject | one entry | two views of the whole log | | answers | is this entry in that tree? | was anything altered or removed? | | fetched with | `get-proof-by-hash` | a proof between two tree sizes | | detects | a promise the log never merged | a log that rewrote its history | | mentions a certificate | yes, by leaf hash | no | ## Who actually checks these The **auditor** does. The specification splits the watching roles: a **monitor** reads entries and cares about their content — a certificate for a name someone owns — while an **auditor** cares about the log's own behaviour and checks tree heads and proofs. The two are different jobs and are often run by different parties. Ordinary connecting clients do neither on the connection path. Fetching a proof would add a round trip to a third party and would tell the log operator which site a user is visiting, so the check that happens during a handshake is an offline signature verification on the timestamps and nothing more. That leaves a real gap, and the honest statement of the model is: the logs are accountable **because** someone independent audits them, not because every client checks. One more thing an auditor has to watch for, and the reason consistency proofs exist at all: an STH is only meaningful if everyone is being shown the same one. A log that shows one tree head to one observer and a different, incompatible one to another has **split its view**, and this is invisible to anybody who only ever talks to it alone. Detecting it requires comparing tree heads observed by different parties — which is why proposals in this area focus on circulating tree heads between observers rather than on making individual clients do more work. ## Why the portal team cares Mostly you do not check these yourself; you rely on the log ecosystem being audited. But the distinction matters the moment you are reasoning about evidence. If you hold a signed certificate timestamp for a certificate issued for one of your names and you want to prove, in a write-up, that the issuance is publicly recorded, the artefact you need is an **inclusion proof against a current tree head** — the timestamp alone is a promise, and a consistency proof says nothing about your certificate at all.