01
From one sealed entry to a whole log
You should be able to: Explain what a per-entry seal cannot prove and why a log needs its own commitment.
A sealed entry proves its own contents have not changed. It says nothing about the entries around it: whether one was removed, whether the order was altered, whether the whole history was re-derived from scratch last night. Trusting a record therefore takes two different guarantees — one per entry, and one over the set.
The set-level guarantee is the harder one, because the failure it guards against is invisible. A log that silently drops a row still validates every remaining row. A log re-cut from a new base still hands you entries that each hash correctly. Nothing at the entry level catches either.
So the estate commits to the whole log with a single value that changes if anything in the set changes, and can only move in one direction — append. That value is the checkpoint, and the rest of this course is what it is and how it is checked.
Source: FlashyOS — @flashyos/checkpoint (checkpoint/1)
02
The Merkle tree head (RFC 6962)
You should be able to: Describe what a tree head commits to and why the RFC 6962 idiom is the one used.
A checkpoint is a Merkle tree head: the single root hash of a binary tree whose leaves are the sealed entries. Change any leaf, add one, or reorder them, and the root changes. Publishing the root is therefore a compact promise about every entry at once — a few dozen bytes that stand for the whole log.
The estate uses the RFC 6962 shape — the same structure Certificate Transparency uses to keep the world's TLS certificate logs honest — rather than inventing one. That is the estate's standing rule: adopt the published standard so a stranger can verify with tools they already trust, instead of a bespoke scheme they have to take on faith.
The tree head is the anchor. Everything a reader checks — that an entry is present, that the log only grew — is a proof against this root, which is why it is the one value a property publishes and pins.
Source: FlashyOS — checkpoint/1, an RFC 6962 tree head
03
Inclusion and consistency proofs
You should be able to: Distinguish the two proofs a checkpoint supports and what each one settles.
An inclusion proof answers "is this entry in the log?" — a short path of sibling hashes from the leaf up to the published root. A reader recomputes the root from the leaf and the path; if it matches the checkpoint, the entry is provably in that log, and no server had to be trusted to say so.
A consistency proof answers the harder question: "did the log only grow?" Given an older tree head and a newer one, the proof shows the old log is a strict prefix of the new — every entry that was there still is, in the same place, and the only difference is appended entries. This is the proof that catches a silent rewrite, because a re-cut log cannot produce one.
Together they are why a transparency log is trustworthy without trusting its operator: inclusion proves presence, consistency proves append-only, and both are checked by arithmetic over hashes rather than by anyone's word.
Source: Flashy Network — the checkpoint over the record
04
The notary: many properties, one log
You should be able to: Explain how per-property fragments fold into one estate-wide append-only log.
Each property serves its own sealed claims as a fragment. A notary fetches those fragments the way any stranger would and folds each new leaf into one estate-wide, append-only transparency log — so the estate has a single record of everything sealed across all its properties, built from live sources rather than a central database anyone edits.
The fold obeys the same append-only union rule the shiplog does: a leaf already in the log keeps its place; only genuinely new leaves are added. A source that cannot be read is reported as unread, never counted as empty — the estate's rule that silence and zero are different findings.
A leaf in this log is deliberately non-identifying where it must be: an identity service, for instance, records that a verification of some assurance level happened at a time, and nothing about who. The log proves activity and integrity without becoming a surveillance record — which is what lets it be public at all.
Source: Flashy Network — the notary and the transparency log
05
Verifying a checkpoint offline
You should be able to: Walk the check a stranger runs, and say why it needs no server and no trust.
The whole point is that verification is the reader's, not the publisher's. A stranger takes the published checkpoint, an entry they care about, and the inclusion proof, and recomputes the root themselves. If it matches, the entry is in the log. To check the log only grew, they take a checkpoint they saw last week and a consistency proof to today's, and confirm the old is a prefix of the new.
None of this contacts the publisher's server for a yes/no, and none of it trusts the publisher's claim. The proofs are self-contained; the arithmetic is open; the tools are the same ones the wider web uses for certificate transparency. A publisher that tried to rewrite history would be unable to produce a consistency proof, and the absence is the alarm.
That is the difference a transparency log makes. "Trust us, the record is complete" becomes "here is the proof the record is complete, check it yourself" — which is the only version of the claim worth making on a record whose entire value is that it can be trusted.
Source: Flashy Network — verify in your own browser
