Election mechanism for invulnerable collators on system chains

[georgepisaltu]

Rendered version.

[bkchr]

I'm not sure if this proposal is the best way forward. With the migration of more and more logic to AssetHub, the collators on Assethub will have more "responsibility". Also with lower block times, the requirements are increasing and it is more important to have high reliable collators.
Also together with the AssetHub migration we will move staking to AssetHub. So, we could try to re-use it here. We probably generally need some changes to the way the collators are being paid and maybe having some bigger pot on AssetHub to ensure people are more incentivized to provide great collators. The pot should be paid out based on the number of blocks a collator was able to include in a session versus the maximum number they could have included theoretically.

We could also have some "secondary collator selection" logic for chains like coretime/people chain to have some testing ground for operators to "grow" and earn reputation, before they try to get elected on AssetHub.

Or we even go lower and change fundamentally the consensus algorithm to have a more open set. Maybe like having an election every session and operators are able to apply by bidding on these slots.

Not saying that all the things I dumped above make that much sense, but I'm convinced that we need something better for AssetHub to ensure we get the best quality etc.

[seadanda]

I had considered the use of some sort of staking-esque mechanism for collator selection along with a bigger collator set for the hub and some other tweaks and think it would be a great solution, but we'd need to look into how it would affect the cryptoeconomic assumptions of Polkadot (if it were to "compete" with validator staking) and it could be something that isn't economically feasible.
Along with the collator payment questions you mentioned there are a more open questions: solving the rewards for nominators of these hub collators/how the staking funds would be split.
Would people just have two nomination sets for the same bonded funds - one set of validators and one set of hub collators? Or would they need to have separate funds? That would mean there would need to be a reward-based reason for people to nominate hub collators which doesn't compete with the validator staking. Either way we'd need to have a separate rewards system for collator staking so people are incentivised to back worthy collators, but also ensure a healthy balance between the two, without degrading the overall CE assumptions of the chain.

There was originally that aim for a given ratio of staked:locked:liquid DOT, the locked proportion of which was previously mostly due to crowdloans but it was always less than expected and now since Agile Coretime it is gone completely. This Hub collator nomination mechanism could be a way to encourage more locked DOT outside of regular staking.

For the rest of the SPs I agree for sure that we could bring more stuff on chain rather than relying on a bounty which needs to be topped up regularly and then distributed, which is currently done basically as you've described (ratio of blocks produced to the number they could have produced) but manually instead of automatically on chain.

[jonasW3F]

After reviewing this RFC and RFC0007, I struggle to see the actual problem that is trying to be solved here. The whole concept of having “invulnerables” introduced by the latter RFC is that they are intended to have a permanent seat and are free from regular re-election. They are chosen and evaluated on a social layer through OpenGov. Does this system not work? Are invulnerables not showing up to do the work, exert inferior performance, or censor transactions? If things are going fine, I don’t think it makes sense to direct the necessary resources to revamp this system right now.

If there are problems, or we expect problems with the launch of Plaza which is reliant even more on a strong set of good collators, there are a few things that came to my mind.

1. The ratio of invulnerables to regularly elected seats appears to be odd to me with 15:5. If we assume that invulnerables are to be trusted (especially if we select a few) and we only need one for censorship resistance, a ratio of 5:15 would make more sense to me. There might be good reasons that are not explicitly mentioned in the RFC0007 for the chosen ratio.
2. Generally, I don’t think it makes sense to elect collators similarly to validators by using “other-stake” DOT. In the worst case, economic security becomes more fragmented, in the best case nominators have no clear incentive to make a proper selection. We’ve already seen that nominators pay less attention than they should to their selection even if they are at risk of getting slashed. Collators are not slashable, so there is no reason to expect nominators to do a particularly better job than some other simple mechanism. Additionally, I imagine there'd be a large overhead of computing NPoS also to determine the collator set.
3. Following the strain of thought from above, purchasers of coretime probably have a high incentive for a good collator set of system chains. They are building and relying on applications that link to functionality to these system chains, they want their users to be happy, and they want to make sure their transactions are not censored. I was thinking whether it would be feasible to endow every core with a vote for the collator set of each system chain. We could then run an election for non-invulnerables once per month using the votes of coretime owners and the NPoS algorithm that is readily available. Adding this utility to cores would have some implications on the price of coretime none of which I think would be negative. Of course, there’s a ton of details to be discussed and evaluated.

[burdges]

Invulnerables exist so that the project cannot lose access to the parachain state. A priori, I'd think invulnerable collators on system chains should be selected by the fellowship, plus probably whatever votes handle code upgrade.

As I understand it, non-invulnerables have an existing election mechanism based upon self-stake, which sounds fine. We could discuss if this should be fresh stake, not used for validators, or if we allow restaking here, aka multiple usages of the same stake. I'm unsure which of these we do now, but fresh stake requires worring about payouts vs validator staking, while restake requires worrying about collusion, but neither sound hugely problematic.

Am I correct that rewards come up here too, in that invulnerables or non-invulnerables get paid less? That maybe a concern, but it's overall okay to pay invulnerables less, because they have other motivations for being there.