Must properly update validator set if governance changes `max_validator_slots`
brentstone opened this issue · comments
Need a way to properly handle the reconstruction of the validator sets when this parameter is changed
Do you have a sense of how difficult this is?
Shouldn't be too difficult, just involves reconstructing the validator sets. Here is a rough general idea:
In finalize_block, at the beginning of a new epoch, read the value of max_validator_slots before and after calling governance::finalize_block. If the value is different, then need to reconstruct the validator set perhaps at the pipeline epoch only (can maybe get away with doing at the next epoch after the current too, since no DKG). Call some function reconstruct_validator_set(max_validator_slots, epoch) if so.
If max_validator_slots decreased, demote the appropriate validators to the below-capacity set. If it has increased, promote the appropriate validators from the below-capacity set in order to fill up the new validator set as much as possible.
@tzemanovic for visibility
Furthermore, a similar thing may be necessary if the validator_stake_threshold is changed, which dictates the other validator set boundary - between the below-capacity and below-threshold sets. However, the size of the below-threshold set is unbounded in principle, so it's likely unrealistic to iterate over these validators to determine which should be promoted to below-capacity in the event that validator_stake_threshold is decreased. If it is increased, we don't have the same problem, since we can more safely iterate over below-capacity validators to demote those to below-threshold.
Perhaps for a change in validator_stake_threshold, we don't do any extra processing upon detecting a change, and we instead put a validator in its correct place only when an event (such as a tx or slashing) changes its stake. I think this is fine since these validators are not participating in consensus anyway.
Governes