Avalanche Agreement strikes back at Gavin Wood: Boca is just a closed membership service center
Original article by Collin Cusce, AVA Labs Senior software development engineer & NBSP;
You can make SnapFingers
& have spent
Prospects for the feed
On July 28, an Avalanche Protocol member collected some of the avalanche Protocol community's doubts about Boca and posted them to Riot's official group, including derogations about Boka's scalability, slot mechanics, and cross-chain performance. Then on July 29 Polkadot co-founder Gavin Wood Long articleIn response to this, he concluded that the avalanche protocol is neither scalable nor secure.
AVA Labs senior software development engineer Collin Cusce then joined the discussion and countered some of Gavin Wood's conclusions.
The following is the full translation of Collin Cusce's article
You, me, @stephenButtolph, @Kevinsekniqi (avalanche Protocol co-founder), and @El33thsor (Avalanche Protocol Co-founder and CEO) We need to talk about this. Let me start by saying that I wouldn't be surprised if I misunderstood the Polkadot. I also know that this does not change the facts: your claim is invalid.
When talking about asynchronous classic consensus protocols, each decision is capped at 33% security and O (n ^ 2) messages. From everything I've seen, GRANDPA falls into this class, which means that it also has a worst-case scale of O(n^2), where n= Node count.
One of our co-founders, @Tederminant, is the lead author of HotStuff, the highest-performing classic BFT consensus protocol.
This is why Libra USES it, it has a maximum of 100 nodes, which I suspect is why Libra only sells 100 expensive validator slots.
However, you are aware of the limitation. That's why you created the NPoS, an improvement over the standard dPoS, but in practice (and in reality), it's the same thing. People nominate their friends as verifiers on the trunk chain.
Each node you add to the trunk chain causes a delay. This means that your only answer is to limit the number of people who vote and let people vote by pledging "nominations". This means that you only need the nodes in the actual validator pool to accomplish the actual consensus.
The security of everyone else in the system depends on these nodes, which have enormous power, as we have seen in other networks with a limited number of nodes.
About "Shared security" : It is only as strong as the underlying security. The Avalanche agreement is stronger. To compare Avalanche with Polkadot, start with Avalanche agreement and GRANDPA. You can remove GRANDPA from Polkadot, replace it with Avalanche and scrap NPoS completely.
Your basic consensus doesn't extend to meaningful participation, you think: if people vote for those who vote, it's the same as participation. But it's not. Your safety depends on a small number of voters who either use social influence or... To the election.
When I read your material, it sounded as if you were building a pool, not a consensus agreement. It is not Shared security, but inherited security from those specified members that authenticate transactions.
There are a few principles that will show that your agreement will work, and that's the Avalanche Agreement paper. Yes, we have a different model, but our model allows for things like private subnets and fast alliances to be built, which are what institutions have long wanted
It also provides a system for public and unlicensed networks to flourish. Have a great virtual machine? On the avalanche protocol. Is there a particular use case? Want to throw away a lot of chains? Pop it onto the subnet. Please correct me if I am wrong, but your system does not see the same function.
Avalanche protocol works regardless of the number of nodes. We are specific. At the same time... "Parallel chains can anchor their slots for up to 24 months at a time and renew 18 months in advance using the same deposit. Essentially, parallel chains receive 18 months of warning."
Reading your post, it seems that you are talking about avalanche protocol security as well as the most insecure subnets. This is not the case. Subnets are subsets of larger validators, subnets are secure independent of larger networks, and cross subnet TXS is not globally mandatory.
Right, we chose another model, the one that we want exclusively to support. You choose the model based on your requirements, but that doesn't make it the best choice for your users. You take an off-the-shelf product, rename it "GRANDPA," and market it as a new highlight.
As for marketing, don't get me started with the plethora of custom terms used to describe industry terms. Rename dPoS to NPoS, say they're completely different when the differences are small, this is just an example. Can you stop doing this?
Some of your points lead me to believe that you have not read our documentation in detail. "We assume a secure bootstrap mechanism similar to bitcoin that enables nodes to connect with enough of the right nodes to get a statistically unbiased view of the network."
Then, your comment is: "The avalanche protocol makes some assumptions about the idea that new nodes should collect (in their words) a" statistically unbiased "network. [2] [3] If the network was partitioned at the time, this would seem to imply a potential failure."
To clarify, these are two unrelated concepts. The first one talks about unbiased guidance, and, by the way, you also need to assume GRANDPA. Data validation is a VM implementation issue, not a consensus. Do you want to validate blockchain all the way? A virtual machine can do it.
Everyone needs a good set of peers to synchronize, that's all. This is true of every network. This has nothing to do with network partitioning, so can you further explain why you raised this issue and how to avoid it?
On sharding, when we query, we set the timeout range, and if the query fails, you reset the credibility. If enough queries time out, there will be no security failure. By design, the avalanche protocol is safe.
I can also quote. "Due to the high complexity of core functions, we expect this number to increase as networking technologies evolve and other easy-to-understand cryptographic primitives are designed and integrated."
Therefore, your protocol is limited by square growth, and you hope that advances in network technology will help you out. Good luck! I don't understand why you think encryption can solve your consensual problems... You still have a limit and you just don't have one.
Gavin, I know the need to defend your hard work. I see. I can tell you that you think you are doing something. I don't think you're doing this primarily because you're constrained by consensus agreements. Everyone who USES classical consensus plays the same story. You're not alone.
But this is the issue of Avalanche. If you want to run an experimental VM on it and you want to run it on another idea (for example, a parallel chain), there is nothing that will stop you from putting a subnet on it and doing that. No more GRANDPA.
"Generally speaking, this is not a safe, scalable platform." I don't agree with this statement. This is like saying AWS is insecure because some Joe can build insecure VMS and interact with other insecure VMS. Platform equals freedom: the freedom to succeed and fail.
I hope you have all the success, but Polkadot is not a platform, but a closed membership service (hub). Avalanche protocol is a true platform.
reading
Boca founder Gavin Wood previously wrote: "NBSP;Gavin Wood writes in response to avalanche protocol's doubts: The avalanche protocol is neither safe nor scalable"
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
