Blockchain, Blockchain ! The buzz continues to spread from coffee machines to boardrooms. Everyone I speak to nowadays is eager to know how to leverage Blockchain tech and what’s in it for them.
A key question in front of us as solution providers is when to choose Blockchain (and when to stick to relational databases) and more importantly which use case to fund/invest.
Based on my experience of Blockchain technology, if your use case meets all the conditions below, using a Blockchain makes business sense:
- A Shared Database: A Blockchain is a distributed ledger. The data contained in a Blockchain is replicated across all nodes within the network and is therefore shared. First step would be to determine if there is a genuine need for data sharing across the entire network.
- Multiple Writers: In a Blockchain, the database is written by multiple writers simultaneously. These writers could be a bank’s customers initiating payments, traders trading in a exchange, ATM/POS transactions, multiple companies updating their records in a government portal etc.
- Lack of Trust: Does your use case involves multiple users that trust each other? Let me ask it differently. Is one user willing to let other users modify the database entries it owns and is he/she blindly trusts the ‘read-only’ information provided by other users? If your answer is a clear NO, then Blockchain can be the answer. But everyone trusts a Blockchain as transactions are confirmed by ‘autonomous’ nodes (that do not trust each other) and considered immutable.
- No need for a central intermediary: If all we needed was a solution that let’s multiple non trusting writers update a shared database, then having a central intermediary that is trusted by all writers could have solved the problem. Everyday we interact with such central intermediaries e.g. Uber, commuter train companies, our banks, government etc. Govt issues us identity documents that are acceptable to all, a bank’s confirmation on a successful transaction is treated as a gospel of truth. Blockchain removes the need of having a central intermediary by its inherent design of immutability, block confirmations, distributed consensus. The transactions performed on a blockchain can thus be trusted by multiple writers who do not trust each other but trust a Blockchain. Do you really need disintermediation and does not having one makes it cheaper , faster , more efficient for your customers.
- Transactions Linkage: It means that transactions created by different writers often depend on one other. For example, A sends some money to B who in turn sends it to C. So, C’s balance is dependant on A. Because of this dependency, the transactions naturally belong together in a single shared database. Taking this further, one nice feature of blockchains is that transactions can be created collaboratively by multiple writers, without either party exposing themselves to risk.
- Authoritative Final Transaction Log: All nodes agree to the contents of this log. For a new node, downloading the entire previous blockchain is a starting point. If a node is down for some time, it can download the incremental blockchain to know the latest contents of Blockchain. In a peer-to-peer database with no central authority, nodes might have different opinions regarding which transaction to accept, because there is no objective right answer. By requiring transactions to be “confirmed” in a blockchain, we ensure that all nodes converge on the same decision.
- Guaranteeing the represented assets: Who stands behind the assets represented on the blockchain? If the database says that I own 10 units of something, who will allow me to claim those 10 units in the real world? Who do I sue if I can’t convert what’s written in the blockchain into traditional physical assets? Is it going to be a bank, a stock exchange, a mineral company? It all depends on the type of asset that is recorded on the Blockchain.
Conclusion: If your use case fulfils the all of the above criteria, using a Blockchain makes sense. Go ahead and invest in it, Blockchain is worth it.
(Disclaimer: Inputs from Gideon. Views expressed are personal and may not necessarily reflect views of my employer.)