Let's do this, the active set size in Polkadot has been long enough at 297!

One last piece that we might want to improve before this goes forth much further is a way to allow a large number of validator candidates onchain. This is something that we fixed for nominators with bags-list, and for validators, the idea is to pre-sort them based on approval stake and use that to deal with a large number of candidacies. 

I expect this work to be done within the next months, and quickly thereafter queued for deployment. The tracking issue is [here](https://github.com/paritytech/substrate/issues/12719) albeit it is not super organized. 

In the meantime, if we proceed with increase to 500, we should note that the maximum number of validator candidates is set to 1200 right now, and perhaps we should increase that to 1500 or a bit more in order to deal with the natural excess interest in becoming a validator candidate. 

We do expect polkadot to reach 768ish or 1000 or 1536ish validators per relay chain eventually.  Yet, our high validator count was never a goal in and of itself, but instead supports more parachains.

At the moment though we've only like 200 validators doing parachain approvals even on kusama (see [6387](https://github.com/paritytech/polkadot/issues/6387)).  We're always making progress on this, but we learned much from the kusama mess in December, which helped [refocus us somewhat](https://github.com/paritytech/polkadot/issues?q=is%3Aopen+approval-voting) 

We should remove this cap on parachain validators before increasing total validator count for several reasons:

First, any small small subcommittee like this breaks standard byzantine security assumptions, which yes reflects poorly upon all those other PoS chains using subcommittees.

Second, we need validators' payouts to be primarily determined by their parachain work, but if we still cap parachain validators then payouts become more random and feel unfair.

We're inherently limited by gossip being O(n^2) of course, but we think parachain approvals can handle beyond 1000 validators like grandpa does.  But what if we're wrong?  Or even temporarily wrong?  It'll suck to go to 500 validators now, but then drop back to 400 later, due to removing the cap on parachain validators. 

We'll need CPU wasting common good parachains on kusama too, which improves confidence when removing this cap for polkadot.

In brief, our product is parachain slots, in that they determine the value of the whole ecosystem.  Ain't much point in more validators if they do not give more parachains, or worse temporarily complicate adding more parachains.

As an aside, we'll eventually go beyond the O(n^2) gossip limits by adding multiple relay chains, but doing so requires improving [this analysis by Byran Ford, et al.](https://arxiv.org/abs/1602.06997 ) 

tl;dr This is blocked on removing the cap on validators doing approvals work.

"We should remove this cap on parachain validators before increasing total validator count for several reasons" - what will this mean for points earned per Era and Nominator returns?

sea212 from Zeitgeist here. Just a little heads up: The proposal uses preimage length `0`. AFAIK this should lead to no change at all during dispatch of this proposal, the proper length of the preimage has to be supplied.

proposal query for proposal index 23:
```
    23
    {
      Lookup: {
        hash_: 0x8a9858782be312ee01e3c12adcbda468f8b8dc46a1e5f5cb029e0ce231ebd705
        len: 0
      }
    }
    15wznkm7fMaJLFaw7B8KrJWkNcWsDziyTKVjrpPhRLMyXsr5
```

Because I don't have the funds liquid right now I have yet to actually submit the preimage, might that be why length = 0?

When you create the preimage hash you have the preimage at hand, so you already know the length of the preimage and can add it as it was done in the following proposal:
```
  [
    24
    {
      Lookup: {
        hash_: 0x45c4a70f163a3ba27a666f813830076e0e9abb4cf6ddd62348ab81a0d6c5c8b3
        len: 655,477
      }
    }
    1ZTGLab6NqXtggd2ff2N9oKbPuQjbeu6P78MCFb3XDc9SjT
  ]
```

You can use the `democracy.propose` extrinsic for that.

I recently tested proposing only the preimage using a `len` of `0` in a local Polkadot clone and during execution (at which point the preimage was supplied already) nothing happend, whereas with proper `len` it worked.

I would like to see more detailed analysis of the amount needed to become a validator once we reach 500. Of course, lowering that 1.6MDOT is good for individuals, but it should not be at the cost of lowering the economic security of the chain too much. I actually might be able to simulate this myself and report back using the `staking-miner` tool. 

All in all though, we should be having this discussion as for the longest time Polkadot's validator set has be constant and with a few dozen parachain, it seems like a reasonable time to increase. 

So just out of curiosity why 297? What was the math behind not choosing a round number like 300. I've always found 297 an interesting choice. Or is it less of a choice and a result of something fundmental in design. And if so is 500 the right choice? Also, would this reduce the "minimum active bond" for nominators?

I appreciate the intent of this proposal, but I must cast a NAY vote for it at this time. The proposal suggests a significant increase in the number of active validators by adding 203 new validators, which is a 68.3% increase. I find this drastic change to be rushed and seemingly not well thought out due to the lack of sufficient arguments to back up the statement that adding 203 new validators will have the desired effect.

It's important to note that such a sudden increase has never been tested on Kusama, and there is no concrete justification for implementing such a drastic change on Polkadot without thorough analysis and testing. A more detailed analysis of the potential implications and benefits of this change would be welcome, rather than simply stating that having more validators will spread the staking amounts and include only community validators, as the proposer suggests.


While the goal of making validating more accessible is commendable, it's crucial to consider the potential risks and consequences of such a significant change. A better approach would be to conduct a comprehensive analysis and propose a more gradual increase in the number of active validators, allowing for proper testing and evaluation of its impact on the network.

I appreciate the initiative [@decentradot](https://polkadot.polkassembly.io/user/decentradot), but I'm also backing the Nay side for the same reasons mentioned above. I think there is no need to rush the jump from 297 to 500 active validators in one go in Polkadot.

As suggested, if a new Referenda would be up for vote, incrementing one validator every new era, I'm all for it.

I leave it here an example similar to the ones done in the past, in this case, it would bring the active set up to 500 active validators, with one new spot open every era.

![](https://i.imgur.com/CDmC4uk.png)

Hey,

Thank you for starting this referendum. However, I need to agree with the comments from the above and vote Nay on this one. 

We agree that it's important to expand the active validator set, but we're concerned that a sudden  increase by ~2/3 could introduce numerous potential risks. The status of such a large number of validators is uncertain, and we don't know if they are still active. Consequently, there is a possibility of triggering a slashing event if over 10% of them are offline.

It's worth noting that Polkadot/Kusama occasionally still experiences issues with disputes, and incorporating a substantial number of potentially underperforming validators might exacerbate this problem. We suggest adopting a more gradual approach to increasing the validator set, as has been done previously.

We would like to thank Arthur for initiating this conversation about expanding the validator set size and welcome further discussion on this topic.

Are you aware of the security assumptions and why that number was chosen in the first place?  
I think this needs a much wider discussion and testing prior to just voting on it.  
It needs to involve the security researchers who normally come up which such numbers, node-developers who can run tests and some economic discussion obviously.

Dear Arthur,

I have voted Aye as a show of solidarity.  Your effort to get this referendum up for discussion is admirable.  Thank you.

Like the others I prefer a gradual increase, my view being an increase of 4 validators each era up to 600.  Having this passed as a Super Majority vote would take a significant effort and there are many current beneficiaries who would see this fail.  

With that said, I would like for a SimpleMajority vote on this topic.  I think the community is interested and responsible enough to make such a decision providing that the outcome does not pose a risk to the chain.

CC:  Council

Totally support the increase of new validators to the active set. Voted Yes in solidarity. A Validator per era sound within reason, maybe even two as long as those slots are not taken by the big Validation houses of the ecosystem, as long as we bring more decentralization into the network.

To help make validating on Polkadot more accessible the following proposal aims to increase the maximum number of active validators per era from 297 to 500.

Currently validators require having at least ~1.663.500 DOT in nominations in order to have a chance at becoming an active validator. This has created a challenge for independent decentralized validators to get into the active set, even when getting support from the thousand validator programme. Increasing the maximum number of active validators per set should help make validating on Polkadot more open to individuals, and lower the nomination target barrier.

![](https://i.imgur.com/ymepSVw.png)
![](https://i.imgur.com/Kula6ci.png)

preimage hash: 0x8a9858782be312ee01e3c12adcbda468f8b8dc46a1e5f5cb029e0ce231ebd705
Encoded call: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.polkadot.io#/extrinsics/decode/0x0709d107

#112 Increase maximum active validator count to 500