We all can agree that Blockchain is the new Buzz word. Everyone, and I am not saying this lightly, literally every big organisation has advertised an intent to do something in Blockchain.
And why wouldn’t they? We have advertised blockchain as this God Almighty solution to avoid data hack, corruption and provide all in all transparency. While this is all true for a decentralised public blockchain network, it is absolutely naive to assume that private blockchains are safe and secure.
Talking about India, in today’s news, Niti Aayog signed a Statement of Intent with a government backed fertiliser company for a blockchain application. A few days ago, the news that we did not report that created buzz around the country, says Niti Aayog is working on a blockchain solution called IndiaChain. The reason we didn’t report it is because I personally don’t prefer to rely on anonymous sources unless they are my anonymous source. Till the time we can verify it ourselves, we will not publish it.
Coming back to Blockchain, while the news of actual projects make us truly happy, blockchain isn’t all that cool to solve all your problems. Heck, it isn’t even truly immutable. Let us understand it further.
Contents
Blockchain isn’t the Coolest
Almost everyone who can describe blockchain will include the word immutable in the description. In plain english, it means something that cannot be modified or changed. But over time we have come to understand that while immutability can be easily achieved in case of a decentralised public network, it can only be achieved in a private blockchain, if all nodes are on their good behaviour.
Before we deep dive into it, let us briefly talk about the Elephant in the room. Blockchain.
Blockchain in Brief
A blockchain runs on a set of nodes, each of which are controlled by individuals, companies or organisations. These nodes are connected by a Peer to Peer network so no single node is the central point for control. Each node can create and digitally sign transactions, when they meet the rules of the blockchain, they are broadcasted to other nodes.
The other nodes then verify the transaction based on certain tests like whether it is conflicting another transaction, its following the rules and is it digitally signed. If these parameters are confirmed, the transaction moves to a memory pool.
At periodic intervals a ‘block’ is generated which then picks up the transactions from the memory pool and broadcasts them to the network. Since each block contains a set of data that links to the previous block, it is literally called the ‘Block-chain’. These blocks then go through a verification process from other nodes and once approved, the block is inserted into the chain permanently.
Now that you understand Blockchain, let us talk about immutability. Can we actually change the data on Blockchain?
Are Blockchains Actually Immutable?
Before we debate whether or not permissioned or private blockchains are perfect, we should talk about the security of public blockchains. Most of the Blockchain advocates will tell you that Public Blockchains are the Holy grails of our decentralised future and many actually can be that. But a lot of the public blockchain cannot be truly immutable.
For any public blockchain that uses proof-of-work mining, the biggest security risk is if someone is able to take control of 51% of hash power required to mine that particular cryptocurrency. We have seen that happen a lot lately. Recently three cryptocurrencies were hacked within a week. The crypto51 app tracks the approximate cost to gain 51% hash power of a particular blockchain network. It would cost you less than $350 to actually gain control of Bytecoin network. There are some coins which only require a Dollar to gain control of. A single USD.

The problem is not that these networks cannot be hacked. The problem is that these attacks can actually wipe out transactions, which beats the so called immutability. How you ask? Well, they have to use the hashing power to mine a secret chain that excludes all the other transactions but their own. Eventually with over 51% hashpower within their control, they can publish the secret chain and the other blocks in the chain will be discarded alltogether – aka wiped out.
Rewritable Private Blockchains
Private blockchains are the need for the governments and institutions. They are cheaper to run and immutability can be achieved as long as all the signees/nodes act with good behaviour. They are cheap to run because private blockchains will not need to waste resources on mining to publish a block. The nodes can verify the digital signature of the transactions and push it. The block is generated based on the verification from all nodes.
Now, the problem of immutability. This is the example from an article multichain, Six hospitals are running a private blockchain to track the data on infectious diseases. One fine day, one hospital accidentally entered incorrect or erroneous data. A few phone calls later, the IT department in all hospitals agree to ‘rewind’ the blockchain by an hour so the erroneous data is deleted. Can we call this immutable? Certainly not.
In an entirely simple way, a private blockchain is only secure as long as none of the participants go rogue. There could be legal agreements made to ensure that between the participants. But what if they collectively decide to alter the data? Is there a way to stop them? Not really. So, how is it any different than the current systems?
The answer is it is cheap and fast. Blockchains are great to maintain a database because there is no single central point, the cost of deploying and maintaining it is low. With the right amount of contracts, we can believe that the nodes, the organisations will behave ‘nicely’ and not alter the data. But do we really need it everywhere?
Do you need Blockchain?
Blockchains are good. They are the cheap alternatives to the current database handlings systems. But the current systems – relational databases have years and years of development behind them. So unless your business meets a few conditions, you really do not need blockchain.
According to an article on Coincenter, you can think of deploying a blockchain only if you require these five things. There are more, but the five are the most important
- Do you need to a structured Database? Does your business really need a structured database?
- Do you need multiple writers on that Database? Are there more than one entity that will create transactions on the aforementioned database?
- Absense of trust? You need entities that do not trust each other. To ensure the transactions are verified appropriately.
- Disintermediation. You rely on a bank to confirm if a transaction is possible. That is the trust you keep on bank which is an intermediary. Now, do you want to get rid of trusted intermediaries? If so, are you ready to have multiple non-trusting entities to ensure the correctness of a transaction on your database?
- Transaction Interaction. Whether the transactions done on your blockchain will be interacting with each other or not?
So, if all the above are required, you can start thinking about deploying a blockchain. Otherwise you’re better off with the current systems available.
Now, for a minute, think about whether or not, the Government bodies in India need a blockchain? If Niti Aayog is partnering with one company, to do a Proof of concept of using blockchain for faster disbursal of fertiliser subsidy, we must ask whether they need it?
News reports say that currently it takes 2-3 months due to a cumbersome process of approval, And blockchain can make it faster and efficient. But can relational databases not achieve the same result? A few integrations, a better process flow and participation from all involved entities, if you get this, you can do it with relational databases too. You do not need a newly deployed solution.
As I said, blockchain is the new buzzword and we are still quite far from truly achieving the most out of distributed databases. Always ask the question, DO WE REALLY NEED BLOCKCHAIN HERE?
What do you think of Blockchain? Let us know in the comments below
Comments are closed.