<p>Private blockchains can be seen as a new method for ensuring consistency in a distributed database, <em>even if that database is an environment of perfect trust</em>. There is an equivalence between how a blockchain prevents two transactions spending the same prior transaction output, and how <a href="https://en.wikipedia.org/wiki/Multiversion_concurrency_control" rel="noreferrer">multiversion concurrency control</a> (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.)</p>

<p>This means that a private 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 (<a href="https://en.wikipedia.org/wiki/Multi-master_replication" rel="noreferrer">multi-master replication</a>). 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 private blockchain can maintain provable consistency (through a single hash!) across many nodes of a distributed database, all of which can write to the data.</p>

<p>When it comes to maintaining a shared database between entities with <em>imperfect trust</em>, private blockchains have some great additional features:</p>

<ul>
<li><p>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.</p></li>
<li><p>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.</p></li>
</ul>

<p>Of course, not by coincidence, these are very relevant features for inter-company financial ledger databases.</p>

<p>There's a more detailed explanation in my post: <a href="http://www.multichain.com/blog/2015/07/bitcoin-vs-blockchain-debate/" rel="noreferrer">Ending the bitcoin vs blockchain debate</a>.</p>

CC BY-SA 3.0
2015-07-23T12:33:55.040Z
Blockchains don't provide MVCC at all. There can not be two writers at the same time and reading an out of date snapshot is pointless if you need to create a new transaction that depends on the latest information. Yes you can have multiple readers, but that doesn't need MVCC. A simple append-only CSV text file can do that!
Jannes
CC BY-SA 3.0
2015-07-23T12:35:26.950Z
The multi-master is nonsense too. Only one master can append at the same time, so you need some locking mechanism or some other way to pace multiple masters. Again: the same can be done with an append only CSV file. (No I'm no suggesting actually using CSV for this.)
Jannes
CC BY-SA 3.0
2015-07-23T13:53:48.887Z
Hi Jannes. Did you read the article? I am saying that there is a theoretical equivalence between what blockchains do and what MVCC does, if you consider a UTXO as a database row. I guess I should explain more inside my answer here instead of just linking to the blog piece...
Gideon Greenspan
CC BY-SA 3.0
2016-05-25T12:25:20.127Z
@Jannes, I know this post is almost a year old, but reading through it, I'm curious. How is the "append-only" part of the CSV text file enforced? In otherwords, how do you enforce that it is append-only? Some sort of hash chaining with a known ending point?
mikeazo
CC BY-SA 3.0
2017-12-20T07:40:37.627Z
By including a hash of the previous state of the csv file (or the previous line) in each new line. (sorry late answer).
Jannes
CC BY-SA 3.0
2015-07-21T05:27:31.240Z
2015-07-23T14:06:15.360Z
2015-07-23T14:06:15.360Z
Gideon Greenspan
<p>Researcher Arvind Narayanan stated his opinion on this matter in his post <a href="https://freedom-to-tinker.com/2015/09/18/private-blockchain-is-just-a-confusing-name-for-a-shared-database/" rel="noreferrer">“Private blockchain” is just a confusing name for a shared database</a>:</p>

<blockquote>
  <ul>
  <li>It is true that adding signatures and hash pointers makes a shared database a bit more secure. However, it’s qualitatively different from the level of security, irreversibility, and censorship-resistance you get with the public blockchain.</li>
  <li>The use of these crypto techniques for building a tamper-resistant database has been known for 25 years. At first there wasn’t much impetus for Wall Street to pay attention, but gradually there has arisen a great opportunity in moving some types of financial infrastructure to an automated, cryptographically secured model.</li>
  <li>For banks to go this route, they must learn about the technology, get everyone to the same table, and develop and deploy a standard. The blockchain conveniently solves these problems due to the hype around it. In my view, it’s not the novelty of blockchain technology but rather its mindshare that has gotten Wall Street to converge on it, driven by the fear of missing out. It’s acted as a focal point for standardization.</li>
  <li>To build these private blockchains, banks start with the Bitcoin Core code and rip out all the parts they don’t need. It’s a bit like hammering in a thumb tack, but if a hammer is readily available and no one’s told you that thumb tacks can be pushed in by hand, there’s nothing particularly wrong with it.</li>
  </ul>
</blockquote>

CC BY-SA 3.0
2017-03-30T07:53:10.267Z
2017-03-30T07:53:10.267Z
dubek
<p>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. </p>

<p>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.</p>

<p>Database transactions needn’t be represented via clunky, inefficiently implemented transition functions (i.e. connecting a block), and the argument that git is more of a filesystem than a database is somewhat irrelevant…the same principles apply to nonhierarchical data structures (i.e. DAGs) subject to arbitrary transition functions (i.e. smart contracts).</p>

CC BY-SA 3.0
2017-01-17T14:44:50.107Z
so then you're saying that a private blockchain *is* better than a database?
smatthewenglish
CC BY-SA 3.0
2015-07-21T06:50:19.163Z
2015-07-21T07:19:21.470Z
2015-07-21T07:19:21.470Z
Eric Lombrozo
<p>It depends on what you mean by "private". The word private is not really associated with Eris as far as I can tell. Rather, the word "permissioned" is used instead, and therein lies all the difference and your answer.</p>

<p>A "private" blockchain might imply a blockchain that is not shared with anyone. Such blockchains would effectively amount to slow databases and nobody would have much need for them.</p>

<p>Eris' value proposition over traditional databases is simple: integrity through cryptographically signed history.</p>

<p>What's stopping twitter from editing my tweets and making it seem like I said something I didn't say? Little to nothing.</p>

<p>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.</p>

<p>Blockchains preserve the integrity of the data within a database. They prevent people from cooking the books. This is of extraordinary importance and value.</p>

<h3>Comparison to git</h3>

<ul>
<li>Git does not have a smart contracts system within its protocol.</li>
<li>Git is more of a filesystem interface, whereas Eris seems more like a database interface, to be used in environments where databases are sometimes used. Git is rarely used like a database.</li>
</ul>

CC BY-SA 3.0
2015-07-21T03:59:49.210Z
A git repository has a chain of hashes as well that asserts history, why is a block chain different to this if you are in an environment without proof of work?
Claris
CC BY-SA 3.0
2015-07-21T04:07:16.227Z
@Bitcoin Possibly protocol rules enforcement? You can also put block hashes onto Factom / Bitcoin to ensure records aren't altered.
ThePiachu
CC BY-SA 3.0
2015-07-21T04:10:12.417Z
@ThePiachu What's to stop me embedding two hashes and just presenting them as fact to different people? A person with one hash can't know that there's another hash with a slightly different preimage somewhere else. This is the same problem as "proving" documents exist with hashes shoved in the Bitcoin blockchain.
Claris
CC BY-SA 3.0
2015-07-21T04:19:53.647Z
I updated the answer with a comparison to Git. Beware that I am not a developer of these systems, so I might be missing some stuff.
Greg
CC BY-SA 3.0
2015-07-21T07:09:15.760Z
@Greg You missed the point I was making by referring to git. Absent the requirement for a trust-less ledger (ie, Bitcoin) you can implement whatever you want in an append-only, signed structure that is audit-able. The end result is simpler, more flexible and quicker.
Claris
CC BY-SA 3.0
2015-07-22T20:50:05.640Z
@Bitcoin Then I am not understanding you, as an "append-only, signed structure that is audit-able" is exactly what we're talking about here with Eris.
Greg
CC BY-SA 3.0
2015-07-23T12:45:03.313Z
@Greg A blockchain is "append-only, signed structure that is audit-able" PLUS much more than that. What banks need is just "append-only, signed structure that is audit-able" and NOT more than that. Git is a beautiful example of that and is a million times simpler than Bitcoin.
Jannes
CC BY-SA 3.0
2015-07-24T01:54:09.687Z
@Jannes Bitcoin and Eris (and any relevant permissioned blockchain) are very different. They use a completely different consensus algorithm. You are free to try to do what Eris is doing with git. Good luck.
Greg
CC BY-SA 3.0
2016-03-22T10:28:53.713Z
"If twitter stored tweets in a blockchain that others could copy, then any modifications that twitter made to this chain would be caught." Isn't the same thing applicable by doing a data diff between two versions of data dumps?
Ramesh
CC BY-SA 4.0
2021-05-15T11:26:41.603Z
@Ramesh Yeah, I don't get that "data integrity" argument. You can achieve the same by giving a third party access to a list of the hashes of your tweets (you would need a little bit more than that if you want to also hide the number of tweets, but that's still feasible). He would then be able to attest the authority did not ponder with your tweets without having himself access to it. You don't need a blockchain for that.
Maxime Rossini
CC BY-SA 3.0
2015-07-21T03:56:40.510Z
2015-07-21T04:19:12.617Z
2015-07-21T04:19:12.617Z
Greg
<p>Blockchain is a mere chain of blocks and this respect is worse than every database on earth. What makes the <strong>public</strong> blockchain unique is the proof-of-work that ensures that thousands of copies of the blockchain are probabilistically  identical all across the globe and with no discrete authority trusted to manage them. A private blockchain is a ledger managed by some authority, so is an abstraction which may be implemented with any db technology</p>

