We'd like to summarize the different actions taken to increase the number of validators on Kusama Network, aiming to open the discussion on the best way to do so on Polkadot Network moving forward. In the past 4 months, there were three mechanisms used to increase the numbers of validator slots on the network:
Public referenda pushed by community members and external motions by Council:
This mechanism was the first one used on Kusama to increase the number of slots: A community member submits a proposal for public referenda or an external motion (if the proposer is a councillor) that will after pass to the referenda queue. The proposal suggests what the new number of validators should be. The main weakness of this approach is the random choice regarding the number of validator slots to add to the set. The value randomness does not take into account factors such as network stability, minimum and average staked, number of nominators and number of waiting validators.
Although this mechanism was widely used at the beginning, we have moved to more controlled and gradual increase mechanisms. This is being used on Polkadot right now, as reflected in Referendum 2 aiming to increase the number of validators to 236 slots.
Scheduled events via democracy:
The scheduled event mechanism (submitted also either via public referenda or external motion to council) aims to increase the number of validator slots steadily upon certain conditions. In the case of Kusama, we reached the 500 validators milestone by using a scheduled mechanism decided by the council and proposed by a council member. Starting at a particular block number in the future, the number of validator slots would increase by 2 every 3600 blocks (which in Kusama speed means 6hs/1 era). This mechanism was repeated for about 150 eras until Kusama reached the 600 validators milestone. After, it was canceled to review network health metrics and develop the third mechanism, explained below.
Automatic increase function
After the 600 validators milestone was reached on Kusama, the council decided to propose a pause in the increase of validator slots to: 1. Analize metrics concerning network health, stake distribution and network bandwidth; 2. Come up with a mechanism that would allow an automatic increase of slots based on these metrics.
With this in mind, a mechanism proposed by the Parity and W3F teams is being implemented by a member of the community. The mechanism is based on the Minimum/AvgStaked ratio and follows 2 specific rules:
Rule 1: If the bottom 1% of validators (more precisely, ceil(0.01 k) validators) have an average staked value strictly above 40% of the global average, in the next era increase the number of active validators by 1%, i.e. k <-- min{K, k + ceil(0.01 k)}.
Rule 2: If the bottom 2% of validators (more precisely, 2 ceil(0.01 k) validators) have an average stake value strictly below 20% of the global average, in the next era decrease the number of active validators by 1%, i.e. k <-- max{100, k - ceil(0.01 k)}.
The goal of the function is to increase/decrease the number of validators based on the network's current status, taking into account the ratio explained above. The desired value of the ratio is configurable in the function, meaning the value depends on the decision of the community: on Kusama, we suggest a 40% value for the ratio. The mechanism will be tested soon.
The summary's goal is to open the discussion on the best way to handle validator slots increase. We invite all members of the community to leave feedback, comments and questions to move to a call to action on Polkadot in the future.