The possible role of blockchain in an interoperability scenario has come up at work, as it has and will for many of you in various contexts. So I thought I would share a perspective on blockchain that might help you cut through the hype and determine its fit for a given solution design.
Blockchain solves a fundamental problem in information technology that has been around since we invented writing. (My introduction to the history of writing was when Mrs. Cutticia, my sixth-grade teacher, said my handwriting looked like Babylonian cuneiform. I asked her what that was. She said to look it up in the Encyclopedia Britannica. Those were the days.)
The problem blockchain addresses arises inevitably from the fact that the record, the data, we make and use about a thing is not the thing itself.
“D’oh” you might say, smacking your forehead, “Mr. Obvious much?” Bear with me, Grasshopper, and all will be revealed.
There are two kinds of stuff. There is real stuff, and there is virtual stuff. Real stuff = people, rocks, trees, gold, water. Virtual stuff = money, orders, contracts.
For real stuff, our information record is a snapshot of that thing’s attributes at points in time (the attributes may be captured and updated at different times).
For virtual stuff, our information record is also a snapshot of that thing’s attributes at points in time.
The difference is that for a real thing, if there is any question about its current attributes, we can check with the actual thing-in-the-world. Is that Gibson ES-335’s color Blueberry Burst? (Why there would be such a thing is a different question.) Let’s just go look at it and see.
But for a virtual thing, like an order, we have only our records of it, and our memories of it. The records might be on paper, or in a spreadsheet or a database. Or Wink, the buyer for Widget World, may have been walking up to the fourth tee with Bob, the sales manager at Our Word is Our Bond, Inc., and said, “Bob, let’s throw another couple of palettes of your prime widgets on our order – same terms as usual?”, and when Bob replies “You’ve got it, Winkster – your honors” the attributes of the order have, in that moment, changed.
For real things, even though we can check the thing-in-the-world for its current attributes, what was its state at some historical time T? Did that rental car already have a big scratch on the door when I drove off in it at the airport?
Our record about a thing, whether real or virtual, is at risk of being out of date the moment it is written. In this sense all records are historical records. A ‘current’ record is simply the most recent update.
We arrive at the core problem blockchain addresses. If the parties involved in some way with an object have a disagreement about its attributes at a point in time, including ‘now’, how do they resolve it? If I have a contract with you that pays you per widgets I use per month, and we disagree about how many widgets I used last month, how do we resolve it?
We can’t, the parties can’t, unless they have (all) agreed ahead of time that that copy (all pointing at the same one) is ‘canonical’, and every other copy is second best. (They can also try to figure out which copy is ‘right’ after the fact, in the midst of the disagreement, when the considerations I’m about to outline still obtain but have to be resolved under the gun, when there are far fewer options.)
But if one party holds the canonical copy, how do the other parties access it? If these are critical business records, such as transaction records, they are generally in one party’s core operational system, with limited access, especially from outside the firewall. How does the other party trust that they are complete, accurate and consistent? A common solution is periodic audit access where the ‘external’ party is allowed to examine the books, or to have an agreed-upon third party audit the books. If you’ve been through getting that into contracts, or executing an audit from either side, you know it’s ugly. If there wasn’t a clear agreement ahead of time, and sometimes even if there were, the black helicopters might even swoop in and disgorge the forensic accountants, coming in hot like a SWAT team with spreadsheets.
To resolve disputes well it is not always enough to simply have the most recent version of a record. The parties want to know every time it was updated, by whom, for what reason, and what the values were before and the update. Historically that level of detail could only be obtained, if at all, from the internal audit trail kept of database changes, which is frequently difficult to ‘mine’. We’ve seen a few time-variant databases here and there, and, more recently, the emergence of event histories. Trying to infer the narrative after the fact is frequently very difficult – it’s why those forensic accountants can afford that helicopter.
The external party needs to know the ‘master’ records are safe from malfeasance and accidental or purposeful harm. We have seen the emergence of industry standard certifications and government mandated standards around these safeguards, all designed to give the parties a warm and fuzzy, including ISO 27001 certs, Sarbanes-Oxley, PCI DSS, and so on, which have, not by accident, given The Big Four a lot of business over the years.
With respect to current attributes, for real things the real world is trumps. But in the age of broadly distributed information, access to the real thing may be problematic for the parties. If there is one master copy, only that copy has to be kept in fidelity.
A blockchain is an agreed-upon-ahead-of-time canonical version of the historical attributes of a thing. It is external to all parties, and equally accessible to all parties. It is append-only, so history is never overwritten or deleted. It is digitally signed and tamper proof. It is made durable by being broadly distributed over the Internet.
The fundamental problem it addresses is disagreement among interested parties on the historical states of an object.
If there is no clear benefit to supporting the agreement among multiple parties about objects of some type, and avoiding their disagreement, blockchain doesn’t fit.
And if you do use it, the issue of provenance still exists, and must be addressed separately.
Software is potentially a perfect copy factory. But in the real world of software, any record of a thing’s attributes is only as good as its provenance. What instrumentation was used to obtain the attributes? How was the identity of the observed object determined? Who was the observer, and what were their bona fides? What time was the observation made? How was the state of the attributes reported?
The First Law obtains in aeturnum: Garbage In, Garbage Out.
(But wait, says the perceptive reader. You’ve described the core problem blockchain addresses, and from that determined when blockchain won’t fit. But aren’t there other ways of addressing the core problem without using blockchain? Couldn’t you have a third party trusted by all, Ernst & Young or somebody – that Alwin C. Ernst always looked like a standup citizen – keep the master records on a durable-through-disaster Oracle or SQL Server installation, or in Google Cloud Spanner or Amazon Aurora Global, or somewhere? When does blockchain fit?. We will look into that next time.)
Stay tuned.
(That next post is here.)
Health IT Architect 