To clean up the queue, the TC Seat has decided to fast-track [motion 398](https://polkadot.subsquare.io/democracy/external/0xbacad43f5467717cb1edfba6317524dc1d24fe3246afbe6a8cea7ed5fae1ba5f), aiming to increase the active validator set to 400, with the following parameters:

- voting period: `403,200 blocks` (28 days)
- enactment period: `28,800 blocks` (2 days)

Dear Alistair, 

How much time is needed to gain confidence with the operations of 250 para validators on Kusama? 

I am asking from the perspective of fast-tracking same on Polkadot once confidence is established such that it enacts before or soon after this referendum enacts.  This referendum seeks to build to 400 with increments, so there's 20 era before the validator count of 400 is actually reached.



Dear Alistair, 

How much time is needed to gain confidence with the operations of 250 para validators on Kusama? 

I am asking from the perspective of fast-tracking same on Polkadot once confidence is established such that it enacts before or soon after this referendum enacts.  This referendum seeks to build to 400 with increments, so there's a little time before 400 is actually reached.



I would recommed against doing this until or at the same time as we increase the number of paravalidators to at least 250, like we will do on Kusama if https://kusama.subsquare.io/referenda/referendum/188 passes.

The issue is that selecting 200 random validators out of 400 validators can give a biased selection occasionally, reducing our security to being able to deal with 1/3 bad guys to less than 1/4. 250 paravalidators would be fine for 1/4. Of course if we had all validators being paravalidators, we'd be ok with 1/3 bad guys. That was always what we planned to do.

As I said in the previous discussion, any increases are blocked on removing the cap on validators doing approvals work, which itself is blocked upon
- various PRs like https://github.com/paritytech/polkadot/pull/6782 
- add thin VRF to schnorrkel and use it in approvals,
- debugging add these changes, and
- testing if all these changes make us fast enough, including in dispute scenarios,
- assessing costs in dispute scenarios,
- etc.

We're projecting early 2023 last I heard for 6782 et al being fully done, but..

In theory, grandpa works at this scale so approvals should work at this scale too.  Approvals needs more gossip messages than grandpa, but not that many more after 6782.  We'd one new researcher coming aboard who should hopefully helps us optimize the gossip protocols and improve their security, so if 6782 does not suffice then we'll do whatever needs doing to make this happen.  In principle though, if we identify that our networking really needs to be better then maybe this is blocked upon hiring more stronger networking people.  It's hard to commit..  <shrug> 


As I said in the previous discussion, any increases are blocked on removing the cap on validators doing approvals work, which itself is blocked upon
- various PRs like https://github.com/paritytech/polkadot/pull/6782 
- add thin VRF to schnorrkel and use it in approvals,
- debugging add these changes, and
- testing if all these changes make us fast enough, including in dispute scenarios,
- assessing costs in dispute scenarios,
- etc.

We're projecting early 2023 last I heard for 6782 et ll being fully done, but..

In theory, grandpa works at this scale so approvals should work at this scale too.  Approvals needs more gossip messages than grandpa, but not that many more after 6782.  We'd one new researcher coming aboard who should hopefully helps us optimize the gossip protocols and improve their security, so if 6782 does not suffice then we'll do whatever needs doing to make this happen.  In principle though, if we identify that our networking really needs to be better then maybe this is blocked upon hiring more stronger networking people.  It's hard to commit..  <shrug> 


As I said in the previous discussion, any increases are blocked on removing the cap on validators doing approvals work, which itself is blocked upon
- various PRs like https://github.com/paritytech/polkadot/pull/6782 
- adding thin VRF to schnorrkel and using it in approvals,
- debugging add these changes, and
- testing if all these changes make us fast enough.

We're projecting early 2023 last I heard.

Hi Jeff,

To confirm:

- Chain security would be reduced if we expand the number of active validators before `6782 et al` are completed 
- We can expect the above to be completed soon (early 2023 has passed)?
- You're recommending that we reject this referendum?

Yes, we should reject this.  We already have a security issue caused by the cap on validators doing approvals work, which worsens if we add more validators. 

We'll likely solve 6782, 7208, etc this summer, so they'll likely pass through the debugging pipeline by 2023, but..

We're unsure if our current pipeline fully addresses the limits on validators doing approvals work.  In particular, we do not have major networking improvements lined up yet, but maybe they're required, ala gossip topology, so no promises of time frame. 

As an aside, there is not necessarily a direct link between the number of 1kv validators and the total number of validators.  If people think 1kv rewards are too erratic, then maybe a solution would be to limit 1kv participants to one validator, instead of the current two (?), so then they all spend more time being elected. 


[@jeff](https://polkadot.polkassembly.io/user/jeff)

It is unfortunate but I'll switch my vote for the preservation of the network.  I've raised the concern to others within the 1KV.

The 1kv programme currently only allows 1 validator per participant.  

After the submission of [referendum 112](https://polkadot.subsquare.io/democracy/referendum/112), seeking to increase the validator active set to 500, the community discussed the possibility and the need of Polkadot increasing the validators set. 

Feedback from the proposals indicates two points:

- There's interest with increasing the number of validators of the active set **but with increments**;

- There needs to be some analysis on the effects of the increase to ensure there's no security concerns.

The results indicate that participating members would like to increase the active set to 400 with increments of 5 per era. They believe that this increase would not compromise the security of the chain and allow for natural (opportunistic) leveling as the set increases. Core developers have also agreed on similar increases by value: 

“With increasing to 500, the amount of DOT needed to acquire a validator will sharply reduce from 1.7 mDOT now, to just around 370 kDOT. We think this is overall unavoidable, but we would personally suggest first increasing to 400 and re-evaluate”

This proposal aims to increase the active set of validators by 5 per era, for 20 eras. The call also executes a one-time increase by 3 to reach 400 validators by the end of the 20 eras. Note that this initiative is submitted on behalf of a coalition of 1kvP validators.

- Preimage Hash: `0xbacad43f5467717cb1edfba6317524dc1d24fe3246afbe6a8cea7ed5fae1ba5f`
- Call data: [HERE](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fpolkadot-rpc.dwellir.com#/extrinsics/decode/0x1a0408070a0c010401000000014038000014000000fe070a14)

Please note this proposal is submitted as an external motion: meaning if/after Council approves, the community will vote in referenda queue for the final decision. 

Make sure to review and vote!

Send a batch of dispatch calls.
Unlike `batch`, it allows errors and won't interrupt.

May be called from any origin except `None`.

- `calls`: The calls to be dispatched from the same origin. The number of call must not
  exceed the constant: `batched_calls_limit` (available in constant metadata).

If origin is root then the calls are dispatch without checking origin filter. (This
includes bypassing `frame_system::Config::BaseCallFilter`).

# <weight>
- Complexity: O(C) where C is the number of calls to be batched.
# </weight>

#118 1kvP Validators Initiative: Increase Validators Active Set to 400