Hashgraph

In the ever-evolving world of digital currencies, Hashgraph stands out as a unique and innovative technology. Unlike traditional blockchain-based cryptocurrencies, Hashgraph employs a novel data structure and consensus algorithm, offering a fresh perspective on distributed ledger technology. This article aims to provide an in-depth understanding of Hashgraph, its underlying principles, and its potential impact on the digital currency market.

Hashgraph Consensus Explained

The hashgraph data structure and consensus algorithm offer a novel framework for achieving distributed consensus. This introductory overview elucidates the workings of hashgraph and some of its characteristics. The objective of a distributed consensus algorithm is to enable a group of users to reach a consensus on the sequence of transactions generated by some users, even when no single user is universally trusted. It essentially serves as a mechanism for fostering trust among individuals who may not initially trust each other. Hashgraph accomplishes this in a fundamentally innovative manner. A blockchain can be likened to a tree that is consistently trimmed as it expands – this trimming is crucial to prevent the block branches from becoming unmanageable and to ensure the ledger comprises only a single chain of blocks. In contrast, hashgraph incorporates new growth back into the ledger’s body instead of pruning it. In both blockchain and hashgraph ledgers, any user can initiate a transaction, which will eventually be placed into a container (the “block”) and then disseminated across the distributed network. In blockchain, these “blocks” of containers are designed to form a singular, extended chain. If two blocks are generated simultaneously, the network nodes will ultimately select one chain to proceed with and discard the other, preventing the blockchain from “forking” into two distinct chains. It resembles a growing tree that is constantly having all but one of its branches cut off. In hashgraph, every transaction container is integrated into the ledger — none are discarded — making it more efficient than blockchains. All the branches persist indefinitely and are interwoven into a unified entity. Moreover, blockchain fails if the new containers arrive too rapidly, as new branches emerge faster than they can be pruned. This is why blockchain requires proof-of-work or another mechanism to artificially decelerate the growth. In hashgraph, however, nothing is discarded. There is no detriment in the hashgraph data structure expanding swiftly. Every member can initiate transactions and containers at their discretion. Lastly, because hashgraph does not necessitate the pruning of potential “forks” (as every transaction container is integrated into the ledger), hashgraph enables more potent mathematical guarantees, such as Byzantine agreement and fairness. Distributed databases like Paxos are Byzantine but do not guarantee fairness in transaction ordering. Blockchain is neither Byzantine nor fair. The hashgraph algorithm achieves being fair, fast, Byzantine, ACID compliant, efficient, cost-effective, timestamped, and resistant to DoS attacks.

How Does the Gossip Protocol Work?

To comprehend gossip about gossip, it’s essential to first grasp the gossip protocol, which is utilized by the Hashgraph consensus. In Hashgraph, when transmitting information between nodes, a member, let’s call her “Alice”, randomly selects another member, for instance, “Bob”. Alice then shares all the information she has up to that point with Bob. Alice repeats this process with a different random member, and Bob does the same, as do all other members. This method ensures that if a single member learns of new information, it rapidly proliferates throughout the community until every member is aware of it. The process of synchronizing information between two members via the gossip protocol is termed a gossip sync. Upon the completion of a gossip sync, each participating member marks the gossip sync with an event. An event is stored in memory as a data structure consisting of a timestamp, an array of zero or more transactions, two parent hashes, and a cryptographic signature. The two parent hashes are the hash of the last event created by the self-parent before the gossip sync and the hash of the last event created by the other-parent before the gossip sync. For instance, if Alice and Bob conduct a gossip sync, Alice would create a new event marking the gossip sync where the self-parent hash would be the hash of the last event Alice created before the gossip sync and the other-parent hash would be the hash of the last event Bob created before the gossip sync. Bob would also create an event marking the gossip sync, but the self-parent hash would be the hash of the last event he created before the gossip sync and the other-parent hash would be the hash of the last event Alice created before the gossip sync. The gossip continues until all members have received the newly created event.

Understanding Gossip about Gossip

The relationship history of these events, as determined by their parent hashes, is referred to as gossip about gossip. This history manifests itself as a form of directed acyclic graph (DAG), a hash graph, or a hashgraph. The hashgraph chronicles the communication history among members. It expands directionally over time as more gossip syncs occur and events are generated. All members maintain a local copy of the hashgraph, which continues to update as members synchronize with each other. These hashgraphs may exhibit slight differences at any given point in time, but they will always maintain consistency. Consistency implies that if both [Alice] and [Bob] contain event x, then they will both possess the exact same set of ancestors for x, and will both contain the exact same set of edges between those ancestors. Each event in the hashgraph comprises the following: Timestamp Two hashes of two events beneath it Self-parent Other-parent Transactions Digital signature

Virtual Voting

Virtual voting takes place when nodes evaluate events and achieve consensus through a voting algorithm. Here’s the process—a transaction is given a timestamp when a node receives it. As it circulates to other nodes in the network, it is assigned a timestamp that is the median of all the timestamps for that transaction received by the network’s nodes. This median serves as the voting outcome. This method establishes a more equitable transaction system than a blockchain because the decision is made by the network as a whole, not by a single node.

Performance

Hashgraph stands out for its remarkable energy efficiency and performance.

Cost

Operating a hashgraph distributed ledger is less costly compared to blockchain distributed ledgers, as it bypasses the energy-demanding proof-of-work. Those who wish to operate hashgraph nodes won’t need to invest in costly custom mining rigs. They can run hashgraph nodes using readily accessible hardware that is more affordable than such specialized mining rigs.

