Gavin Wood writes in response to avalanche protocol's doubts: The avalanche protocol is neither safe nor scalable

Original title: "Strike Back! Gavin Wood writing PK Avalanche Agreement"

原文作者： Gavin Wood

Phala team & NBSP;

Previously:

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. This is Polkadot co-founder Gavin Wood's response.

以下为 Gavin Wood 原文翻译：

Apparently, the avalanche Protocol community seems to have some misconceptions about Boca. Hopefully this will make sense to the avalanche protocol folks. & have spent & have spent

About:

"Boca only has 100 parallel chains" (suppose there are 1,000 nodes of these parallel chains).

"You only have 100 parallel chains." (Suppose each of these parallel chains has 1,000 nodes running at high speed on the trunk chain.)

"Boca is expected to have 1,000 validators," I hope your stuffy consensus makes sense -- so much time spent not on consensus but on validation blocks.

"Even though 100 parallel chains are not a hard limit per se, at the end of the day, each parallel chain needs a verifier. That's probably a hard limit, scalability is involved. Maybe Boca can have a little more than 100 parallel chains, but what's the point?

Boca was designed so that each block could execute 100 parallel chains/threads in parallel.

Throw away the meaning of abbreviation, GRANDPA[3]& NBSP; The consensus is not staid. GRANDPA achieves the subsecond block validation speed on a Kusama network of 400 verifiers. And that's just 400 validators. And our estimate of 1,000 validators is very easy to reach.

Given that the complexity of these core functions is currently under control, with the improvement of the network and the optimization of the development language, this number will definitely increase after the threshold is lowered. By then well over 1,000 verifiers and well over 100 parallel chains of slots will have joined the Boca network.

About:

"Communication from node to node will become more difficult, block sizes will become larger, bandwidth requirements and processing requirements will become higher, resulting in centralization of node operators (like Solona)."

The Design of Boca is clean, and there will be no heavy use of communications resources by the subsystem, which is essentially the GRANDPA Consensus and the other parts that ensure availability. The bandwidth requirements of these modules are also not high, either very low, or even the increase is linear. While this may not be a 100% guarantee that all parallel chains will be safe, there is reason to believe that Poca's trading capacity will increase over time.

It is misleading to think that the avalanche protocol, like Polkadot, allows any number of chains to be "connected". Polkadot parallel chain slots (much like Eth2.0 sharding) mobilize the entire network's capabilities to ensure security. The avalanche protocol may allow more chains to be "connected" (like Cosmos), but in general, these linked chains are far less secure than the central chain.

A useful cross-chain application should not worry about consensus-level security when running cross-chain. This means that it either runs in the middle of an extremely safe chain (only a bit safer than our current scheme), but is constrained by efficiency; Or the inter-chain application can only run on the chain with the lowest security (there will be the possibility of attack, so it is only a little safer than our current side chain bridge scheme).

Avalanche protocol is not the first project to swap the concepts of "extensibility" and "lots of links". A truly scalable consensus system should be able to perform state transitions with the same quality of security, while still being decentralized and Byzantine fault tolerant (BFT). You'd be great to be able to perform Turing complete state transitions at near-local computing speed, as Boca has done.

Unfortunately the avalanche protocol does not currently do this.

About:

"Acknowledgement time of the relay chainIs 12 to 60 seconds. But surely there is more to the Fisherman node than that, because the white paper says it will take 60 seconds.Then their target is 60 seconds (which is still high)."& have spent

"But this might be modified by the Fisherman node (which is what they are up against, because they did not explicitly date the block on the Fisherman node). Therefore, it is possible, though unlikely, to reverse the restored block in GRANDPA (as mentioned in the video on Boca's website)."& have spent

Parallel chain trade confirmation takes about 60 seconds, several seconds slower than the relay chain. But unlike bridge networks, cross-chain sharding is completely secure and has zero latency.

Judging from the recently released design update, we have introduced a clear secondary validation mechanism from the verifier module. Since we have introduced clearly appointed level II inspectors from the verifier set, there is no longer a need for fishermen to obtain our baseline safety assurance (see section 4.4.2, "Effectiveness and Availability" in the overview document). But the Fisherman nodes will be preserved because they help strengthen the security of the entire network.

In practice, if your trade is small or not so risky, your confirmation time will be far less than the theoretical maximum. Bitcoin's confirmation mechanism is divided into three levels: a memory pool (a transaction that feels like buying a beer), a block (a transaction that feels like shopping online), and six to 12 blocks (all the remaining types of transactions). This is all the block recognition levels, which represent different economic costs. The validation of 12 blocks, for example, means the cost of reversing 12 blocks, essentially the ability to dig out 13 blocks in the same amount of time (i.e., 51% of the attacks). To reverse one block, you need to be able to dig two blocks. To reverse a trade in the memory pool, you simply replace it with another trade before it is packaged by the miner. This layer is relatively easy.

