How far along is the success of the Distributed Ledger and DApps?
My attitude to Distributed Ledgers was never particularly enthusiastic, though I admit I was initially seduced by the idea of an independent e-currency that could not be created on demand by governments. It turned out that this ‘independence’ is one of the biggest risks associated with cryptocurrencies: most, if not all, countries have a monopoly on the issuing of money. So, if cryptocurrency is in fact money, it can be very easily declared illegal – as has happened in countries that are concerned about the strength of their currency1.
This analysis is my personal attempt to understand the situation and become less skeptical about the Distributed Ledger (abbreviated to DLT – Distributed Ledger Technology). How does it differ from any other database? What is its value? What are the current use cases? Many publications already cover this area. I am going to define what DLT really means, what features it has, where it could be successfully used, and when.
My analysis starts with a Wardley Map.
At the top, we have a customer (or a group of customers) that currently has a broad array of needs, none of which demands a DLT solution. Actually, if we found a user need that explicitly required it, further analysis would not be necessary. This is a bit of a ‘chicken and egg’ situation: such close connection between a user need and its solution is possible only if the solution is created as a response to a well-understood customer problem, and this was not the case with the Distributed Ledger. A connection may or may not emerge in the future, and it may happen in the next five years or in hundreds of years (the first electric cars appeared at the beginning of the twentieth century, but it has taken us a long time to make them feasible).
In the absence of a specific user need for it, in order to discover how the Distributed Ledger could be used to improve the efficiency of our existing solutions, and to look for possible new opportunities, we need to understand what the DLT does efficiently and where this efficiency could be useful. (Efficiency is critical, as it is the cornerstone that will secure survival of the ecosystem. Without it, investors will move somewhere else.)
The core feature of the Distributed Ledger seems to be its shared state. Different bits of information are spread across multiple nodes thanks to some wonderful algorithms, and once something is stored, it cannot be modified. Regardless of whether you store information about who has how much money (and how it is transferred) or whether you store and process information about sent messages, the second core feature of the Ledger is the immutability (and traceability) of its history.
In fact, the Ledger does exactly what humans did in small communities: where everyone knew everyone else in the group, and interacted and gossiped with them, everyone knew everything. The outcome was exactly the same as in a Distributed Ledger, but, unfortunately, efficiency was slow.
You cannot rely on gossips when you do important transactions. For example, you could buy a house and the unscrupulous former owner could immediately call the cops to remove you, as you would have no proof of the transaction until the gossip about the sale had spread. So humans invented ‘trusted third parties’. We standardized and centralized many different transactions (and therefore knowledge about exchanges) and started creating transaction proofs (buy/sell agreements, registers, documents, licences, etc.).
A Distributed Ledger can decentralize those transactions, and move us back to our natural state, with the difference that instead of gossips, we have modern tech.
I have found three cases in which the DLT could be more efficient than other trust distribution mechanisms:
- In many countries you cannot buy or sell real estate without a notary supervising the transaction. The notary, being a third-party trust provider, certifies the transaction has taken place, and submits documents to proper registers (which take time to recognize the change). The danger is that someone could sell the same property multiple times in the front of different notaries, within one day, so there is always a risk that you have bought property that had already been sold. A Distributed Ledger, through almost immediate confirmation, could deliver immediate confirmation.
- Failing to file your tax return is always a problem. It is not only good to have filed it, but it is also good to have confirmation that you have done so – just in case. In many countries, paper letters are still the most trusted way of communication. But what happens if you send an empty envelope? You will get a confirmation of its receipt, and the Tax Office will have to prove that the envelope was empty. Having a fingerprint of the message sent would definitely prevent that. In fact, it works the other way, too. Some banks use a blockchain-based solution to show that certain documents were sent to customers, and that customers acted on them.
- When you buy a car, there is a short period between buying it and notifying the proper authority. The seller can still say it was stolen, so it would be good to have reliable proof of the transaction. Currently, we rely on a written agreement (in paper form) that serves as the proof. A Distributed Ledger could be used to notify all the interested parties immediately.
So, at this point, we can say that a Distributed Ledger provides very specific functionality – immutable history and shared state – and its value is relevant in contexts where the biggest constraint on users is the inefficiency of existing communication and trust engines. The fundamental question is, where exactly?
The speed of the communication (the DLT transaction) is not often the most important criterion, especially if each transaction is a bit different. Sometimes, there are other more significant risks, so introducing a Distributed Ledger will not improve system efficiency, because the constraint is somewhere else. Immutability is often a really valuable feature, but only if there are no intermediaries between transaction parties and the ledger. If banks send information about increased fees to customers, and put hashes of the documents in the ledger, and then the same banks control the solution that stores the ‘customer read’ flag, the Distributed Ledger is no more trustworthy than the banks themselves. But if you are a direct participant in the transaction, what will happen if your identity gets compromised, or indeed, if anything goes wrong? Direct access to the DLT comes at a price – you have a very limited possibilities of fixing mistakes, even if the mistakes are caused by bugs in the DLT code ii.
Here is the problem. The Distributed Ledger is not really a great trust provider. It spreads information, and provides proofs that information is consistent, but that is all. Trust has to come from some other place – because if we no longer know everyone in our vicinity, we have to rely on trusted third parties – and then we can use the Distributed Ledger.
My conclusion is that today, there are places in which a Distributed Ledger could help – but these places have enormous structures built around less advanced practices. Many registers sanctioned by legislation, traditions, practices and business models cannot be changed easily due to their sheer size.
That is critical to the success of the Distributed Ledger. We either manage to provide a compelling use case (e.g. showing efficiency will be increased by at least an order of magnitude) or we will have to wait a while for widespread adoption of the Distributed Ledger. And only after the Distributed Ledger becomes ubiquitous will some of the use cases be automated, creating space for DApps.
So, in short: the success of Distributed Ledger is still far in the future.
iThe situation is a bit more complicated, but we have already seen countries banning cryptocurrencies if they threaten their interests.