The Value of Blockchain

In my previous post I argued that the core problem blockchain addresses is disagreement among the interested parties about the historical states of an object – a rental car, an order for granola, the price of pork belly futures.  That was sufficient to let us rule blockchain out as a viable technology for large class of solutions. But it was not sufficient to rule it in.

Let’s continue to unpack the problem space and see if we can make some headway on ruling it in.

It’s not enough for parties to agree which copy of a record is canonical.  They also have to agree on the fidelity of that record to the object. Maybe you assumed that. But how exactly do they do that?

Remember the record is not the thing, it is only a historical snapshot of the attributes of the thing.  

Let’s flip it, and ask how a record can lack fidelity to the object.

It can be out of date.  

But that is the nature of records.  You can’t ‘fix’ that, you can just update the record more frequently if its being out of date is problematic.  One key advantage of event-based architectures is that the out-of-date latency of records is reduced from the hours, days, or weeks of batch cycles to seconds.

It can be inaccurate – it can have incorrect information in it.  

How do the parties prevent that?  As I mentioned in the last post, provenance, upstream quality management – how was the attribute change instrumented, who reported it, how was the report transmitted, etc. – is part of the larger puzzle, and is vital to the record’s quality.

Provenance speaks to the accuracy and currency of the attribute values presented in an update.

But no matter how shiny the provenance – and it’s frequently a tarnished ‘unknown’ – there are still two kinds of validation we need to do at write (we may, for example, have updates from different sources in contention): validation of the domain of the attribute – a zip code can’t have the value ‘Zippy the Pinhead – and validation based on the previous state of the object.

The familiar model of events will help us here.    There is a state change in an object effected at some time or during some duration of time by some agent with some purpose using some tool.    

For real things, the valid transformations that can happen to an object, and in turn the valid values an attribute describing that object might assume, are constrained by physics, agreement among the interested parties, and by the legal constraints the action and their agreement falls under.  

A brick can’t turn into gold, it can only realistically turn into pieces of brick (cf the oldie-but-goodie ‘Six Kinds of Composition’). But the parties may agree ahead of time that the only valid places for bricks – those bricks of interest to the parties – are in one of the parties’ warehouses or in a truck moving from one to another, such that that ‘location’ attribute of the ‘brick’ record can only change into “Warehouse A”, or “Warehouse B” or “Truck Z”.

For virtual things, such as an order, the valid transformations and in turn the valid values of the attributes describing the object have no physical constraints, they are only constrained by agreement among the parties and the laws governing the agreement.

Wait a minute.  What just happened?  We just thought our way out of records to the meat world of real objects and the noosphere of virtual ones.

The permitted state changes, the permitted changes to a record, are constrained by the parties’ agreement about the objects whose attributes are being recorded.  

Agreement on what constitutes a valid record is agreement about what constitutes a valid state change, a valid transaction, for the object whose attributes it records.

The record constraints are an expression of the terms of their agreement about the things themselves.

Having an agreed-upon, shared master record forces clarity in the parties’ agreement about the thing recorded.

This is a powerful thing. 

There is alchemy that happens when they agree on a shared master record about virtual things that makes it even more powerful.

Remember I’ve held that the record is not the thing itself – in the last post we had the example of the sales order that was updated in conversation by Bob and the Winkster on the fourth tee.

That’s true when there are many copies of the record about the thing, in memory, in ledgers, in spreadsheets, in databases.

But when the parties have all agreed that the One True Copy is _that one_, that Bob and Wink’s conversational fourth-tee update to an order is not real until the One True Copy has been updated to reflect it, no matter how honorable they are, at that point the virtual order and the One True Copy of the attributes of the order are indistinguishable.   The current version is never out of date – there is nowhere else a state change can happen.

This is a revolutionary thing.   We have corralled a virtual thing and made it manifest.

This corralling can’t be done by database constraints.   You need a solution that manages state change validation, not just domain validation.   And a solution where those agreed-upon validation rules are, themselves, kept secure and inviolable.  

Blockchain.

<As Billy Mays>But wait, there’s more </Billy (RIP)>.

You don’t just keep one kind of record in a database.  And you don’t have to keep one kind of record in a blockchain.   If you have closely-related, dependent transactions, you can keep the records – or in the case of virtual objects, as we have seen, now the things themselves – in the same blockchain, and have your blockchain-managed rules handle not only the state changes of each object, but also the state change of the overall process.

Rules are just records of another kind.  It seems like a natural extension from having object and process state change rules to putting an entire contract in a blockchain and automating its execution.

But there is a practical challenge in creating an all-encompassing contract automation model.   Contract terms may be based on events or conditions external to the objects in the blockchain.  One solution to this is the Oracle, not to be confused with the one Larry ‘borrowed’ from IBM. This is Oracle as in the Oracle at Delphi, or maybe a Turing oracle machine – it is an external ‘black box’ that provides Truth about something necessary to the execution of the contract.  For example, you might have a contract term to pay an amount which is a function of the payment date’s Federal Discount Rate.   The Federal Discount Rate would come from an Oracle. 

But Oracles seems somehow to violate the spirit of blockchain – now we are trusting external technologies, which would seem to demand discrete agreement and management.

At this point we have abstracted so far away from conventional business solutions that many may fear losing sight of shore – thar be Dragons.  

So we will stop our journey for today and recap.

Blockchain should not be used if disagreement among parties about the historical state of an object is not an issue.  

If the validation of records, and in turn the underlying agreements about the objects themselves, are simple, then a trusted third-party intermediary (good old Alwin C.) might be a better solution than blockchain – but that is likely going to be less true over time as blockchain solutions become cheaper and easier to use.

If the state change rules are complex, and themselves a source of potential disagreement, blockchain is the better choice. 

There is also a practical challenge I see around moving to blockchain solutions. Many of the technology transitions we make are gradual. (I guess that is the ‘big back office software types’ we). We pilot, we move some work onto a new system, we take measured steps. We very rarely big bang on over to a new tech. I’m not sure I see an incremental path to blockchain at grain finer than an entire transaction. You have to go all in on a transaction – that is the nature of the beast. That means higher risk, and a tougher sell. So minor transactions to build trust, maybe, certainly not any aortic flow.

Putting entire contracts into blockchain for their automated execution is technically viable.  But the use of Oracles to round out the functionality raises some technology and security questions which have not yet been worked out to general satisfaction. And the level of abstraction and distance from conventional contract approaches will make it a hard sell to business leaders.  So proceed with caution.

Stay tuned.