The failure that looks exactly like success
The interesting failures in a register are not the ones verification catches. Verification catches somebody changing a line after the fact, loudly and at a known index. The ordinary failure is a line that was already wrong when it was written, and against that the structure has nothing to say. It preserves the wrong line faithfully, reports no problems, and hands the reader a clean result.
★ What you walk out with tonight. Three sentences you can say to anyone selling you a register. It does not make an entry true. It knows nothing about the world that a person or a sensor did not type into it. It does not decide who may write. Plus the practical consequence that catches people out later: a mistake is kept as carefully as a fact, so correcting one means adding to the register rather than repairing it.
LiveWhat the guarantee actually says4 min▶
Hold the promise still and read it slowly. Each block contains the previous block's hash, so anyone holding a copy can establish that these entries are byte for byte the entries that were written, in this order. Every word of that is about bytes. None of it is about the cold store, the container, the inspector or the clock.
The gap between "unaltered since written" and "accurate" is where nearly every disappointed expectation lives. It is not a flaw in the design. The design never claimed to close it, and it cannot be closed by any amount of hashing, because the only place it can be closed is at the moment the entry is made.
A buyer recomputes all six Harbourgate hashes and every link matches. What they have established is that nobody has touched the register since it was written. Whether consignment 41's seal was inspected at all is a question about a person in a cold store, and it is exactly as open as it was before the register existed.
Self-studyThe words that will keep coming back4 min▶
- Point of entry. The moment a fact about the world becomes a sentence in the register. The weakest link in every provenance system, and the one the chain does not touch.
- Oracle. Whatever puts outside information onto the chain: a person typing, a sensor reporting, a system feeding in readings. Trusted exactly as much as it would be trusted without a chain.
- Garbage in stays garbage. An inaccurate entry verifies as cleanly as an accurate one, and keeps doing so indefinitely.
- Write access. Who is permitted to add an entry at all. Decided outside the chain, before the chain sees anything.
- Append only. New entries go on the end; nothing already in the register is replaced.
- Correction entry. A later block that says an earlier block was wrong. The only correction mechanism an append only register has.
- Key management. Issuing, holding, rotating and withdrawing the secrets that let somebody write. A discipline of its own, covered in the security and access control courses rather than here.
Unaltered since written is not the same as true
15 min liveThree limits, and the useful move with each of them is to ask where the answer does live, because in every case it lives somewhere and somebody owns it. The first two both sit at the point of entry, which is why they are taken together.
Put the first two limits on a timeline and they stop being abstract. A register covers the last step of a four step journey, and the three steps before it are where the accuracy of the record is actually decided.
...
...
LiveA faithful record of a false statement4 min▶
Compare the second and third buttons above. In one the register was built with a wrong entry at block 5 from the start. In the other the same wrong text was put there afterwards. The second case is caught immediately and loudly. The first is not caught at all, and never will be, because nothing about it is inconsistent.
That asymmetry is the whole of the first limit. The structure defends the boundary between "written" and "now", and there is no structure defending the boundary between "happened" and "written". An organisation that wants its register to be accurate has to spend its money on the second boundary, where hashing does not reach.
LiveThe oracle problem, without the jargon4 min▶
Anything a register knows about the physical world arrived there because a person or a sensor put it there. That step is exactly as trustworthy as it would be with no chain involved. Harbourgate's entry that the seal was intact is worth precisely what the inspector is worth, and if a door sensor reported it instead, it is worth what the sensor and its wiring and its maintenance record are worth.
The unhelpful response is to add more chain. The helpful responses are all in the physical world: two people signing off instead of one, a photograph taken at the point of inspection and hashed alongside the entry, a sensor whose readings are compared against a second sensor that would have to fail in the same direction at the same moment. None of those is a blockchain technique. All of them raise the value of the entry, which is the only thing that raises the value of the register.
Self-studyWhere the disagreement really is4 min▶
One camp holds that the oracle problem is fatal to provenance registers generally. If the entry point can be lied to, a tamper evident record of lies is not an improvement on a mutable record of lies, and the expense buys a feeling of rigour rather than rigour itself.
The other camp holds that this misreads what changed. Before, a lie at the entry point could be quietly revised later to fit whatever story was needed; now it is fixed at the moment it is told, by the person who told it, and it cannot be tidied up afterwards when the consequences arrive. Pinning a statement to a time and an author is not nothing, and several kinds of fraud depend on the tidying up rather than on the original lie.
Both readings are held by serious people. Notice that they agree on the mechanics and disagree about how much of real world dishonesty happens at the entry point rather than later, which is an empirical question about your own operation and not a question about chains.
Who may write, and what it costs to be unable to erase
9 min liveThe third limit surprises people more than the other two. A chain has no opinion about who is adding entries to it. It will link and hash whatever it is handed, from whoever hands it over, and report that everything checks out.
LiveAccess is answered before the chain sees anything3 min▶
Real registers do restrict who may add an entry, and they do it with signatures: a writer holds a secret, uses it to sign the entry, and everybody else checks the signature against that writer's public key. The checking is arithmetic and it works. What it establishes is narrow and precise. It establishes that the holder of a particular secret produced this entry.
Everything difficult is on the other side of that sentence. Who was given the secret, whether they still work here, whether it has been copied, how it is withdrawn the hour somebody leaves, who is watching the log of its use. Those are the questions that decide whether write access means anything, and they are the subject of learn-cyber-security-with-phoebe and learn-data-access-control-with-phoebe rather than of a register design.
The last consequence is the one that turns up eighteen months after go live, when somebody finds a mistake. A register that cannot be edited also cannot be repaired, and that changes what reading it means.
LiveA mistake is preserved as faithfully as a fact4 min▶
Immutability is sold as protection and it arrives as an obligation. The property that stops a hostile party quietly revising last year's entry is the same property that stops your own team quietly fixing this morning's typo, and there is no version of the design that grants one without the other.
So the correction procedure is not a detail to be worked out later. It is the part of the operating model most likely to be missing on the day it is needed. Somebody has to decide what a correction entry looks like, how it names the block it is correcting, who is allowed to issue one, and how an ordinary reader is supposed to notice it exists.
LiveWhat this does to everyone who reads the record3 min▶
In an editable store, the current state is the answer. Look up consignment 42, read the row, done. In an append only register there is no row to look up: the answer is a conclusion drawn from every entry that mentions consignment 42, in order, with later entries overriding earlier ones according to a rule somebody had to write down.
That rule is real work and it is usually underestimated. It has to handle a correction of a correction, an entry that contradicts an earlier one without saying so, and the question of what a reader sees if they stop reading halfway. Every organisation running an append only register ends up building the summarised current view that the register deliberately refuses to keep, and then has to keep that view honest.
Self-studyWhat must be decided before the first entry4 min▶
Anything written cannot be unwritten, which makes the decision about what goes in a decision that has to be made once, in advance, and correctly. Personal details, commercially sensitive prices, anything a counterparty would object to seeing preserved permanently in every copy held by every participant: once entered, those are in every copy forever, and no amount of goodwill afterwards retrieves them.
The usual answer is to put a hash of a document on the register rather than the document, so that the register can prove the document has not changed while the document itself lives somewhere it can be withheld or destroyed. That works, and it moves the problem rather than solving it, because now the register's value depends on somebody still holding the document the hash refers to.
Take the three limits to your own register
18 min hands onNo code. Six steps on the register you picked earlier, done out loud. The aim is to leave with a written list of the things a chain would not fix, so that nobody has to discover them during implementation.
Name your inspector
For one field in your register, name the person or the device that decides what value goes in. Not the team, the individual role. Then say what would happen if that role wrote something convenient rather than something true, and who would ever know.
Separate the two boundaries
Write two headings: what happened, and what was written. List your existing controls under each. Most organisations find every control they have sits under the second heading, which is the one hashing already covers.
Price the entry point instead
Pick the one change at the point of entry that would most improve the accuracy of your records. A second signature, a photograph, a cross checked reading. Estimate its cost and compare that to the cost of a register project.
Say who may write, out loud
Name every party that can add an entry today, and how their permission is withdrawn on the day they leave. If withdrawal is a ticket somebody has to remember to raise, write that down as a finding.
Write a correction entry
Assume the entry you care most about is wrong. Write the exact text of the correction, including how it identifies what it is correcting, and then say how somebody querying that subject next year would find it.
List what must never be written
Name the fields that would be unacceptable to preserve permanently in every copy held by every participant. Decide for each whether it stays out entirely or goes in as a hash of something held elsewhere.
The habit to keep. When somebody proposes putting a record on a chain, ask what changes at the point of entry. If the answer is nothing, the proposal improves how well the record is kept and does not improve how right it is, and those are different products sold at very different prices.
Three questions
An inspector writes that the seal was intact without opening the container, and the entry is added to the register normally. What does verification report?
The false entry was written normally, hashed normally and linked normally, so every check passes. A register full of accurate copies of wrong statements verifies exactly as cleanly as a truthful one, and that is the failure that no amount of hashing catches.
A door sensor reports whether a container was opened, and its readings go straight onto the register. What has the register added to the trustworthiness of those readings?
Whatever a register knows about the physical world got there because a person or a device put it there, and that step is exactly as trustworthy as it would be with no register at all. Improving the sensor improves the record. Hashing the sensor's output does not.
Block 5 is found to be wrong. What does correcting it look like, and what does a reader now have to do?
Immutability cuts both ways. The property that stops a hostile party revising an old entry is the same property that stops your own team repairing a mistake, so correction means appending and the current answer on any subject is a conclusion drawn from the whole register rather than a row to look up.
Homework
Twenty minutes. Session 6 puts a decision path in front of you, and it works far better with these two pages in your hand.
Write the limits list for your own case
One page, three headings. What would still be inaccurate, who could still write, and what could never be corrected. Bring it to session 6, where the first question of the decision path assumes you have it.
Find out whether anyone else would hold a copy
For the register you have been working on, list the parties who would actually accept a copy and check it. Names of organisations, not categories. If the list is empty or has one name on it, that finding decides most of session 6 on its own.