With HIP-16 attempting to address the keys per validator per shard issue, would you be inclined to post a new discussion exclusively for dynamic key limitation?
I do agree that would be simpler than slashing at the lower bounds. Preventing the issue from occurring in the first place is preferable to allowing it to happen and then punishing the behavior afterwards
And what do you think about incorporating this idea from Soph?
I like how you extended my original proposal to reduce the reward of folks near the lower bound only targeting the validator with keys above 5. I think the number of 5 shouldn’t be static but instead dynamic like the the proposal of this HIP 16 to limit keys with a number that is dynamically defined.
But I also like setting a cap, like what what @CryptoTech mentioned above, and that Jack discussed in this comment
“caps out” here means reward start degrading for everyone’s delegations in that validator if they reach the max ONEs estimated.
If it is enforced, validators with too many delegations will be forced to open up a new validator moniker and communicate to their delegators to shift it over to their new validator.
Crypt0Tech, would you be willing to spin off a separate thread specifically for this component?
I realize that I’m asking you both to restart this process over again, and that most previous attempts have stalled out. I think - and hope - a new more streamlined proposal for both topics may stand a chance at gaining more traction