Hi,

Once a card is pinned to the town noticeboard, nobody can quietly reprint a different bracket and say it was always there. The town has already read it. That is most of what a ledger is for.

On top of that one idea sits a small, old trick that lets a mark about as long as a short sentence argue for a field of a thousand names, and for a computer, a run of eighty thousand steps of AI training. It costs about ten extra marks per argument.

It also has a blind spot, and the blind spot is not a bug. A card like that will tell you a name was in the field. It will never tell you the field was the whole field.

Leave one name out before the wall goes up and every name that remains can still be proved.

If a proof can only ever say "in", what do you have to pin beside it to say "all"?

Listen:

Apple Podcasts: https://podcasts.apple.com/kg/podcast/plain-strata/id6783455764?i=1000799455064

YouTube: https://youtu.be/VN6EiqYWTNI?si=7Xnb5Yd3pzQcy0_o

---

The full piece, no need to click through:

A sports hall in a small town has a bracket pinned along one wall, a thousand names in a row across the bottom. Above every pair of names someone has written a short mark, worked out from both names beneath it, so that changing a single letter in either name would change the mark. Above those marks sits a row of marks worked out from the marks. Ten rows up, the wall narrows to one slot, the champion's. The organizer copies that single mark onto a card, pins the card to the town noticeboard, and goes home.

A week later a man says player 438 never entered. The organizer could reprint the whole bracket and let him check every pair. Or the organizer can hand over the name of player 438 and ten other things: the opponent that player met in each round on the way up. The man works the marks upward, round by round, and finishes with a mark that either matches the noticeboard or does not. Eleven things were examined, and a field of a thousand has been settled.

A computer settles an argument about one step of a long piece of work the same way. A tree of hashes proves that one step was among a thousand with ten hashes, and it can never prove that nothing was left out.

Why does the organizer need a noticeboard at all, when the bracket could simply be kept in a drawer?

The noticeboard is what makes the card hard to argue with. The organizer cannot quietly reprint a different bracket a week later, because the town has already read the card.

For machines the noticeboard is a ledger: a shared spreadsheet nobody is allowed to lie to, kept in full by every computer that joins. It charges for every byte and refuses any transaction past a fixed size. What goes on it must be small, and once it is there nobody can edit it.

The work being argued about is long: an AI agent takes forty steps, a training run eighty thousand. Whoever did it wants to leave a promise on the ledger about exactly what happened, so a stranger can check one piece later.

The promise is a hash, the same thing as the marks on the wall. Hash comes from the French hacher, to chop, the same root as the dish of chopped leftovers. Any block of bytes goes in, and a short scramble of a fixed length comes out, thirty-two bytes whatever the input, and one changed bit in the input changes the entire scramble. A hash published in advance is a commitment, from the Latin committere, to entrust: later you can show the exact thing you had, and you cannot quietly swap it for another.

There are two obvious ways to make that promise about a thousand steps.

The first is to hash every step and publish all thousand hashes: thirty-two kilobytes. Any single step can be checked at once, because its hash is already on the ledger. But a run of eighty thousand steps needs about two and a half megabytes, more than a chain will take in one transaction. The quarrel is cheap and the promise is impossible.

The second is to glue all the steps together and publish one hash of the whole. That is thirty-two bytes, and it fits anywhere. But to check step 17, somebody has to produce every step, so that the hash can be worked out again from scratch. The promise is cheap and the quarrel is impossible.

One way makes the promise enormous and the other makes the quarrel enormous. Is there a size in between?

Yes, and it costs the same thirty-two bytes as the second way. It gives nearly the provability of the first, at a price of about ten extra hashes per quarrel. It is one hash applied in one arrangement, and the arrangement is the entire idea.

Building it takes three moves.

First, every step is written down in one exact form and hashed on its own. That hash is a leaf. The exact form matters, because a hash is taken over bytes and never over meaning: two honest parties who print the same step slightly differently get different hashes for it, and that looks exactly like a lie.

Second, the leaves are paired. Two hashes are glued end to end and hashed again, then the results are paired and hashed, and so on until one hash is left. That last one is the root.

Third, the root goes on the ledger, where the person who did the work cannot reach it, and the leaves are kept.

On paper the wall is drawn upside down: the root at the top and the leaves at the bottom. The data are the leaves and the summary is the root, and people write summaries above details.

The structure carries a man's name. Ralph Merkle described it in his Stanford dissertation of 1979, to let one public key vouch for a large batch of one-time signatures. It was invented to solve a problem about keys, not about auditing, which is why the name says nothing about what it does. The plain name is a hash tree.

