Private blockchains Vs Hashgraph, Ripple, BigChainDb

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?

Lidia

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

Sarinasarine

1) We could make a database immutable by revoking the write permission and setting the admin user password to a some gibberish. 2) If there is a private chain with 3 nodes in it, if two node decided to alter the data then the data will be collapsed already. However, I do see your point. Thank you. – Lidia

1) There are varying degrees of immutability (the inability to change something). While revoking write permissions and locking out the admin might seem like enough, it won't protect the hard drives from being directly overwritten (maybe with noise). The database needs to detect and recover from such things, if it can. Generally speaking, the more copies the better, because then it gets more difficult to wreck them all. Immutability engineering is actually a fascinating topic. – Sarinasarine

2) As mentioned in the previous comment, the more copies the more immutable the data gets. Byzantine fault tolerant systems can handle somewhere between 1/3 and 1/2 of the nodes going rogue (depending on the consensus algorithm used). Some will just halt if they detect that threshold has been exceeded, to prevent any damage from spreading to the good nodes. – Sarinasarine

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.

Thorax

In permissioned/unpermissioned network, we do gotta trust 1/3 of the nodes. – Lidia

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.

Prepositive