# Avalanche and Polkadot

*There are apparently some misconceptions about the Polkadot protocol within the [Avalanche](https://info.avax.network/#tech) community. Hopefully this will clear them up.*

> They are limited to 100 parachains (assuming they actually manage 1000 nodes)
>
> You are limited to 100 parachains (and that’s assuming they manage to get 1000 nodes working on the relay chain at any decent speed).
>
> Polkadot is hoping for 1000 validators on the relay chain (good luck with that with traditional consensus - to give them more time rather than process every block they validate chains of blocks instead which adds to the latency and gives them more time for consensus).
>
> The 100 parachains isn't a hard limit but it ultimately depends on the number of validators they are able to get in the relay chain. They may hit scalability issues with just 1000 and need to reduce that, or they may be able to get a bit more than 100 parachains. Either way 100 application blockchains isn't exactly a large number.

The current expectation for Polkadot that around 100 parachain/threads will be executed in parallel every block is our conservative estimate.

Despite the name, GRANDPA isn't actually that traditional. Kusama has 400 community validators and its GRANDPA instance delivers sub-second finality. Our tests indicate that 1,000 validators will be perfectly achievable.

As the core functionality is all of well-bounded complexity, we expect this number to increase as networking technology improves and additional well-understood cryptographic primitives are engineered and integrated. We expect this will allow us to push well beyond 1,000 validators and 100 parachain slots.

> It's the overhead in communication with every node sending to every other node which becomes harder, the larger the block size and the bandwidth / processing requirements increase, further leading to centralisation of people able to run nodes (like the case with Solana)

Polkadot was explicitly designed so that few subsystems (essentially GRANDPA and the availability system) require pervasive connectivity and the total bandwidth required on these subsystems is of well-bounded complexity, either small or growing only linearly. It is true that this does not allow indefinite numbers of parachains to be secured, but it does give us reason to believe that Polkadot's transactional throughput will grow over time.

Attempting to frame Avalanche as being a design that allows arbitrary numbers of chains to "be connected" in the same way as Polkadot is misleading and false. A Polkadot parachain slot (much like an Eth2 shard) comes secured with the full might of the whole network. Avalanche may allow more chains to be "connected" (much as Cosmos does), but generally speaking, these connected chains are far less secure than the central chain.

Owing to the fact that *useful* multi-chain applications need to be able to run across chains without considering underlying consensus security implications, this means that either security will be bottlenecked by having applications run only in the central high-security chain (little better than the present circumstances), or that inter-chain applications run only with the security of the least-secured chain (and thus are at risk of attack, again little better than the bridged side-chains we have at present).

This is a common trope and Avalanche isn't the first protocol to confuse "many chains" with "scalable". A truly scalable consensus system is able to execute *more state transitions*, all with the *same security guarantees* whilst still being decentralised and BFT. Kudos if those state transitions are Turing complete and executed at native speeds, as is the case generally in Polkadot.

Avalanche falls a long way short of this.

> The relay chain has finality of 12 - 60 seconds but that’s not really final, because you need to leave time for fisherman to challenge - the whitepaper suggests 60 minutes.
>
> So they aim for 60 seconds (which is still high) yet it can be reversed through a challenge of fisherman (that is their sole purpose and they don't specify a timeout for the fisherman to challenge before its final) - So whilst it might be unlikely it is still possible the block finalised in grandpa is reverted (as detailed in the video on the polkadot site where they go through that exact scenario).

Complete finality might take up to 60 seconds for a parachain transaction, and a few seconds less for a Relay chain transaction. Cross-shard finality is fully secure and unlike bridge-based systems has no latency.

As of the most recently published deisgn, fishermen are no longer required for our baseline security guarantees as we have introduced explicitly-appointed secondary-checkers from the validator set (see Section 4.4.2 Validity and Availability in [Overview Paper](https://arxiv.org/pdf/2005.13456.pdf)). Fishermen are kept since they only bolster security with no other implications.

Practically speaking, finality can take a lot less than the maximum if your transaction is small or your risk threshold is not absolute. Bitcoin has three typical levels of "finality": mempool (e.g. for paying for a beer), 1 confirmation (e.g. for small, online purchases), 6-12 confirmations (for the rest). These are situations of transactional-finality which represent varying levels of economic cost for reversion. 12 confirmations, roughly speaking, represents the economic cost of overturning 12 blocks of the Bitcoin network, essentially the ability to mine 13 blocks in that time (i.e. a comprehensive 51% attack). 1 confirmation represents the ability to overturn 1 block and effecively mine 2 in that time. If it's only in the mempool then it just represents the ability to not have the transaction replaced by a mutually exclusive alternative before it is mined, a comparitively easy proposition.

Polkadot could also be said to have sub-finality stages based on economic cost of reversion. These are not final in a theoretical sense but for particular levels of value, are final in a practical sense. If you're buying your sixth Lambo, then you'll probably need to wait a minute or so for the transaction to be fully finalised. If it's just a cup-of-coffee then arriving in the parachain's mempool or PoV block is almost certainly sufficient, which would happen in a few seconds.

It is also worth noting that while Bitcoin and proof-of-work chains in general have a bad rap for being only "probabilistically final", proof-of-stake chains, even ones labelled as having "instant finality", really give no absolute guarantee either. All crypto-economic consensus systems (whether blockchains, DAGs or anything else), are ultimately secured on... economics. Their finality-guarantee comes with certain economic caveats, usually that an attacker is economically rational or that they don't have *that* much capital to spend. If for some reason these don't hold, then all bets are off and your finality algorithm, whatever it is, isn't worth anything.

> As you are limited to a number of parachain slots then this means those 100 parties are competing with each other to get validated

Polkadot provides two market-based mechanisms for buying into its comprehensive security umbrella: Parachain slot leasing gets you a full slot for 6-24 months at a time. Parathreads allow you to pay a small amount for each time you want the chain's logic to progress (and thus transactions to be processed).

All practical systems require some anti-transaction-spam management. This comes in the form of fees. Having market-based mechanisms to manage what level of fees are required to get logic executed is typical and can be seen throughout the crypto-economic ecosystem.

Our estimates are that the initial version of Polkadot can probably process upwards of 4,000 *times* as many transactions per second as Ethereum. With 4,000 times as much supply, conventional economics would imply that the corresponding price for transacting be accordingly lower.

> With polkadot you also have the issue of potential censorship if relay chain doesn't validate block
>
> it leads to potential censorship

No idea how you would conclude this. It doesn't.

> you could end up having to pay enormous fees

Parachain slots do not require fees to be paid. There is the opportunity cost of the deposit and that is set fairly with an auction which depends on the market demand.

> every couple of years in an auction to keep your slot so that you can be validated or otherwise have to migrate your entire solution.
>
> ...or being forced to pay huge amounts of money to continue running your project on the platform or be outbid by competition and have to migrate everything over to a new chain with potentially all new tooling as well..

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. If for some reason a parachain is outbid on every auction throughout those 18 months and eventually loses its lease, then the parachain deposit is freed and it exists perfectly happily as a parathread until such a time that it raises enough of a deposit to become a parachain again.

There is no need for any migration, and while we cannot predict what the parachain slot market will look like, we are putting in a lot of effort to ensure that parathreads become a perfectly practical means of securing a application with Polkadot.

We can state a few facts about the costs of leasing a parachain though. Assuming there are 70 parachain slots, then:

- the cost for leasing any of those slots will be no more than what the 70th parachain is willing to bid;
- the ongoing costs of leasing a parachain will be at most 1/70 of the cost of securing Polkadot; and
- Polkadot security is efficient: we use fewer resources to secure Polkadot, in terms of the number of validators, than standalone chains.

The latter two points mean that it becomes orders of magnitude cheaper to secure the same transaction throughput in Polkadot than it would be in a standalone chain.

As such, costs can be expected to be a tiny fraction of what would typically be paid for the level of security and interoperatibly that Polkadot provides.

> The solution for connecting other blockchains such as ETH and BTC really isn't great either by putting another parachain in the middle between each connection (further limiting the number of available slots).
>
> and the solution to interoperate with the likes of ETH and Bitcoin really isn't a great solution involving a dedicated parachain in between each of them as a bridge taking one of the slots and massively adding to the time taken for finality to be achieved.

It is unlikely that a whole parachain would be needed for one bridge. Bridges, especially to slow-moving chains like Bitcoin, don't tend to be much work. Much more likely is that it's a parathread or that there is a single parachain that aggregates many bridges.

> ETH 2.0 has finality of 6 minutes, Polkadot says 12 - 60 seconds (but this is actually longer because there still needs to be a period where fisherman can claim they are invalid and actually has the potential to roll back committed blocks on the relay chain..
>
> It's pointless claiming you can process more tps than VISA when the finality window is like 60 minutes.

It's not. For low-value transactions, practical finality can be expected in a few seconds. For full security, you might have to wait up to 60 seconds (though it'll likely be less under normal operating conditions).

> AVAX you have sovereignty for each blockchain with no limits on the amount of blockchains that can be added and thus not potentially forced to pay extortionate fees to have your blocks validated.
>
> AVAX has less than 3 seconds (generally a lot lower than that) and as it has the default subnet which everyone validates then it can be used as a secure place to interoperate with other chains.

The security provided by Avalanche on its "subnets" is materially different to that of Polkadot and as such direct comparisons of performance cannot be made.

In reality, Avalanche is akin to a centralised version of Cosmos where *self-selected* and *overlapping* subsets of its validator group act as the security on the subnets.

This results in materially different levels of security across the chains within the system. Inter-shard attacks become feasible, as messages from one (less secure subnet) may be able to effect a transition on another (more secure) subnet. In effect, the entire system becomes only as secure as the least secure subnet.

The solution of having a single, central place to execute any logic which might be sensitive simply results in a scalability bottleneck and reduces the other chains to "second-class citizens" whose state-transitions cannot be trusted, similar to the Cosmos model. A truly scalable system provides the *same security guarantees* across the system, *regardless of where the logic is executing*.

Polkadot and Eth2 provide full security across the system. Notably, early versions of Eth2 circa 2015 played with the idea of inconsistent security on shards. It was eventually thrown out in favour of full security throughout. It is the only way you can have an single scalable application platform. Technologies such as SPREE which facilitate inter-chain applications rely on full security throughout.

As such, Avalanche is not a secure, scalable platform.

---
## More information
To find more information about:
* Polkadot please see [here](https://arxiv.org/pdf/2005.13456.pdf) and
* about GRANDPA please see [here](https://arxiv.org/pdf/2007.01560.pdf).

You can find a compilaton of FAQ [here](https://wiki.polkadot.network/docs/en/faq).

Please feel free to contact us for more questions.

[^1]: https://arxiv.org/pdf/1906.08936.pdf