Summary: Add a limit based on BLS Keys to prevent validators to bid on lower bounds or below it.
Background: The upper and lower bounds were first designed to reinforce decentralization, the validators at the higher bound would need to set more keys in order to be in the sweet spot of the rewards and avoid being penalized by diminished rewards due to being beyond upper bounds. Now the boundary is between 1.35 / 0.65 Median Stake. And acting like that, the more the stake, more keys and more nodes could be spun up. Nothing wrong with that, except that the lower bounds incetives are being targeted by validators with large stake.
Motivation: Based on epoch 791 and on previous epochs, the pursuing for the lower bounds has reached a whole new level. As the pic below shows, the first single bls-key validator at slot 731 with 3.5kk (where the median stake is 3.2kk), from 900 slots. So the last 169 slots were all ocupied by multi-blskey validators. And most of it with far more than 4 keys, meaning a total stake higher than 15kk. This is repeating over and over, now we have validators which around 2.5kk unelected, and even if that validator achieve the medium stake, it would be unelected. The growth rate of the entrance barrier to be elected with this allowed action is only behind the shard0 db size growth. And the purpose of the incentive of the bid below the lower bounds that is to incentivize the election of small validators, is being deviated from the original function.
Could be discussed for sure, but I believe that something like that, would really⌠really prevent it from happening. Would you risk increase your rewards by 1% and possibly decrease it, by 30%? Having a 6% APY while all the others have 9 ~11%, would be really noted.
This has become a major issue. I consider it an abuse of the protocol
I think itâs even resulted in a DECREASE in total elected validators in recent weeks (someone feel free to fact check me)
I voted for 4 keys and 30%:
If a validator doesnât try to game the protocol then their rewards wonât be slashed. I would even be in favor of making it as low as 2 keys. Because it shouldnât matter how big or small your validator is, it should be prohibited either way
I do think that 50% or 70% slashing is excessive, however. But 30% is a pretty good figure imo. It needs to be sufficiently high otherwise this proposal would lose its effectiveness
Lastly, I think redistributing the rewards to unelected validators is a terrific idee
There must be a way to make bigger validators not be able to bid in the lower bounds with out having a slashing penalty. If it just made them not-elected from bidding too low should be enough in my opinion. A sliding scale of who can bid on the lower bounds and have the analytics page show that adding a key will put you in the red if you have so many keys. I love the idea, I think itâll be very beneficial for add more validators
I think thatâs a good idea, forcing an un election from validators bidding low to reap rewards of lower bounds. I dont think that has to be necessarily only for the âbig validatorsâ, it should be for everyone on the network - we shouldnât single them out imo.
Back to Crypt0âs post, I think capping the key count is a step in the right direction to avoid having smaller validators pushed out of election. The more we have, the more the network decentralizes - one of the projects goals.
If they bid too low they become unelected? Let me know if Iâm reading that properly. Becoming unelected is the equivalent of a 100% slashing penalty. Functionally the same
I do like the idea of putting something there to warn validators when they are over-keyed that they will incur a rewards penalty
Thatâs my understanding of what happens when you bid too low anyway, thatâs the risk you take to get higher rewards for your delegates. Please anyone correct me if Iâm wrong. I donât consider being not-elected the same as slashing. Slashing is taking away rewards, if youâre not elected you donât earn any.
If we was able to do a sliding scale depending on total stake, it would free up keys by default without making key caps to keep the security of the network
Thatâs probably not a bad idea and might be easier than having the network enforce a strict key count. Doing that may end up having validators with more keys drop them as a result; effectively doing the same thing as a cap would without enforcing it.
Having that mechanism would be somewhat of a âsoft capâ and is (imo) probably better to implement first rather than a hard cap limiting keys. That way all validators have the choice of assigning more keys and would be less enforcing by the dev team themselves - but rather the blockchain mechanisms would self regulate.
This is definitely some kind of issue when some validators are using autobidder-scripts to bid under median stake near lower bounds. Still trying to think a correct way to guide big validators into right direction, and thinking if it is a best way to hard limit bls-keys regardless of total delegated amount? This is not an issue with smaller validators, because max delegation can be set before amount of delegations will grow too much.
Are there any possibilities to calculate BLS key -cap individually for every validators based on total amount of delegations and current median stake? And if a validator is bidding with considerably more keys than needed for to stay between upper bounds and median stake, rewards will be decreased?
The ideia is interesting, but I believe that in order to implement that, would need a rework of the protocol, since the bid and the nodes are spun based on the KEYS system. In order to keep it simple, would be necessary to use the system that we already have.
Empirical data to demonstrate the clear flaw in the system and abuse their of. I would like to reiterate a âRound Robinâ approach to validator selection particularly when using multiple BLS keys. If an individual or group take the time to setup and configure a validator, I think it prudent of the protocol to round robin through all eligible validators before assigning additional slots to validators that are using multiple keys.
The key to decentralization starts with how validators are selected. Fundamental in my mind to ensure a more robust and secure network. The voting side of this, if folks feel strongly about how a big validator is voting, and wants to allocate their votes to them. Iâm all for the power of the people. I think decentralization starts with how validation is done, and security of the network should be the most important aspect of validator selection. Not how more efficient a validator business will profit off the rewards provided.
This is not just the responsibility of the validator, in my opinion, but also the delegator. How do we ensure security of the network and still provide the people with the voice they are given through their stake in the network? Should both of these reside in the same mechanism? I would argue, NOT, but that is not how Harmony ONE was established. Profits should not drive security of the network, validators, governors, and delegators all have a responsibility to ensure the security of the network by distributing the validation power until changes to the framework can be built to ensure a more reliable and secure network. Profits got us to this point, now we need to figure out a way to secure the network.
There are almost 200 slots that could be released from bigger validators by them removing excess BLS-keys, and there would be no influence on their APY. Only thing they should focus on is, that they should be bidding between upper bounds and median stake. I think that there might be no need for significant changes for validator selecting or rewarding unelected validators if bidding significantly under median stake with too many BLS-keys would cut profits.
I am not for slashing for going into the lower bounds. If a validator wasnât motivated with extra rewards they wouldnât bother to dive into it. All running into the lower bounds would do would be to run the risk of lesser rewards if they end up straddling the cut off.
Iâd just like to see the big guys not push out 7 little guys for more rewards.
That would be kind of a soft way to guide bigger validators to release those slots. Because as far as I understand correct, rewards are the same despite of bidding with extra amount of keys needed at 3,5kk-5kk or enough keys staying between upper and lower bounds resulting 5kk-7kk bid. Only thing that matters is signing percent and to stay between upper and lower bounds.
Shouldnât we just ask them to adjust their autobidding scripts a little bit higher? And if not doing it, then try to develop something to make it unpreferable way to proceed with bidding too low?
Cutoff doesnât have to be the median effective stake, it could be something like 85-90% from it. So that thereâs enough room for not losing rewards accindentally but still leaving a lot of more space to the smaller validators.
It would completely eliminate the need to slash rewards for validators who are over-bidding keys. And it would dramatically increase the # of elected validators immediately upon implementation. Weâd go from around 160 elected validators to around 280 elected validators (unsure how many of the non-elected validators are ineligible); a MARKED improvement
If the devs can do this, I support this proposal. Otherwise, Crypt0Techâs proposal may be the best alternative
Iâm not sure what youâre suggesting here, to keep the status quo? I may be missing something
The behavior of many of the mid-sized and larger validators is well known and has been going on for some time. (Obviously I donât need to tell you this.) Thereâs been ample time for them to stop pushing out the little guys but yet it persists. Human nature and greed isnât going to change without a catalyst. Slashing would be that catalyst
I donât consider being not-elected the same as slashing. Slashing is taking away rewards, if youâre not elected you donât earn any.