Some people in the blockchain/distributed ledger space have tried to advertise blockchains as a “better database” solution that should assume a role like SQL databases within an enterprise. I often try to explain to people that blockchains/distributed ledgers are different than a database. Though they are superficially similar, they have different use cases and tradeoffs. You should probably use a blockchain if you need consensus or have some sort of tension among the actors contributing to the distributed ledger. That said, the more familiar I become with the way large enterprises work, the more I see a role for a “fool proof” database, which I suspect is what people building internal blockchains are trying to sell
Broadly construed, blockchains can do a lot to ensure the integrity of a ledger by creating conditions for the network to evaluate each claim submitted to it. People trust the ledger because they trust the process that leads to the validation of the claims. Though one might assume that the same type of thought would go into the important databases that drive Fortune 500 companies, I’ve encountered a startling number of bad architectures leading to costly mishaps. Perhaps the most appalling anecdote of poor database usage came from the Sakurity blog when, last year, Egor Homakov discovered a way to create unlimited balances on Starbucks gift cards by exploiting a race condition vulnerability: http://sakurity.com/blog/2015/05/21/starbucks.html. Race conditions can occur when a program has to deal with many operations executing concurrently.
In the Starbucks case, Homakov tried to merge values from one gift card to another online. The code on the Starbucks site checks the balance of a gift card and then transfers it. However, in between the checking and the transferring, the money is transferred elsewhere. If the transfer does not happen atomically, and two concurrent transactions are processed, credit can be “created” and issued to the cards rather than transferred between them.
To explain the problem, say there are two transactions, tx1 and tx2. If the program executes in this order, you have a problem:
tx1: check if A has a balance > 10: yes
tx2: check if A has a balance > 10: yes
tx1: Ok deduct 10 from A! Balance is now 0
tx2: Ok deduct 10 from A! Balance is now -10
tx1: Ok credit B with 10!
tx2: Ok credit C with 10!
Indeed, after six tries (there is an element of randomness to race conditions) Homakov was able to combine values (rather than transferring them from one to another), turning two of his $5 gift cards into $15 gift cards.
The tragedy of the Starbucks episode is that databases were designed precisely to solve issues like these. One of the first things taught in classes on databases is "transactions" and how to deal with the very scenario laid out above. To combat these scenarios, most databases dealing with financial transactions exhibit a property called ACID: atomicity, consistency, isolation and durability. In concert, these features ensure that there is little room for an inconsistent state that would render the types of flaws seen in the Starbucks case.
And, so, I think there has been a bit of confusion as to the benefits of blockchains in place of a traditional database. I think many people conflate blockchains with one of their features: correctness by construction. When a database has correctness by construction, a lot of low level operations are encapsulated into high level operations which are harder to get wrong. Blockchains aren’t designed to serve as conventional database alternatives: their structure is complex compared to what a database might need to succeed. However, a blockchain does prevent the types of basic errors seen by executives at Starbucks by employing a robust method for evaluating and ordering transactions.
A blockchain may not be an appropriate substitute for SQL databases, but consider that it ensures better transaction construction than some multi-billion dollar companies have been able to buy. Though the case for blockchains as a SQL database alternative is very weak, there is a strong argument for a better type of databases that harbor correctness by construction.