Private Blockchain vs. Centralised Database: When to Use Each One?
Private Blockchain vs. Centralised Database: When to Use Each One?
Private Not Public
Before I begin, I’d like to clarify the difference between a public and private blockchain. The overarching distinction is between who is allowed to participate in the network. As the name suggests a public blockchain is completely open and anyone can join, Bitcoin being one of the largest public blockchain networks. A private blockchain network requires an invitation and must be validated by either the network starter or by a set of rules.
From Diamonds to Turkeys
According to Pitchbook there are over three thousand private blockchain companies and to me that number seems low. In the past few months I’ve seen blockchain projects focussed on diamonds, art, loans and even Thanksgiving turkeys.
All of these businesses share one underlying assumption; we think the blockchain is better suited to this than a centralised database. As an investor, founder or potential employee this is a crucial hypothesis to test. A simple way to do this is to look at the four-key differences between blockchains and centralised databases.
- Disintermediation (removal of intermediaries)
Let’s start with disintermediation. Blockchain easily wins out here. The crux of blockchain is enabling a database to be shared across multiple parties with an element of trust and importantly without a central administrator. This is made possible by the blockchain transactions requiring their own proof of validity and proof of authorisation. Transactions on the blockchain can be verified and processed independently by “nodes” which ensures all the information stays in sync.
Why is this important? The contents of a centralised database are stored in memory on a system which anyone with sufficient access can corrupt or destroy. Using blockchain alleviates the dependency for a human organisation to be in charge of this data.
Again, why is this important ? My bank has never stolen my money and I know Facebook is super careful with my data (cough). Joking aside the hiring and expense to set up a sufficient human organisation to protect and control important data is huge. Blockchain offers a cheap and easy alternative to replace these organisations. Blockchain one, regular database zero.
Privacy is not something you often hear mentioned in the same sentence with blockchain. Unless, that is, the sentence goes: “due to every node verifying every transaction on a blockchain we sacrifice a large element of privacy”. These nodes require visibility into the current blockchain state, requested modification and digital signature. As you can imagine this would not work for many applications such as financial institutions which tend to avoid full transparency at all costs.
This problem is solved nicely by a regular database as the transaction need only be visible at that specific location rather than across the network. A central authority can control the transactions a particular user can undertake including read/write requests whereas a blockchain can be write-controlled only.
Recently we’ve seen developers attempt to solve this problem by allowing you to transact under multiple blockchain addresses or using techniques such as zero-knowledge proofs. This comes at a cost as the more you want to hide on the blockchain the more compute power is required to verify the transactions. Blockchain one bygone database one.
“I’m going to go out on a limb and say for the forseeable future, blockchains will be slower than centralised databases.”
This leads nicely into performance. Without wanting to cause a furious storm of outrage I’m going to go out on a limb and say for the foreseeable future blockchains will be slower than centralised databases. Simply put, when processing a transaction, a blockchain has to do the same as a regular database, plus three more tasks.
- Digitally signed transaction. Each blockchain transaction must be signed using a cryptography scheme such as ECDSA. The creating and verification of these signatures is a core element to the speed limitation of blockchain.
- Consensus approval. In any distributed database, compute power must be expended to ensure the nodes in a network reach consensus. This depends on the consensus mechanism and to be fair, regular databases have to deal with conflicting transactions, but these request queues are much more profound on a blockchain.
- Centralised databases process a transaction maybe once or twice. On most blockchain networks the transactions are processed by every node and therefore require more work to achieve the same result.
Painfully, granny’s database has taken the lead by two to one.
We finish this match on the case of robustness. While it is true regular databases offer many techniques for database replication, a blockchain-charged database has a much higher fault tolerance. This is all stems from the final point in the previous section on redundancy. Since every node processes every transaction, no one node is critical to the greater database. The blockchain ensures all the nodes that go down can get back in sync, unlike regular databases which slowly but surely grind to a halt.
This transforms the economics of creating a database. Regular databases require expensive infrastructure to achieve best-in-class fault tolerance which even the leading enterprises can’t get right. With blockchain you can build an extremely robust database with say ten nodes around the world. Coincidently the low cost, high redundancy system isn’t too dissimilar to how Google built its early search engine. Well done Larry and Serge.
Ready to Analyse
We end in a tie ball game which conveniently gives us a lens to analyse our private blockchain projects. Is this an industry which values disintermediation and robustness or is confidentiality and performance the main concern? For example, extremely competitive markets often prefer the privacy of centralised databases. This is made all the more pertinent if there is a neutral central agency where the database can be stored.
There are plenty of areas where blockchain has strong use cases. Supply chain management and provenance tracking has many transacting parties, requires extreme fault tolerance and are subject to high levels of counterfeiting, theft & database corruption. Another example is small financial companies which continually run the risk of being hacked. The blockchain offers a nice solution to avoid the concentration of control and facilitate cheap and quick deployment of such financial systems.
At the risk of sounding obtuse, if trust, robustness and to a lesser extent security aren’t the primary drivers of a market than a private blockchain most likely isn’t the best nor necessary technology to serve it. Think twice before putting that turkey on the blockchain.