HEDERA vs AVALANCHE: The Ultimate Decentralization Showdown
Disclaimer: As my readers may already know, I’m an independent researcher, and an Hbar enthusiast.
I’m not affiliated with Hedera’s management in any capacity, and my opinions are solely my own.
Moreover, I’m an architect by profession, and my expertise is definitely not distributed systems, but you’d be correct to assume that I have done required due diligence and do take full responsibility for the claims I make in this article. You should be able, on your own, to either intellectually corroborate or refute those claims. I acknowledge beforehand that some of my statements might come across as a bit extrapolated at times. I was purposefully aiming to create that deliberate tension between my opposing arguments when comparing those 2 networks, so as to easily convey to the not-so-technical reader the essence of my conclusions. This is not a deep-dive technical analysis, but rather a high level attempt to capture and explain complex consensus mechanisms in simple layman’s terms.
Let me get that straight first.
DLTs are not “trustless” systems, they are “trust amplification” systems. You always start with some initial trust, and you distribute that trust over time. You start with a handful of nodes, and you gradually expand those nodes. You start by controlling some stake and your influence in the network in the beginning, with the aim to let go of that control gradually, and you do that so that your system acquires resilience and becomes unhackable.
A network holding trillions of dollars of native Internet value should not be allowed to go down, it should not have a single point of failure. A global distributed database of money should not be controlled by a handful of people.
Proof of Work is faster than Proof of Stake in distributing influence.
1 node=100% Hash Power. You control the network, you mine all the coins, you write the longest chain.
2 nodes=50% Hash Power, and your influence immediately halves in two.
100 nodes=1% Hash Power. You now only have 1% influence over the network.
PoW is a powerful decentralization mechanism, but it unfortunately comes at a cost. It’s expensive, slow, energy inefficient, and because of the way the profit incentive model is implemented in the Bitcoin blockchain as an example, miners end up discarding the idea of further decentralization in favor of more consolidation in the hands of a few pools.
On the other hand, Proof of Stake mints all the coins beforehand. It has to do that, because it needs to calculate a percent influence from the total number of coins, so at any given time, the system has to be aware of the total coins in the network. You initially hold 100%, and you gradually distribute them away.
Holding all the coins yourself renders them worthless, sharing your coins accrues their value, and the security of your network.
PoS is slower than PoW in distributing trust, because a PoS network relies on its scarce resource (A coin) to be valuable as a premise to begin with. PoS advantages are that it’s cheaper, faster, and unlike PoW gives you some insight over who’s controlling the influence in the network.
So, without delving deep into the PoW vs PoS debate, both assume some initial trust, (Trust in the code, the consensus mechanism, the core developers, the tokenomics, etc…), and both aim at ultimately distributing and amplifying that trust to the edges of the network, albeit in different ways.
So the question becomes…
Are all PoS networks created equal? Are they all designed the same? What kind of PoS system should I trust? Which consensus mechanism using PoS is designed to gradually decentralize, and which one is, like Nakamoto Consensus, naively designed to resist further decentralization and ultimately consolidate? Which systems allow the gradual release of power and which become vulnerable if power is conceded?
But what is Avalanche Consensus first?
Avalanche primary network comprises of 3 chains, P-Chain, X-chain, and C-chain. Avalanche consensus is applied onto a DAG in the X-chain, which is optimized for payments and assets transfers.
Snowman Consensus is a specific implementation of Avalanche Consensus on the P-Chain and the C-Chain, both linear blockchains.
Avalanche on X-chain doesn’t totally order all transactions, but aims to only order its conflicting transactions, which are basically “double spend” transactions that are trying to spend the same UTXO.
To keep it simple, Bob has 100$. He gossips transaction A (I want to buy 100$ worth of Gold) to half of the network, and transaction B (I want to buy 100$ worth of Silver) to the other half of the network. Because of network latencies, each half now receives both transactions at different time intervals, in a different order, and each node, on its own, needs to figure out which TX to accept first and which to discard, and they all need to reach the same conclusion or consensus.
So how does the Snowball protocol (Avalanche without a DAG) achieve that?
As an example, imagine you’re the top left node in Figure 1 above. The initial ttansaction you received is A, so your preference is (Gold Yellow), and you set your initial Consecutive Success counter ß to 0. You then query a fixed preset number of nodes (ex: k=5, highlighted in red, out of the total nodes n=68), and you wait for a majority quorum size ex: α=>3. If the majority 3 is same as your preference, you increment your success counter ß (0+1=1). You sample again another 5 nodes at random, if you get the same majority color, you increment again your Consecutive Success counter ß (1+1=2). If you get a majority for a different color, you switch your color and reset ß to 1. If no majority is reached (ex: 2 yellow, 2 blue, and 1 node goes offline), you reset ß to 0. You repeat the same process and keep sampling until your Consecutive Success counter ß reaches a predetermined number ex: ß=10 then you terminate the algorithm, you decide on that final color, you execute the transaction and discard the other. Every other nodes does the same and they all reach the same conclusion.
The way these parameters are currently set in Avalanche are as follows:
n(network nodes)=1578
k(sample size)=20 nodes
α(quorum size)=14 nodes
ß(decision threshold)=20
One could immediately notice that there are no mathematical guarantees in this model to align with the traditional sense of Byzantine Fault tolerance, which requires 2/3 safety, 1/3 liveness deterministic thresholds.
Why sample k=20 nodes for example instead of a 2/3 of n, or 1/3rd of n, why should you parametrize α=16 instead of α=15, why choose 20 instead of 10 as your consecutive success counter?
Avalanche naturally pretested those numbers to achieve what it deemed were optimum results to reduce bandwidth, whilst achieving some high probability safety and liveness thresholds.
Unfortunately, the Snowball algorithm above is slow, and has poor liveness guarantees, if you had to choose nodes at random. A small number of malicious nodes can steer the decision in either direction and prevent honest nodes from reaching consensus.
Listen to Associate Professor John Augustine from IIT Madras referencing the paper “Stabilising consensus with the power of two choices” at min 43:06 where he explains that this majority sampling algorithm can only tolerate √n.
https://youtu.be/lroPq170RiM
The Avalanche whitepaper mentions the same:
“If f ≤ O(√ n), then the Snow protocols terminate with high probability (≥ 1−ε) in O(logn) rounds”, which basically just means that if malicious nodes f in Avalanche are less then 40 for a 1600 nodes network, then the protocol terminates with high probabibilty in 3 to 4 rounds.
40 nodes is only 2.5% of total nodes in the network! If the network is 10,000 nodes, it can tolerate 100 nodes being malicious. That’s 1% of all the nodes!
In our Figure 1 example, instead of tolerating 22+, 1/3 of 68, the network can only tolerate roughly √ 64=8 malicious nodes for liveness.
But wait? What happened to the strong mathematical definition of Byzantine Fault Tolerance BFT, which stipulates that in order for a distributed system to achieve the highest level of security, its algorithm has to make sure it can optimize and tolerate for a 1/3 malicious participants?
Yet Snowball settles for √n.
But the Avalanche team doesn’t give up! They optimise the system, or should I more accurately say… THEY CENTRALIZE IT!
So instead of selecting 20 nodes at random to query, they toss a global coin for everyone to follow, they create a bias to accelerate the drift towards one color or the other. They instead choose 20 nodes with the highest stakes. The more Avax a node bonds, the more often it is queried by other nodes. Now, I’m not sure exactly how this stake weighted selection mechanism is tweaked to work, but it sure seems to mean that if you hold 50% of the coins, you’re guaranteed to be queried 50% of the time, and it sure seems that it’s designed to keep the stewards of the Avalanche network in control!
You see, Proof of Stake means different things to different DLTs.
PoS is a weaker Proof in Avalanche. In Avalanche, you don’t vote with your coins on the order of transactions. In Avalanche, you vote with your nodes, 14 nodes to be exact, and PoS, instead of being a scarce resource to weigh your influence, is just a selection mechanism to choose the powerful and prevent the cheaper stake nodes from participating in consensus.
The total supply of Avax is 395,891,290M.
The circulating supply of Avax is roughly 268,777,038M.
A node’s maximum stake is 3,000,000M Avax, including its own stake and the stake delegated to it.
Here’s a small table showing the 40 nodes with the highest stakes. https://avascan.info/staking/validators?s=totalWeight%2Cdesc#tabletop
You can see that the top 40 ranked nodes hold around 100M in stake, that’s around 40% of the circulating supply (That’s 2.5% of 1600 nodes holding 40% of the stake), with the bulk of each node’s own stake being => 2M, and the rest delegated to it. Now, if you’re wondering who’s controlling these nodes, I’ll leave you with these snapshots from the Avalanche Telegram Group.
Now, that’s not how PoS in Hedera works. A better PoS is one that actually represents your true influence in the system. In Hedera all the nodes participate in consensus, all the nodes vote and weigh in with their coins. 1coin = 1 vote, and your power is proportional to the coins you hold. The Hashgraph measures that, and each node virtually collects 66,66% Hbar votes before commiting to a value. Now, that’s a strong mathematical guarantee. In Hedera, you would need to buy up more than 1/3rd of the coins to disrupt liveness (slow or freeze the network) and 2/3rd of the coins to disrupt safety (corrupt the database, double spend etc). Now that’s a hard protocol to break.
In Hedera, all nodes participate in the same protocol, all nodes are equal, all first class citizens. You spin up a node on Hedera, you vote, regardless if you stake a penny or a million, unlike Avalanche which has its first class citizens with a higher stake that dictate the consensus, and it’s 2nd class citizens on the receiving end, just validating and accepting the majority rule.
PoS is a filtration mechanism in Avalanche. You currently require 2000 Avax to spin up a node, and the reason Avalanche caps the minimum stake, is so that it’s expensive for a malicious node to cheaply spin up additional nodes (sybil attack).
If Avalanche allowed any node with any amount of stake to participate in the consensus queries (as a truly democratic and decentralized model should), a malicious actor holding a Million Avax would spin up a Million nodes with 1 Avax each, and that’s bad for the Avalanche consensus, because the bad guys now have 1M nodes against 1600 honest nodes, and if you allowed a random selection of any 20 nodes in the system regardless of their stake (as a truly democratic and decentralized model should), the Avalanche protocol has a higher probability of choosing the bad guys, and your system is jeopardized.
What do you do instead?
You optimise your protocol, or more accurately said…YOU CENTRALIZE IT.
You make sure your algorithm selects only the powerful few, that’s Emin Gun Sirer, and 19 nodes of his best friends.
You see, in Avalanche you don’t vote with your stake, you vote with your nodes. Avalanche is just a weak emulation of Bitcoin’s PoW, but it’s worse, because it’s got no coins at stake, no slashing…
But more on that later.
Hedera’s PoS instead translates sound BFT guarantees. It allows all nodes to participate, all nodes to be queried on equal footing, and collects 66.66% of all votes, and does that without actually sending any votes. No queries at all.
Now, that is BRILLIANT.
If you want to dive deep into the Hashgraph algorithm, here’s your video:
https://youtu.be/wgwYU1Zr9Tg
All Hedera coin holders vote democratically. You can stake 100 Hbar/node or you can stake a million, it’s your choice, and you get rewarded proportionally to your stake. If you had 1M hbar, you can spin up 1M nodes, it doesn’t matter, your influence will always be 1M hbar, because on Hedera, unlike Avalanche, you don’t vote with your nodes, you vote with your Hbars, and as long as no single or multiple malicious entities hold more than a third of all 50B Hbars in existence, your system is safe.
It’s true that in Avalanche, all 1600 nodes validate, but not all get queried, not all have a say in consensus. Only the powerful 20 get queried, they steer the ship. The remaining nodes just accept the color preference and the consensus the powerful in the system dictate.
Now let that sink in, which is more decentralized, a protocol that chooses 14 nodes out of the same powerful 20 to give you the consensus between A or B, or a protocol that weighs in 2/3 of its 50 Billion distributed coins. 14 nodes vs 16B coins voting. That’s easy math for me.
You see, the Avalanche protocol is not a BFT protocol in the strongest sense of the term, and that’s why it has to remain centralized. Avalanche is unable to democratize its stakes, and these will likely always remain high. The powerful few will never dare let go of their control, because if they did, the bad guys could easily take over.
On the other hand, Hedera’s BFT algorithm is built to scale, and is designed to allow gradual decentralization. The larger the distribution of the coins, the bigger a third of the Hbar pie in circulation. The bigger the pie, the more utility for the coin, the more expensive it is to acquire, and the more resilient the network.
In Avalanche, its risky to give up control.
In Hedera it’s better to give up control.
In Avalanche, the more concentrated the stake, the more secure the chain.
In Hedera the more distributed the stake, the more secure the chain.
Now that you know that the Avalanche PoS network has “nothing at stake”, let’s dive deeper.
As much as Avalanche likes to brag about its DAG, its consensus mechanism is a cheaper “longest chain” rule Nakamoto Style consensus, masquerading as a revolutionary “sub-sampling” Consensus, whereas in reality, this sub-sampling is more akin to an election mechanism that only filters the powerful to vote on 2 forks of the DAG. But instead of voting with costly scarce resources such as a valuable coin (PoS) or with expensive computation (PoW), the powerful 20 vote with… CHIT!
You heard that right. It’s all about the precious chit, literally! 😅
Now, before you go on reading, I strongly advise you to watch this full Avalanche Consensus video first, and more specifically watch 15:05 onwards to understand the remainder of this article below:
https://youtu.be/ZUF9sIu-D_k
Avalanche protocol is the same as the Snowball protocol described above, but optimized and implemented specifically over a DAG. Specifically, Avalanche is trying to resolve 2 conflicting transactions on 2 forks of the DAG. So let’s recap what the video explained.
Everytime a conflicting “double spend” transaction is issued, nodes query other nodes to ask them their preference for either one of the 2 forks. If a majority 14 nodes over 20 prefers fork A over fork B, you give A a chit and set its value to 1. You increment your confidence counter for A, and your consecutive success counter for A, and transitively upwards in the DAG, you increment A’s ancestors’ both confidence and success counters as well.
If chit is false=0 (14 nodes queried don’t prefer it), you set confidence for A to 0, and your consecutive success counter to 0. This automatically resets A’s ancestors consecutive success counters to 0.
To keep things simple, Confidence is designed to steer nodes and force them to converge towards one fork versus another. So when a node asks another node about its preference between 2 forks, the node replies with the fork that has the highest confidence counter.
In Bitcoin terms, think of it like the fork with the most proof of work every node is trying to rally after, but instead of expensive PoW, in Avalanche you just spin chit up.
The Consecutive Success counter is akin to block confirmation time in Bitcoin, it’s just a finality counter, because just like Bitcoin, Avalanche has to wait to resolve its forks before it makes any decision on either one.
The current finality counter for accepting and executing a transaction on Avalanche is set at 20 success confirmations. (At least 20 blocks deep).
Now does the above sound familiar?
If you thought “longest chain rule”, you would be totally right!
Avalanche just reinvented Bitcoin, but instead of voting with your hashing power, so that it’s prohibitively expensive for you to vote on 2 forks and revert history, in Avalanche you vote with cheap chits on 2 forks of the DAG without incurring any cost or penalties.
A breakthrough consensus mechanism indeed. No PoW, no PoS slashing.
Proof of Chit is the new kid on “the block”.
So let’s try to double spend and create money out of thin air on Avalanche.
In the example below, I showcase how an account A with 1M Avax, can send 2 transactions to 2 different accounts B and C, all 3 anonymous accounts belonging to the same malicious group, succeed in both transactions, effectively doubling a Million by minting another 1M Avax out of thin air, convincing half of the network of tx B and the other half of tx C.
The attack is as follows:
You prepare 2 Forks in secret. You stack 19 blocks on top of your “double spend” transaction, and you get ready to release both forks at the same time.
Network latencies will make sure half of the network receives Fork1 first and the other half receives Fork2 first. Since half of the network isn’t aware of a conflicting fork and cannot see it yet, no conflicts in chit or confidence counters are spotted between the two. The protocol queries for the top tx on each fork, and checks downwards to see if any of the 20 transactions on any fork are within some conflict set and finds none, gives all 20 transactions a chit, applies transitive voting downwards, increments both confidence and success counters on both forks, and 2 “double spend” transactions get accepted in different parts of the network. There you go, you just minted 1M Avax out of thin air.
Pulling such an attack is no easy feat of course. You have to be lucky on both sides of the network to get a majority of 14 queried nodes receiving the same fork to double spend, prefer it, vote on it and accept it. (The higher the % of malicious nodes within the network and the 20 sampled of course, the more successful the attack).
So how do you thwart or minimise the likelihood of such an attack occuring?
You guessed it right, you centralize Avalanche and you only select to query the 20 nodes with the highest stakes.
But hold on!
Something just doesn’t add up in this model!
What if the nodes with the highest stakes are the ones trying to pull that double spend, or mint free money?
Who’s going to prevent that?
Will they get slashed for behaving maliciously? No.
Will they lose their stake if they voted on 2 different forks with cheap chit? No.
Unlike Bitcoin which demands expensive energy to be able to fork a longer chain, manipulating history on Avalanche seems like a random walk, especially when you’re controlling all the stakes to get elected all the time, with no built-in penalties in your protocol to prevent you from abusing your own chain.
Now, I’m not saying that the nodes with the highest stakes are going to attempt such a feat. All I’m saying is, “YOU HAVE TO TRUST THEM NOT TO DO SOMETHING BAD”, which defeats the whole purpose of a decentralized Blockchain in the first place.
As mentioned in the beginning of this article, initial trust in a handful of nodes/developers to bootstrap a PoS network may be required at genesis, as long as the ultimate goal is to distribute that trust, and as long as you are able to do so. The issue I have with the Avalanche protocol, is that it is designed to remain centralized and under the control of only a handful of wealthiest nodes.
Unfortunately, The Avalanche protocol just cannot scale, and as much as Avalanche likes to claim it is decentralised, the Nakamoto Coefficient doesn’t lie. The number of nodes may lie, but the stakes don’t lie. The Nakamoto Coefficient represents the number of validators that would have to collude together to successfully slow down or block any respective blockchain from functioning properly, and here’s the number for Avalanche, estimated at 26 by a few sources online. As I’ve shown above, it’s actually lower than that. It’s only 14.
Now compare that with the full 39 seats of the Hedera Hashgraph Council members who will be the initial set of nodes bootstrapping the network.
Hedera is starting with an initial set of 39 nodes. Community nodes are estimated to gradually join later this year as well.
The Hedera Governing Council Members running the nodes are not currently required to purchase and hold Hbar. The Hedera nodes running the network are not staking Hbar yet.
The way the system is architected currently is as follows:
The Hedera Treasury consists of multiple cryptographically secure, multi-signature accounts.
The Treasury Account delegates (proxy- stakes) its Hbars to the nodes equally, so every node votes with equal stake on the order of transactions.
This is a temporary measure.
Once Hedera goes permissionless, any node will be able to participate in consensus with any amount of Hbars it stakes.
All nodes are equal, all nodes get queried, a truly optimized aBFT PoS mechanism.
This PoS IS NOT an election mechanism to filter the powerful. On Hedera, you vote your true weight with a scarce resource called Hbar, which will only get more expensive as utility grows and the network expands, a valuable resource which you have to pay for to acquire.
It is COSTLY to acquire 16 Billion Hbars to attack the system, and the more you buy of it to try and corner the market, the higher you’ll have to go and chase the price.
In Hedera, CHITS are not allowed.
The snowman++ consensus on the C-Chain (Smart contract linear blockchain) is geared towards even more optimization…
Or should I more accurately say…CENTRALIZATION!
Unlike the X-chain, the C-Chain relegates the ability of nodes to asynchronously propose blocks to the background, practically redesigning the “leaderless” part of Avalanche as a contingency plan, and instead, to speed things up and reduce the many forks on the linear blockchain, C-chain introduces a random selection mechanism for only 6 nodes (waiting in line for 5 seconds each) at each block height. And, as you might have already guessed, these 6 nodes are selected according to stake weight. So now we’re down from 1600 nodes proposing blocks at blockchain height H to only…1 node.
From the GitHub page, we read the below:
https://github.com/ava-labs/avalanchego/blob/v1.6.0-fuji/vms/proposervm/README.md
“-Validators are pseudo-randomly sampled without replacement by weight, seeded by S.
-maxWindows number of subnet validators are retrieved in order from the sampled set. maxWindows is currently set to 6.
-Each proposer gets assigned a submission window of length WindowDuration. currently set at 5 seconds”
In layman's terms, 6 nodes with the highest stakes are chosen for each block height just in case, but 1 ultimately proposes, and gossips the block. Now this part is not very clear to me (I couldn’t find any documentation), but I’m going to assume that upon receiving that block, all nodes validate and then query again the 14 nodes with the highest stakes for their preference to check if any conflicting fork exists, and just follow the same Avalanche protocol until the fork with the highest success counter is approved.
Are the confidence and consecutive success=20 parameters the same on both the X-chain and the C-chain? Mystery!
You see on Hedera, you have 1 chain, you have 1 DAG, and you transfer assets, and you do smart contracts and a lot of other things, and everything is totally ordered, and it’s asynchronous aBFT and it’s leaderless…
But most importantly, in Hedera you vote with your Hbar because the Hashgraph Algorithm is truly…
DECENTRALIZED…
I’ll just end with a final short comparison.
Decentralization is also the capability for a consensus protocol to scale. Sharding is one way to measure scale.
There is a limit to how much throughput and latency one shard can tolerate.
Hedera is capable of tens of thousands of TPS, 3 seconds latency and deterministic finality. With these powerful aBFT features, Hedera is able to issue state proofs necessary for inter-blockchain communication. Every round, every node changes the state of its accounts, computes a state root hash and gossips it to the rest of the network to get 2/3 signatures on it.
In layman's terms, It’s like a proof that certifies that whatever a single node IS communicating to another shard, it is indeed the 2/3 consensus of its own shard and that it’s not lying about it. You cannot forge a state proof. You can learn more from Dr. Leemon Baird at 23:10 onwards.
https://youtu.be/mYrTBxfanPU
Avalanche cannot scale and decentralize because Avalanche doesn’t shard.
Avalanche doesn’t shard because state Proofs in Avalanche are expensive, slow and unsafe to produce (Probabilistic finality is not good enough).
A shard in Avalanche cannot trust another shard.
Don’t take my word for it, listen to Zaki Manian, ex Director at Tendermint Labs (Cosmos) and Emin Gun Sirer, Founder of Avalanche, discuss interoperability (from min 48:30 to 50:10)
https://youtu.be/WL4vdAR0vSs
Here’s a snapshot from the Telegram channel that seems to refer to the same issue. (I am unable to confirm the veracity of the claims though):
Conclusion 1:
Avalanche’s algorithm protects its network by always making sure they have a high probability of electing the good guys to give you consensus (Chosen by Stake weight). This assumes perpetual trust in the good guys. That’s a weak assumption.
Verdict:
Semi-Trustless system. Semi-decentralized.
Conclusion 2:
Hedera protects its network by preventing ANYONE (The good guys and the bad guys) from acquiring 1/3rd of its total coins. It makes no assumptions of who’s good or bad. No single minority is in control, and everyone weighs in.
Verdict:
Trustless system. Highly Decentralized
I could go on and on, but that’s enough comparisons for one article.
If there’s a conclusion to be drawn here, it is the fact that most people don’t really understand the true meaning of decentralization when it relates to blockchains and the purpose decentralization is aiming to achieve.
Sure enough, It is not always black and white, and decentralization is definitely a spectrum.
Its boundaries is constantly being stretched and redefined.
Finally, despite my rough take on the Avalanche protocol, my respect goes to all the smart researchers on both the Hedera and the Avalanche team.
Different blockchains for different purposes and usecases.
May all the good blockchains prosper
