In 2016 Gartner located blockchain approaching the peak of inflated expectations. A year later in 2017, the analysts assessed blockchain as still peaking but also starting to tumble towards the trough of disillusionment. The following years saw the start of several big blockchain projects. Maersk and IBM founded «TradeLens» for the global shipping ecosystem. Notable insurance companies came together and launched the Blockchain Insurance Industry Initiative (B3i) to address critical insurance industry needs. Adnovum, universities, and major players of the Swiss car industry developed the common vision to manage the life cycles of cars with blockchain and launched the association cardossier to achieve it.
Lately, the party of blockchain platforms and decentralized applications has been sobering up and this process has claimed victims. TradeLens and B3i announced their discontinuation for financial reasons in 2022. However, cardossier has so far withstood the increasing pressure and is now facing better prospects.
These events are a glimpse at the exciting story around DLT solutions that has been unfolding for a few years. We are not just observers but also actors with our product SB4B and our substantial stake in cardossier. Although it is normal that many innovation initiatives do not survive, the risks being plentiful, I think the blockchain hype was quite extraordinary. It will take time to draw all the right conclusions, but for our own investments and the best possible service to our clients, we should take a closer look now. The next hype is just around the corner.
What is DLT?
Distributed ledger technology (DLT) denotes IT solutions which implement a ledger with a decentralized architecture: instead of managing a central ledger, different parties maintain many instances of the same ledger. Distributed processes ensure a consolidated and consistent evolution of the data in the instances. Diverse consensus models can be a part of these processes. With these, the parties validate updates on the ledger according to predefined algorithms.
Blockchain, most famous representative of DLT
Blockchain implementations are a well-known subset of DLT solutions. «Chain», the eponymous feature of a blockchain, means the linking of data blocks with hashes1. A blockchain develops by continuously adding new data blocks. In the process, the hash of the previous block becomes part of the newest block and so on. Thus, a chain of blocks emerges whose consistency can be checked with the used hash function. The most common consensus models in blockchains are the proof-of-work (PoW)2 and the proof-of-stake (PoS)3 models.
Linking with hashes has a decisive advantage: it makes it hard to modify the chronological order of the changes in the ledger afterwards. Attempting to do so would mean that the whole development of the data from the manipulated block needs to be recalculated. Such a reevaluation would not go unnoticed by the other parties. The consistency of the chronological order is particularly crucial for crypto currencies to prevent double spending. On the other hand, it can be an issue if certain historical data must be deleted.
DLT, and blockchain in particular, is complex. The costs for development, integration, and operation tend to be significantly higher than for «classical» solutions. By now, there are several offers for managed DLT solutions in the cloud or enterprise DLTs for an on-premise installation4. With these, the costs can be reduced depending on the maturity and complexity of the product. Nevertheless, the application of DLT must be justified and deliberate.
Now that the technology is a bit clearer, what could go wrong with it? Not much if a company applies blockchain so that it experiences a substantial improvement. This is easier said than done. Following business management guru Dr. Goldratt’s5 advice, among other conditions, we must apply the technology to a context where it solves a real limitation that previously was managed differently. I argue that the chosen context is often determined by other factors. To illustrate the issue, let’s take an outside observer's viewpoint for a moment.
«We’re excited to announce a joint venture with Maersk, a global leader in container logistics, that will bring blockchain technology to all the participants who play a vital role in one of the world’s biggest networks – the global shipping ecosystem.»
«The transition from a consortium to an independent company is a definite step forward for B3i in harnessing the enormous potential of Blockchain for the insurance industry.»
«Yesterday, notable Swiss companies, universities, and government agencies
It is notable that announcements like these were common during the «golden» blockchain years and achieved their immediate goal. The term blockchain was successfully used for advertising and financing new initiatives, start-ups, joint ventures, and so on. If you apply it consciously for a clear purpose like that, it should be fine. If, however, the promotional potential of current trends determines your main technology decisions further down the line, you might be in trouble. I’m sure that some engineers, tasked with converting these ambitions, asked the right questions but, in the end, many delivered what was advertised, nevertheless. It is understandably difficult to criticize the choice of a cool new technology which made the whole enterprise possible in the first place. TradeLens, B3i, and cardossier diligently developed their platforms with blockchain and went live.
Most of us should be a bit concerned now. We remember the method of designing good software differently: First, we gather as much as possible about the context, i.e., stakeholders, requirements, and constraints. Second, we sketch a target solution that satisfies all the constraints optimally. Third, we determine which products, patterns, and technologies we need to implement and operate that target picture effectively. At this stage of the process, we might well find out that DLT or blockchain is an option, maybe even the best one in the given context. But what is the likelihood of that?
«The international blockchain project B3i is history. The company has filed for bankruptcy because the more than 20 international insurance companies financing the project have cut off funding.»
If your project started during the hype years, chances are that the technology had already been chosen before you even started gathering constraints and sketching a solution space. Which means most likely you started a software project with unsuitable technology, or in other words, with bad architecture. This can lead to several problems, even existential ones.
«Unfortunately, while we successfully developed a viable platform, the need for full global industry collaboration has not been achieved. As a result, TradeLens has not reached the level of commercial viability necessary to continue work and meet the financial expectations as an independent business.»
I am aware that my argument is exaggerated and grossly simplified. I am sure people thought about the relevant constraints and requirements of their business domain and the solution space already before starting their blockchain initiatives – some more than others, I guess. I am trying to make the simple point that during an emotional time, like the blockchain hype, the usual technological «due diligence», inherent part of the development process, can be pushed into the background just enough to end up with a mismatch between problem and solution.
How can we fix this once it has happened? The possibilities range from dropping everything and going home to investing again and rewriting the entire solution. Each organization must find a cure that fits them. We were stuck with a technology mismatch with SB4B in cardossier and the way we approached it was with a radical redesign. After several years of productive operations, we started the design process from scratch again, with all the learnings from the previous years and keeping an open mind when it came to the choices of technologies. The outcome is a peer-to-peer platform with an effective application of signatures and hash functions that avoids the additional complexity of blockchain altogether. This isn’t for everybody, since minimal productive traffic and self-financing made this approach possible for us.
But, more importantly, how can we prevent this situation in the future? I think that if we can navigate future tech hypes with the same euphoria as we did with blockchain and, at the same time, have a set of basic, tough, objective criteria at hand to challenge applications, the bottom line will be more satisfying. For DLT, we created such a criterion model as a decision tree (see Figure 1). Such tools can guide us through emotional discussions and give us the arguments needed to place our investments carefully and consult clients adequately. If we don’t boldly challenge bad technology choices up front, the market will take care of it ultimately … but at an immense cost.
How to challenge DLT as a technology choice
The following decision tree gives a first orientation on whether DLT is a suitable part of a solution from a purely technical point of view.
Figure 1: Guidance for the DLT decision
In the positive cases, you end up in one of three types of DLT solutions.
- Permissionless: Everybody can join without explicit permission (e.g., Bitcoin).
- Public-permissioned: With the right permission, everybody can join. The network is open to the public under certain conditions.
- Private-permissioned: With the right permission, a defined set of participants can join. The network is not open to the public (e.g., Hyperledger, R3 Corda, and SB4B).
If an answer leads you out of the diagram, the application of DLT must be challenged.
1A hash is a digital fingerprint of a data set that verifies the authenticity of the data set without permitting conclusions about its content.
2Transactions are validated by solving computationally intensive mathematical problems.
3A selection of network members validates transactions.
4SaaS: AWS Managed Blockchain; enterprise solutions: Adnovum SB4B, R3 Corda, Hyperledger Fabric
5Essays on the Theory of Constraints, Eliyahu M. Goldratt, 1987