Fix collator selection (take_candidate_slot) extrinsic in permisionless slots in system chains

[FaradayNodes]

We believe that it is appropriate to consider that the selection (take_candidate_slot) extrinsic should not be allowed to join the active set as collators with a higher bond can be kicked out from the active set while collators with lower bond remain active and system chains should be secured by validators with highest bond.

Faraday has been targeted and kicked out of the active set 18 times in the last 4 months while having more bond than others collators.

https://assethub-kusama.subscan.io/extrinsic/8199076-2
https://assethub-kusama.subscan.io/extrinsic/8201373-2
https://assethub-kusama.subscan.io/extrinsic/8204565-2
https://assethub-kusama.subscan.io/extrinsic/8219088-2
https://assethub-kusama.subscan.io/extrinsic/8258863-2
https://assethub-kusama.subscan.io/extrinsic/8343257-2
https://assethub-kusama.subscan.io/extrinsic/8352061-2
https://assethub-kusama.subscan.io/extrinsic/8358998-2
https://assethub-kusama.subscan.io/extrinsic/8368517-2
https://assethub-kusama.subscan.io/extrinsic/8376166-2
https://assethub-kusama.subscan.io/extrinsic/8381601-2
https://assethub-kusama.subscan.io/extrinsic/8385602-2
https://assethub-kusama.subscan.io/extrinsic/8390758-2
https://assethub-kusama.subscan.io/extrinsic/8395782-2
https://assethub-kusama.subscan.io/extrinsic/8402561-2
https://coretime-kusama.subscan.io/extrinsic/1895570-2
https://people-kusama.subscan.io/extrinsic/2566288-2
https://people-kusama.subscan.io/extrinsic/2672859-2

[bkchr]

A solution is being worked on here: paritytech/polkadot-sdk#7317

[FaradayNodes]

A solution is being worked on here: paritytech/polkadot-sdk#7317

Thanks Bastian!

It seems that the solution George is working on solves a different problem. Specifically, when a collator joins the active set, it kicks out a candidate from the active set and then reduces its bond to be active with a lower bond.

The problem I mention is a different one, namely that the extrinsic selection (take_candidate_slot) extrinsic should not be allowed to join as a permisionless collator and it should be done with the (register_as_candidate) and (update_bond) calls.

The network should be secured by the collators with the highest bond, but the (take_candidate_slot) extrinsic allows collators with a higher bond in the active set to be targeted and kicked out while others with a lower bond remain active.

[georgepisaltu]

1. It doesn't make sense (economically) to kick someone out if there's a free slot you can occupy with register_candidate. We can add a requirement that take_candidate_slot can be used only when the list is full but it doesn't have any functional impact.
2. You are not allowed to lower your bond if you're within the top candidates that will be selected for collation next session. There is a "trick" to do this if you leave intent and right after you leave you register back with a lower bond. As explained before, this is not a problem if other pay attention and start competing for the slot you're about to give up, but I agree it's annoying and unnecessary to keep watch for the slot like this, so that's why the fix in this PR was proposed.
3. If you just increase your bond to the maximum amount you'd be willing to deposit for the collator slot, your problem would actually go away because if someone kicks you, they can only do so with a higher bond, and you already bonded the maximum amount, so clearly you don't want to collate on this chain anymore.
4. It is intentional that take_candidate_slot is working in the way you describe, so that you are always incentivized to bond the maximum amount to secure your slot, in case someone wants to target you specifically for whatever reason. The simple solution is that, if they kick you out and there are collators with lower bonds, the person that kicked you made a decision against their economic best interest. Now you can rejoin the set by kicking a candidate with a lower bond and the collator that kicked you bonded extra for no benefit.

[FaradayNodes]

Collators with multiple invulnerable slots will use those rewards to artificially and irrationally drive up bids on permisionless slots.

What is the real use case for the take_candidate_slot extrinsic?
Why can't the take_candidate_slot be removed from being used in permisionless slots and only allow the register_candidate extrinsic?

[georgepisaltu]

Collators with multiple invulnerable slots will use those rewards to artificially and irrationally drive up bids on permisionless slots.

What is the economic incentive for them to do this? They are already invulnerables, they are collating and they are not bonding anything, they are fully benefiting from the bounty already. Why would an invulnerable bond extra on a permissionless spot just to take you out? What do invulnerables gain if there are no permissionless slots other than their own clones (for which they are essentially paying out of pocket for everything they bond over the minimum bond)?

Forget about economics, why would any invulnerable care if you're collating on permissionless spots or not? If they have something against you personally and they want to take you out, they need to pay out of pocket for this and not only outbid you, but bond so much as to outbid everyone under you that is still within the threshold, since you could just be rejoining with a lower bond by taking out someone else from underneath you. If you bonded the maximum amount you'd be willing to part with and all of this still happens to you, then it's just not feasible for you to collate on this chain.

What is the real use case for the take_candidate_slot extrinsic?

