I agree we require an incentive/bonus to encourage people to delegate with new and unelected validators.
Your solution looks excellent, you have clearly put a lot of time and thought into the proposal. I think we all agree that something has to change, otherwise we risk making it very difficult and costly for any new validators to make election.
In order to prevent validators with a large stake from targeting the lower bounds should we make it impossible to bid on multiple keys, until you have multiple times the Median Stake?
i.e. If the Median stake was 5m you would only be able to bid on a second key at 10m. All validators with less than the Median Stake would fill the balance of free keys, until all 900 slots were filled.
I am not sure if this would solve the issue but thought it was worth putting it out for discussion.
For sure, it’s another way to approach as well. I believe someone proposed something like that as well. @TrickLuhDaKidz if recall. I would like this, since it certainly prevent any diving in the lower bounds, even by mistake. In the last couple weeks, the entrance barrier greatly increased by many factors and we don’t need a another barrier blocking the entrance of aspiring new validators. It’s already costly to run a server. The shard 0 db growth exponentially, the server costs are skyrocketing. Many new validators aspiring to join the, just left without being elected even once. If we don’t do something to ensure that the new validators board the protocol, we will be stuck with the same quantity and the cycle will never break. The big ones getting bigger and the new ones just going out, without a proper chance to prove themselves.
I have experienced first hand that ER is a key factor when gaining and loosing delegators. If a validators ER drops, and is no longer seen to be competitive. It is likely that the validator can expect un-delegations.
This creates a problem for many validators with large stake pools. As a validator you have a duty to your delegators to run your validator node in a professional manner and to ensure you are providing competitive returns for your delegators. By bidding on additional BLS keys you are providing your delegators with competitive rewards. However, you might also be taking a BLS key from a new or unelected validator.
I do not feel it is fair to pass judgement on validators because they are trying to succeed and grow. However, that said the pursuing of lower bounds rewards has had a negative impact on network growth and can make it near impossible for new and unelected validators to make election.
If it was not for the excellent community all working together to support new and unelected validators, many would quit before becoming elected.
I very much agree, educating delegators has proven to be a key component in the success of network growth.
I fully agree, that’s why I commented on your proposal.
Reading your proposal, I can clearly see you have an excellent understanding and the technical knowledge needed to present a fully throughout proposal. I unfortunately do not possess the technical knowledge to make such a proposal.
I can however, clearly see we have an issue with the entrance barrier for new aspiring validators and feel we can collectively find a solution that benefits new validators without penalising the larger or medium sized validators.
I see many problems with giving rewards to those with multi-keys in the lower bounds.
encourages centralization by pushing out/new validators from being elected
encourages bots spam (looking at you autobidder)
creates inconsistent network (validators are encouraged to take risks that sometimes don’t work out and they end up unelected)
a system disguised as the validator acting in the best interest of the delegator but really is about a validator taking risks between 0% (if unelected) and 0.20%+ increase in APR.
Delegators want decentralization. If we want to act in the best interest of all our delegators, we can vote in their interest and create a system that doesn’t incentivize taking such risks for such a small and inconsistent gain.
After the recent events. Now at epoch 837 Many validators have dropped out of election. The binance only, dropped around 20 keys. And guess what? All keys were taken. And even considered stable validators were caught off-guard and went unelected.
We have a pool of 83 Eligible validators, what could have been a NEW ATH on validator count, and possible reaching the 200 count, became just an awesome opportunity for those wishing to improve their rewards.
I know the team is really busy with the recent events but this question is becoming out of control, something must be done.
Can someone answer if this proposal is feasible and if it’s, if the VDAO allows, it can be put to vote? Thanks.
It is time we quit dragging our feet as a community
We know this issue exists. We see it every election. We saw it when external keys went from 800 to 900. We’ve seen it again this week, with the number of elected validators plummeting from ~167 to 149 currently
This is necessary for the future stability, security, and prosperity of the Harmony ecosystem
Over the course of several days, Binance and KuCoin both dropped out in separate epochs, but here we are today, and the number of elected validators has actually decreased by >10% from where we were before the network went down
The warning bells are blaring. The current system is not working as intended. So let’s fix it!
Im in support of this, but I need to point out inaccuracies when I see one.
I know you are annoyed, but being factual and accurate is important or it will undermine our position in the first place.
When Kucoin dropped, we reached an ATH of 170 validators - fact.
I get that the keys were taken up esp in Binance case and we should address this as a community, but when we provide selective statistics e.g not mentioning 170 ATH when kucoin dropped (crypto’s post), resulted in others (you) inadvertently using the wrong context e.g by saying there was a decrease of 10% validators when kucoin dropped) is counterproductive.
Also, when crypto says stable validators getting unelected and caught off guard, I think it were due to undelegations and/or not signing enough? I recall 900th slot was still about 3m, but I stand corrected if this is indeed not the case.
Anyway, back to the topic.
I personally think this recent incident has showed us the importance of having more validators. I know some would argue it would take longer to recover if we were more decentralized, but i think we shouldn’t muddle the recent outage with the fact that a couple of large validators, if malicious can choose to bring down a shard ANYDAY.
Thank you for this proposal, I definitively support the intention.
I made a similar proposal here with the dynamic key limitation :
Dynamic key limitation : The protocol will prevent to add a new key if that makes your validator bid below the 0,65xEMS. Note : If a validator looses some stake and bid below the 0,65xEMS, the protocol won’t delete automatically his keys, but this validator will likely have to delete manually his keys to stay elected and once done he won’t be able to add a new one (if the bid is under 0x65xEMS). This limitation will also give some relief to the validators who were fighting for keys and less stress/tension is expected in the validator community.
I find my solution more simple, fair and equal for everyone. No cap, no slashing nor extra complications, what do you think @CryptoTech ?
Well, I can’t say for the KuCoin event since it happened in the middle of the “spam crisis” and I’m pretty sure every validator was too worried with the whole scenario, to pay attention to something else. Not to diminish it’s importance, it’s just that, if there’s no network running, there’ll be no new validators as well, so priorities first.
But I recall that in between all those happenings, we had an EPOCH where we definitely had some real low stake validators elected, and this could happened within the time-frame when KuCoin dropped the keys for bad sign rate. We all know that when the spam attack was happening, most of the rpc calls where not working also the shard 0 was halted. No one was removing or adding keys. So this EPOCH was a perfect result of an EPOCH where the game was not being played. Was a perfect epoch to be repeated over and over. But as soon as the rpc and shard 0 problem resolves, the autobider is working again AND all the things come back. If we had an ATH of 170 as you said, it’s just worse than before, since we had the opportunity, the new validators got elected, since no divings happened, and got pushed out for some increased rewards by a “couple of validators” as you stressed. So, thanks to bring up the fact that when the system is not being played, and it work as intended, there’s a place for all.
And for the “stable” validators being unelected, if wasn’t the lower bound farming, they would’ve stayed elected, even with the undelegations. Fact.
I believe we a agree that either way this “issue” must be addressed. Giving opportunity to new validators is important to the organic growth and health of the network/protocol. If we must punish or set limits in anyway to those who prevent it, so be it.
@TrickLuhDaKidz As is allowed by the protocol… Until the protocol is changed (IF) then this will continue, greed or not… I don’t believe in punishments but rules to prevent should be in place OR not making it worthwhile to underbid.
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.
“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
The main issue right now is multiple keys validators bidding below the 0.65EMS.
They do that because that give a significant boost in ER.
We need to address this issue first and the dynamic keys limitation seems to be a good solution (to me).
The second issue, is the multiple keys validators bidding just above the 0.65EMS.
What we need here is a comparison in terms of rewards when bidding at 0.65EMS versus bidding at 1.35EMS.
I did it once, comparing 2 different validators on the same shard, almost same uptime, one close to 1.35EMS and an other one close to 0.65EMS and guess what? The rewards were almost identical… That was like a 0.3% difference in rewards (not apy!).
We need more numbers and comparison but I really think once we can show everyone the difference is neglectable, some validators will start releasing keys.
I propose to solve the first issue first, anyone can make a new proposal. @TrickLuhDaKidz , if you want to reuse my initial idea, it’s fine
We’ve seen many times , bids not just above, but below the 0.65 EMS.
Would take some time to gather the data around that and making a fair comparison would be quite impossible, since we would need to at least compare 2 validators with the same keys at the same shard and approximate stake. Not everytime we will have those scenario.