Hashgraph

The better Blockchain?!

11 min readFeb 1, 2018

Aside: You can find more information about the related Blockchain technology here.

Introduction

Distributed ledger technologies such as the Blockchain are heavily discussed nowadays since they enable disruptive ways to store transactional data in a tamper evident way, making it possible to share consensus about the correct order of transactions and therefore the correct “state of the world“. Use-cases for distributed ledger technologies range from value-related transactions (e.g. money transfers) to avoid the double spending problem, to programs which code is deployed through transactions and will be executed by every single participant in the network with no way to stop it (see: Smart Contracts or Ethereum).

One of the most famous real-world rollouts of distributed ledger technology is the cryptocurrency Bitcoin. Bitcoin started in 2009 and grew significantly since then.

Operating at such a high scale unveiled some drawbacks around Bitcoins underlying technologies, namely the Blockchain and the „Proof-of-Work“ consensus algorithm.

This post won’t go into too much detail around Bitcoins scaling issues (that will be covered in separate posts), but the following is a list with common problems the cryptocurrency currently faces while it scales to meet demand:

The „Proof-of-Work“ consensus algorithm wastes lots of energy and time (by design)
Transactions can take up to 30 minutes to be processed
Miners (clients which create new blocks for the Blockchain) can change the order of transactions
Coming up with two new blocks at the same time can result in (hard) forks or orphans
It only supports a single-digit throughput for transactions
Controlling >51% of the network means that the Blockchain can be altered

One can see that the Blockchain in combination with different consensus algorithms such as „Proof-of-Work“ has some significant downsides which already turned into scaling issues for various implementations based on such technologies. One might ask:

Is there a solution for this problem?

Yes, there is! The Hashgraph is a new approach to find consensus in a distributed network. Hashgraphs inventors claim that it’s fast, fair and secure:

It can process 250.000+ transactions per second
It supports mathematically proven fairness via timestamping
It’s secured with Asynchronous Byzantine Fault Tolerant guarantees

This blog post will take a look behind the scenes of the Hashgraph protocol to show how it works and why it might be yet another game changer in the distributed consensus algorithms world. We’ll see that the Hashgraph algorithm is actually brilliantly simple and therefore can be explained in just a couple of minutes with the help of some easy to understand concepts.

How it works

Let’s imagine that we have three participants in our network. Their names are Alice, Bob and Carol (A, B, C). All three have joined our network and want to submit different transactions and agree on a correct state of the network at any given time. Their overall goal is to find a consensus about who sent what transaction in which order.

Gossip (about gossip)

The first challenge we face is the problem of information sharing. How can we ensure that the whole network is aware of our new transactions? How do we reach each and every node, even if we’re not aware of its existence?

The computer science toolbelt offers a variety of different solutions to solve this issue. One protocol is especially interesting, since it solves the problem in a simple and elegant way. It’s called the „Gossip“ protocol.

Gossip exactly means what its name stands for. The idea is to spread information like a wildfire. Any given node shares the information it knows with every other node in the network it’s aware of. This process repeats until all nodes in the network don’t hear any new information, meaning that the whole network is in sync.

Here’s a simple example to illustrate the gossip protocol:
Let’s say Alice wants to store some information in the network and wants to sync with the other clients about the new transaction. Alice already knows Bob and shares the transactional information with him. A new timestamped data point called “event”, which contains data about the fact that Alice and Bob synced, is created.

Bob knows Carol. Right after he got the information from Alice he gossips the „news“ about Alices transaction to Carol. A new timestamped event is created which tracks that Bob and Carol have synced

The information about Alices transaction spreads like wildfire and this procedure repeats until every node knows about the transaction and therefore the whole network is in sync.

The „Gossip“ protocol is a good way to spread new information in a network in a fast and efficient way. Syncing all nodes with one-another in the network reduces single-point-of-failures since all nodes share the same knowledge and are therefore independent from each other. The only speed-limitation is the network bandwidth from one node to another. There’s no single bottleneck in this communication method since nodes talk directly to each other without the need to go through a middleman (e.g. a server).

However using this simple version of a „Gossip“ protocol is not enough to be the back-bone of a tamper evident distributed ledger technology. The main problem is that while all the transactions are shared in the network and timestamps are used to determine the order of those, it’s not guaranteed that a malicious node doesn’t modify the data and tricks the whole network into a different thinking about the networks correct state.

There’s a need to somehow enhance the information which is spread through gossiping with some meta-information to make it possible to detect malicious node-behavior.

Swirlds, the inventors of the Hashgraph algorithm came up with a solution for this problem. They call it „Gossip about gossip“.

Here’s an example to show how „Gossip about gossip“ works:
Let’s say that Alice wants to share some transactional information with the network. Alice knows Bob and shares her intent to do a transaction with him. Bob hasn’t seen the information just yet and creates a new data point („event“) which stores information about the transaction. Nothing special so far.

However there’s more than that. First of all Bob signs the event he just created to ensure that everyone knows that he’s the author of it. Next up Bob adds a timestamp to the events metadata to ensure the correct order of transactions. (Aside: the Hashgraph algorithm has some logic which circumvents the problems of out of sync node clocks). The last two important meta informations are two hashes. One hash is the hashed information about the most recent event Alice has seen, the other hash contains information about the most recent event Bob has seen.

In a Hashgraph events always include this metadata:

Signing of author
Timestamp for transaction
Hash of last event the sender has seen
Hash of last event the receiver has seen

Whenever the network gossips some new information it includes information about recent gossips, hence it “gossips about gossip“.

The fact that all events contain verifiable information about old, already gossiped information makes it hard to manipulate the data since doing so would render the graph invalid. Those inner-transactional dependencies draw some parallels to the Blockchain technology and its „chain“ properties.

