Polkadot - Gradual increase of active validator set to 372 validators

Governance
1

Dear Polkadot community,

I am creating this post to initiate a discussion on a proposal focused on the future expansion of Polkadot active validator set. This proposal outlines a one-year strategy to increase the number of validators on our network incrementally.

You can find all the specifics, including the detailed roadmap, proposed timeline, and in-depth analysis of the potential impacts, in the Full proposal document.

The proposed rate of increase is adding one new validator every three days. This gradual increment of validators is designed to improve the decentralization of the Polkadot network and provide a longer time frame for the rebalancing and optimization of nominator stakes on elected validators. In addition, this proposal includes an enactment delay of around 3 months in order to meet the time schedule of other upgrades required before the increase can commence such as an increase in the number of paravalidators as it already happening on Kusama with the proposal to Increase Parachain Validators to 250

Implementing a year-long roadmap into an on-chain scheduler significantly showcases OpenGov capabilities. It promotes transparent collaboration between Parity Core Developers and the Community and encourages cooperative execution of network expansion plans.

This proposal builds upon two previous referenda which failed to pass due to concerns over network security, stability, and dependencies on specific GitHub issues. A substantial one-off increase in active validators might expose the network to heightened security risks and potential instability. The timeline proposed in the previous gradual increase proposal was considered too brief, and there were concerns that the same number of paravalidators spread across more validators might weaken network security.

A clear timeline is set out to ensure the structured and timely implementation of this proposal. We aim to launch the proposal on-chain on July 15, 2023, with the enactment approximately one month later. Subsequent months will be spent monitoring changes in the Kusama network and identifying potential issues. This delay is also aimed to provide a substantial time buffer for the launch of the Polkadot OpenGov proposal to expand the paravalidator set to 250 as described in the Network scalability roadmap. After an additional two-week buffer for final checks, the expansion of the Polkadot validator set will commence on December 1, 2023. The planned increase is expected to be completed by July 13, 2024.

The proposal addresses:

  1. The minimum required number of paravalidators.
  2. The economic impact on validator and nominator earnings.
  3. The influence of the validator set increases on the average stake amount.
  4. Alignment with the network scalability roadmap.




(Source: wpank Validator scaling Dashboard)

Pre-image with extrinsic proposing a 105 day (1,512,000 blocks) delay with 1 validator increase every 3 days (43,200 blocks) can be checked here:

https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.ibp.network%2Fpolkadot#/extrinsics/decode/0x01044012170001c0a800004b000000fe070a04

The number of days/blocks will be fine-tuned to closely match the described timeline before onchain launch. This proposal will be launched under the staking_admin OpenGov track.

2260×1600 333 KB

I’m looking forward to hearing your thoughts, opinions, and feedback on this proposal.

Thank you!

CS

2

At W3F research, we recommend against any increases to the number of validators until after the parachains team succeeds in completely removing the limitation on the number of validators doing paracains work. Ideally, this means set_max_validators no longer exists.

I’ve replied to 3 or 4 proposals of this form in the last couple months, so please see those proposals for the reasoning. In brief, sub-committees are always a mess for security.

If anything, we should remove the limitation on polkadot now before launching bridges, by reducing the number of polkadot validators to 200 or however many validators do parachain work.

5 Likes
3

Also, security level in the linked document are bullshit. You need concentration bounds like Hoeffding’s inequality to estimate bounds for random sub-committees. It’s worse, our randomness is imperfect so you need some model for the randomness first. We only need an easy randomness model for security of praos/babe or sassafras, but here you need something much better, and nobody worked it out.

4

Removing maxValidators from the code will take a while, since the active set is much larger on Kusama. We’re going to propose 250 on Polkadot soon and we could just disable maxValidators afterwards. Polkadot active set size can be bumped as work on the scalability roadmap makes progress and confirmed to work well at that scale on testnets/Kusama first.

1 Like
5

After discussing with several individuals closely involved with Polkadot’s scalability roadmap, I have received important insights and feedback on the matter. It appears unlikely that the number of validators (excluding paravalidators) on Polkadot will increase this year.

Another essential point that was highlighted is that the set_max_validators parameter will likely be removed first on Kusama, where it will undergo thorough testing before being implemented on Polkadot. Given the larger set size on Kusama, it may take some time before we see these changes reflected on Polkadot.

Taking into account the recentl information, I’ve decided not to move forward with the proposal for validator set expansion.