Smart contracts, mechanically

A rule is filed in the register the same way an entry about a consignment is filed. It is hashed with everything else, it is linked to what came before it, and anybody holding a copy can see which version of it is there. When something happens that the rule cares about, every participant runs the rule against the register they hold. Because they hold the same register and run the same rule, they produce the same output, and there is nothing left to argue about.

That is the whole of it. The interesting property is not that code runs, which is unremarkable. It is that a rule nobody can quietly swap out produces a result nobody has to take on trust, because everybody computed it themselves.

• Deterministic. Same inputs, same output, every time, on every machine. The single requirement the whole design is built around.
• State. What the rule is allowed to read: the register, and nothing else.
• Oracle. Whatever puts outside information into the register so a rule can react to it. A person typing, or a sensor reporting. Session a5.
• Append only. A rule adds entries. It does not replace them, so a rule that behaved wrongly leaves its wrong output in place.
• Immutability. The property that makes an old entry trustworthy, and the same property that makes a mistake permanent.
• Code is the agreement. The position that what the rule does is what was agreed, with no appeal above it. Part 4, argued both ways.
• Upgradeability. Whatever arrangement lets a filed rule be replaced later. Every such arrangement gives somebody the power to change the rule, which is the thing filing it was meant to prevent.

Ordinary automation runs in one place and reports its answer. Everyone downstream believes the report, because checking would mean holding the same data and the same code, which they do not. The report is a trust relationship wearing the clothes of a computation.

Here the computation is repeated by everybody who cares. There is no report to believe. A participant who thinks the output is wrong recomputes it, and either they are wrong or the others are, and the disagreement is settled by arithmetic rather than by seniority.

A rule reads the register and nothing else. That is not a restriction somebody added for safety, it is the only thing every participant demonstrably holds in common. Anything outside it is something one machine has and another does not, and the moment a rule depends on such a thing the participants stop agreeing.

The practical consequence is that any fact the rule needs must already be an entry. Somebody has to have written it down first, which is where Part 3 starts.

A rule that needs to pick something at random cannot simply draw a number, because every participant would draw a different one and the register would fork into as many versions as there are participants. Anything used as randomness has to be a value they all already hold, which means it is not secret from anybody who holds the register, including whoever stands to gain from the outcome.

That is a genuinely hard problem, and it is hard for a reason that is now obvious rather than mysterious: shared and unpredictable are close to opposites when everybody has the same copy.

A rule cannot ask what time it is. Each participant's clock says something slightly different, and slightly different is enough. What a rule can use is a value recorded in the register, which is a claim somebody made about the time rather than the time itself.

So a deadline enforced by such a rule is enforced against a written claim, not against the world. That is a smaller thing than it sounds like when somebody says the deadline is enforced automatically, and it is the same shape as the limit in Part 3.

Take the property that makes an old entry trustworthy and apply it to a rule. Nobody can change the rule after the fact, which is exactly what you wanted when you imagined somebody tampering with it. It is exactly what you did not want the moment you notice the rule says intact where it should have said broken.

The mechanism draws no distinction between those two cases, because a distinction would require knowing what was intended, and that is precisely the thing it has no access to. Correctness has to be bought before filing, with review and testing, by the ordinary unglamorous means. There is no arrangement that keeps a rule beyond reach and also lets you fix it.

Session a5 established that whatever a register knows about the world, a person or a sensor put there, at unchanged trustworthiness. A rule that reacts automatically makes that limit sharper rather than softer. Before, a false entry sat in a register and somebody might notice before acting on it. Now the entry is the action: write the sentence and the consignment moves.

So automation raises the value of lying at the point of entry, and every defence against that is in the physical world. Two signatures instead of one, a photograph hashed alongside the entry, a second sensor that would have to fail in the same direction at the same moment. None of them is a chain technique.

Suppose a rule does something every party agrees was not what they meant. The register holds a valid output, produced correctly by a rule everybody ran. There is no error to report and nothing to verify differently. The question of what should happen now is a question the chain has no answer to, and never claimed to.

It goes where such questions went before: to whatever written agreement exists outside the register, to whoever has jurisdiction over the parties, and to what the parties are willing to do voluntarily. Any organisation relying on automatic rules should know which of those it would be reaching for, before it needs one.

The obvious compromise is to file the rule and keep a way to replace it if it turns out wrong. Notice what that does. Whoever holds the power to replace the rule now holds the power to decide outcomes, which is the position the arrangement was built to remove. Participants are back to trusting a party, and the rule is a strong default rather than a guarantee.

That is not an argument against it. Plenty of operations would rather have a strong default with a named owner than an unstoppable rule. It is an argument for saying which one you have bought, because the two are sold with the same vocabulary and they are not the same product.

Press the second button and the inspection line is changed after the fact. Verification reports a mismatch at that block immediately, which is the case the structure was built for and it handles it loudly.

Now consider the other case. The false line was filed at the time, by the person entitled to file it. Nothing to detect, nothing to report, and the rule runs on it. The register is in perfect health and the consignment is gone. Only one of these two is a chain problem, and it is the less likely one.