Private blockchains Vs Hashgraph, Ripple, BigChain

Question

I have been investigating different blockchains for some use cases. In the end, I came to the conclusion that setting up a private blockchain is equivalent to having a distributed database with blockchain concepts like immutability, digital signatures on top of it. Eg: Bigchaindb. (Well, If we do need smart contract feature then distributed database might not work)

Theoretically, hashgraph consensus algorithm doesn't look secure enough for a public chain. It looks like a close alternate version of Ripple.

In summary,

1. Hashgraph, Ripple suits for private chain.
2. Private chain is equivalent to setting a Distributed database

Here I am sharing my views, to know in what way private chain is better than a distributed database?

Answer 1

Most distributed databases in existence today are fault tolerant (so they keep running if a few nodes go down among many), but not Byzantine fault tolerant (BFT), i.e. they can't handle arbitrary faults. Most blockchains are BFT, so even if you don't trust some of the nodes, you can trust the overall system.

Most distributed databases allow the change or deletion of data. (There are some interesting exceptions here, but I digress.) Most blockchains do not.

Most distributed databases have a central "admin" user who can do almost anything, including change data, delete data, delete entire tables/collections, or delete the entire database. Most blockchains have no single point of control like that.

Until recently, BigchainDB wasn't BFT and the database admin (e.g. the MongoDB database admin) could cause havoc. The next version will be very different: it will be BFT, and it won't have any single point of control (i.e. no more global admin or anything similar).

Answer 2

In most DB implementations you: a) know the nodes and b) trust the nodes.

In a permissioned DLT you: a) know the nodes but b) don't trust the nodes.

In an unpermissioned DLT you : a) don't know the nodes and b) don't trust the nodes.

It's a spectrum of what you are trying to accomplish with a DLT. With CULedger for example, hashgraph is being used because the nodes know each other and agree to engage, but they don't necessarily trust each other in the sense that their interests may not be perfectly aligned.

To be clear, hashgraph is a consensus layer right now. There are plenty of features that would still need to be sorted before it would be ready for an unpermissioned implementation: stake issuance/allocation, node mgt (including node reconnect), user/account mgt, etc. As a consensus layer, hashgraph is as "secure" as the application you build on top of it. I put "secure" in quotes only because I understand that means different things to different people. The consensus layer itself is cryptographically sound...it's just a question of how you report and consume transactions (which are just byte arrays).

To take it a step further...could you implement a Cassandra cluster with distributed nodes and permissioning that allowed nodes to play with each other without trusting each other? Maybe. I'll admit I don't know if there is support for untrusted distributed nodes, but I do know that most DLTs were built with that purpose in mind.

Great question btw.

Answer 3

Defining features of hash graph consensus are virtual voting, transaction ordering and the swiftness of gossip to gossip protocol. These are helping hash graph to achieve a state of eventual asynchronous BFT in a chronotopic architecture. If we add more cryptographic rigor and integrity to these properties, it will be a fast, secure and self organized public distributed graph ledger with unique properties.