To prove that step 438 belongs, the prover hands over the step, its number, and one other hash for every round on the way up: the hash that was glued to yours before the pair was hashed. That partner is called your sibling, from the Old English for kin, the one other node with the same parent. The siblings along the path from your leaf to the root are the entire proof. The number matters too, because at every round it tells the checker whether their running hash goes to the left or the right of the sibling. Order is enforced by the arithmetic.

The cost is the number of rounds. A thousand steps need ten siblings, three hundred and twenty bytes. A million steps need twenty, six hundred and forty bytes. Every doubling of the work adds one hash. The word for growth like that is logarithm, from the Greek logos, a ratio or a reckoning, and arithmos, a number. A contract on a chain can afford a few hundred bytes and a handful of hash operations, even though it could never hold the run itself.

And what does the man at the noticeboard learn? That player 438 was in the field. Nothing about the other nine hundred and ninety-nine, or about whether the field held a thousand players or a thousand and one.

What if he is never shown a player at all, but handed a mark from the middle of the wall and told it belongs to one?

Take four players, A, B, C and D, with hashes a, b, c and d. Call the hash of a and b together p, and the hash of c and d together q. The top of the wall is the hash of p and q together, which is r, the mark on the card.

A cheat arrives at the noticeboard and claims the field had only two players. His first player is a sixty-four-byte scrap: the hashes a and b glued end to end. His one opponent is q. The man hashes the scrap and gets p. He hashes p with q and gets r. And r is on the card. A different field, a different bracket, the same mark at the top, and nobody told the man how tall the wall was.

The hash function did nothing wrong. It was asked to do two jobs, to say "this is a player" and to say "this is two marks glued together", and from inside a hash function the two cannot be told apart. It is the same fault as gluing words end to end. The strings "ab" and "c" make exactly the string that "a" and "bc" make, and the result cannot say where one ended and the next began.

The repair is to put the job into the bytes. In the certificate logs defined by a standard called RFC 6962, a player is hashed with a zero byte in front, and a pair of marks is hashed with a one byte in front. Prefix is from the Latin prae and fixus, fastened in front. Now the two jobs are different inputs to the hash, and no inner mark can pass for a player. The word for it is domain separation. A domain is from the Latin dominium, what a lord owns, and the idea is the same: every use of one hash gets its own estate, and no other use can claim it.

A second guard is to publish the number of players beside the root, so the man knows how many rounds to expect. Careful designs use at least two guards.

The consequence is that the mark at the top now commits to who played and to how the field was drawn, and no part of the wall can be shown as another part.

Bitcoin met the same weakness from the other side. When a row has an odd number of hashes, it copied the last one and paired it with itself. In 2012 it was found, and recorded as CVE-2012-2459, that for some block sizes two different lists of transactions gave the identical top mark, because a list that already ends in a repeated pair looks exactly like a shorter list that was padded. No hash was broken. The map from lists to walls was ambiguous. A wall that can be drawn two ways commits to less than it seems to.

So with the wall drawn without ambiguity, what exactly has been promised?

A root is a claim about a set that nobody else will ever see. Someone holding thirty-two bytes is shown one step and ten hashes, and becomes certain that the step belongs to a structure whose contents they cannot list. Membership without comprehension, repeatable for any number of steps without ever adding up to a view of the whole. Five things stay unsaid.

The card does not say the step was right. A step can be in the box and still be a wrong step. The ledger is a notary and not a judge: it certifies what was committed and when, and takes no view on whether it was any good.

The card does not say nothing is missing. A prover who leaves out the step where everything went wrong produces a perfectly valid root over the steps that remain, and every one of them can be shown with a valid proof. Closing this takes something more: a count published beside the root, a tree kept in sorted order so that an absence has a provable place, or a rule that step numbers run without gaps.

The card does not say what order things happened in, unless the number is bound into the proof. In a wall where the path is the number, it is. In a tree built over a loose set, it is not.

The card does not say anything is secret. A leaf is only the hash of its step. If steps are drawn from a small vocabulary, a tool name or an amount in a narrow range, a guesser can hash each candidate until one matches the leaf. Keeping a step secret has to be bought separately, with a random number stored beside each step and hashed in with it.

Nor does the card say it is current. Whether a root is the latest root is a question only something outside the structure can answer.

The structure is excellent at in and silent about all. Most arguments in this field that go wrong go wrong right there: a published root, a wall of valid proofs, and a quantity nobody committed to.

Where does the card have to be pinned for any of this to count, and who has to keep the steps?