(Virtual) Voting

Another important functionality is to determine if a transaction in the network is valid. Taking yet another look into the computer science toolbelt shows that voting algorithms can be applied on the graph to check, whether the recorded transactions are valid.

Performing voting on the Hashgraph can be quite time- and resource consuming since lots of data is stored and therefore processing it to check for validity will take quite some time.

Swirlds solution for this problem is called “virtual voting”.

“Virtual voting” means that the outcome for every given voting-powered validity check can be performed without the need for actual computations. Given the information which is stored in the Hashgraph it’s actually possible to predict the outcome of the vote in a mathematically correct and proven way.
Having this capability might sound crazy, but it’s actually not too far off. The „magic“ part which makes „virtual voting“ possible is the information which is gathered through “gossip about gossip“. “Gossip about gossip“ ensures that every node in the network knows at any given time how the current and historical state of the network looks like, enabling a way to virtually vote about the validity of transactions.

A simple example

Now that a basic understanding of the Hashgraph algorithm is in place it’s time to look at an example to re-visit and solidify this knowledge.

This example uses three different clients which participate in the network. All clients want to propose transactions and agree on a consensus about the networks state.

The three clients are called Alice, Bob and Carol (A, B, C). The graph grows upwards and time is described using the Y-Axis.

The network starts with three empty data points („events“). One event per participant:

Now let’s say that Alice wants to do a transaction and share it with the whole network. Alice knows Bob and shares her intent to perform a transaction with him. Bob is not yet aware of Alices transaction and creates a new event to store this information in the Graph. Bob signs this event (since he’s the event creator), attaches a timestamp and the hash of Alices last event and the hash of his last event. In this case both hashes are the hashes of their initialization events.

Now Bob knows about two events. His own initialization event and the one he just created after he received the gossip from Alice.

Let’s assume that Bob randomly picks Alice again to gossip and therefore share all the information about the events he’s aware of. This information includes his own initialization event and the one he created previously to track Alices gossip.
Now Alice sees that there’s an event she is not yet aware of (Bobs initialization event) and creates a new event entry to store that new information in the graph. She signs this event, timestamps it and adds the hash of her last event and the hash of Bobs last event to the event data.

As time goes by, the graph grows and might look something like this:

The graph after yet another round of gossiping

Since all nodes consistently gossip and therefore share and store information with one another we can be sure that the previously described „virtual voting“ (where at any given time we can guess the outcome of a performed vote) always returns the correct result and therefore ensures the validity of transactions in the graph.

Note: We won’t do a deep dive into the voting algorithms in this post since it’s slightly out of scope and will turn into a longer essay. Make sure to check out the Hashgraph whitepaper to see how voting algorithms are used in a Hashgraph.

Now that we’ve covered the basic building blocks for understanding the Hashgraph consensus algorithm it’s time to take a look at the advantages and disadvantages to figure out if the Hashgraph will be a game-changer or if shortcomings might harm adoption.

Advantages

The following are Hashgraphs advantages (in no particular order).

Fairness

A Hashgraph is fair since no participant can manipulate or even slow down transactions. Every single transaction which is sent into the network is processed and recorded.

Fast

A Hashgraph is blazing fast thanks to the Gossip protocol to share information and sync the graph. The only limitation is the bandwidth between clients when they gossip. A Hashgraph has no single servers which process information and therefore no bottleneck.

(D)DoS resistant

Given the fact that all nodes store all the information about the graphs state it’s impossible to perform (D)DoS attacks and therefore take down the network. The network is stable and „alive“ as long as one node is available. Upon joining, a new node will be randomly contacted and gets updated about the current state of the graph thanks to the “gossip about gossip” protocol.

Inexpensive / Efficient

The Hashgraph algorithm is highly inexpensive compared to other consensus algorithms like „Proof-of-Work“ which is used by Bitcoin. “Proof-of-Work” wastes energy and time by design to ensure that only trustworthy participants (those who have proofed their trustworthiness through work) work on the Blockchains evolvement.

A Hashgraph stores each and every proposed transaction and doesn’t need to waste energy and time to find a consensus since all transactional data is signed and contains information about the history of events in the graph.

Timestamped

Each transaction in a Hashgraph is timestamped to ensure the correct order. The so-called „consensus timestamp“ is computed based on the median of all the times at which each node first heard about the transaction through gossiping.

Challenges

While it’s obvious why the Hashgraph consensus algorithm is often called a game-changer in distributed ledger technology it also comes with some challenges and potential shotcomings of its own.

Not widely used (yet)

As of today there are no widely used applications of a Hashgraph implementation like Bitcoin is for Blockchain technology. Swirlds state that for the time-being the main use-cases are around business-grade implementations which highly rely on Hashgraphs speed, security and mathematical validity.

Patented

The Hashgraph is protected by three individual patents and therefore requires licensing when using it.

Closed Source

Right now one has to request the official SDK from Swirlds homepage to build solutions on the Hashgraph technology. Unfortunately the official implementation is not open sourced (yet).

However there are some open source implementations, but be aware to use them in a “serious application” without checking the patents and ask for permissions / purchasing a license.

Conclusion

In this post we’ve seen what the Hashgraph consensus algorithm is, how it works and why it has huge potential to disrupt the status quo in distributed ledger technologies.

The Hashgraphs main building blocks are the „gossip about gossip“ and „virtual voting“ techniques, making it possible to sync all notes in the network about the knowledge of transactions and decide whether a given transaction can be considered valid without the need to reach out to other nodes and collaboratively vote about the validity.

Thanks to the Hashgraph it’s finally possible to agree on a consensus in a network in a fair, fast and highly efficient way without the need to waste time or energy. However different challenges such as the lack of „battle-tested“ real-world implementations or the patented and closed source nature might slow down its adoption.