So when should you consider a blockchain? Answers with Flow Charts.
There is nothing wrong with considering a blockchain whenever you have data to store and handle. The important point to take note of is: blockchain is probably not the right tool for your problem, despite being an exciting technology. But how do you systematically think through the options and decide wither to use a blockchain or one of the many alternatives to blockchain?
Several groups have come up with their take on “When to use blockchain?” independently. This includes academic researchers, the Hyperledger consortium, and the National Institute of Standards and Technology (NIST) of the USA. Their answers are geared more towards a technical audience that builds software-based products rather than business developers and decision makers in management. Nonetheless, their answers can guide managers and help to facilitate communication between technical staff and management.
The Decision Path in Flow Charts
Because blockchain is just a database with some very unique properties, a blockchain can be a solution when you need to handle data.The following statement, taken from Wüst/Gervais paper titled “Do you need a blockchain?”, boils down the situation precisely:
“…using […] blockchain only makes sense when multiple mutually mistrusting entities want to interact and change the state of a system, and are not willing to agree on an online trusted third party […]”
Understanding the implications of the terms mistrusting, state of a system, and trusted third party is key. It is less important to understand the technical details of how and why these properties are archived than it is important to understand the implications. The implications both have a technical scope (i.e. blockchains are slow, typically public, etc.) as well as a business scope (i.e. the independence on trusted third parties can pose both threats and open new opportunities).
The following flow chart, taken from Wüst/Gervais’s academic paper, summarizes their analysis. The first three decisions check for state, participants, and trust. The following decisions determine what type of blockchain is the right one.
The Hyperledger project also has a flow chart with a decision path guiding the user to either a public or permissioned blockchain (leaving out the distinction between public and private chains). You can read more about the flow chart here.
An interesting difference in these charts is the phrasing and how explicitly they talk about the context: In the Wüst/Gervais paper, one check in the flowchart is whether a trusted third party is available, while Hyperledger’s chart only asks for conflicting incentives and the lack of trust.
A non-tech example of conflicting interests of distrusting agents together with a trusted third party are traders and a clearing house. Clearing houses exist to counteract the traders mutual distrust and are explicitly enabled to act as an intermediary for traders by regulatory law and legal processes. Following both charts, one might come to different conclusions about the applicability of blockchain: Because clearing houses are a trusted third party, it is not necessary to rely on a blockchain (Wüst/Gervais), but because you have distrusting entities, you can (Hyperledger). In this situation, building a blockchain-based solution will compete with an already well-established established solution (i.e. the clearing houses).
NIST recently proposed another flowchart. In contrast to the other two flowcharts, it points to alternative solutions, ranging from spreadsheets to specific types of databases that can do a better job than a blockchain. One downside of this chart is the lack of questions guiding to private or permissioned blockchains.
Should you use a blockchain?
Unless you are building a blockchain product on purpose, there is no generic answer to this question. I strongly recommend to take all flow charts mentioned here, sit down with business people as well as engineers, possibly together with a mediator, and walk through the charts. The chart structure is generally aligned along the same set of questions: Do you need to store data? Is it you, or are there others who need to read and modify the data? Do you trust each other, or do you need to enforce honesty with a technological solution? But neither chart offers guidance to think through business-specific aspects of blockchain: Where can blockchain solve problems? Where is blockchain better than existing solutions? Going back to the example of clearing houses: Are the laws enabling clearing houses just the best “bad solution” we could think of so far? Is it better to replace clearing houses with a trust-less, decentralized blockchain-based solution? The answer will depend on the willingness of the industry to embrace and use new solutions as well as the regulatory support or pressures for an alternative solution.