Hashport Explores: Hedera’s Main Strength vs Competition
“Hedera is not a blockchain, it’s a Hashgraph.”
I bet you’ve heard that a hundred times before!
So what exactly makes Hedera stand out from the competition, and what differentiates the Hashgraph from other consensus mechanisms? Let’s explore these questions through the lens of the different networks currently integrated with hashport.
The Consensus Algorithm
At the core of every distributed ledger is what’s known as its consensus mechanism. It is essentially the ability of nodes to reach the same agreement as all the other honest nodes in the network on the order of transactions submitted to the ledger. The honest nodes should be able to process those transactions in the same order and compute the same state (i.e. update the same account balances), even if up to a third of nodes are faulty or malicious.
Most blockchains either follow Nakamoto consensus, some modification of the classical PBFT consensus, or a hybrid of both.
Nakamoto consensus is just the longest chain rule, the chain with the most proof of work that any node can easily calculate to remain in consensus with the rest of its honest peers.
PBFT is a 3 phase communication between nodes to send votes and receipts of votes to decide on a yes/no question.
Ethereum, BNB Chain, and Polygon could be considered a hybrid of Nakamoto and PBFT, whereas Avalanche combines the probabilistic properties of Nakamoto consensus with its own Avalanche subsampling algorithm.
As an example, Ethereum emulates the longest chain rule by using (LMD-Ghost) to weigh its forks, and uses a BFT-style voting algorithm (Casper FFG) to checkpoint its blockchain epochs for finality.
Hashgraph is different in that it introduces a new consensus with a unique and desirable set of properties. So what are some of these properties?
Hashgraph vs PBFT vs Avalanche
BNB SmartChain and Polygon use the Cosmos-SDK and a forked version of Tendermint consensus which is inspired by the classical PBFT algorithm.
The Tendermint protocol proceeds in rounds, where each round has a dedicated proposer (AKA coordinator or leader). The leader selection is a stake-weighted round-Robin election mechanism, where leaders are rotated proportionally to their voting power.
The communication steps in each round are similar to PBFT. Under optimal conditions (If the leader is honest, and communication is timely and reliable, etc), Tendermint achieves consensus in three communication steps: “Propose, Prevote, and Precommit”.
Each of these steps have timeouts that expire and reset to prevent the algorithm from stalling (or else a node could wait indefinitely for a step condition to become true before proceeding to the next step). This continuous transition between rounds avoids liveness issues, and keeps the protocol running.
As one could deduce from the above, there may be more than one round required to commit a block at a given height.
A few reasons that might delay the termination of a round are:
• The elected leader goes offline (DDoS).
• The elected leader proposes an invalid block.
• The elected leader proposes a block that does not propagate in time.
• More than 2/3 of prevotes for a proposed block aren’t received in time by enough validators by the time they reach the Precommit step. Even though >2/3 of prevotes are necessary to progress to the next step, at least one validator may have voted <nil> or maliciously voted for something else.
• More than 2/3 of prevotes were received by enough nodes, but more than 2/3 of precommits for the proposed block are not received by enough validator nodes.
The way Tendermint resolves these “time delay” problems is by selecting a new leader and moving to the next round, or by increasing certain round timeout parameters over each successive round.
The same applies for Ethereum. In Bitcoin, the mining difficulty is what determines the rate at which the blocks get added to the chain. In Ethereum, time is fixed and is divided into slots (1 slot = 12 seconds) and epochs (1 Epoch = 32 slots). In every slot, a committee of validators is randomly chosen, whose votes are used to determine the validity of the block being proposed.
One validator is then randomly selected to be a leader in every slot, who is responsible for creating a new block and sending it out to other nodes on the network.
In Avalanche consensus, Avalanche relegates the X-chain leaderless block proposal mechanism to the background, and reduces “contentions” on its linear C-chain by introducing a stake-weighted random election of six proposers at each block height.
Each proposer is assigned a five sec submission window. A proposer cannot submit its block before its submission window starts (the block would be deemed invalid), but can submit its block after its submission window expires, competing with the next proposers.
One could immediately notice from the above, the “synchronisation” efforts required at each block height to optimize the timely production of blocks. All these networks have what we call “partial synchrony” assumptions. These “synchrony” issues arise because of the linear nature of blockchains, and the need to carefully resolve their forks. Due to network latencies, a blockchain node might temporarily have a different view of the network than its peers, and needs to wait to grow its assurance of its fork choice before making a final commitment decision.
Hashgraph consensus does not require specific timing assumptions between its communicating nodes for it to function safely. Hashgraph doesn’t need to slow down to resolve its forks. As the DAG structure grows, every node on Hedera always ends up with the same exact top-down global view of the Hashgraph as every other node. The Hashgraph enables this through its “Gossip about Gossip” protocol. A node can be offline for five minutes or an hour, it doesn’t matter. As long as it is able to ultimately sync with some other node, it immediately receives the full missing history of past transactions, and computes the correct final state.
Hashgraph is said to be completely asynchronous.
In leader-based systems, reaching consensus can be delayed for an unknown period of time or even prevented, if packets are delayed/dropped or a leader is attacked. An attack on a leader could result in a network-wide liveness issue, because a leader node is a potential bottleneck.
Hashgraph is leaderless, and thus any node can go offline for an undetermined amount of time without affecting the consensus of the overall network. This makes Hedera much more resilient to network attacks such as partitions, eclipse attacks, DDoS etc.
Moreover, all PBFT-based protocols mentioned above require in each round some quadratic message complexity to communicate their votes to their peers. This complexity grows as a function of the number of nodes in the network.
Here is a graphic to help explain how adding just one node at a time can exponentially increase the communication time required to send votes between all the nodes.
Even Avalanche consensus requires O(1) communication overhead per round for a few rounds in order to query peers for their fork choice preferences.
In comparison, Hashgraph requires zero vote communication overhead besides gossiping the signed transactions and their timestamps.
Because every node has a global view of the history of transactions (aka the Hashgraph), they calculate the consensus locally. Hedera calls that process “virtual” voting.
In addition to saving bandwidth, this process ensures that members calculate their votes according to the rules. If Alice is honest, she will calculate virtual votes for the virtual Bob that are honest. Even if Bob is malicious, he cannot attack Alice by making the virtual Bob vote incorrectly.
The above properties are major ones that allow Hedera to be faster, cheaper, and more energy efficient than most networks out there.
Speed vs Cost vs Efficiency
To compare our currently integrated networks, here are a few recent metrics:
Speed (As of Sept 2022)
Hedera: 10,000+ tps ( 3 sec to 100% finality)
(15M gas/sec)
Ethereum: 12 tps (10–20 sec block time)
(15M gas/block)
Polygon: 6500 tps (3 sec block time)
(30M gas/block)
Avalanche: 4,500 tps (5 sec block time)
(8M gas/block)
BNBChain: 160 tps at max capacity (3 sec block time)
(100M gas/block)
Transaction Cost (As of Sept 2022)
Hedera: $0.0001 fixed
Ethereum: $0.66 variable
Polygon: $0.012 variable
Avalanche: $0.02 variable
BSC: $0.19 variable
Energy efficiency: (As of Sept 2022)
The “UCL Center for Blockchain Technologies” (UCL CBT) and the “Crypto Carbon Ratings Institute” (CCRI) both issued different reports with slightly different results, analyzing the carbon footprint of nine PoS-based distributed ledgers including Hedera, Ethereum, Cardano, Tezos, Polkadot, Avalanche, Algorand, Solana, and Polygon.
In these papers, many calculations were formulated, amongst those a mathematical consumption model that was used to predict the expected energy consumption per transaction, as a function of network load. This model not only showed that the energy consumption per transaction of PoS-based DLTs was three orders of magnitude more efficient than that of Bitcoin, but highlighted significant differences amongst the DLTs themselves.
The metrics from these reports below:
Report 1:
Energy Footprint of Blockchain Consensus Mechanisms Beyond Proof-of-Work (UCL):
Ethereum: 557.13 wh/tx (After the Merge for 3000tps ~ 2.8wh/tx)
Cardano: 378.53 wh/tx
Polkadot: 115.56 wh/tx
Tezos: 10.95 wh/tx
Algorand: 5.34 wh/tx
Visa: 1.5 wh/tx
Hedera: 0.02 wh/tx
Report 2:
Energy Efficiency and Carbon Footprint of PoS Blockchain Protocols (CCRI):
Cardano: 51.59 wh/tx
Tezos: 41.45 wh/tx
Polkadot: 17.42 wh/tx
Avalanche: 4.76 wh/tx
Algorand: 2.70 wh/tx
Solana: 0.16 wh/tx
Report 3:
Energy Efficiency and Carbon Footprint of the Polygon Blockchain (CCRI):
Polygon: 0.1031 wh/tx
Conclusion
Some consensus algorithms have proofs that they are BFT, but the proofs rely on assumptions that do not reflect the reality of today’s internet which includes firewalls, botnets, DDoS attacks, worms, and viruses. Hedera achieves asynchronous BFT status, the golden standard for distributed network security.
Hedera is leaderless. Nodes transmit transactions simultaneously, which in turn enables a higher throughput consensus to be possible. Higher throughput allows for:
- Consensus nodes charging less for transactions, hence a cheaper network even when compared to Layer 2 solutions.
- Less energy consumption per transaction, hence a network that is more environmentally-friendly than most L1s.
Even though most of the hashport team has originally sprung out of the Hedera ecosystem, the hashport platform is agnostic in that it aims to connect all EVM and non-EVM blockchains. It holds no preference for a network over another. It favours no ecosystem over another. It is independent in that it has its own set of validators, its own fee structure, and its own set of rules.
We believe that the market is the fairest of all arbiters and rational economic players will ultimately decide which networks are worthy of retaining the world’s most valuable assets and which are not.
About Hashport
hashport is the enterprise-grade public utility that facilitates the movement of digital assets between distributed networks, extending their functionality in a quick, secure, and cost-effective way. In order to remain platform-neutral, hashport functions without the use of a proprietary token. The network is built on a robust and performant architecture, secured and operated by a group of industry-leading validator partners from around the world. hashport has passed a rigorous security audit and follows industry best practices; regularly performing comprehensive network tests to ensure the integrity of the network.
Website | Twitter | Reddit | Telegram | LinkedIn | YouTube | GitHub
Disclaimer: The information provided on hashport’s website does not constitute investment advice, financial advice, trading advice, or any other sort of advice. You should not treat any site content as advice.
New to trading? Try crypto trading bots or copy trading on best crypto exchanges
Join Coinmonks Telegram Channel and Youtube Channel get daily Crypto News
