31

Since the banks appear to be currently looking into the idea of "blockchains" but don't want to be dealing with "Bitcoin", 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?

10

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.
  • 5
    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? – Anonymous Jul 21 '15 at 3:59
  • @Bitcoin Possibly protocol rules enforcement? You can also put block hashes onto Factom / Bitcoin to ensure records aren't altered. – ThePiachu Jul 21 '15 at 4:07
  • 3
    @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. – Anonymous Jul 21 '15 at 4:10
  • 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 Jul 21 '15 at 4:19
  • 5
    @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. – Anonymous Jul 21 '15 at 7:09
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).

  • so then you're saying that a private blockchain is better than a database? – smatthewenglish Jan 17 '17 at 14:44
6

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 (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). 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.

  • 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! – Jannes Jul 23 '15 at 12:33
  • 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.) – Jannes Jul 23 '15 at 12:35
  • 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 Jul 23 '15 at 13:53
  • 1
    @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 May 25 '16 at 12:25
  • By including a hash of the previous state of the csv file (or the previous line) in each new line. (sorry late answer). – Jannes Dec 20 '17 at 7:40
4

Researcher Arvind Narayanan stated his opinion on this matter in his post “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.
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

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.

  • 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). – Jannes Jul 23 '15 at 12:40
  • @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 Dec 19 '17 at 5:10
  • 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 Dec 20 '17 at 7:45
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
  • This seems related to the topic at hand, but doesn't answer the main point of the question. – Murch Apr 15 '16 at 14:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.