the solution seems obvious: a “limit one seat per customer” policy. … If a validator wishes to stake more some than twice the seat price, they can start a second validator, and incur the “penalty” of the additional operational complexity.
The reason why the current system is rewarding proportional to stake is that it’s “fair” mechanism.
Any non-fair mechanism lead to just more hacks that people will deploy. Specifically if one tries to force validators to have more “nodes”. For example, it’s pretty easy to add to neard right now an option to sign with as many validator keys as one wants. Hence it will look like there are a bunch of validators in the network - but in reality they all run on the same computer.
So we actually not increasing decentralization at all and decreasing transparency.
See Block and chunk producer selection algorithm in simple nightshade for a way to purely increase number of validators.
This still would have centralization of larger capitalized validators but would remove some of the current mechanics around the problem with not having enough stake due to seat price going up all the time.
One way to do this would be to up-weight any downtime in the your_adjusted_online_ratio by the number of seats held by the validator.
This an interesting option. This will need to be paired with more information in explorers around current offline ratio and penalty rate communication.
E.g. something like this validator has 0.99% online rate and is penalized with x10 because of large stake hence effective return rate is X%. Which would allow people to consider this information more when selecting validators.
where if that validator misses his expected block amount even by 1, he still gets kicked?
Kick out ratio doesn’t change as it’s in % missed blocks. So it’s just penalty on returns.
And mostly it will penalize delegators for putting on a large validator that doesn’t deliver 100%
I think one problem with this option in current setup is that validators may not want to accept more capital over some line and right now there is no way to restrict this. But this can be a good addition to the staking-pool contract version.