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.