CC BY-SA 3.0
2016-02-22T17:36:57.307Z
2016-02-22T18:02:19.623Z
2016-02-22T18:02:19.623Z
Davide C
<p>The private blockchain should answer to :</p>

<ul>
<li>distributed database</li>
<li>immutability (cannot change the past)</li>
<li>integrity (cannot hack the present)</li>
<li>consensus to validate new blocks</li>
<li>a Turing complete language enabled to allow smart contracts</li>
</ul>

CC BY-SA 3.0
2016-04-15T14:16:18.260Z
This seems related to the topic at hand, but doesn't answer the main point of the question.
Murch
CC BY-SA 3.0
2016-04-15T12:45:03.500Z
2016-04-15T12:46:09.653Z
2016-04-15T12:46:09.653Z
Benjamin Fuentes
<p>Another use case is where the 'permissioned' participants are a limited group of cooperating parties, where there is no particular enduring trust.</p>

<p>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. That is a very expensive and slow process.</p>

<p>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.</p>

CC BY-SA 3.0
2015-07-23T12:40:58.690Z
You're comparing a current (possibly inefficient manual) process with a blockchain. But the question is about the difference between a blockchain and something much simpler than a blockchain. For example Git, or an even simpler purpose built system, possibly relying on SQL (as that is already proven and abundant technology).
Jannes
CC BY-SA 3.0
2017-12-19T05:10:20.003Z
@jannes But can you SQL inject a blockchain?  This question is more complex than you're letting on.  There's a lot of power in having an append only data structure that can't be manipulated right out of the box.
Kelseydh
CC BY-SA 3.0
2017-12-20T07:45:49.663Z
Like git or a systemd journal, or a hash linked list, or an SQL database where each row contains a hash of the previous row.
Jannes
CC BY-SA 3.0
2015-07-21T04:05:39.017Z
2015-07-21T04:05:39.017Z
Ron OHara
<p>Since the banks appear to be currently looking into <a href="http://tpbit.blogspot.ca/2015/06/bitcoin-vs-blockchain.html">the idea of "blockchains" but don't want to be dealing with "Bitcoin"</a>, it seems that there is a lot of hype for private blockchains out there like Eris or Hyperledger. However, a lot of people tend to point out that a blockchain without a currency is essentially "an SQL database".</p>

