Fix (backing) relying on para ids being unique

[eskimor]

Here we assign a ParaId to a validator group as if that were a unique mapping. This needs to be fixed. Any other occurrences of this assumption need to be fixed as well. Goal should be that a parachain being scheduled on multiple cores does not brick it.

Without full elastic scaling implemented only one core will be successfully occupied in the end and all other potentially produced blocks won't make it (wasted effort), but the parachain should still be able to get some blocks included.

[sandreim]

Both node side and runtime make assumptions around a 1:1 mapping between parachain and backing group.

Problem

On the node side the statement-table crate implements a generic Table which is designed with the said assumption in mind. The table is used to manage own and received statements of different candidates under a given relay chain block. To instantiate the table we need to provide all the backing groups, and in the case of multiple cores assigned to the same para, only the last core group would be retained. The statement table will fail to import statements and generate BackedCandidates. Statements for a given candidate will be checked based on the backing group info - number of required votes, validator indices and authority ids. One can easily see how this fails if candidate is build on a core for which we don't have the backing group info.

On the runtime side things are even worse, we cannot reason about the CoreIndex, hence know the backing group when processing a backed candidate . So, even if only one core is occupied by a para with multiple cores assigned we wouldn't know the backing group, unless we test indices across all of them which raises a security issue as there is no way to ensure backers attest only their own backed candidate and not also other candidates on other cores.

Proper Solution

The solution I recommend is to introduce the CoreIndex in the CandidateDescriptor (or maybe in the outputs of the candidate) which will then allow us to improve the statement table to support multiple cores assigned to same. This would also allow to make the necessary changes in runtime inherent processing as we'll have the precise backing group information.

No easy hack available

I've been considering to get away without CoreIndex, but reality has hit pretty hard. While we can deal with candidates that are backed by the local node (then we know the core_index) we cannot deal with incoming statements unless we change the StatementDistribution protocol such that CoreIndex is specified with the statement. Then we can easily check if the ValidatorIndex is in the backing group assigned to CoreIndex. However this won't work with the runtime where the CoreIndex is not available.

That being said, I'd want to hear some thoughts on this. I'd argue that we should craft an RFC to for an extended CandidateReceipt, CandidateDescriptor and dependent structs as well as future proof it for further additions. We could support both the old and new formats to not break parachain teams, but we'll still have the pain to upgrade the StatementDistribution network protocol.

[sandreim]

Oh, or maybe there is a way to always be able to know for sure the core, based on validator index in the statement. We can always search all the backing groups and then we'd know the core. Would be a bit slower to process these, but will work in runtime and client.

[eskimor]

As discussed, for sure the proper fix is to have the CoreIndex as part of the candidate commitments, which we plan to launch this year. In the meantime accepting backing groups to attest to multiple candidates seems acceptable, as it only affects paras that actually make use of elastic scaling and the threat is only reward stealing and only easily achievable if the backers are also block producers: Otherwise the legitimate backers should usually win on a first come first serve basis.

Having this interim solution would not only benefit parachains needing this soon, but also allows us to parallelize work more: We could already have an elastic scaling solution that works and can fix issues/improve performance, while we are still rolling out/developing the candidate commitment solution.

[eskimor]

Actually. Not even reward stealing should be possible.
I think it should be possible that this is totally fine: We just need to ensure that a backing group can not testify on more than one core per block.