I explained above.

Why can't the take_candidate_slot be removed from being used in permisionless slots and only allow the register_candidate extrinsic?

This was the model we transitioned from when we introduced the collator selection model we have today. All of the design decisions can be found in the original RFC about collator selection as well as the PR that implemented it.

[FaradayNodes]

Hi George,

The collator selection pallet used a first come, first served fixed bond registration system paritytech/polkadot-sdk#106.
A simple permissionless collator selection system was requested and the take_candidate_slot extrinsic was introduced https://github.com/paritytech/cumulus/pull/2960collators

Collators can join the active set with the register_as_candidate extrinsic and place the desired bond as high as they like to secure their slot with the update_bond without directly attacking a specific collator.

New system chain collators are not welcome and are being targeted with the take_candidate_slot extrinsic.
Here is an example, I have removed the name.

This is creating a very hostile environment and the spirit of the ecosystem should be inclusive and avoid this kind of conflicts. If the collator selection can function properly without the take_candidate_slot extrinsic, I respectfully request that the Polkadot Fellowship remove it.

Faraday

[SimonKraus]

Thanks for the quote ^ @FaradayNodes - you have been offered to take over a slot. An established collator offered to remove one of their collators to make room for you.

That wasn't enough and you wanted to take 4 slots or more right away and kick out collators that were very friendly and welcoming to you.

You planted a seed of hostility and now you're not happy with the outcome - then just put enough money on the table (bond high enough). Runtime devs won't help you on that front.

[FaradayNodes]

Thanks for the quote ^ @FaradayNodes - you have been offered to take over a slot. An established collator offered to remove one of their collators to make room for you.

That wasn't enough and you wanted to take 4 slots or more right away and kick out collators that were very friendly and welcoming to you.

You planted a seed of hostility and now you're not happy with the outcome - then just put enough money on the table (bond high enough). Runtime devs won't help you on that front.

This comment has nothing to do with the issue we are dealing with.

However, I will respond briefly to clarify things. It is true that one operator offered an invulnerable slot, but the reality is that there were other operators who had been running permissionless nodes long before who indicated that they had priority, but the reality is that none of them got it.

The current model for allocating invulnerable slots to new operators is based on the creation of new system chains being created, which is not scalable as more operators start running system chain collators.

We have tried to push for a fairer and more decentralised system than currently exists, but we have been attacked by a small group of operators (including you) who do not want to give up their share of power.

Increasing the decentralisation of the system chains and improving the current allocation of invulnerable slots is a complex issue where all operators can work together with feedback, I would be grateful if you would not pollute this issue which has a clear proposal: remove the take_candidate_slot extrinsic.

[georgepisaltu]

This will be my last comment on this topic unless new information is presented.

First off, the invulnerable discussion is completely separate. While we are working on a change to the invulnerable protocol, there's no reason to get into it now.

Secondly, you keep proposing that we remove take_candidate_slot and we only use register_candidate and update_bond. I explained above but it is functionally the same. If there are 5 slots that will collate, and you're sitting on 3rd with your bond and you then get taken out with take_candidate_slot, just call take_candidate_slot to take out the 4th slot, you could even rejoin with a lower bond now that you're out. The person that took you out now has to put up a completely new bond to kick you again. If they're willing to do that for the 4th and 5th slots, then you would have been taken out even if we did the register_candidate + update_bond. All it does is generate more spam calls on chain for no functional benefit.

New system chain collators are not welcome and are being targeted with the take_candidate_slot extrinsic.
Here is an example, I have removed the name.

And then you give me a message from some collator that called that extrinsic on you. It's part of the protocol and it's working as intended. There is a very easy solution to all of this, especially after paritytech/polkadot-sdk#7317 lands, which is raise your bond so that nobody kicks you out again.

Meanwhile, you can still prevent this behavior by putting up a higher bond and watching the collator set at the session boundary. The chain emits a CandidateReplaced event which contains information about the target, the caller and the new deposit. You are already running a collator, you can just watch for this event and use the information to reregister automatically with a simple script.

This is creating a very hostile environment and the spirit of the ecosystem should be inclusive and avoid this kind of conflicts.

I am in the collator chat with you and this extrinsic is not what's creating the hostile environment. It is the refusal to work within the protocol design and actually bid for the slots that is fueling this discussion. There was no way to get into the collator set before the introduction of this extrinsic, now there is but you have to up your bids, can you just do that?

If the collator selection can function properly without the take_candidate_slot extrinsic, I respectfully request that the Polkadot Fellowship remove it.

For the last time, there would be no functional change to the protocol if we removed take_candidate_slot, there would just be more spam on chain. If you want that extrinsic removed, please propose an RFC detailing the motivation, the benefits and the drawbacks of your suggested change.

[FaradayNodes]

The take_candidate_slot extrinsic facilitates targeting a collator and I think Polkadot should adopt an agnostic approach