Demystifying Hashgraph: Benefits and Challenges

• Demystifying Hashgraph: Benefits and Challenges

Recently, on our Zilliqa social channels a number of people have asked us to take a look at Hashgraph. So, here is what we think.

Hashgraph is a new consensus protocol that has garnered attention lately by being projected as a technology that will make blockchains obsolete. According to Hashgraph’s website, it is claimed that Hashgraph has the following properties:

Fast: 250,000+ Transactions Per SecondFair: Mathematically-Proven Fairness (via Consensus Time Stamping)Secure: Bank-Grade Security (Asynchronous Byzantine Fault Tolerant)

A cursory read of these three properties suggests that Hashgraph may indeed be a game changer — — with 250,000+ transactions/second, it could solve the scalability issue facing most blockchains today.

In this article, we take a look at Hashgraph from our point of view, present its pros and cons, and address the following million-dollar question:

“Did blockchain just become obsolete?”

Note: All references in this article are based on Hashgraph’s whitepaper and website.

What is Hashgraph?

Hashgraph is a new consensus alternative to the blockchain. It uses a gossip protocol that works in the following manner: Every node in Hashgraph can spread signed information (called events) on newly-created transactions and transactions received from others, to its randomly chosen neighbors. These neighbors will aggregate received events with information received from other nodes into a new event, and then send it on to other randomly chosen neighbors. This process continues until all the nodes are aware of the information created or received at the beginning. Due to the rapid convergence property of the gossip protocol, every piece of new information can reach each node in the network in a fast manner.

The history of the gossip protocol can be illustrated by a directed graph, i.e., each node maintains a graph representing sequences of forwarders/witnesses for each transaction. In the ideal case, all the nodes have the same view of all transactions and their witnesses. Further, by performing virtual voting, each node can determine if a transaction is valid based on whether it has over two-thirds of nodes in the network as witnesses. Note that Hashgraph runs in the Byzantine setting, where the assumption is that less than a third of nodes are Byzantine (nodes that can behave badly by forging, delaying, replaying and dropping incoming/outgoing messages).

Pros and Cons

Let’s analyze the three claims put forward by Hashgraph.

1. Fast. Hashgraph is fast, as it uses the gossip protocol to spread messages to the network and also performs some optimization of the gossiped messages to reduce the communication overhead. The gossip-about-gossip also yields a consensus protocol. However, there is another reason why Hashgraph is fast: it currently works in a permissioned setting.

“At this time, Hashgraph is only deployed in private, permissioned-based networks” — — Hashgraph Team on Telegram.

Below, we discuss the difference between permissioned and non-permissioned networks. The difference is crucial as it has a direct impact on the throughput of the consensus solution.

In a non-permissioned setting (aka public blockchain) like in Bitcoin/Ethereum, the nodes participating in the consensus protocol are not known beforehand and untrusted since any node is allowed to join or leave the network at will. Moreover, the consensus mechanisms for such a setup have to account for maliciousness, particularly Sybil attacks where a single user generates multiple entities to influence the consensus process and for instance, mounts double spend attacks. Solving these issues in a non-permissioned setting affects the overall throughput.

On the other hand, in private (permissioned) distributed ledgers, identities of all nodes are known beforehand and the network is not open to an arbitrary participant. The prior knowledge of the identities of the participating nodes provides a natural protection against Sybil attacks and makes it easier to reach consensus. This means that no Sybil resistance mechanism needs to be put in place and hence the throughput can be increased dramatically (when compared to public blockchains).

As Hashgraph is currently a private distributed ledger, its throughput should be compared with the likes of other private blockchains, e.g., IBM HyperLedger Fabric (700 transactions per second) or Red Belly (400,000 transactions per second). Its throughput should not be compared with public blockchains like Bitcoin or Ethereum (10 transactions per second) as it is equivalent to comparing apples with oranges. Currently, Hashgraph has yet to release concrete technical details for its deployment as a public ledger.

