Subnets currently query the validator_set for the subnet in their parent. Every time the validator_set changes, an increasing sequence number is assigned to the new configuration, and the validators in the subnet pick it up to reconfigure the subnet accordingly.
However, not every update to the validator_set may be valid. It may be the case that while the validator_set already includes a number of validators, the min_validators requirement hasn't been fulfilled and the configuration is not valid and, thus, shouldn't be applied in the subnet. For the initial membership, validator processes already have checks to prevent the network from starting to validate if there's not a minimum number of nodes, but once the network is operating, any change to the validator_set will be picked up by subnet validators independently to if it fulfill all subnet requirements or not.
Proposal
The proposal is to introduce an intermediate next_validator_set structure that keeps track of the most up-to-date membership configuration whenever a new peer joins or leaves the network. If all the requirements set by the subnet are fulfilled, then the validator_set is updated so the new configuration can be picked up by the subnet. If this is not the case, no updates are propagated to validator_set, preventing in this way subnets from picking up an invalid configuration.
Ideally, we should also ensure that validator_set use sequential configuration numbers whenver is updated to prevent potential delays from happening in the application of the new configuration.
Background
Subnets currently query the
validator_setfor the subnet in their parent. Every time thevalidator_setchanges, an increasing sequence number is assigned to the new configuration, and the validators in the subnet pick it up to reconfigure the subnet accordingly.However, not every update to the
validator_setmay be valid. It may be the case that while thevalidator_setalready includes a number of validators, themin_validatorsrequirement hasn't been fulfilled and the configuration is not valid and, thus, shouldn't be applied in the subnet. For the initial membership, validator processes already have checks to prevent the network from starting to validate if there's not a minimum number of nodes, but once the network is operating, any change to thevalidator_setwill be picked up by subnet validators independently to if it fulfill all subnet requirements or not.Proposal
The proposal is to introduce an intermediate
next_validator_setstructure that keeps track of the most up-to-date membership configuration whenever a new peer joins or leaves the network. If all the requirements set by the subnet are fulfilled, then thevalidator_setis updated so the new configuration can be picked up by the subnet. If this is not the case, no updates are propagated tovalidator_set, preventing in this way subnets from picking up an invalid configuration.Ideally, we should also ensure that
validator_setuse sequential configuration numbers whenver is updated to prevent potential delays from happening in the application of the new configuration.//cc @dnkolegov @matejpavlovic