Open kianenigma opened 2 years ago
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.
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.
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 toDesiredTargets
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 thanValidators
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
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, thenElectionScore
.