Blockchain and Distributed Ledger Technology: In the Trough of Disillusionment

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 hashes¹.  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)² and the proof-of-stake (PoS)³ 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 installation⁴. 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.

Application

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’s⁵ 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.

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?

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.

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.

Cure

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.

Prevention

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.

Footnotes:

¹A hash is a digital fingerprint of a data set that verifies the authenticity of the data set without permitting conclusions about its content.

²Transactions are validated by solving computationally intensive mathematical problems.

³A selection of network members validates transactions.

⁴SaaS: AWS Managed Blockchain; enterprise solutions: Adnovum SB4B, R3 Corda, Hyperledger Fabric

⁵Essays on the Theory of Constraints, Eliyahu M. Goldratt, 1987