<p>I'm wondering, does a private blockchain have any advantages over a traditional database solution, or can everything that a private blockchain does be replicated with some effort using a database application?</p>

<blockchain><database><private-blockchains>
Is a private blockchain better in any sense than a database?
ThePiachu
# Is a private blockchain better in any sense than a database?

(Asked by: username_0 on 2015-07-21)

Since the banks appear to be currently looking into [the idea of "blockchains" but don't want to be dealing with "Bitcoin"](http://tpbit.blogspot.ca/2015/06/bitcoin-vs-blockchain.html), it seems that there is a lot of hype for private blockchains out there like Eris or Hyperledger. However, a lot of people tend to point out that a blockchain without a currency is essentially "an SQL database".

I'm wondering, does a private blockchain have any advantages over a traditional database solution, or can everything that a private blockchain does be replicated with some effort using a database application?

**Tags:** blockchain, database, private-blockchains


---

## 7 answers

### Answer by username_5 on 2015-07-21. Score: 9

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.

Database transactions needn’t be represented via clunky, inefficiently implemented transition functions (i.e. connecting a block), and the argument that git is more of a filesystem than a database is somewhat irrelevant…the same principles apply to nonhierarchical data structures (i.e. DAGs) subject to arbitrary transition functions (i.e. smart contracts).

> **Comments:**
> **username_6**: so then you're saying that a private blockchain *is* better than a database?  

---

### Answer by username_7 on 2015-07-21. Score: 9

It depends on what you mean by "private". The word private is not really associated with Eris as far as I can tell. Rather, the word "permissioned" is used instead, and therein lies all the difference and your answer.

A "private" blockchain might imply a blockchain that is not shared with anyone. Such blockchains would effectively amount to slow databases and nobody would have much need for them.

Eris' value proposition 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.

### Comparison to git

* Git does not have a smart contracts system within its protocol.
* Git is more of a filesystem interface, whereas Eris seems more like a database interface, to be used in environments where databases are sometimes used. Git is rarely used like a database.

> **Comments:**
> **username_8**: A git repository has a chain of hashes as well that asserts history, why is a block chain different to this if you are in an environment without proof of work?  
> **username_0**: @Bitcoin Possibly protocol rules enforcement? You can also put block hashes onto Factom / Bitcoin to ensure records aren't altered.  
> **username_8**: @username_0 What's to stop me embedding two hashes and just presenting them as fact to different people? A person with one hash can't know that there's another hash with a slightly different preimage somewhere else. This is the same problem as "proving" documents exist with hashes shoved in the Bitcoin blockchain.  
> **username_7**: I updated the answer with a comparison to Git. Beware that I am not a developer of these systems, so I might be missing some stuff.  
> **username_8**: @username_7 You missed the point I was making by referring to git. Absent the requirement for a trust-less ledger (ie, Bitcoin) you can implement whatever you want in an append-only, signed structure that is audit-able. The end result is simpler, more flexible and quicker.  
> **username_7**: @Bitcoin Then I am not understanding you, as an "append-only, signed structure that is audit-able" is exactly what we're talking about here with Eris.  
> **username_2**: @username_7 A blockchain is "append-only, signed structure that is audit-able" PLUS much more than that. What banks need is just "append-only, signed structure that is audit-able" and NOT more than that. Git is a beautiful example of that and is a million times simpler than Bitcoin.  
> **username_7**: @username_2 Bitcoin and Eris (and any relevant permissioned blockchain) are very different. They use a completely different consensus algorithm. You are free to try to do what Eris is doing with git. Good luck.  
> **username_9**: "If twitter stored tweets in a blockchain that others could copy, then any modifications that twitter made to this chain would be caught." Isn't the same thing applicable by doing a data diff between two versions of data dumps?  
> **username_10**: @username_9 Yeah, I don't get that "data integrity" argument. You can achieve the same by giving a third party access to a list of the hashes of your tweets (you would need a little bit more than that if you want to also hide the number of tweets, but that's still feasible). He would then be able to attest the authority did not ponder with your tweets without having himself access to it. You don't need a blockchain for that.  

