collator-protocol: cleanup connecting to backing group

[alexggh]

There are a few things wrong with the way we are handling connecting the validators in the backing group:

1. validators_to_connect returns only validators in groups we already have a block to advertise and the last backing groups we advertised something to, that means that if our backing group changes, but we don't have anything to advertise it will continue to try to connect to the previous backing group and validator will log this and disconnect it immediately.
   On the validator you will seeDeclared as collator for unneeded para and on the collator you will see Connect/Disconnect requests. This will continue every reconnect_timeout(4s from each active signal) until the collator advertises something to the new backing group. This is harmless, but it pollutes both the collator and the validator logs.

2. A collator connects only when it has something to advertise to its backing group, this is a bit too late and we can improve it by connecting the collators to the backing group immediately after they notice their assigned backing group.

3. Staying connected to the last backingroup we advertised something does not work for elastic scaling because we have different backing groups and if the collator set is big enough that collators author just one block per group rotation, then we will always connect just when we have a candidate to advertise.

Proposal to fix:

Have collators always connect to the backing group they got assigned to and keep the connection open until backing group changes. Also, try to connect when have something to advertise or on timeout to have more chances of being correctly connected.

Todo

• Confirm that proposal does not have other undesired side effects.
• Tests

[alexggh]

Not needed anymore, removed the entire class.

[lexnv]

Nice one!

[ordian]

2. A collator connects only when it has something to advertise to its backing group, this is a bit too late and we can improve it by connecting the collators to the backing group immediately after they notice their assigned backing group.

The problem with that was that the number of collators of a parachain could substantially exceed the number of connection slots of validators. E.g. Moonbeam has around 80 collators. I think we set the limit high enough to alleviate the problem.

3. Staying connected to the last backingroup we advertised something does not work for elastic scaling because we have different backing groups and if the collator set is big enough that collators author just one block per group rotation, then we will always connect just when we have a candidate to advertise

also keep in mind there might be forks and even without elastic scaling in theory we could be connected to multiple backing groups because of that - since we connect to the union of the group for active view

---

Overall the changes make sense given that are well tested

Curious how much of this is expected to be affected by the collator protocol revamp @alindima

[alindima]

The problem with that was that the number of collators of a parachain could substantially exceed the number of connection slots of validators. E.g. Moonbeam has around 80 collators. I think we set the limit high enough to alleviate the problem.

This is a good point. Moreover, currently up to 3 paras can share the same core, so they effectively share this limit (without ensuring that it's fairly distributed).

With the revamp, we split the overall connection limit to the number of paras within view that are assigned to this core (and try to ensure it's evenly distributed).

One idea that could make this even smarter would be to have some other message sent to the collator protocol (by cumulus) which declares that it'll be our turn to author a block in X amount of time. With aura, we know for sure when that is going to be.

We get the advantage of being connected in advance without putting too much pressure on backing validators by connecting all collators to them at all times.

[alexggh]

One idea that could make this even smarter would be to have some other message sent to the collator protocol (by cumulus) which declares that it'll be our turn to author a block in X amount of time. With aura, we know for sure when that is going to be.
We get the advantage of being connected in advance without putting too much pressure on backing validators by connecting all collators to them at all times.

I like this idea very much, I'll try to have a look how hard would be to implement, hopefully not too hard.

[alindima]

One idea that could make this even smarter would be to have some other message sent to the collator protocol (by cumulus) which declares that it'll be our turn to author a block in X amount of time. With aura, we know for sure when that is going to be.
We get the advantage of being connected in advance without putting too much pressure on backing validators by connecting all collators to them at all times.

I like this idea very much, I'll try to have a look how hard would be to implement, hopefully not too hard.

CC: @skunert how does this sound?

[skunert]

One idea that could make this even smarter would be to have some other message sent to the collator protocol (by cumulus) which declares that it'll be our turn to author a block in X amount of time. With aura, we know for sure when that is going to be.
We get the advantage of being connected in advance without putting too much pressure on backing validators by connecting all collators to them at all times.

I like this idea very much, I'll try to have a look how hard would be to implement, hopefully not too hard.

So can a collator mess around with this by providing false data? If they lie about their turn it will mess up the connections, and I understand we have limited slots right?

[alindima]

One idea that could make this even smarter would be to have some other message sent to the collator protocol (by cumulus) which declares that it'll be our turn to author a block in X amount of time. With aura, we know for sure when that is going to be.
We get the advantage of being connected in advance without putting too much pressure on backing validators by connecting all collators to them at all times.

I like this idea very much, I'll try to have a look how hard would be to implement, hopefully not too hard.

So can a collator mess around with this by providing false data? If they lie about their turn it will mess up the connections, and I understand we have limited slots right?

This is about the happy case, when collators use the implementation we provide.

We were previously connecting only after we built the collation.
With this PR we will always maintain connections to the backing group (from all collators)

My idea was to have something in between: connect in advance but only once we know we'll have the right to author a collation in X amount of time.

The adversarial case you mention is handled by the revamped protocol (on the validator side)

[paritytech-workflow-stopper]

All GitHub workflows were cancelled due to failure one of the required jobs.
Failed workflow url: https://github.com/paritytech/polkadot-sdk/actions/runs/18416013367
Failed job name: test-linux-stable

[paritytech-release-backport-bot]

Created backport PR for stable2506:

• [stable2506] Backport #9178 #10058 with remaining conflicts!

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin backport-9178-to-stable2506
git worktree add --checkout .worktree/backport-9178-to-stable2506 backport-9178-to-stable2506
cd .worktree/backport-9178-to-stable2506
git reset --hard HEAD^
git cherry-pick -x db5c89ffb65503c766fec651cf4dabfa8c820398
git push --force-with-lease

[paritytech-release-backport-bot]

Created backport PR for stable2509:

• [stable2509] Backport #9178 #10189 with remaining conflicts!

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin backport-9178-to-stable2509
git worktree add --checkout .worktree/backport-9178-to-stable2509 backport-9178-to-stable2509
cd .worktree/backport-9178-to-stable2509
git reset --hard HEAD^
git cherry-pick -x db5c89ffb65503c766fec651cf4dabfa8c820398
git push --force-with-lease