An On-Ramp to the Problem
If you are not a cryptographer, start here. This chapter builds — from nothing —
the single strange question the treatise answers, and hands you just enough about
blockchains, digital signatures, and the internet’s naming system to enjoy the
argument. If you already know what a Solana program, a DNS TXT record, and
DNSSEC are, skip ahead to the treatise.
A question that sounds like science fiction
We are building a world of software agents — programs that act on our behalf, increasingly without a human watching each step. Sooner or later, one such agent must convince another piece of software to take its word for something. And that raises a question that sounds like it belongs in an Asimov story but is, in fact, a concrete engineering problem today:
How can one program prove to another that it will behave a certain way — that it is the kind of agent that faithfully performs some task — when the second program can only understand cold mathematics?
To feel the force of this, we need to meet the coldest, most literal-minded verifier we have ever built: a blockchain program.
The one thing a blockchain program can do
A blockchain — Solana is the one in this story, but any would do — is, for our purposes, a shared public computer that no one owns and no one can quietly tamper with. You can put small programs on it. Once deployed, such a program runs exactly as written, the same way for everyone, and its memory (who owns what, who is allowed to do what) is public and permanent.
That sounds powerful, and it is. But such a program is also profoundly blind. It has no senses. It cannot browse the web, read your email, phone an API, or check the time except by the blockchain’s own clock. It sees only the data handed to it in a transaction, and it can do only deterministic arithmetic on that data.
There is essentially one interesting thing it can check about the outside world, and the entire edifice of blockchain “authority” is built on it:
Did this request carry a valid digital signature from a particular key?
Everything a blockchain program “believes,” it believes because a signature checked out. It never really knows who you are. It knows only that whoever holds a certain secret key agreed to this action.
What a signature actually proves
A digital signature is one of the loveliest ideas in computing. You hold a secret number, your private key. From it you can compute a matching public key, which you can publish to the world — it gives nothing away. Now, using your private key, you can stamp any message with a signature. Anyone with your public key can check the stamp and confirm two things at once:
- the message was signed by whoever holds the matching private key, and
- the message hasn’t been altered since.
Crucially, you prove all this without ever revealing the secret. Possession of the private key is demonstrated by its effects — a valid signature — not by showing the key itself. Hold on to that idea. The whole treatise turns on a question it inspires: could you prove you possess a behaviour the way you prove you possess a key — by its effects, without “showing” it?
Where the trouble starts: facts the program can’t see
Signatures are perfect for proving “the holder of key K agreed to this.” They are useless for proving “something is true out in the world.” And real applications are full of the second kind of claim.
Our running example — the one that started this whole inquiry — is domain
ownership. Suppose a blockchain program must only act for the true owner of, say,
example.com. The program cannot browse to example.com. It cannot look anything
up. The fact “this person controls example.com” lives entirely outside the
blockchain, in a part of the internet the program has no eyes on: the Domain Name
System.
DNS in ninety seconds
The Domain Name System (DNS) is the internet’s address book. When you type
example.com, DNS is what translates that human name into the numeric address of a
server. It is a vast, hierarchical directory, and — this matters — whoever
controls a domain controls what its DNS records say.
Among the kinds of records DNS can hold is a plain-text one called a TXT
record: an arbitrary note attached to a name. Because only the domain’s true
controller can set these, TXT records are the internet’s standard way to prove
you own a domain. The pattern is everywhere — Google, Apple, and countless
services ask you to “add this TXT record to your DNS to verify ownership.” You
place a specific value where only the owner could, and anyone who looks it up is
satisfied you’re in control.
So there is our bridge: to prove you own example.com, you publish a special TXT
record — in our system, at the name _solana.authority.example.com — containing
the public key you want to be recognised by. A human, or a server, can look that up
and confirm it. But the blockchain program cannot. It has no way to see DNS.
DNSSEC: when the address book learns to sign its answers
Ordinary DNS answers are unsigned — you simply trust the resolver that fetched them.
But DNS has a security extension, DNSSEC, that changes this profoundly: with
DNSSEC, DNS records come with cryptographic signatures, arranged in a chain.
The internet’s root zone signs the records that point to each top-level domain
(.com, .org); those in turn sign the records for individual domains; and so on
down to the TXT record itself. At the very top sits a single, world-famous public
key — the root Key-Signing Key, guarded by an elaborate public ceremony.
Read that again with the previous sections in mind. DNSSEC turns “who owns this domain” into a chain of digital signatures anchored to one well-known public key. And a blockchain program’s one talent is checking digital signatures against known public keys. A fact that seemed hopelessly outside the program’s world turns out to carry, in DNSSEC, exactly the kind of witness the program was built to verify. Much of the treatise is the slow unfolding of that coincidence — and it is not really a coincidence at all.
SithBit, and the key that has to stay awake
The concrete system behind this book is SithBit, an experimental decentralised email protocol. In it, wallet addresses act as email addresses, and the blockchain records which mail domains are authorised and who runs them. A special administrator key, the postmaster, is what signs off on authorising a new domain.
Here is the tension that set everything in motion. To let people onboard their
domains automatically, SithBit runs a small service that (a) checks the applicant’s
DNS TXT record to confirm ownership, and then (b) submits the blockchain
transaction to authorise them. But step (b) requires the postmaster’s signature —
and so that powerful administrator key must sit online, hot, on an
internet-facing server, ready to sign at any moment. That is precisely the key you
would most want kept offline in a vault. Automation and safety appear to be at war:
you can have a cold, safe key or hands-free onboarding, seemingly never both.
Why must the key be online at all? Because the blockchain cannot check the DNS itself. It cannot trust the deed of verification; it can only trust a key that vouches, after the fact, that the deed was done. The postmaster’s signature is standing in for a behaviour the program cannot witness. Remove that indirection — teach the program to check the deed — and the whole tension dissolves.
The leap
Which brings us back to the science-fiction question, now sharpened to a point:
Could a blockchain program be made to trust a behaviour — “this agent honestly checks DNS ownership” — directly, the way it trusts a key? And if so, what would the agent present to prove it has that behaviour, in a language whose only word is signature?
The human who posed this had a striking first idea: what if a behaviour could be written down as a canonical sequence of bytes, and an agent could prove it has that behaviour by showing that a hash of its own program matches the hash of those bytes — the private key made implicit in the agent’s own structure? The treatise takes that conjecture seriously, shows exactly where and why it breaks, and then rebuilds its true and workable form. Along the way it discovers a single organising principle — a “conserved quantity” of trust — and from that one law derives seven distinct, concrete techniques, ranked from the ones we could build tomorrow to the ones still at the frontier of cryptography.
How to read what follows
The treatise is deliberately styled after Isaac Newton’s Principia: it proceeds by Definitions, then four Laws of Trust, then three Books of numbered Propositions, each with a short proof or argument and a Scholium — a digression or commentary, several of which wander happily into science fiction and folklore, because the questions here are as old as the golem and as new as this morning’s code.
You need not read it in order. Each Book stands on its own; the Scholia can be skipped or savoured. But if you have followed this on-ramp, you already hold the one key idea the entire argument turns on:
A blindfolded judge who trusts only signatures can still come to trust a fact about the world — but only if that fact already carries a signature of its own.
Everything else is working out what that means. Turn the page.