election-provider: allow smaller solutions.

[kianenigma]

Currently, the election-provider-multi-phase pallet has a very very strict check that any solution must be of a certain size to pass the feasibility check.

This is not needed. In staking, we actually two values:

• Validators: akin to DesiredTargets
• MinimumValidators: missing.

We need to change the fn desired_targets API to actually return two numbers, analogous to the two values above.

If MinimumValidators is not reached, we raise an error. More than Validators is also not allowed. The range between [MinimumValidators, Validators] is allowed, where we prefer the larger solutions.

I think we don't need to actually encode

where we prefer the larger solutions.

In any way. A solution that has more validators probably also higher ElectionScore by nature. Else, we can explicitly sort/compare based on the number of winners first, then ElectionScore.

[kianenigma]

cc @jakoblell curious what you think before we start this. I think we have discussed this before, but can't find any records of it.

[jakoblell]

In any way. A solution that has more validators probably also higher ElectionScore by nature.

Quite the opposite. The most significant part of the solution score is min_support (that means the stake behind the smallest validator still getting elected) and if you distribute the same total staking amount among a smaller number of validators, the min_support value can significantly increase due to this (assuming that the nominations allow that, but this will likely be the case).

So if we want to compare different solutions with a different validator set size, this will need some kind of adjusted score value to account for the number of validators, for example as suggested in https://github.com/paritytech-secops/srlabs_findings/issues/243.