substrate icon indicating copy to clipboard operation
substrate copied to clipboard

session, staking: introduce static limit on the number of validators

Open andresilva opened this issue 2 years ago • 5 comments

We need to introduce a static value for the maximum number of validators allowed in staking and session, we can then use this limit to replace a couple of storage entries with length-bounded data structures, e.g. DisabledValidators, Invulnerables, OffendingValidators can use BoundedVec.

See: https://github.com/paritytech/substrate/pull/9448#discussion_r693232481

andresilva avatar Sep 07 '21 18:09 andresilva

Hey, so we can have the DisabledValidators, Invulnerables, and OffendingValidators use the BoundedVec. Apart from that. how are we having an upper limit, is it static or dynamic? And how do we want to validate it?

ShubhamPalriwala avatar Jan 06 '22 13:01 ShubhamPalriwala

I'm confused by "static" here. You want a global limit no chain ever exceeds? Or you want some more authoritative governance controlled limit?

We believe no substrate chain will ever exceed 3072 validators because we believe the OmniLedger sharding approach kicks in before 1500 validators, possibly before 768, and someone might require a factor of two so the set could be split. We envision doing this with the polkado relay chain eventually. We might require better randomness for this, but that's preferable to running gossip on more than 3072 validators.

burdges avatar Jun 25 '22 19:06 burdges

We want a static limit that can only be changed by a runtime upgrade, similar to what exists here: https://github.com/paritytech/substrate/blob/master/frame/babe/src/lib.rs#L176-L178, so that we can use this limit to use size-bounded collections like here: https://github.com/paritytech/substrate/blob/master/frame/babe/src/lib.rs#L198-L205.

For example this vector in session pallet can currently grow indefinitely: https://github.com/paritytech/substrate/blob/master/frame/session/src/lib.rs#L523-L530

cc @kianenigma ?

andresilva avatar Jun 27 '22 11:06 andresilva

How do the size-bounded collections help? It's weight computations?

I suppose 3072 fits nicely if you do not matter a factor of 2x or 3x but likely going that high requires other runtime upgrades, so it could be set lower if required.

burdges avatar Jun 28 '22 19:06 burdges

The static limit can be set by entities adding staking and session pallets to their runtimes, for the node I believe 3072 is acceptable?

Then add this bound to relevant storage items.

Might be an over simplification on my part.

Doordashcon avatar Aug 02 '22 06:08 Doordashcon

I've made a draft of the proper way to do this in https://github.com/paritytech/substrate/tree/kiz-properly-bound-staking-validators

@Doordashcon this is how you should go about doing https://github.com/paritytech/substrate/pull/12125. Nonetheless, as noted in https://github.com/paritytech/substrate/pull/11967#pullrequestreview-1079629888, this might be a little bit of an involved issue since it touches multiple pallets and perhaps you should work with someone from our team to do this.

I will try and create a new tracking issue for bounding the staking pallet, and devise a plan there. Hopefully we can come up with some better small steps for you to contribute through.

kianenigma avatar Sep 05 '22 09:09 kianenigma

Replaced with https://github.com/paritytech/polkadot-sdk/issues/255

kianenigma avatar Sep 05 '22 11:09 kianenigma