The autobidder is configured by the validators themselves…we saw and we are still seeing it. EPOCH 792: The lower bound is 3.39kk. 9 validators below lower bounds and from those 9, 5 has more than 4 keys (the winning voting option for now). Occupying 123 slots. Guys…please wake up…if it was enforced now. At least 5 keys would be freed, that could have elected a another 5 small validators, reaching those with 153k stake.
The way to make “not preferable” to BE in a place where you do not belong, is the slashing. Even a validator that IS UNAWARE, will notice a reduction in their rewards and will try to figure out why. Well, at least a validator that cares about it, not an Autonomous validator that run it just on autopilot/autobider.
I was talking about bidding under median stake for no reason. Maybe there’s only a need for education? As far as i’ve seen there are only few validators trying to bid under lower bounds to achieve higher rewards. And doing it they are always taking a risk to be pushed out from committee.
I can make a Google aiheet tomorrow to explain this phenomenom to show, that there are over 100 slots that could immediately be released with no affect for rewards.
The ones that bid below lower bounds will only be pushed out by other that have a bigger stake and consequently will take more keys reaching the lower bounds. It’s as a cascade. Only the bigger can slash the bigger. OR having an high influx of stake to small validators positioning them above the lower bound. But as I stated on my previous answer to you. It’s very highly unlikely and almost impoasible to happen. So, must need another big validator to try to take care of them AND still pushes out the small validators the same way. Using the system against the system, still punishes the guys that need the benefit of the lower bounds.
Its a very comfortable position. Preying better rewards without supervision and no real risky. And it’s totally allowed.
I just cannot understand why they are doing it. Voting power is the same with three bls bidding 6kk and four keys bidding 4,5kk, so the rewards are also the same. As long as bidding is between upper and lower bounds. It’s a bad habit for nothing, only pushes smaller validators out.
This was our solution to excess keys being used by validators with 5+ keys, if there’s anything you can take from it to enhance your proposal.
Our solution serves as a credit system. If a validator bids in the upper range (1.05-1.35xEMS), they receive part of a credit funded by validators with 5 or more keys who bid in the lower range (0.95-0.65xEMS). The protocol would fund this credit by slashing a validator’s bid. Validators with elected bids in the 0.95-1.05xEMS range would be unaffected by this proposal as their bid would neither be slashed nor would they receive any of the available credit. Additionally, the normal EPOS rules for bids below 0.65xEMS and above 1.35xEMS would still apply and remain unchanged by our solution. Therefore, this would only adversely affect validators that operate in the 0.65-0.95xEMS range, where the most key mismanagement occurs.
There are certain rules from a logic standpoint that we consider important to include to make this a complete solution:
Those with 5 keys or less won’t be subject to a slashed bid for operating in the lower range, which provides them with a bidding advantage over validators with more than 5 keys;
Despite not being subject to lower range bid slashes, validators with 5 keys or less would still be eligible for the additional credit for elected bids in the upper range;
Validators with more than 5 keys and elected bids in the lower range (0.65-0.95xEMS) would be subject to diminishing rewards the lower they bid with the severity of the reduction in rewards based on the validator’s key count. For example, if there were two validators with the same bid amount in the lower bound, the validator with a higher key count would earn fewer rewards per key than a validator with a lower key count;
Credits rewarded to those bidding in the upper range diminish based on a validator’s total key count. For example, if two validators with the same bid amount in the upper bound, the validator with a higher key count would earn less of the upper range credit per key than a validator with a lower key count.
Our solution is intended to achieve the following objectives:
Incentivize all validators to bid as close to 1.35x as possible;
Disincentivize validators from adding keys to the lower range without cause;
Minimize key usage without cause by all validators;
Provide validators an opportunity to gain an ER advantage over validators with higher key counts than their own;
Minimize disruption to delegators; and
Incentivize delegators to choose validators who minimize key count.
Our solution ensures that a validator always carries an advantage over a validator with more keys than their own while holding validators of all sizes accountable for responsible key management. Medium-sized validators will hold an advantage over larger validators, and smaller/unelected validators would hold an advantage over medium and large-sized validators. This creates a system where validators are encouraged and incentivized to bid as closely to 1.35xEMS as possible.
We haven’t proposed it yet because it’s a bit complex and may be difficult to find consensus.
It´s a very interesting proposal, very elegant solution as well. Seeing that you mentioned that the complexity was one of the couses of it´s halt, we can try to make the % fixed at first. and later move on to a relaxing or even making it dynamic, as you initialy proposed. Having tiers on how close to the 0.65 lower bounds like 5% for every 0.1 below the 0.95 EMS. And if the validator goes below the 0.65 EMS it will be slashed fully by whatever is decided by the community if the vote pass. Also, the returns to the validators at the upper bounds would be in the same way, 5% of the pool for every 0,1 above the 1,05 EMS. And if there´s any validator above the 1.35, it would receive the same % decided as punishement for the validator that had bid below the lower bound.
So would be something like this.
1.05 EMS bonus
1.35 < bid = same % of the pool decided as penalty for the bidders below the 0.65 EMS
1.25 <= bid <= 1.35% = 15% of the penalty pool
1.15 <= bid <= 1.25% = 10% of the penalty pool
1.05 <= bid <= 1.15% = 5% of the penalty pool
This being set and said, would be interesting to set a RULE on the deliverance of the bonus for the ones that are in the “EMS bonus range” so, the rewards will ALWAYS go to the HIGHEST BIDER first and them to the lower bider in succession. And by this way, if there´s a total % reward amongst the validators on reward range that would go beyond 100% of the pool, each highest bider will receive it´s share, until the 100% is achieved, so could be possible to some validator to BE in the reward range, but will not receive his share, since the reward pool would be empty. This could promote a 'beneficial competition". Also, if the reward pool is not entirely used, it just would sit there, and will aggregate more to the next epoch.
Bid < 0.65 - could it be calculated that it’s not beneficial? Percent for rewards would be calculated by bid/lower bounds.
All the validators having under 2-6 (amount should be discussed in the community) should maybe be released from penalties to prevent a situation when there’s total delegated amount growing over upper bounds and adding a key will return validator near lower bounds and get penalized.
Yeah, that’s the proposal, only the validators above the blskey limit criteria would be penalized. Didn’t got you about it not being beneficial. What must be calculated?
I don’t think educating validators to not hold excessive keys is the issue here. These aren’t new validators that may still not fully understand the bidding process. This is also something that has been discussed on this site for months. It’s not a recent issue. Some of the validators who excessively bid on keys are on talk.harmony.one, but they don’t seem to make their way into these discussion threads. Credit to the larger validators who DO take part in these discussions
In short, I think we are well beyond the point of education. That hasn’t worked over the last 6 months. Six more months won’t make a difference either, imo
We are at the stage where we need to make actual changes. Either we need to take the necessary steps to drastically increase the number of validators and improve decentralization - OR - we need to just abandon this charade and acknowledge the goal of 1,000 validators was a complete failure. Which outcome do you want? I want this project and community to excel
This is a very important topic, in order for the network to grow new validators must be able to become elected.
However, currently a lot of the keys in the lower bounds <Median Stake are being used by validators with larger total stakes and multiple keys. The large validators are doing what is best for their delegators and the validators that don’t stay competitive run the risk of un-delegations.
Restricting the number of keys, a validator holds does not seen fair as the larger validators are large for a good reason, people trust them with their investment and that should not be penalised.
What would happen if validators could not bid under the Median Stake?
The problem Is not the median stake is bidding way below. Certainly a validator that grew big enough can bid above the 0.65 margin and still provide good rewards for their delegates. Bidding below the 0.65 threshold was initially designed to provide a bonus for those that did not reached the minimum to be elected but still was elected, this way, the high apy would be seen as an incentive for the ones that didn’t had enough stake to reach the minimum. Having big validators farming this area is not what was expected and certainly is not healthy for the network
… it´s happening for quite a while now…