Hashgraph is the new decentralized consensus alternative to Blockchain.
Hashgraph serves the same needs as Blockchain: a democratic and secure way to exchange information. In that sense, hashgraph is a digital database, a decentralized online transaction record. It is a digital file than contains a ledger with names and balances. And so, users perform exchanges, while the digital file updates automatically all the time to include the new changes.
Hashghraph came out in the summer of 2017, almost a decade after blockchain’s first application, Bitcoin. For many fintech specialists, hashgraph is often characterized as Blockchain V2.0. In spite of its recency, hashgraph has been adopted by Deutsche Telekom, DLA Piper, and Nomura.
The elements of a hashgraph
A hashgraph is made up of events.
A hashgraph is made up of events. Every event contains three elements: A. A timestamp B. A list of transactions, and C. Two regular parent hashes.
A. Timestamp: The timestamp reveals time and date an event was created.
B. List of transactions: The list holds all the information regarding the transactions among users.
C. Two regular parent hashes: A hash is what identifies the event and its content. It’s what gives an event a unique identity, much like the human fingerprint. A parent hash is the hash of the previous events. In the case of hashgraph, there is a self-parent and an other-parent hashgraphs. But more about how hashes work in practice is coming in a bit.
Hashgraph is made up of these events and the information exchanged between them.
How does hashgraph work?
Suppose we want to create a type of auction that, unlike traditional auctions, is able to operate without a central authority. In this auction, all participating parties publicly maintain a distributed ledger on their computers, known as nodes.
Within the hashgraph framework the nodes share information with one another. The nodes are not just sharing what they’re also sharing who and when. This trail of information means each node knows when they found out about it and who they found out about it from. This allows the nodes to locally engage in a virtual voting protocol unique to hashgraphs. Without communicating with one another and consuming bandwidth mathematically rigorous voting algorithms are used by each node to agree on the order of transactions and how to apply them to change the state.
How is a transaction made?
Let’s assume there are 4 nodes in the network, with each node representing a user. Thus, node A is George, node B is John, node C is Mary and node D is Alice.
As soon as a node enters the Network, it creates an event, which is represented here by a gray circle. Each event contains transactions and the purpose of the hashgraph is to ensure the validity of said transactions. Every node must come to a consensus about the order of the events and agree on the timestamp.
So, how can we ensure that every node can reach consensus on the current state of the ledger? Also, how can we ensure that one node cannot manipulate the entire system? This is where the gossip protocol comes into play.
The mechanism of gossip control is based on the sync of the nodes. Each node repeatedly calls others at random to sync with them.
On the graph, each node has its own vertex. The circle represents an event when one of the network nodes exchanges information with another node. Whenever such communication occurs, each of two nodes marks the event on their vertex and links the event with the preceding event on their vertex. This way, the full graph is simply a representation of a history of how the network nodes talked to each other. This is known as the gossip protocol.
Let’s see how this works in our example.
George chose at random to call Mary. When they connected, George sent Mary all the events he knew that Mary didn’t. Then, Mary records the communication that took place between them in the form of a new event. A new event is a new circle which has lines going straight down to his own last event, and diagonally down to George’s last event. This new event is different from the first, as its components are updated: A new transaction is recorded, the timestamp changes and the hashes change as well. The new hashes that every new event contains are those of the two events below itself, called self-parent and other-parent cash. In our example, the new event gets its hashes from the last events of George and Mary.
Moving on, Mary then picks another node at random. And so she chooses John. Upon receiving the new information, John is creating a new event recording the fact they synced, and including the hashes of the most recent event by himself and the most recent event by Mary.
Likewise, John then chooses George, and creates a new event.
Then George chooses Alice and so on and so forth.
This continues, growing a directed acyclic graph upwards forever and it gets bigger with time. This is a graph connected by cryptographic hashes, and this is where hashgraph gets its name from.
Each event contains the hashes of the events below it and is digitally signed by its creator. So the entire graph of hashes is cryptographically secure. It can always grow, but the older
parts are immutable, as strong as the cryptographic hash and signature system used.The gossip protocol is also known as epidemic protocol, because gossip spreads information in a manner similar to the spread of a virus in a biological community.
Hashgraph, being a decentralized online transaction record means that there is no authority power for any one node? So how is security maintained during every transaction?
Byzantine Fault Tolerant
Unlike the other systems, hashgraph is proven to be fully asynchronous Byzantine. Other systems are some kind of Byzantine Fault Tolerant but not fully asynchronous. But what does all this mean? Why are we talking about a long-fallen empire? And what does tolerance mean in this context? To understand more about these, we have to understand a classic thought experiment: The Byzantine Generals Problem.
The Byzantine Generals Problem
This though experiment, also known as Byzantine fault, gets its name from a 1982 paper. The problem that it tries to solve is that of decentralized decision-making: How can an optimal decision be made in total absence of hierarchy? To express this kind of problem, writers of the original paper came up with an allegory.
Imagine that you are a general in the Byzantine army and you’re planning to attack an enemy city. You have the city surrounded by several battalions, each of which is led by another general, far away from you. Your objective is to plan a coordinated attack on the city from all sides at the same time. If the attack is not coordinated, i.e. not all battalions attack at the same time, you fail.
In addition, you need to remember that this is the middle ages. There are no cell phones or any telecoms for that matter. Also, torch or smoke signals could be seen by the enemy. Furthermore, sending messengers on horseback can get them captured or killed, so this is not an option. Worse yet, there is a possibility that other generals are traitors and they send messages back to you confirming that they will attack when their true intention is to retreat.
How can you ever be absolutely certain that all of your battalions will reach consensus and attack simultaneously? And how do the other generals know that the messages that they received from you are genuine? How do you make sure with absolute certainty that all generals reach consensus and all attack together?
In our case, the battalions are the nodes that have to reach consensus on the current state of the ledger. Not only that, but once Yes or No is decided, there is no turning back; it has to be an irrevocable decision. Furthermore, you have to have a mathematical guarantee that all nodes have reached the same decision.
The essence of the problem is about individual parties being able to trust each other directly – no strings attached. All allegories aside, the Byzantine fault isabout a bunch of people, none of whom trust each other, trying to come to an agreement to a Yes/No question.
Asynchronous Byzantine Fault Tolerant
Now that you’ve grasped the Byzantile Fault concept, let’s see why adding the word asynchronous is so important.
Asynchronous means that you are not making any assumptions about timing. And Asynchronous Byzantine means that you make no assumptions about how soon a recipient will get your message or how fast messages are passed over the internet. This capability makes it resilient against DDoS attacks, botnets, and firewalls.
Let’s assume that the ‘bad guys’ control the entire Internet. These bad guys have installed malicious firewalls everywhere, between every pair of people in every possible pattern. If that was not enough, those guys make up the ⅓ of the whole network. So 1 out of 3 people are basically bad actors. If you can prove that you have the strongest proof of Byzantine agreement, then you have achieved fully asynchronous Byzantine. And hashgraph technology does exactly that.
The rest of decentralized ledger technologies, including blockchain, are partially asynchronous or not synchronous at all. That factor alone can lead to a number of security issues. In 2018 alone, over $1 Billion in cryptocurrency was lost to hackers [source]. This would not be possible with the hashgraph technology and that explains why hashgraph is considered to have the highest security.