How is a 'managed' permissioned blockchain different from a relational database service?

Question

How is a managed and permissioned blockchain (Like the hyperledger blockchain service offered by IBM bluemix) different from a relational database service ?

Answer 1

The value proposition of permissioned blockchain systems over traditional databases is simple: integrity through cryptographically signed history. What's stopping twitter from editing my tweets and making it seem like I said something I didn't say? Little to nothing.

This is where a blockchain approach comes in. If twitter stored tweets in a blockchain that others could copy, then any modifications that twitter made to this chain would be caught. Blockchains preserve the integrity of the data within a database. They prevent people from cooking the books. This is of extraordinary importance and value in certain application areas.

In general, private or permissioned blockchains can be seen as a new method for ensuring consistency in a distributed database, even if that database is an environment of perfect trust. There is an equivalence between how a blockchain prevents two transactions spending the same prior transaction output, and how multiversion concurrency control (MVCC) in a relational database prevents two transactions modifying/deleting the same database row. From the perspective of the MVCC storage layer, there is no such thing as modifying a row in place.

This means that a permissioned blockchain can provide the same kind of concurrency control as MVCC, but in a distributed database which can be written to from many different locations simultaneously (multi-master replication). A blockchain is certainly not an ideal solution for all scenarios like this, but if the row size is small, transactions affect few rows, and conflicts only happen if someone is misbehaving, a permissioned blockchain can maintain provable consistency through a single hash across many nodes of a distributed database, all of which can write to the data.

When it comes to maintaining a shared database between entities with imperfect trust, permissioned blockchains have some great additional features:

• The database can contain application logic in the form of constraints on valid transactions. This kind of constraint goes beyond regular database stored procedures because it cannot be circumvented under any circumstances.

• The database has per-row permissions which use public key cryptography. Furthermore, every transaction presents a publicly auditable proof that its creator(s) had the right to delete/modify its prior rows.

Of course, not by coincidence, these are very relevant features for inter-company financial ledger databases. Signed commitments with immutable history are all that’s required for proof of integrity. Moreover, assuming commitments are immutable (transactions can only be reversed by adding a new commitment that reverses the actions of the previous commitment), you only need to keep track of the most recent commitment.

If the commitment signer is a known entity, a single honest "auditor" is all that's required to keep the commitment signer honest. Anyone closely watching the signer will be able to easily prove the signer modified the history.

Another use case is where the permissioned participants are a limited group of cooperating parties, where there is no particular enduring trust. The NASDAQ example is this use case. A known set of participants who currently remove the trust requirements by manual records (usually spread sheets) and expensive lawyers. A blockchain style shared database, whilst slower than an SQL DB, solves the proof of integrity in this case both faster and less expensively than the current manual/legal processes.

Further reading:

• Ending the bitcoin vs blockchain debate
• Blockchains vs centralized databases

Attribution: Parts of that answer where authored by Greg Slepak, Eric Lombrozo, Gideon Greenspan, and Ron OHara at Bitcoin Stack Exchange under the terms of CC BY-SA 3.0.