A knotty problem
I am/was a bit perplexed about the usage of blockchain. In theory, it is “cool technology” and it obviously works (at least on some scale, as is proven by the digital currencies). Why then is this something that has not already revolutionized the industries? While there could be many reasons based on the context of the usage, this got me thinking and here are my thoughts.
If the shoe fits …
I watched (again) a short clip where Steve Jobs describes an approach to product development and the use of technology (i.e. how and where technology fits into products). His conclusions are simple and direct – and true yet as of today, 20 years after he arrived at the conclusion. It is that we should not look at technology (i.e. blockchain in this case) and see where we can twist it in. Rather, we should look at the user experience and then work backwards to see where the technology can deliver.
It is not a question of whether it can be done – anything can be done. The more important question to ask is – is it worth doing?
In case of blockchain (distributed ledger), many initiatives that had started missed this fundamental aspect. It is not a question of whether it can be done – anything can be done. The more important and relevant question to ask is – is it worth doing? Does this matter - what problem is this solving?
It is not a commentary on distributed ledgers – I personally think it is a very useful technology. However, by trying to squeeze it in places where it does not belong, and hence failing to get traction, it is losing the credibility and wider acceptance. It is simply delaying the inevitability of certain possibilities. In some sense, this is the same thing that happens to agile transformation in many places (“we tried it – it doesn’t work here” leading to a generalized summary “agile doesn’t work”).
Trusted vs trustless
So, going back to the basics again. Blockchain is meant for ecosystems where trust is required but not available - not where trust is not required or where trust is required and available.
Blockchain is meant for ecosystems where trust is required but not available.
As digital currency has been built on blockchain, let us look at this in further details using this area - money. Imagine your company chooses to pay your salary in digital currency – can it do that? Of course it can – so many digital currencies already exist and they can choose one and create a structure around the process. Now think of it in a different light – would it matter to you (or your company) if it paid you in bitcoin or dollar as long as the value of what was paid remains the same? What do you gain – your payment would anyway be made electronically? Both parties are already known to each other and there is implicit trust - your company can measure and valuate the work that you have done for which you are getting a salary. A trustless system is useless here (unless we are talking of bypassing the entire banking system and building a parallel economy).
Now imagine another hypothetical use case. The people in a country does not trust that the elections using traditional ballot will be fair. However, they still trust democracy and want a fair election. Imagine if they could use a system, based on distributed ledger, where each candidate is a “peer” and the votes cannot be tagged against individuals and individual votes cannot be modified (rigged) but the net results show up. It would be a fascinating achievement in many countries where government-aided corruption rules. The system is trusted but the participating entities do not trust each other.
Why do we need trustless ecosystems?
I think where we need to start from is for us to rethink where (and why) we may need to enter into a trustless transaction and then work backwards to see if distributed ledger will work, rather than trying to put distributed ledgers in everything. This is where smart contracts come in. If we are able to record information of significance to parties in a contract, if that information remains immutable (without the need for a central regulator) then decisions can be taken (automatically) on such information and both parties can agree on such decisions without running to an arbitrator. When you look at it in such light, you will realize that it has the power to revolutionize how insurance (and claims) are dealt with.
If you can have a system, which understands the terms of the insurance and the conditions of claim, automatically, the cost of administration in insurance industry would dramatically change. If you can then feed this information from devices automatically rather than entered manually, you can further streamline the experience. Imagine your car is insured and having IOT devices monitoring it. You veer off the road and caused damage – the IOT devices note your speed, break application, steering movement, time of day, location, traffic, road surface condition, weather coditions etc and can decide (or at least recommend) if your claim (“another driver pushed you off the road in a case of road rage”) is valid. It may even top it off with a video of the incident! If your claim is decided to be valid, it is honoured automatically – without you needing to separately prove to the insurer whether you were being truthful or not.
We have the answers - let's roll
No - we don't have all the answers, yet. There are two aspects to consider. As I said already, the volatility and insecurity of digital currencies, combined with public lack of faith expressed by trusted institutions has given distributed ledger (blockchain) a bad reputation. It is an uphill battle to build a user experience on an untrusted technology where the core premise is that the technology is most trustful component in the eco-system!
The second aspect, which is a question of maturity, will hopefully be addressed in parallel.
An anecdote: On the mainframe, COBOL (Common Business Oriented Language) was first introduced in 1950s to help the bankers write software for the banking system. The programming language was kept simple, using keywords which are similar in structure and usage as in everyday English.
For example, consider the code fragment for adding one to a number:
ADD 1 TO A GIVING A (far easier to read/write for a non-programmer than) vs A++ (built by programmers for programmers).
In a well-written program you can “guess” what’s going on and it is enforced through the usage of keywords. The people who wrote the programs knew what was supposed to be done by the programs. This resulted in a majority of the programs in mainframe being written in COBOL, even though it may not be the best programming language (from a technical features perspective) on the mainframe. The idea is that anyone could learn to program easily and people who coded programs had business knowledge.
This is relevant because today we are at the threshold of one more such epic decision. A smart contract is essentially a software program with a bunch of conditional statements and actions pertaining to it, which replicates a legal contract. However, the people who are writing these contracts are software programmers who have no formal understanding of how the contract was supposed to work. Anything which is “obvious” to a lawyer (and hence not documented separately for the programmer) will most likely not be programmed. This could lead to "smart contracts" with legal loop holes which can be exploited. Any such exploitation will actually harm the reputation of the underlying technology whereas the technology was not to blame – it is how it is applied.
What is the way out of this?
In my opinion there are two big steps that needs to be taken to address each of these aspects.
Firstly, for a successful distributed ledger-based application to work, you need a trusted system that can be used by trustless participants. Trust is difficult to generate – which is why trusted institutions of today (e.g. Governments, Industry organizations, National Banks) should setup the systems, run it for a limited period until the society learns to trust the system and then walk away from it. Such institutions should not have a commercial interest in the system or it will be difficult for the system to be trusted and it will be difficult for them to walk away from the money – this is why it has to be one of such organizations and not big corporations. The big corporations can help generate trust in the system by being participants and users but not by being providers of the system. It is a different mindset and approach than the currently implemented systems. In my opinion, this needs to change to accelerate adoption.
Although it is a bit ironic that the technology was originally proposed to avoid such central trusted authorities, it needs their help. But thinking deeper you will realize that this is not so strange – without it, the adoption cycle would just be longer. Do you think the early rich men trusted the first bankers – no way. But eventually the bankers were able to generate trust and holding the money of all the rich today. It took time but we got there.
A contract with many legal loopholes is not really very smart – even though it may be built using latest technology.
Secondly, writing smart contracts should go out of the hands of people who do not understand legal contracts. A smart contract should not just be smart in the use of technology but also smart from a legal perspective. A contract with many legal loopholes is not really very smart – even though it may be built using latest technology. If this means a legal training for all the software developers involved in writing smart contracts or new way of representing smart contracts by lawyers – it could be a choice. But the end goal is unmistakeable. The contract should be legally watertight. Any NLP algorithm that can translate an existing legal contract to a smart contract would be worth a fortune at this moment!
Feedback
This is my perspective on blockchain. I am sure you may have a different view and I would like to hear from you. Leave your comments!