2. Fair. Hashgraph also provides fairness via consensus time stamping. This means that if one transaction reaches two-thirds of the network ahead of other transactions, it is considered to be the first. It is a relatively fair system, as two-thirds of the network are witnesses and it is difficult for a majority of them to make unfair decisions. However, Hashgraph is based on the gossip protocol and this means that when a node chooses its successors uniformly at random, there is some probability (e.g., one-third, if the node’s neighbors are chosen globally and uniformly at random) that all the chosen nodes may be Byzantine or malicious. These malicious successors can stop passing the transaction to the next group of nodes, thereby preventing the transaction from reaching two-thirds of the network which would result in an unfair outcome for the honest creator. In addition, trying to ensure that every honest node is connected to some honest nodes, and that every message can be transmitted to other honest nodes without being stopped by intermediate Byzantine nodes, is an open problem in itself. While this is currently not an issue given the private nature of Hashgraph, this will be a hurdle to overcome when releasing a public distributed ledger.

3. Secure. Hashgraph is an asynchronous BFT, but it is not deterministic. In Fischer et al. (1985) it was shown that in asynchronous systems, deterministic consensus protocols are impossible even in the simple case of only one faulty node. A consensus protocol can be either non-deterministic asynchronous or deterministic non-completely asynchronous in the Byzantine setting.

For deterministic protocols, all honest nodes reach consensus by round r for some a priori known constant r. For non-deterministic or probabilistic protocols, the probability that an honest node is undecided after r rounds approaches zero as r approaches infinity. For synchronous protocols, roughly speaking, messages are guaranteed to be delivered after a certain bound ∆, but the asynchronous protocols don’t have such a bound.

Hashgraph is a non-deterministic asynchronous protocol by adding randomness. The compromise is that the consensus protocol will terminate eventually but there is uncertainty as to when termination will occur. In its current design, Hashgraph employs coin toss (i.e., middle bit of a signature) for nodes to make decisions when there is no progress in the consensus protocol. Therefore, there is non-zero probability of all honest nodes having the same value after numerous rounds of coin toss. Eventually all the honest nodes will become unanimous. However, if all the Byzantine nodes try to disrupt the protocol by manipulating the gossip protocol as detailed in point 2 above, the effectiveness and efficiency of this coin toss approach becomes questionable, as it may take numerous rounds to reach consensus.

And the million-dollar question, does Hashgraph make Blockchains obsolete?

Hashgraph is an interesting consensus protocol that has been shown to yield high throughput in a private and static setting. Hashgraph is fast, fair, and secure within the permissioned setting it currently operates in. However, if and when used in a public setting, Hashgraph will face the same issues that other public blockchains are facing today and may not be able to maintain its security and performance.

In fact, scalability is still an open problem for public blockchains. It is interesting to see new solutions being proposed by the community. For instance, Ethereum uses PoS for their Casper protocol, NEO employs dBFT, EOS has a dPoS-based solution, and Zilliqa implements sharding. All these solutions have their own benefits and weaknesses as there is no silver bullet to solve the scalability problem and there has never been one for many scientific problems.

Another important question is what does a scalable solution actually mean? Does this mean that the solution is scalable in the number of users or in the number of transactions, or in the size of the network? If a P2P network is capable of processing thousands of transactions, can we call the solution scalable? If so, what happens when the network doubles its size — — can the throughput be maintained? In fact, a solution that is scalable in a single dimension may not be well-suited for a use case that requires scaling in a different dimension. Hashgraph currently scales only in the number of transactions processed but does not scale with the number of nodes in the network. Zilliqa for instance scales with the number of nodes in the network.

So, let us all appreciate the underlying technology in Hashgraph but not with closed or blinded eyes. And while we appreciate Hashgraph, we should also appreciate blockchains which have paved way to the likes of Hashgraph in just the same way, they have paved the way for Ethereum, EoS, NEO, Zilliqa and many others.

Thank En Hui and Amrit for their feedback and help.

This disclaimer informs readers that the views, thoughts, and opinions expressed in the text belong solely to the author, and not necessarily to the author’s employer, organization, committee or other group or individual.