Hedera Hashgraph, may be, somewhat broken.
Hedera Hashgraph has been called Blockchain 3.0 and has been setting the blockchain and crypto community on fire, with fast consensus and asynchronous Byzantine fault tolerance. It seems awesome, yet I think it is broken — you decide.
Hedera Hashgraph was announced as the public non-permissioned ledger version of Hashgraph (the permissioned ledger), which used trusted nodes as supermajority for their consensus.
We ask if Hashgraph scales from that trusted supermajority requirement to the entire untrusted big bad Internet? The answer, I believe, is no.
A few days back, I did a critical review of Algorand here. Algorand tries to pick a committee of trusted users for building consensus using a combination of “pure” Proof of Stake and cryptographic self-selection (simply put, they pick their chit(s) from a hat, which they use to vote for consensus). That turns out to have some unforeseen liveness and safety issues.
A similar problem may occur with Hedera as well, albeit from a different direction.
Algorand tries to achieve fast BFT by using an ingenious method of cryptographic self-selection and limiting the committee size. Hedera uses “virtual voting” to achieve fast BFT. This approach is in a way similar to self-selection, except that it happens by checking the DAG for complete info on “gossip over gossip”. The problem with Hedera is that the trusted committee size is indeterminate and possibly indeterminable. That is a serious problem. (Also check update below.)
Let us understand. For flagging consensus using the DAG, Hedera uses the same supermajority criterion as that of Hashgraph, which is that when more than 2n/3 of the “virtual votes” of trusted nodes are registered, then consensus is reached. Let us ignore the terminology of “famous nodes” etc for the purposes of this review. Instead of 2n/3 nodes as in Hashgraph, Hedera uses 2n/3 votes, where each node gets as many votes as the coins staked by that node.
Firstly, in a non-permissioned setting, where there could be thousands of nodes, the count of which may be unknown at any given time, how will Hedera know that it has seen 2/3rds of gossip, to achieve consensus?
Even if Hedera could store these nodes in a registry and knows the pre-defined count of all nodes in existence, how can it be sure that 2/3rds or more of them are honest?
Since Hedera uses Proof of Stake to give as many votes to each node as the count of their tokens held in their wallet, how can it ensure that honest nodes with majority of money will, indeed, participate in virtual voting? This results in Proof of Stake failing to produce consensus in Hedera as 2/3rds of total money may not appear as votes for consensus, causing some safety issues if not careful.
Indeed, most of the coin holders will generally prefer to store their tokens in a cold wallet and not participate in any online behaviour at all unless they are doing a transfer. This is similar to the problem faced by Algorand as well.
In the absence of knowledge about how many nodes (n) exist, 2n/3 (of either nodes or votes) cannot be calculated. This will cause a liveness issue in Hedera.
It appears that Hashgraph works well in a permissioned setting but Hedera Hashgraph may not work well at Internet scale.
Hope I haven’t missed out something simple!
Update: I had a long discussion with Mannon (Hedera admin on telegram), who pointed out that 2/3rds of stake are locked up for 5 years to ensure supermajority lies with the council. (Please check telegram for the conversation.) Again, as a technical solution, this is not much better than Tendermint (except for async BFT) and from an economics perspective, it is bad for 2/3rds of stake to be locked up, only to be released later. From that time onward, the system becomes more and more insecure and thus, it just postpones the problem to a period later than five years and is not a real solution.
Update 2: It has been pointed out to me that, if for instance, just a 1000 (that hold 35% of the wealth) out of the total 1Mill Hedera nodes are partitioned off, for instance, behind the firewall of China or by some oligarchs in Russia or even an unexpected shutdown of an AWS zone containing Hedera validators, then Hashgraph will be prevented from reaching consensus for a block and just halt. As it stands, as per the limitations of BFT, the system has to be resistant to 33% of nodes failure — but with just a few of the Hedera proxy treasury nodes (which hold 2/3rds of the wealth) not responding, Hedera has a very current liveness problem with its design.
Update 3: Hedera lead developer Paul Madsen has put this out in the Reddit post “Yes the network will pause until at least 3% becomes available once more.”
Hedera should put this out in the website. Note that this temporary halt will happen even when some of the treasury/proxy nodes get trapped in an AWS or other cloud outage for several minutes. Also in the case of China/Russia trapping these nodes, Hedera may never get the 3% it needs.
This has several problems:
- Users/Developers who have been promised a few seconds finality will have to be told that finality may take much longer and they have to write code expecting it to happen
- When you are doing hundreds of thousands of tx/s, if the network is down for 15 to 20 minutes, this will pile up to billions of transactions. Hedera will need to analyse, test and publish how long the transactions will be stuck before getting confirmed
- This “pausing” behaviour is completely unexpected in an asynchronous BFT solution. Hedera should moderate claims about being aBFT tolerant.
Update 4: (final update)
As predicted, Hashgraph shuts down due to some council nodes going offline.
Do take a look at an alternative consensus protocol which does not have these problems. (shameless self-plug)
https://medium.com/@rajeshbhaskar/design-of-a-new-blockchain-protocol-proof-of-trust-2bf2c1997adb
— Cheers! (Rajesh Bhaskar — rajesh@trilloc.com)
(My team and I are working on a new blockchain based on concepts from Algorand and others.)
(*) The purpose of publishing this article is to educate, clarify and thwart any loopholes in Hashgraph and blockchains in general and to study alternatives.
(-) Please read the Hashgraph White Papers to understand more about Hedera Hashgraph and Hashgraph
(+) If you liked this article and would consider donating to my independent blockchain research efforts to build a better blockchain, please do so to the wallets below:
ETH: 0x058503afffd50303e1e49623c67e8760f50d304d
BTC: 3PrR945zHeTPh7kmUiftUUwmxUV2jkuy4M
