Much has been written about blockchains and their most popular applications, cryptocurrencies and smart contracts. That does not come as a surprise as Bitcoin is already 9 years old. Yet, blockchain-adoption is not rampant and most of us still struggle to understand when and where to use a blockchain. Even worse, confidence is spreading despite misconceptions: According to Deloitte’s 2018 blockchain survey, 75% to 80% of managers across leading industries self-identify as competent in blockchain technology. Simultaneously, about 1/3 thinks that speed is one of blockchains key advantages — and that’s just not true for almost all use-cases of blockchain.
Over 70% of executives think they are “blockchain experts” according to Deloitte’s 2018 Blockchain Survey 😂 They also believe the biggest advantage of blockchain technology is speed 🤦♂️ The biggest problem in blockchain is hubris. And it’s toxic. 🤮 There are no experts.
Why is blockchain so hard to grasp? Why is it not clear what its applications are? Is it just because blockchain still is fairly new and traditional industries have not yet implemented many blockchain projects? When should you actually consider a blockchain?
Blockchain never stands alone. At its core it is just a data structure, a database to store data with several interesting properties. It is a technology that enables products. I believe that blockchain is affected by the same two reasons we encounter frequently when bringing any technology to the market that. First, engineers (understanding the technicalities of blockchain well) are usually not the type of person to reason through business cases, especially in highly regulated markets such as financial services and insurance.
But on the other side, business people often do not understand the technology well enough to judge which pain can be solved by the specific properties blockchain can offer and which threats and opportunities these might offer.
Bridging this gap between the business and the technology requires to make an effort in conscious communication between both sides (or alternatively, people well-versed in both fields or able to mediate between both sides). Let’s illustrate this by a thought experiment:
Think of blockchain as a new type of engine. With a new engine (blockchain) we can build new types of vehicles (i.e. blockchain-based products). Who is impacted by this? Car-makers (i.e. people offering products as solutions to others) come to mind immediately because they can build their new cars. The question is whether anyone needs this type of car. To understand that they need a deep grasp of their customers’ needs.
But any type of businesses itself is also affected. New types of cars (blockchain-based products) can offer new opportunities or threats for their business. Think of a restaurant owner, for example. They might conclude that this new type of car offers an opportunity, because he can now purchase a new car with it and offer deliveries (cheaper, faster, better than before). But the owners could also come to the conclusion that it only affects his customers rather than themselves. A new type of car might lead to more people driving and introduce drive-thru services. Or contrary to that, the new type of car might lead to people driving further and enable customers get to competitors faster and easier, leading the restaurant owner to lose business. Yet, to play through these scenarios, the restaurant owner does not need detailed knowledge of the new type of engine. Nor do the car makers care about the restaurant owners’ business (unless they are trying to develop a car specifically for customers like them).
To conclude this thought experiment, lets ask: Do we currently have too many restaurant owners thinking about the specifics of a new kind of engine? I do think so.
So when should you consider a blockchain?
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. There are many alternatives to blockchain, both from a purely tech point-of-view and from a business/ecosystem point-of-view.
Several authors wrote about when to use blockchain, including academic researchers, the Hyperledger consortium, and the National Institute of Standards and Technology (NIST) of the USA. Often, these articles are geared towards a more technical audience building products, not the end-users of products. A good example is the following statement, taken from Wüst/Gervais paper titled “Do you need a blockchain?”:
“…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 […]”
To fully understand this statement, it is crucial to understand what dis/-trust, state of a system, and trusted third party precisely mean. This, in turn, either needs a solid grasp of blockchain itself to derive the implication, or someone who can mediate between these terms in the context of blockchain and elsewhere.
In Wüst/Gervais paper, the authors summarize their analysis in a flow chart. The first three decisions are already summarized in the above quote. The last decision(s) just 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 branch leading of public but permissioned blockchains when compared to Wüst/Gervais flow chart). You can read more about the flow chart here.
When designing PoCs with Hyperledger Fabric, @IntellectEU came up with a very helpful “Blockchain Decision Path” to see whether using distributed ledger technology would give a boost to the use case. More: https://t.co/3hbjjkhgDU
An interesting difference in these charts is the phrasing and how explicitly they talk about the context: In Wüst, one check is whether a trusted third party is available, while in 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. In this situation, the clearing houses exists to counteract the traders mutual distrust. The clearing house is explicitly enabled to act as an intermediary for traders by regulatory law and legal processes. That help to establish trust in the clearing house and the associated processes.
In this case, a blockchain might offer a solution that stands in competition to an already well-established established product. If your goal is another product and not building a competitor, it might be a better choice to reuse the existing solution rather than building your own.
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 your 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?
Overall, your answer is certainly yes if blockchain offers you a solution that no simpler alternative offers.
Did the article pique your curiosity? Are you left looking for ways to answer the questions? Are you in dire need of more blockchain information? If you or your organization need support, training, or mediation, please reach out to me at chris [at] alatus [do]t tech. I will be happy to guide you through the process of evaluating threats and opportunities of blockchain, and mediate between the tech, business, and operations staff at your business.
When to consider a blockchain. In short. was originally published in Data Driven Investor on Medium, where people are continuing the conversation by highlighting and responding to this story.