In last few posts at TheBlockchainAcademy.com, we have already observed that blockchains are often over-hyped enough to let everyone climb on the rope, especially the start ups looking for harnessing the blockchain technology sooner. Well, everyone who is thinking to set up a start-up in the blockchain space must read this post, since the industry still seems in its infancy. Everybody is grasping for the buzzword that may, in reality, be well-sorted with the relational database and it can be there is no need for the blockchain in the concept. All of us, being a part of the industry, are waiting to have a clearer understanding of where exactly the blockchains can genuinely add value in an enterprise project, and where we can just have a useless outcome. This blog sets out to define the scenarios which become the basis of making this difficult decision.
If your project requirements are met by relational databases available today, don’t be insane to initiate a blockchain project
Why is this so? This is because products like Microsoft SQL and Oracle hold decades of rich development behind them. They have deployed on millions of servers that run trillions of queries. They have some of the most comprehensively tested, debugged and optimized codes, processing thousands of transactions every second without blinking an eye.
Does this mean blockchains are useless?
Absolutely not. However, before you think of embracing the shiny blockchain project, you must be very clear about the purpose. There are certain scenarios that must be fulfilled to have a worthy blockchain project. If these are not fulfilled, maybe you need to redefine the project, or simply save time and lots of money by dropping the idea of having a blockchain for your project, since you don’t need it at all.
1. The Database
Here is the first rule. Blockchain is a technology for shared databases. Start by determining why you are using a database, by which I mean a structured repository of information.
2. Multiple Writers
Blockchain is a technology for databases having multiple writers. It means there should be more than one entity generating the transactions that alter the database. In majority of the cases, the writers also run nodes which carry a database copy and transmit transactions to other nodes in a peer-to-peer manner.
3. No trust
If database is being written by multiple entities, there should be some level of mistrust among the entities. In simpler words, blockchain is the technology for databases having multiple non-trusting entities or writers. You might wonder that mistrust can only be present among organizations like banks, and companies operating in a supply chain space. However, mistrust can also arise in a single organization, such as between divisions or departments. By mistrust, I mean one user is not willing to let another change the database entries which it owns.
Blockchain disqualifies the need for trusted intermediaries, through enabling database having multiple non trusting entities to be changed directly. Transactions are independently verified and processed by each node that maintains a database copy. The question to ask is that do you need such disintermediation for your project use case? Good reasons to consider blockchain based database over a trusted intermediation may include lower costs, auto reconciliation, faster transactions, new regulation or just an inability to have a suitable intermediary.
5. Transaction Interaction
Blockchain makes sense for the project having databases shared among multiple writers, who don’t trust each other and modify database directly. However, it is still not enough. Blockchain truly shines when certain interaction is found between transactions created by the writers. Interaction, in its fullest sense, implies that transactions created often depend on one another. Due to dependency, the transactions belong together in a single shared database.
So, if your project doesn’t meet any of these scenarios, you should not consider a blockchain, or else it would simply be a useless blockchain project. If any of these scenarios is absent you can think of:
· Regular file storage
· A centralized database
· Master-slave database replication
· Multiple database which users can subscribe
If your project fulfills these scenarios, you need to define the rules of your application in terms of the transactions that database follows. You must be confident regarding your validators and the ways to define distributed consensus. And lastly, if you want to develop a shared ledger, you must know who is going to back up the assets represented by the ledger.
Copyright 2017 Bryant Nielson.