Avoiding blockchain for blockchain – s sake: Three real use case criteria, Bits on blocks
Bits on blocks
Avoiding blockchain for blockchain’s sake: Three real use case criteria
2016 was the year of creating frameworks and filters to determine if a business problem was worthy of a blockchain-based solution. Often, the frameworks would proclaim inappropriate potential use cases as ripe for blockchaining, as the frameworks were often designed by blockchain vendors or consultants to let as much through as possible. However, many of the proofs of concepts built in 2016-17 have not become industrial solutions. Why?
Two main reasons are:
- The technology didn’t meet the requirements of the use case
- The use cases themselves were selected badly
This post discusses what went wrong with use case selection, and presents two fresh and better questions for use case selection.
2016: Poor use case selection
Here are some common questions I eyed in 2016, used to identify potential blockchain use cases:
- Do you have lots of participants?
- Is there data sharing?
- Does data need to be “validated”?
- Are there contracts?
However, these were poor selection criteria and were often based on a cursory look at the properties of Bitcoin’s blockchain and network, and then misapplied to other business scripts. For example:
Do you have lots of participants?
Bitcoin’s blockchain has lots of participants – about Five,000 validators called knots, and about 10-15 miners who create blocks. The decentralisation is there because the Bitcoin network is designed to not have any known entity in control. However for industry distributed ledgers where parties are identified and known, you don’t need lots of validators: efficiencies can be created instantly just with a distributed ledger inbetween two participants. You don’t need lots of participants for a distributed ledger to improve things.
I have written about this before. Data sharing is a solved problem: use a web-portal.
In Bitcoin, validation is narrowly defined: it means mathematically validating digital signatures and validating that a bitcoin being spent hasn’t already been spent. Bitcoin doesn’t validate the “truth”. Bitcoin doesn’t validate legal or moral assertions. Bitcoin doesn’t validate the results of academic research (yes, I have seen a proposal for a blockchain use case where miners validate that academic researchers haven’t cheated with their results…).
Ethereum popularised the term “clever contracts” which made people believe in magic. Unluckily, self-executing magic contracts only exist in Harry Potter. The presence of contracts in a business network does not instantaneously mean blockchains or distributed ledgers are suitable.
There are many other filters and frameworks applied, many of them not helpfully.
2017: So what? What now?
So how should we think about this technology? When should we commence to think “blockchain” or “DLT”? It’s about collective control over data (not collective data), and assured multientity processes (not automating business workflow).
So here are three fresh questions where a distributed ledger could be considered. They are a little more nuanced than the two thousand sixteen set.
1. B2B workflows: Are there bilateral, or even better, multilateral B2B workflows where each participant needs to independently validate the other participant’s data accuracy and/or processes?
A distributed ledger can give parties assurance that the data being stored and used by their counterparts is the same as the data they are working with. The ledger won’t flag if a participant is being “truthful” or not (ledgers are only as good as ledger entries), but it will assure that the same data is being accessed by the participants.
Similarly, a distributed ledger can give parties assurance that the workflows inbetween parties are being adhered to, and that each entity is running the same business logic, or at least coming out with results that are compatible with the pre-agreed rules of engagement. In other words, proposed switches to ledger data goes after pre-agreed rules.
Even with a distributed ledger, does each party need to validate the results of someone else’s calculations? Of course they do. It would be bonkers to rely entirely on someone else’s calculations. The difference now is that the reconciliation comes before data is stored, rather than after. I wrote about distributed ledgers being “confirm as you go” rather than “confirm after the fact”. Switching the order makes a large difference to operational risk.
Two. Industry utilities: For the potential industry use case, could you imagine and design an industry utility that would make sense? Why doesn’t it exist? Perhaps it wouldn’t get traction because of political reasons around ownership: either because everyone or no-one would want to own it?
A distributed ledger, in some cases, could provide the response – it avoids the problem of ownership and control of a utility. Everyone participates in the sharing of certain types of data, and mutual validation of the data and multilateral processes, but the data itself doesn’t go through a single entity which has ultimate control over data passing through the network – the bottleneck has gone.
Trio. Is centralisation a risk?
Perhaps there’s a ideally good centralised solution. I have written previously about interbank payment systems and centralisation risk. As cybercrime and cyberwars become reality, there is an instant and urgent need to de-risk critical infrastructure systems that have central points of failure. Investigating if a distributed ledger could be used in place of a central point of failure is an imperative for nation states.
The frameworks for use cases we were using in two thousand sixteen are no longer adequate, and as the global understanding of this fresh technology grows, we must evolve how we determine when to apply this technology.
I understand the reality of budgets, committees, and organisational politics: sometimes sprinkling a blockchain on an inappropriate use case can unlock budget to build automated systems that wouldn’t otherwise receive funding. And that’s fine!
However, I have long been a proponent of avoiding blockchain for blockchain sake (B4BS). The three criteria articulated in this article should help us think about determining real value-adding use cases that improve business and industries.