5 ways in which blockchain is NOT just a slow database.
Recently, there has been a proliferation of articles denouncing distributed ledgers as ‘slow’ database technology. That just isn’t true, and here are 5 ways that we can compare and contrast blockchain vs database technology.
Reason 1. A blockchain is a ledger
According to Google, synonyms of ledger include:
book, account book, record book, register, registry, log; records, archives, books; balance sheet, financial statement
You’ll notice the terms that are conspicuous by their absence. A ledger is a summary of things, a ‘log’ or ‘record’ or ‘account book’; it is not a space to store things (e.g. a database). A distributed ledger should be used to keep track of things, to register and record their movements and histories. A distributed ledger shouldn’t be used to store data / files or assets.
A distributed ledger has the same relationship as your account book with your bank. The account book keeps the record, the bank keeps the cash.
Database = A system to store data.
Blockchain = A ledger to record and log movements.
Reason 2. A blockchain is intentionally immutable.
A database is intended to be an efficient way of storing and retrieving data. For that reason, CRUD operations are optimized so that you can ‘Create’, ‘Read’, ‘Update’ or ‘Delete’ your data as easily as possible. This way you can have cloud infrastructures provide services to millions of people (often simultaneously).
A blockchain is for making sure that you have a reliable and immutable audit trail of something. A blockchain does not make data more ‘trustworthy’, it keeps an immutable log of everything that happens to something (mapped to an on-chain asset).
A database does not want to keep an immutable log of every transaction for it would massively impact performance.
A blockchain is designed to keep an immutable log of every transaction.
Database = Fast efficient data storage.
Blockchain = Secure, immutable ledger.
Reason 3. A blockchain is distributed by its nature.
Yes, there are distributed databases.
No, blockchain is not simply a bad distributed database.
The immutability and decentralization of blockchain means that it can be useful as a ‘shared’ record of things between actors that do not trust each other but do trust the blockchain.
A distributed database (with its CRUD operations) will either need to be heavily permissioned, or controlled by a centralized party. This is to stop party A from maliciously (or accidently) tampering with data from party B. A database is designed to have a database admin, to be an efficient controllable tool to store the data of an organization. There are issues in creating ‘mutually beneficial’ datastores, and blockchain is a valid technology to log and report on assets that are shared between non-trusting parties.
Where you need to share accounts or a ‘ledger’, a blockchain is more appropriate than a database. Where you need to share ‘data’, a database is more appropriate. In most real life scenarios, you will probably want to do both.
Database = A distributed store for sharing data.
Blockchain = A shared ledger that cannot be tampered with.
Reason 4. A blockchain is not ‘slow’ or ‘inefficient’.
Bitcoin is built on blockchain but blockchain is not bitcoin. The underlying technology ‘blockchain’ is an umbrella term for a way of recording transactions in a way that you cannot later edit or remove. There are different ‘consensus’ algorithms which is the way that the blockchain is programmed to accept ‘new’ transactions. It is essentially a security layer to stop malicious actors from hijacking the blockchain.
The big breakthrough when Bitcoin was invented, was the use of Proof-of-Work as a probabilistic solution to the Byzantine Generals Problem as described in depth by Satoshi Nakamoto in this e-mail.
To hijack a network you would need a clear majority of the computing power, which in a large-scale public network is improbable at best. If 51% of the network was in agreement about the data that had gone before it, 49% of the computing power would not be able to alter those transactions. In fact, the surge of popularity for blockchain is due to the fact that bitcoin which is now a famous and high-profile target, has so far proved to be a robust technology.
Bitcoin was ‘designed’ to be CPU intensive and intentionally complicates the algorithms used in mining. A blockchain is not ‘slow or inefficient’ unless it is intended to be, and in this case it was a design feature based on security. The security has proved extremely robust in a hostile environment. There is nothing inherent to blockchain that makes it ‘slow and inefficient’, there is simply a high profile example of a blockchain that intentionally uses a lot of computing power to improve the security of its network.
Database = Has centralized security designed by DBA / network administrators.
Blockchain = A protocol that is designed to be robust, at scale.
Reason 5. A blockchain is a term that has many sub-genres.
“Databases are rubbish.”
Quite a ludicrous and sweeping over-generalization covering an immense number of separate systems designed for different purposes.
“Blockchain is rubbish” is an equally ludicrous statement.
Some uses for blockchain are poorly thought out and badly implemented. But there are many different types of blockchain to be applied in different situations.
Private blockchains can be fast efficient ledgers for sharing information between a small network.
Public blockchains can be slow trustworthy ledgers to providing access to public records.
In between these two types there are exists a massive spectrum of potential implementations; from financial instruments through to provenance tracking. None is right or wrong, they are simply different ways of applying distributed ledger technology to achieve a purpose.
Just like MySQL is worse than MongoDB for big data; there are no ‘good’ and ‘bad’ databases, simply technologies applied for differing purposes, and the trick as ever is to make sure that you pick the right one.
Blockchain is the same, so the next time someone tells you, ‘Blockchain is just a slow, crappy database” then do us all a favour and point them towards this blog.
Database = Many different flavours, many different purposes.
Blockchain = Many different flavours, many different purposes.
Our training course!
Build with Blockchain is a training course getting hands-on with real practical applications of Distributed Ledger Technologies (DLT).
Led and designed by Dr Keir Finlow Bates, a serial blockchain inventor and leading figurehead of the blockchain community, we will take you through the code line by line, and soon you too will be able to deploy production ready private blockchain networks and understand what is going on behind the scenes.
The course can be found here: https://www.udemy.com/course/1918684. For a limited time only interested students add me on LinkedIn: Author LinkedIn link will be provided with a free access coupon to join the course! Please mention the course in your connection request.
At chainfrog we’ve been building and deploying scalable production blockchains for over 2 years, so if you are in need of some consultancy you can also get in touch either via email edward (at) chainfrog.com. These are exciting times and I hope you take something away from my article, feel free to connect with me on my twitter and LinkedIn accounts.