Hedera Hashgraph is a recent cryptocurrency which claims to have a superior architecture than bitcoin's by achieving 100% finality and having higher transactions per second. It already had it's ICO valuing it self at 5 billion dollar market cap, so is the hype for it justified?
The company will hold 90% of the supply of hbar coins for the first year and after will hold 66% of the supply for four-to-five years. Nodes, which make the distributed system run and make all the code change decisions, are distributed across 39 enterprises chosen by the Hedera Governing Council.
They have plans to eventually distribute all coins and have millions of nodes run by anyone around the world with “the basic requirements for bandwidth, CPU, and storage” but the basic requirements are not specified and how “basic” they are will determine how decentralized Hashgraph can be.
Hashgraph’s proof of stake is similar to Cardano’s Ouroboros proof of stake, as both use proxy staking, therefore the same distribution security issues of Cardano will be present in Hashgraph.
Hashgraph will assign staking nodes like bitcoin mining assigns mining pools. Proxy staking for someone who doesn’t already have over 1% staked will make the odds of getting frequent rewards slim ultimately making large pools like bitcoin’s emerge.
So instead of a 51% attack hashgraph will have to worry about a 33% attack and according to the Pareto principle 1% of individuals could very well control more than 33% of the supply. The cost of running a node might also make it unprofitable to run one if you have less than a set percentage staked on it, limiting the number of nodes possible to exist.
Hashgraph is a POS coin with a DAG architecture which allows for up to 10,000 tps for cryptocurrency transactions and 10 transactions per second for “other services”, making Ethereum able to process more smart contracts per second than Hedera, however they also say in the whitepaper that it will “increase systematically” but how much the tps will increase is not mentioned.
The coin is proof of stake to avoid sybil attacks, otherwise any malicious entity could just create a multitude of nodes enough to exceed 1/3rd of all nodes in the network and attack it, so to attack the network you’d need 1/3rd or more of the coin supply. The 1/3rd threshold is due to the algorithm being asynchronous Byzantine Fault Tolerant, meaning that independently of timing, the network needs more than 2/3rds of the stake allocated on trustworthy nodes.
When sending a transaction to a node, the node creates an event and tries syncing with other nodes, when nodes sync with each other it’s called Gossip Sync.
When Gossip Syncing, Bob’s node sends a message to Alice’s node with all the events Alice didn’t already have and Alice creates an event “celebrating” that exchange, then Alice’s node follows that by sending back all the events Bob’s node didn’t have and Bob creates an event for that too.
Alice and Bob keep syncing with other nodes, and those nodes do the same and so on. Each of Bob’s events hold the hash of the previous event, and the hash of the event from Alice which synced with Bob, with these hashes the graph can be constructed hence the name Hashgraph.
Each event holds a timestamp, digital signature of the event’s creator, the transactions and the two hashes.
Img 1. Hashgraph example
Every node has a copy of the hashgraph which it can use to “virtual vote” or, in other words, each node can use it’s own copy of the hashgraph which was built during all syncs with other nodes, to guess the stake weighted voting process and ultimately determine the order of timestamps of all events and thus transactions.
Each node has a copy of the hashgraph so they can determine the results of the voting process which every other node will also calculate using their copy of the hashgraph.
Each event has a round, you can calculate the round of each event and so can every other node. Each round has witnesses, the witnesses are the events which first appear in the round for each node.
Each child of the DAG is either the same round of the parent or the round after. The condition for an event X to be round r+1 where the parent event is in round r is the following: If an event X has a parent of round r and it can strongly see a super majority of round r witnesses, that event X belongs to round r+1. To strongly see a super majority of witnesses, the event X must have a path to more than 2/3rds of witnesses which also goes through more than 2/3rds of the witnesses.
A witness is either Famous or Non Famous, and this will determine whether the witness can be used to get a timestamp from an event of the previous round or not. To know if a witness is Famous or not, we need the votes of the witnesses in the next round. Each witness in the next round votes YES if it can find a path to the witness being voted on or NO otherwise. If a supermajority (+2/3rds) votes YES the witness becomes famous after votes get counted taking into account the weight of the each vote from the stake of the node. For the votes to be counted, the witnesses in the round following the round where witnesses are voting, will count the votes.
If a witness is determined Famous, it means most members received it fairly soon after it was created and thus the Famous witness can be used to gather a timestamp which will be used in the calculation of the stake-weighted median of all timestamps of an ancestor event.
For witnesses to count votes, they must strongly see the witnesses in the previous round which are voting, to strongly see them they must have enough paths to them which cover more than 2/3rds of witnesses doing the voting. If the vote counting witnesses strongly see enough voting witnesses to make a decision on the outcome of the election (votes must have a supermajority), then it will be decided whether the witness being voted on is Famous or Non Famous.
The purpose of strongly seeing witnesses is to avoid forks, where Bob makes Y event pointing to previous event Z and another X event also pointing to previous event Z and syncing the different versions with different people.
Finally, we find all the earliest ancestor events of famous witnesses which are also decedents of the event we're finding out the timestamp of, we get all the timestamps of these events and determine the stake-weighted median of all timestamps. The median will be the consensus timestamp of the event we're measuring and the timestamp of all transactions in it as well.
The ordering of events then done in the following order: round received, timestamp and then signature.
Img 2. Example of multiple rounds of counting, voting, and timestamp median calculation from edureka! channel in the this video.
.
https://help.hedera.com/hc/en-us/categories/360000096597-Network-Governance
https://www.hedera.com/hh-whitepaper-v2.0-300819.pdf
https://docs.hedera.com/docs/hashgraph-overview