The strongest objection to the tree is that it makes the promise cheap for the chain by moving the cost onto whoever keeps the leaves. A root with nobody holding the leaves is a number nobody can argue about, and if the keeper vanishes or declines, the envelope stays sealed for good. And where nothing has to be settled on a chain, the tree buys little: a flat list of eighty thousand hashes is two and a half megabytes and fits on any website. The tree is a decision about where the cost lands, and it only pays when a ledger has to host the argument.

Next comes the question of who may write on the board. A record the worker holds a handle to is part of the thing being checked, not a witness to it. That is why the root goes on a ledger and not into the worker's own log file.

A ledger does not settle that by itself. On Bittensor, the network that pays strangers for AI work, each judge publishes a row of scores sealed first and revealed later, a commitment over a list. The software release of 7 October 2026 is written in exactly those verbs: set, commit, reveal. Under the single-judge mode it introduced, one identifier alone may do any of the three. A commitment says nothing about who was allowed to make it.

And timing matters as much as place. On 14 October 2026 an open dataset matched all 514,096 feedback entries in the agent reputation registry on Base against payments. Only 728, about one in seven hundred, could be tied to a payment from the rater to the agent, and 725 of those were plain transfers, which show that two addresses dealt with each other and not what the review was about. A judgment written without a commitment to the thing judged cannot have one added afterwards. The card has to be pinned when the claim is made.

Is this a trick of blockchains, or is it older than they are?

Git, the tool most programmers save their work in, stores a commit as the hash of a tree of hashes of folders and files, so it can tell that a folder is unchanged without opening a single file in it. A file system called ZFS hashes every block on the disk into a tree, so decay is noticed when a block is read and not years later.

Ethereum keeps its world state, every account and its balance, in a tree of hashes, and the thirty-two-byte root is what ten thousand machines compare instead of the state itself. That is the same wall read in the other direction: agreement instead of proof. Its tree has sixteen branches at each node, which makes five rows over a million items instead of twenty, but each row of a proof then carries fifteen siblings, so the proof grows to about twenty-four hundred bytes against six hundred and forty. Height has been traded for width.

The certificate logs are the closest cousin. Public, append-only logs of the certificates issued for websites, standardized in RFC 6962 in 2013, are the document that fixed the zero byte and the one byte. Besides proof that an entry is in the log, they offer a second kind of proof: that the log as it stands today begins with the log exactly as it stood yesterday. A short proof, and an operator cannot quietly rewrite history without breaking it.

Commit to the root, argue along the path. In every one of these, a claim about a large collection is made local, and the cost of settling it drops from the size of the collection to the height of the structure. It is the halving of a tournament, and of binary search. The logarithm is the receipt.

What would it look like with one real run on it?

On 15 September 2026 Gensyn, a company working on training AI across machines nobody owns together, published a small language model called open-1b: about 1.61 billion numbers, trained over 80,957 steps, with a hash published for every step covering the batch of data, the model's numbers and the working numbers of the update. Checking is mechanical. An auditor loads the saved model from before a step, replays that one step, hashes the result and compares. Independent auditors each certify single steps, and the ledger carries names, not payments.

What Gensyn published is a list, the first of the two obvious ways, and a list is the right choice there, because nothing is settled on a chain. The tree is what the list becomes on the day a ledger has to host the argument.

Suppose that day has come, and an auditor says step 41,200 does not replay. The wall for 80,957 steps is seventeen rows tall, because two to the seventeenth is 131,072 and two to the sixteenth is only 65,536. The auditor hands over the record of step 41,200, its number, and seventeen siblings: five hundred and forty-four bytes. The contract hashes the record with a zero byte in front, folds in each sibling with a one byte in front, seventeen times, and compares the result with the root pinned when the run was published. If it matches, the argument is finally about training and not about which bytes are under discussion.

Everything the card cannot say is still unsaid. The root does not say whether the replay will match. The number of steps has to sit beside the root, or a run with steps missing would still give a perfectly valid root. The root has to have been pinned on a ledger the trainer cannot write on, at the time the run was published, and not assembled afterwards. Somebody has to keep the saved models, since replaying a step needs the state before it. And an auditor may truthfully answer that it could not replay the step at all, which is a sentence about the auditor's own machine and not about the trainer's work. No root has a slot for that sentence.

Eleven things settled a field of a thousand in the hall. Eighteen settle a run of eighty thousand steps in a contract. Neither says a word about whether anything was left out.

Can the completeness gap be closed cheaply for a run whose final length nobody knows? A count has to be published beside the root, and publishing a count means knowing when the run ends.

And where does a root have to be written for a commitment to survive a worker that holds the keys to its own machines? That one is about reach and not about mathematics, and no arrangement of hashes answers it.

---

The two voices are AI. The research and writing are mine.

Decentralized AI, layer by layer.

Dastan,