HIP-2: EPoS upper bound change

Summary: This proposal is to introduce a change in core EPoS mechanism, allowing the upper bound to be higher than 15%.

Background: Due to the nature of EPoS, validators are currently incentivised to expand their bls keys to take more seats, to try and bid below the lower bound, which is incentivised in the way that it enables more effective stake than actual stake, resulting in bigger gains. This is also one of the reasons why new and smaller validators can’t get elected, due to validators taking more seats than actually needed.

Motivation: With this proposal it would incentivise bigger validators to shrink their bls keys and bid for less seats on the upper bound, which would in turn allow smaller validators to get elected.

Specification: Setting the upper bound higher and incentivising validators that bid around there similarly to those under the 15% lower bound. We should discuss the actual % and incentives in this thread, together with the core team.

Suggested voting options: yes or no

4 Likes

Yes, agree. It will make more validators elected and bigger valodator can keep their revenue.

Regards,
Enter Group Validator

3 Likes

I’ve proposed before something that we could add on top of the original idea. This would be to decrease the reward for folks in the the lower bound Open Staking: Improvement Proposals - #4 by sophoah

What do you guys all think ?

the idea is to complement @mindstyle idea to further increase the need for big validator to use less keys.

2 Likes

This is also one possibility yes, but i think this one should be added as a separate proposal to be discussed in this forum. Please make a thread for it :slight_smile:

so to clarify, is this proposal only the increase the upper bound of the epos to 20%, but not change the lower bound of 15%?

have you done any estimate on how many new validators can be elected if we increase the upper bound to 20%? The thing is not just increase the upper bound, it is also related to big validators don’t want to reduce the number of slots to leave some rooms to smaller validators. That probably won’t change much if we just increase the upper bound. The big validators may have to make some sacrifice to keep a healthy network level decentralization, IMO.

In general, I am not against the adjustment of upper bound, but it is just not convincing to me yet why and how 20% upper bound will bring new validators to the network. I would like to see some simulation or estimate.

2 Likes

Yes, we need to have more convincing evidence that this change will alleviate the problem. Better to have a poll on some of the big validators to see whether they would reduce their keys if we change the upper bound to 20%.

Regarding the lower bound, also helpful to understand what’s the effect. I would imagine if lower bound is -20%, then it also helps avoiding validators to fight for the last few seats because the benefits is less significant now because the effective stake is closer to the actual stake for the last few seats. I would recommend adding the change to lower bound to -20% also part of the proposal.

Anyway, It’s better to first have some clear evidence about the potential behavior of validators if this proposal is implemented.

Regarding the timeline, this change will take roughly 1 week for implementation and 2 weeks for mainnet rollup.

Hello RJ and Leo, thanks for replying!

Yes so just changing upper bound to, for example 20%, will not be enough since the bigger validators will not have a good reason to do it, hence why the additional proposal is to make it incentivies, similarly to being below the lower bound.

Since the newer validators will have smaller stakes and probably a lot below lower bound, the bigger validators surely wont let them take the good ROI “for free”, but if they have an incentive to stay on the upper bound, i believe they should.

1 Like

I am not 100% clear of what advantage my delegates would have from this proposal (based on current description). If my delegates would make with my validator being at the top of the bidding vs being elsewhere or at the bottom, I will happily take it.

Sacrifices dont really work in this pseudo anonymous space & it is unfair to expect the validators to sacrifice rewards as such an action means that their delegates will earn less than what they can earn with another validator.

If there are clear incentives to be at the top of the bidding, i would support it.

At the end of day, if my delegates are going to make less rewards than say a validator in the bottom pile, I am afraid I will be doing what is in the best interest of my delegates.

yes, this is exactly why we are proposing for the upper bound to also be incentivised, otherwise it will not work

I think increasing the upper bound will allow more validators to be elected. I think is important for everyone, including delegators to understand that their current rewards won’t be affected by this. Current validators could reduce the number of keys moving more towards the 15% and higher upper bound without any impact on the rewards.

This will implicitly allow other validators to join the network.

One issue I see with slashing validators closer to 0.85 is that would put smaller and new validators who can’t meet median stake at a disadvantage. If a validator starts off with a low earning rate, that rate stays with them for their first 30 epochs putting them a step behind right out of the gates.

I found the first 3 BLS keys were most difficult to manage due to the upper and lower thresholds. With more stake, its much easier to manage your nodes effective stake.

1 Like

Won’t increasing upper bound for bigger validators make them earn more? Won’t we get back to the “Rich becomes richer” then?

If it is incentivised then yes, but at the same time many big validators are now chasing it on below the lower bound, making the smaller validators unable to join or kicking some out.

tldr; this is not even a rich get richer problem, we are trying to change how EPoS works in order to facilitate many smaller validators getting in (who can have higher effective stake and can even earn more).

1 Like

I do share the idea discussed here, but I don’t think that changing just a one factor from many which applicable for EPoS design can resolve the issue we have.
Very nice that you’ve raised it in the frame of Governance!

1 Like

