System Parachain Collator Decentralization

[joepetrowski]

The Vision

This item is only partly technical. We often launch system parachains with Parity operated collators at genesis. We should either change this or have a fast plan to distribute collation duties. We've done this with some success but there's room for improvement.

Overall, what each parachain's collator set should look like is:

• 15 Invulnerables, of which only 2 from Parity/W3F, and
• 5 candidates elected via placing bonds.

The principles leading to this are:

• Collation is probably not profitable. Invulnerables will probably want some payment from Treasury as service providers.
• People don't want to compete in elections on multiple chains to do the same service. There is an opportunity cost to those funds being tied up.
• Collators with some reputation should be elected by governance as Invulnerables on some chains (they may get this reputation by running validators, or running collators by placing a competitive bond).
• A large number of governance-selected collators ensures single entities don't take over collation when there is little competition for the (not-so-profitable) slots.
• All that said, there should always exist a means for an entity to become a collator on a chain permissionlessly. About 25% of the collator slots should be open to an election, where the top N bonds are selected as collators.

The Plan

These are the primary technical things to be done. Once these are in place, most of the operation (requesting Treasury funds for operation, making the case to be an Invulnerable) should be handled by the collator community. This should be encouraged to reduce the reliance on Parity-run collators.

• Change from fixed bond, first-come-first-served model to a top N election. (https://github.com/paritytech/polkadot-sdk/issues/106)
• Make Candidate -> Invulnerable path more ergonomic. (https://github.com/paritytech/cumulus/issues/2782)
• Add ability for remote chains to report points/offences (https://github.com/paritytech/polkadot-sdk/issues/1481)

Also Discussed In:

• https://github.com/polkadot-fellows/RFCs/pull/7
• https://github.com/paritytech/cumulus/issues/1159 and linked Forum post in this thread

[rphmeier]

Now that we are going to a fellowship-RFC process, wdyt about resubmitting as an RFC?

[joepetrowski]

I can, but what do you think is the ideal outcome? The plan has been discussed quite a lot already in the Forum, and also has an OK on direction from auditors. I've already opened a PR to close 2782, really the final step is implementing the top-N election (I think @kianenigma already has an implementation in mind).

That is to say, although I always welcome new criticism/opinions, I don't expect major changes to direction. But if we primarily want to document these runtime design/economic decisions in one place, and expect that RFC approval by the Fellowship makes it easier e.g. to get Treasury funding for collators operating within this system, then yes I think it is worth it to submit as an RFC.

[rphmeier]

It's a fairly major change that it'd be nice to get explicit fellowship approval on as we shift the decision-making process of the networks. Of course, it has to go through governance either way, but it'd be a good signal and precedent.