Efficiency

Hashgraph boasts 100% efficiency, as understood in the blockchain community. In blockchain, efforts are occasionally wasted mining a block that is later deemed stale and discarded by the network of nodes. In hashgraph, the equivalent of a “block” of transactions never becomes stale. Hashgraph is also efficient in its bandwidth usage. Regardless of the bandwidth required to inform all the nodes of a specific transaction (even without reaching consensus on a timestamp for that transaction), hashgraph adds only a minimal overhead of additional bandwidth to achieve a consensus timestamp and arrange the transactions. Moreover, the hashgraph voting algorithm doesn’t necessitate any extra messages to be sent for nodes to vote on validating transactions (or for those votes to be counted) beyond the messages through which the network nodes learned of the transaction itself.

Throughput

Hashgraph is swift. It is solely limited by the bandwidth. If each network node has sufficient bandwidth to download and upload a certain number of transactions per second, the network as a whole can manage nearly that many transactions per second. Even a high-speed home internet connection could enable a hashgraph node to be fast enough to handle a transaction volume equivalent to the entire global VISA card network.

State Efficiency

Once a network transaction takes place, all nodes in the network will know where that transaction should be positioned in a history of transactions with 100% certainty within seconds. More importantly, every node will know that every other node knows this. At that juncture, the network can simply incorporate the effects of the transaction and, unless required for future audit or compliance, discard the transaction data. Therefore, in a minimal cryptocurrency system, each node would only need to store the current balance of each network account that is not empty. The nodes would not need to retain the full history of the transactions that led to those balances all the way back to “genesis.”

Fault Tolerance

Like most distributed ledgers and blockchains, there’s always a possibility that a network participant may not be trustworthy. Communication delays or network latency could lead to improper communication between nodes. Consensus mechanisms are engineered to handle these faults by establishing fault tolerance criteria. Developers must take into account and plan for dishonest actors, poor connections, network latency, and other network problems. Hashgraph consensus can reportedly withstand up to one-third of the network behaving maliciously. It is said to be asynchronous Byzantine fault tolerant—the highest level of security—which implies that honest nodes on a network continue to function even in the presence of malicious actors.

Fairness

Hashgraph is deemed fair because no single node or miner is granted exclusive rights to determine the consensus timestamp assigned to a transaction. Instead, the consensus timestamps for transactions are computed through an automated voting procedure in the algorithm, enabling the nodes to collectively and democratically establish the consensus. We can differentiate between three facets of fairness.

Fair Access

Hashgraph is inherently fair because no single node can prevent a transaction from entering the system, or significantly delay it. If one or a few malicious nodes attempt to block a specific transaction from being disseminated to the rest of the network and thus be included in the consensus, the random nature of the hashgraph gossip protocol, which facilitates communication between nodes, will ensure that the transaction bypasses that obstruction.

Fair Timestamps

Hashgraph assigns each transaction a consensus timestamp that is based on when the majority of the network nodes received that transaction. This consensus timestamp is fair, as it is impossible for a malicious node to manipulate it and cause it to deviate significantly from that time. Every transaction is assigned a consensus time, which is the median of the times at which each node claims it first received it. Here, received refers to the time when a given node was first passed the transaction from another node via gossip. This is part of the consensus, and so has all the guarantees of being Byzantine. If more than two-thirds of participating nodes are honest and have accurate clocks on their computer, then the timestamp itself will be honest and accurate, because it is generated by an honest and accurate node or falls between two times that were generated by honest and accurate nodes. Because hashgraph takes the median of all these times, the consensus timestamp is robust. Even if a few of the clocks are slightly off, or even if a few of the nodes maliciously give times that are far off, the consensus timestamp is not significantly affected. This consensus timestamping is useful for scenarios such as a legal obligation to perform some action by a specific time. There will be a consensus on whether an event occurred by a deadline, and the timestamp is resistant to manipulation by an attacker. In blockchain, each block contains a timestamp, but it reflects only a single clock: the one on the computer of the miner who mined that block.

Fair Transaction Order

Transactions are arranged according to their timestamps. Because the timestamps assigned to individual transactions are fair, so is the resulting order. This is critically important for some use cases. For instance, consider a stock market, where Alice and Bob both attempt to purchase the last available share of a stock at the same moment for the same price. In blockchain, a miner might place both of those transactions in a single block and have complete freedom to decide in what order they occur. Or the miner might choose to include only Alice’s transaction, and delay Bob’s to a future block. In hashgraph, there is no way for an individual node to unduly influence the consensus order of those transactions. The best Alice can do is to invest in a better internet connection so that her transaction reaches everyone before Bob’s. That’s the fair way to compete.

Conclusion

Hashgraph presents a compelling alternative to traditional blockchain technology. With its unique approach to achieving consensus, it promises higher throughput, fairness, and security. However, like any technology, it’s not without its challenges and criticisms. As it stands, Hashgraph is a patented technology, which raises questions about its decentralization. Moreover, while theoretically promising, Hashgraph is yet to be tested on a scale comparable to mature blockchain networks. Despite these challenges, Hashgraph represents a significant step forward in distributed ledger technology, and it will be interesting to see how it evolves in the coming years. Whether Hashgraph will revolutionize the digital currency market or coexist with blockchain as another option for building decentralized applications remains to be seen. Nevertheless, its innovative approach provides valuable insights for the ongoing exploration of distributed ledger technology. Register today to become part of the digital currency transformation and seize the opportunities offered by this thrilling new category of assets.