There arent that many really, unless we totally change how EPoS works, but that would be too much work. So we are looking for the easiest solutions that would help.

One could also be to disincetivise people under lower bound, but im not sure thats really fair. It would stop bigger validators to extend their keys though since theres no extra rewards. But in the end theres always kicking out other validators so there is less total network stake which also means more rewards.

2 Likes

I do not think that this will solve the issue, as there are multiple problems. I would counter this proposal with the proposal below:

Root Problems: When additional validator slots become available below the Lower Bound (currently EMS * 0.85), larger validators quickly deploy more BLS keys to fill these validating slots, and pursue increased rewards for their delegators. This makes it very difficult to bring new Validators into election, as they are competing against far more experienced Validator operators, with the ability to adjust their Bid more effectively. Additionally, as the value of $ONE rises, the cost of starting a new Validator becomes extremely prohibitive. We need EMS to go DOWN, not UP.

Background: Prospective Validators who want to join our community have a difficult time gathering the necessary delegations to reach the EMS * 0.85 Lower Bound, and become elected. It is very difficult to gain the support of delegators who will not earn anything until the Validator becomes elected. Compounding the situation, if an opportunity arises where the lowest bid is more reasonable for a new Validator to become elected, it is usually far below EMS * 0.85, encouraging larger validators who are trying to improve their Expected Returns (ER) to add more BLS, and fill these slots. Not only does this make it nearly impossible for a new Validator to become elected without some sort of “Angel” Delegation, it also encourages experienced validators to battle each other for the highly prized slots below EMS * 0.85. Additionally, with the band so tight, new validators who have only 1 BLS must continue attempting to attract new delegations, even though their ER is negatively effected by the fact that they must grow well past the Upper Bound in order to have enough total delegation to safely deploy a second BLS.

Motivation: In order to become more decentralized, we need to allow new Validators to join the electorate, participating in consensus. This also encourages participation of Community Minded Validators, by incentivizing them to contribute to the ecosystem in some way, in order to attract delegations.

Specification: I propose lowering the Lower bound to EMS * 65, and the upper bound to EMS * 1.35. I would also propose weighting Stake Weight more heavily. To those who are not familiar, Stake Weight is effectively, how much a Validator bids per BLS key. I feel that modifying these two variables would not only solve our problem, but also be the simplest to develop, as it would mean modifying two existing variables in the binary, as opposed to re-writing new code. Below is an example of why I feel that this would solve our current issue.

Given:

  • EMS = 6,000,000 ONE
  • Upper Bound (EMS * 1.35) = 8,100,000
  • Lower Bound (EMS * 0.65) = 3,900,000
  • Stake Weight variable becomes more impactful
  • There are 3 current factors which Validators can use in order to maximize their ER
    o Shard population (How many BLS occupy each shard) – irrelevant for this discussion
    o Stake Weight (Plays a marginal role, and is almost immeasurable)
    o Occupying BLS slots below the Lower Bound

By far, the best way to increase a Validator’s ER is to occupy BLS Slots below the lower bound, as each key gets rewarded as though the bid was EMS * 0.85 (currently) or EMS * 0.65 (proposed). Being diligent as a validator, and noticing when a large amount of BLS become available presents an opportunity, as rewards become quite nice when a Validator can win BLS slots below the Lower Bound. This is by far the most effective way to raise a Validator’s ER. This also creates the effect of high competition, and attrition, as Validators fight for these prized slots, and push each other out of election. By lowering the Lower bound, we will make it more reasonable for new Validators to join our ranks, as the incentive for larger and more experienced Validators simply isn’t there. To further sweeten the incentive to not bid extremely low, we can increase the importance of Stake Weight (Bid per BLS) in calculating rewards. By putting more weight on the Stake Weight, we encourage larger Validators not to occupy the slots below EMS, because dividing their total delegation between more BLS will result in decreased rewards, as their Stake Weight will be reduced.

A careful balance must be struck between Stake Weight and the Lower bound, or else this could have the same unintended consequences as merely incentivizing the range from EMS to EMS * 1.15. I would recommend that we revisit the issue 1-3 months after implementation, to evaluate the effectiveness of the change, and potentially tweak the modification to Stake Weight.

Suggested Voting Options: Yes or No

5 Likes

I am curious to hear your thoughts on my counter proposal, as I agree… I do not feel that the initial proposed solution addresses all the issues. Please keep in mind that the intent of this proposal is not to help your delegators earn more, but to help the network grow and decentralize, by adding more Validators who will hopefully become active contributors to the ecosystem.

2 Likes

Do you feel that my proposed change above would help small validators grow past their first few BLS keys?

I agree! This will allow small validator to earn optimized rewards when they’re having dead numbers delegated: 7 million to 9 millions ONE delegated when the EMS is 5.8 and upper badn is 6.6 millions.

Right now having 1 BLS key when having 8.5 millions delegated is a nightmare, happened to Cheeky ONE and GGA in the last couple of epoch.

Adding 2 BLS key will make their electing BLS keys underbid.

2 Likes

Agreed, I lost delegators because of having 9million delegations.

1 Like