When is the right time to increase validator count on Polkadot / Kusama?

Governance
1

Title says it all.

Kusama and Polkadot have had the same validator count since their inception.

What are the advantages and disadvantages of increasing the number of active validators?

If we decide we want to increase the number of validators, what are the metrics that we should look at to indicate this would be safe for the network?

What is the long term goals for Polkadot and Kusama in this regard? How many validators is enough to provide a trust-less, unstoppable pool for the multi-(para)chain future?

2 Likes
2

I am bumping this thread, because there might now be a reason to increase the number of validators on Polkadot.

Recently Polkadot was added to: https://nakaflow.io/

This keeps track of the Nakamoto Coefficient for various Proof of Stake chains.

image
image1054×1750 101 KB

At the time of writing this, Polkadot is ranked #2 with a coefficient of 93 behind Mina which is 95.

If we were to increase the number of validators on Polkadot from 297 to ~320, thanks to the Phragmen Election algorithm, we will likely get our Nakamoto Coefficient up to around 100, and take the #1 position.

Kusama has been running steady with 1,000 validators since its genesis, so I think an increase to 320 would be of little technical concern. I am aware that number of validators can add a burden to the Parachains protocol, but someone who has that technical knowledge should speak on the effect of this change on the network.

Now truthfully, I don’t think there is really that much to gain by being #1 in this arbitrary list, but it always helps to cement ourselves as a leader in the blockchain ecosystem.

I would like to re-seed this conversation:

  • first figuring out if it would be fine to increase the number of validators to 320 on Polkadot
  • second figuring out when in general we should change the number of validators on Polkadot and Kusama
    • for example always to cement ourselves as a leader in such metrics
2 Likes
3

It is a good question. Not sure if anything has changed since the last time it was mentioned:

1 Like
4

We first need all validators to be parachain validators before adding more validators.

We discuss approval voting paramaters in Better approval voting paramters · Issue #640 · paritytech/polkadot-sdk · GitHub, and fractional relayVrfModuloSamples needs implementaiton, but roughly…

needed_approvals = 30 
needed_approvals * num_cores = relayVrfModuloSamples * num_para_validators

We want num_cores to be big since we sell those, which increases relayVrfModuloSamples, makes validators work harder, and pushes our networking and hardware limits.

We’ve like 40 real parachain cores on polkadot now, yes? We should gradually spin up 40 glutton parachain cores, and slowly reach relayVrfModuloSamples=8. We should not destabalize the network to kusama levels while doing this. If this works, then yeah we’re probably fine increasing somewhat.

We should not exceed 500 validators on polkadot until Alfonso, Alistair, Chen-Da, and I identify the target number per relay chain in a multi-relay chain setting.

1 Like