Blockchains are essential for some projects and poorly suited for others. Using them where it is not needed could be a costly mistake.
BY GIDEON GREENSPAN / July 26, 2017
Many different use cases have been proposed for blockchains, relating to financial assets, health records, identity management and supply chains. But when examined in the cold light of day, many of these applications do not need a blockchain at all, and could be implemented perfectly well using a regular relational database. By that I mean either big iron behemoths like Oracle and SQL Server, or for the more adventurous and open-minded, MySQL and Postgres. So before we even start talking about blockchains, it’s important to set one thing straight:
If your requirements are fulfilled by today’s relational databases, you’d be insane to use a blockchain.
Why? Because products like Oracle and MySQL have decades of development behind them. They’ve been deployed on millions of servers running trillions of queries. They contain some of the most thoroughly tested, debugged and optimized code on the planet, processing thousands of transactions per second without breaking a sweat.
And what about blockchains? Well our product, MultiChain, was one of the first to market, and has been available for just over two years. Despite that young age, it’s extremely stable, because we built it off Bitcoin Core, the software which powers bitcoin. Nonetheless, given a choice between two equally suitable technologies, why use the one that’s still in its diapers?
So am I saying that every purported blockchain use case should be built using tried and trusted relational databases instead? Absolutely not. There are certainly some applications whose ideal architecture has a blockchain at its core. But before you embark on that shiny blockchain project, you need to have a very clear idea of whether that applies in your case.
There are a bunch of conditions that need to be fulfilled. And if they’re not, you should go back to the drawing board. Maybe you can define the project better. Or maybe you can save everyone a load of time and money, because you don’t need a blockchain at all.
Do you need a blockchain?
- The database
Here’s the first rule. Blockchains are a technology for shared databases. So you need to start by knowing why you are using a database, by which I mean a structured repository of information. This can be a traditional relational database, which contains one or more spreadsheet-like tables. Or it can be the trendier NoSQL variety, which works more like a file system or dictionary.
A ledger for financial assets can be naturally expressed as a database table in which each row represents one asset type owned by one particular entity. Each row has three columns containing: (a) the owner’s identifier such as an account number, (b) an identifier for the asset type such as “USD” or “AAPL”, and (c) the quantity of that asset held by that owner.
Databases are modified via “transactions” which represent a set of changes to the database which must be accepted or rejected as a whole. For example, in the case of an asset ledger, a payment from one user to another is represented by a transaction that deducts the appropriate quantity from one row, and adds it to another.