"Elastic" validator sets on Kusama

Is it possible or even preferable to hand over control of the validator size limit to an algorithm that has the highest number of previous honest block producers?

e.g., We have 50 or so validators waiting (who could be honest!) because the governance on Kusama establishes a limit on the number of validators. This sounds economically like a minimum wage; a “barrier” over which one has to “jump” to achieve employment. This barrier perhaps should, after bootstrapping, a la Kusama right now, be enforced by how the system judges itself to be honest according to its peers. This could include low-earning “trial periods” as a chance to prove this validator is able to behave honestly.

After putting this idea in the internal Substrate channel, some responses included:

@JAM: I’d be curious if it is possible to to add these hypothetical trial validators as block producers but not grandpa voters, or if there’s some reason these sets need to be the same

@joepetrowski: Conceptually, there is no requirement that babe / grandpa sets are identical. Not sure how rooted that assumption is in code. When I talked with Al, he said it would likely be the same set for a while. I think it is a good idea to add some sort of alternate mechanism for increasing the validator set size. We need more validators to support parachains, but a lot of bigger validators probably won’t vote to increase the set size because it just means they need to spin up more instances. At least as a first step, it could be just council motions that send the set increase to a vote with supermajority against to pass.

Gavin: here’s a big incentive [for the governance to increase the number of validator slots]: to increase the number of parachains it can process. it’s definitely possible to have more babe validators than grandpa validators; it was something we were considering, and it might yet happen. however the big problem is the allocation of rewards. babe is a mostly low-security endeavour. compared to grandpa, which is much more critical, as it’s what light-clients rely upon. we didn’t figure out a good way of splitting them, but it could be as little as 2% of the rewards for babe. so if we had, say, 300 babe validators and 125 grandpa validators, then each babe validator will get ~1/100th of what the dual-purpose validators get at the moment.

Perhaps this isn’t necessary for the near-term, but such a governance minimization on Kusama may provide useful if we have more (meaningful) proposals battle for attention as time goes on. I’d like to know what others think.

1 Like

I think this is worth discussion and we should start by identifying the costs of changing validatorSet size dynamically.

For one thing we’ve now seen that major network events like the recent timewarp can have long lasting repurcussions on the stability of finality, and that we probably need more stringent requirements (and potentially larger rewards and penalties for misbehavior) for GRANDPA validators. I would say separating the two types of validation, and their economics, is a prerequisite before automating the size of either set.

IMHO. there should to be a safeguard in terms of changing the ValidatorSet size dynamically under certain conditions (the client is updated to right version, latency, etc), makes total sense.

today’s problem is an exception, Yes we are Mainnet Kusama but ppl think is testnet, they are right on both assumptions, so in their minds this is not important…

There is one problem that everyone is overlooking (I think), is that the waiting to validate list gets stale because there is no incentive to be in that list right now whatsoever, there has to be certain degree of randomness (almost like a lottery) in choosing the Validators for the next set. The Validator set as of now after a while doesn’t change, in this case people who is already Validating will deploy as many validators as possible chocking the little validators out because they have the Min required to become a Validator.

Every epoch a certain number of validator (no matter what) should always be changed and re-shuffled.

This will create two things:
-everyone in that list will be ready to validate and are dead serious about it.
-more small Validators will be part of the network (bc there is a chance of reward). and also the network will be more diverse than what it is now. Having a validators set from 1 “investor” can run 25/130 servers is not ideal and far from it.