It can also be said that Polkadot has a secondary recognition stage, and the rollback cost varies according to the situation. The finalization of a block is generally not a theoretical confirmation, but by specific circumstances, in terms of some specific economic costs. If you have five Lamborghinis and are buying a sixth, you will probably have to wait 60 seconds or so for the deal to be confirmed on the relay chain. And if you just want to buy a cup of coffee, it's clear that the transaction only needs to be confirmed in a parallel chain of memory pools or PoV blocks in a matter of seconds.

It is worth mentioning that everyone knows that such a PoW chain of Bitcoin only exists "probabilistic confirmation", but the PoS chain, even the chain claiming "instantaneous confirmation", cannot guarantee that 100% will not go wrong. In fact, all token economy consensus systems (whether blockchain, DAG[4] or others) ultimately derive their ultimate protection from the economy itself. Their security is based on economic considerations, because an attacker is usually an economically rational individual or simply cannot afford the cost of an attack. If none of the above is true, then there is no point in writing your consensus algorithm in a fancy way.

About:

"The slots are limited, so 100 parallel chains need to be reeled in."

Boca will offer two market-economy mechanisms to keep buyers' parallel chain experiences safe:

1. Buy out the slot lease for 6-24 months.
2. Using parallel threads, pay only a small fee for each logical iteration of the blockchain.

All systems need some level of anti-spam and anti-spam mechanisms, so we're charging for them. Market-determined fee rates and market-based enforcement mechanisms are also typical and common in the cryptographic economy.

According to our initial estimates, the original Boka could handle 4,000 times as many transactions per second as Ethereum. As the supply increases by a factor of 4, 000, in traditional economic terms, the price of the transaction should fall accordingly.

About:

"When the trunk chain cannot verify the block, it is equivalent to being reviewed"

"This may lead to an audit."

I don't know how you came to that conclusion. It's wrong.

About:

"You could end up paying a huge fee."

There is no service charge for parallel chain slots, only the opportunity cost and margin of a fair auction based on market demand.

About:

"You have to go to an auction every few years, otherwise [your slot will be occupied] the whole solution won't work."

"You have to be forced to pay a huge fee to continue running your project on Boca. You either have to win on the inside roll, and you always have to be ready to move to a new chain in case of a new one..."

Parallel chains can only be bought out for 24 months at a time. If the contract is to be renewed, it must be renewed 18 months in advance. So, a parallel chain has an 18-month reminder period. If you do not win an auction and do not win a slot during the 18 months, your deposit will be released back to you. You can use the money again for the next bid.

And even if you don't get a slot, there's no need to move. While we cannot predict what will happen to the slot market at this time, we will do our best to ensure that parallel threads serve as a perfect alternative.

Suppose we have 70 parallel chain slots, then:The rental cost of any of these slots will not exceed the bidding price of the 70th slot and the rental cost of any parallel chain will not exceed 1/70 of the maintenance cost of the Poca, and the sharing security of the Poca is very efficient, and the maintenance cost is lower than that of other non-cross-chains, depending on the number of veriators.

The latter two points mean that using boka is cheaper than using other non-cross-chain solutions with the same throughput.

As such, it can be expected that the parallel chain cost will be only a small fraction of the cost of paying for Boca security and interoperability.

About:

"When you cross a chain to another ecology, like ETH or BTC, you need to use a parallel chain every time (slots are harder to get)."

"When you cross the chain with BTC and ETH, because there is a parallel chain in the middle, the block validation time is greatly increased."

A bridge is unlikely to occupy the resources of the entire parallel chain. In particular, Bridges in chains with low TPS, such as Bitcoin, do not have a large workload and may only occupy a parallel thread, or may only serve as one of many Bridges in a parallel chain.

About:

"ETH 2.0 confirmations take six minutes, but Poca says it only takes 12-60 seconds (which might actually be longer... Because the Fisherman node still needs to be confirmed, and might cause the confirmed blocks to be rolled back..."

"Even if you claim to have MORE TPS than VISA, there's not much practical value if the confirmation time is 60 minutes."

It isn't. Small transactions can be confirmed in seconds. If it is for 100% safety, you may have to wait 60 seconds (although this is not common in normal operations).

About:

"You have full sovereignty over your block on avalanche protocol, can send the chain, and will not be blackmailed to verify your block."

"The avalanche protocol takes less than three seconds to validate. And since everyone can verify using a subnet, it's a perfectly safe, cross-chain operating environment."

Avalanche protocol's so-called "subnet security" is not the same thing as Boca's Shared security. Don't talk about performance comparisons.

In fact, the avalanche protocol is similar to a centralized Cosmos, with an overlapping selected group of verifiers acting as subnet security.

This results in significant security disparities across chains throughout the system. A cross-sharding attack is feasible because messages from one (low-security) chain can cause a state migration over another (more secure) subnet. The security of the entire network is equivalent to that of the least secure chain.

As with Cosmos, any solution that tries to design a central area to perform sensitive logic runs into scalability bottlenecks and degenerates some of the chain into "second-class citizens" whose state transitions cannot be trusted. A scalable system is one that has the same level of security regardless of which chain the program is running on.

In conclusion, avalanche protocols are not secure and scalable.

Original address: https://hackmd.io/@gavwood/HJrgddTxD

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