Disproving Gavin Wood’s FUD against Avalanche
In late July, Avalanche was attacked heavily by Polkadot.
It started when some Polkadot shills entered Avalanche Telegram, tried to shill Polkadot and triggered a debate. Suddenly, it escalated quickly.
Based on a publication from July 28, 2020 by Gavin Wood, CEO of Polkadot, who obviously see a dangerous competitor in Avalanche, he made many false claims about Avalanche: https://hackmd.io/@gavwood/HJrgddTxD#
But Avalanche noticed his FUD quickly. On Telegram, Kevin Sekniqi, COO and Co-Founder of Avalanche replied:
“I haven’t read it yet but I just scrolled to the bottom and saw this: “Furthermore, unlike Polkadot, Avalanche makes certain assumptions about new nodes being to collect a “statistically unbiased” view of the network. This implies an assumption that there are no network partitions of the variety that true BFT protocols are resistant against. This means it cannot rightly be called a BFT consensus protocol.”
Which is entirely incorrect and shows that Gavin knows nothing about Avalanche. Hence, this article is already flawed and can be ignored.
Avalanche is certainly secure against network partitions, and Gavin hasn’t really read the literature. “
Many people in Avalanche Telegram were confused why suddenly Polkadot shills attacked Avalanche and Kevin commented:
“Yeah super weird. I woke up to his post, when none of us made any comments regarding Polkadot.
Regardless, the whole post demonstrates lack of understanding of Avalanche from Gavin.
Nothing against on Polkadot, it’s a fine attempt to build a distributed system. But Gavin can’t come in saying what he said without being extremely correct into everything. And he very much wasn’t.
If I wanted to build PBFT all over again with multiple shards, I would have just done it. But indeed if I have time soon, I may need to respond to it. Respond to Gavin’s article or release mainnet?”
Steven Buttolph, responsible for engineering and Senior Systems Architect at Avalanche, arrived and disproved Gavin’s FUD quickly:
“I think he really made one comprehensible claim: “Avalanche doesn’t handle partitions.”
This is plainly incorrect. Sampling is performed over the current stakers in the network not the currently connected nodes. Sampling a peer that isn’t connected results in a query timeout, which resets the confidence values… so nothing is committed during a partition. Once the connections are reestablished, decisions are made again.
This is the second time this was a point of confusion by other projects… so I suppose we should try to make this more clear to people. “
Later, Collin Cusce, responsible for engineering and Senior Systems Architect at Avalanche, provided a detailed response on Twitter and pointed out many misconceptions and false assumptions which Gavin Wood from Polkadot did in his publication:
“@gavofyork
You, me, @stephenbuttolph, @kevinsekniqi, and @el33th4xor gotta have a little chat about this:
I’ll open with, I wouldn’t be surprised if I misunderstand things about Polkadot. I also know it wouldn’t change facts: that your claims can’t work.
When talking about asynchronous Classical consensus protocols, there’s an upper-limit of 33% safety and O(n²) messages per decision. From everything I’ve seen, GRANDPA falls under this category, and this means that it also has a worst-case scaling of O(n²) where n=node count.
One of our co-founders, @Tederminant, is the primary author of HotStuff, the most performant Classical BFT consensus protocol. It’s why Libra was going to use it. It’s also maxing at 100 nodes, which I suspect, is why Libra only had 100 expensive validator slots they were selling.
You’re aware of this limitation, though. This is why you created NPoS, which is something you call an improvement over standard dPoS, but in practice (and reality), it’s basically the same thing. People nominate their pals to be validators on the Relay Chain.
Every node you add to the Relay Chain causes a delay. This means your only answer is to limit the voting participant count and have people “nominate” voting by staking. This means you’re only having actual consensus done by the nodes in that pool of actual validators.
Everyone else’s security in the system is dependent on those nodes. Nodes which hold a hefty amount of power and as we’ve seen in other networks with a limited number of seats.
Regarding “shared security”: it’s only as strong as the foundational security. Avalanche is strictly stronger. To compare Avalanche with Polkadot, start with Avalanche consensus vs. GRANDPA. You can gut GRANDPA from Polkadot, replace it with Avalanche, and ditch NPoS entirely.
Your root consensus doesn’t scale meaningful participation. You have this idea that if people are voting for people who vote, that’s the same as participation. It’s not. Your security rests on a low number of voters who used either social pull or …anything… to get elected.
When I read your stuff it sounds like you’re building a mining pool, not a consensus protocol. It’s not shared security, it’s inherited security from those nominated members set to validate transactions.
There are principled ways to show that your protocol will work. This is what the Avalanche protocol papers prove. Yes, we have a different model, but our model allows for things like private subnetworks and fast coalition-building… things institutions have wanted for a long time
It also provides a system for public and permissionless networks to thrive. Got a cool VM? Put it on Avalanche. Got a niche use case? Want to be able to toss up lots of chains? Pop it on a subnet. Correct me if I’m wrong, but I don’t see that same capability in your system.
Avalanche works without regard to node count. We’re ad-hoc. Meanwhile… “Parachains can secure their slots for up to 24 months at a time and renew them up to 18 months in advance using the same deposit. Essentially, a parachain would get 18 months of warning.”
Reading your post, it seems that you’re saying Avalanche is only as safe as its least safe subnet. This is not the case. Subnets are a subset of the larger universe of validators. A subnet’s security is independent of the larger network. Cross-subnet txs aren’t enforced globally.
Yes, we chose a different model, one Avalanche can uniquely support. You chose your model out of necessity, but that doesn’t make it optimal for applications end users. You took something off the shelf, rebranded it “GRANDPA,” and said you’ve got the new hotness in your marketing
And with regard to marketing, don’t get me started on the vast amount of custom jargon you use to describe industry terminology. Rebranding dPoS as NPoS and saying it’s something totally different when the differences are super minor is just one example. Can you please stop this?
Some of your points make me think you didn’t read our documents in detail. “We assume a safe bootstrapping mechanism, similar to that of Bitcoin, that enables a node to connect with sufficiently many correct nodes to acquire a statistically unbiased view of the network.”
Then, your comment: “Avalanche makes certain assumptions about new nodes being to collect (in their words) a ‘statistically unbiased’ view of the network [2] [3]. This appears to imply a potential malfunction should the network be suffering a partition at the time.”
To clarify, these are two unrelated concepts. The first one talks about unbiased bootstrapping, which by the way, you need to assume as well, GRANDPA. Data validation is a VM implementation issue, not consensus. You want a blockchain you validate all the way up? VMs can have one.
Everyone needs a good set of peers to synchronize with, that’s all it’s saying. This is true for every network. This has nothing to do with network partitions, so can you expand on why you brought that up and how you don’t suffer from this?
With regard to partitions, when we query, we set bounds on timeouts, and if the query fails, you reset confidences. If enough queries time out, we don’t have a safety failure. Avalanche is safe under partition by design.
I can quote things too. “As the core functionality is all of well-bounded complexity, we expect this number to increase as networking technology proves and additional well-understood cryptographic primitives are engineered and integrated.”
So, your protocol is bounded by quadratic growth, and you’re hoping advancements in networking technology will bail you out. Good luck! I do not understand why you think cryptography will solve your consensus problem… you’re still capped, and Avalanche isn’t.
Gavin, I understand the need to defend your hard work. I get it. I can tell you think you’re onto something. I don’t think you do primarily because you’re limited by your consensus protocol. It’s the same story with everyone using Classical consensus. You’re not alone.
This is the problem that Avalanche solves, though. If you want to run an experimental VM on Avalanche, which works on some of your other ideas like parachains, there’s nothing stopping you from tossing up a subnet on Avalanche and doing just that. No more GRANDPA.
“Taken in aggregate, Avalanche is not a secure, scalable platform.” I disagree. This is like saying that AWS isn’t secure because some Joe can put up an insecure VM and talk to someone else’s insecure VM. Platforms equal freedom: freedom to succeed as well as freedom to fail.
I wish you all the success you can gather, but Polkadot isn’t a platform, it’s a closed membership service. Avalanche is a true platform. “
Source: https://twitter.com/CollinCusce/status/1288142879827861504
Shots fired!
Finally, Gavin Wood didn’t research carefully about Avalanche and made some wrong assumptions. Avalanche did a great job in addressing his FUD and providing an answer for clarification.
However, AVA Labs is aware about so much publicity since Avalanche is a truly revolutionary project. Avalanche is not easy to understand because it’s quite different from what we have seen so far. It’s just normal people have questions and tend to jump to conclusions how Gavin Wood did. But if he does so, he needs to base his accusations on facts.
Need more information about Avalanche?
Official website: https://avax.network
Telegram: https://t.me/avalancheavax
Medium: https://medium.com/avalabs