---

### Answer by username_1 on 2015-07-21. Score: 7

Private 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](https://en.wikipedia.org/wiki/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 private 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](https://en.wikipedia.org/wiki/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 private 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*, private 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.

There's a more detailed explanation in my post: [Ending the bitcoin vs blockchain debate](http://www.multichain.com/blog/2015/07/bitcoin-vs-blockchain-debate/).

> **Comments:**
> **username_2**: Blockchains don't provide MVCC at all. There can not be two writers at the same time and reading an out of date snapshot is pointless if you need to create a new transaction that depends on the latest information. Yes you can have multiple readers, but that doesn't need MVCC. A simple append-only CSV text file can do that!  
> **username_2**: The multi-master is nonsense too. Only one master can append at the same time, so you need some locking mechanism or some other way to pace multiple masters. Again: the same can be done with an append only CSV file. (No I'm no suggesting actually using CSV for this.)  
> **username_1**: Hi username_2. Did you read the article? I am saying that there is a theoretical equivalence between what blockchains do and what MVCC does, if you consider a UTXO as a database row. I guess I should explain more inside my answer here instead of just linking to the blog piece...  
> **username_3**: @username_2, I know this post is almost a year old, but reading through it, I'm curious. How is the "append-only" part of the CSV text file enforced? In otherwords, how do you enforce that it is append-only? Some sort of hash chaining with a known ending point?  
> **username_2**: By including a hash of the previous state of the csv file (or the previous line) in each new line. (sorry late answer).  

---

### Answer by username_4 on 2017-03-30. Score: 5

Researcher Arvind Narayanan stated his opinion on this matter in his post [“Private blockchain” is just a confusing name for a shared database](https://freedom-to-tinker.com/2015/09/18/private-blockchain-is-just-a-confusing-name-for-a-shared-database/):

> * It is true that adding signatures and hash pointers makes a shared database a bit more secure. However, it’s qualitatively different from the level of security, irreversibility, and censorship-resistance you get with the public blockchain.
> * The use of these crypto techniques for building a tamper-resistant database has been known for 25 years. At first there wasn’t much impetus for Wall Street to pay attention, but gradually there has arisen a great opportunity in moving some types of financial infrastructure to an automated, cryptographically secured model.
> * For banks to go this route, they must learn about the technology, get everyone to the same table, and develop and deploy a standard. The blockchain conveniently solves these problems due to the hype around it. In my view, it’s not the novelty of blockchain technology but rather its mindshare that has gotten Wall Street to converge on it, driven by the fear of missing out. It’s acted as a focal point for standardization.
> * To build these private blockchains, banks start with the Bitcoin Core code and rip out all the parts they don’t need. It’s a bit like hammering in a thumb tack, but if a hammer is readily available and no one’s told you that thumb tacks can be pushed in by hand, there’s nothing particularly wrong with it.


---

### Answer by username_11 on 2016-02-22. Score: 3

Blockchain is a mere chain of blocks and this respect is worse than every database on earth. What makes the **public** blockchain unique is the proof-of-work that ensures that thousands of copies of the blockchain are probabilistically identical all across the globe and with no discrete authority trusted to manage them. A private blockchain is a ledger managed by some authority, so is an abstraction which may be implemented with any db technology


---

### Answer by username_12 on 2016-04-15. Score: 1

The private blockchain should answer to :

* distributed database
* immutability (cannot change the past)
* integrity (cannot hack the present)
* consensus to validate new blocks
* a Turing complete language enabled to allow smart contracts

> **Comments:**
> **username_13**: This seems related to the topic at hand, but doesn't answer the main point of the question.  

---

### Answer by username_14 on 2015-07-21. Score: 1

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. That is a very expensive and slow process.

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.

> **Comments:**
> **username_2**: You're comparing a current (possibly inefficient manual) process with a blockchain. But the question is about the difference between a blockchain and something much simpler than a blockchain. For example Git, or an even simpler purpose built system, possibly relying on SQL (as that is already proven and abundant technology).  
> **username_15**: @username_2 But can you SQL inject a blockchain?  This question is more complex than you're letting on.  There's a lot of power in having an append only data structure that can't be manipulated right out of the box.  
> **username_2**: Like git or a systemd journal, or a hash linked list, or an SQL database where each row contains a hash of the previous row.  

---

