HIP-2: EPoS upper bound change

I support this. YES.

1 Like

As a new validator I can feel the struggle of getting enough delegations to get elected, as I think most of the new validators do at the moment. Iā€™m all in for discussion and changes in the EPoS system that could help increase the networkā€™s decentralization. The decentralization aspect is one of the key elements that get promoted when talking about Harmony, yet I still think the validating gets too easily handed over to the major league players, which in turn makes the network more centralized - and that I do not wish to happen. With all that said, I plan on voting yes on any changes that make the Harmony network better, and this topic at hand seems to be an improvement over the current iteration, so my vote on this topic is going for YES.

5 Likes

Hey guys, about that proposal, ill answer two things, for the third im waiting on Ogre to check my DM first.

Upper and lower bound changes ā†’ if you check the whitepapers and what that is all about, you will see these two bounds are actually essential for security of the network, and cant be changed as we wish. I believe even the uppoer bound change from 1.15 to 1.2 is quite a lot, according to what we discussed with @rongjian , but i can let him respond with a more detailed answer on this. I also feel the lower bound rarely comes into play anymore, as the entry into committee is lately higher than that. So lowering it further does not do anything if you ask me, as it still doesnt incentivise big validators to shrink their keys. Imagine this: we have these bounds set, and somehow many small validators can now get elected next epoch, and instantly get a big boost since their stake is low. The big validators can still simply extend their keys to kick them out (any new validator getting in means less rewards for them), because they are actually incentivised in doing that. I believe that proposal still doesnt solve the core problem, which is making the entry for new validators lower, without too much risk they would get kicked out by the bigger ones. If we simply just set upper bound higher, that does not mean the big validators will shrink keys, they dont do that even now, why would they do it then? I still think that, apart from releasing more internal seats, the only way to get more seats available is to incentivise upper bound and make the big boys fight it up there, instead of on the lower bound. Its not a bullet proof solution, sure, but it does keep them from kicking the smaller ones out since theyre incentivised to shrink bls keys.

Maybe one solution is also to simply disincentivise the lower bound, but im not sure that plays well with the EPoS mechanism either.

Note that these responses are without considering the Stake Weight, because im still waiting on Matt to explain what exactly that is (we dont have that in the validator information). Once i know what exactly that is, ill amend my response. But for now it just looks like another parameter that would probably clash with the EPoS mechanism which is purely based on effective stake.

IIRC in last summer there was a discussion about giving maximum BLS keys amount of a validator so that if a validator gets too many delegations, their rewards will not be optimized and discouraging many people to delegate to overly sized ā€˜big validatorā€™.

And it forces the team behind a big validator to open up a new validator address with new node setup and everything, costing them additional effort and cost to maintain several validators at a time. I think it will be a good option to reduce the big validators dominance as Mattā€™s proposalā€™s main point. Iā€™m sorry if this is a little bit out of topic

Yeah we already have that, but the number is quite high. We have talked a lot about this and in the end decided against, because the last thing we want to see is POPS1-10 validators and Smartstake 1-5 etcā€¦ That completely defeats the purpose of decentralisation, as the entity is still the same in the end, despite some additional costs. It does not add anything to security either.

The main purpose of this original thread is to make big validators shrink keys in order to let new validators in. Lets not extend it to too many other things, because im afraid that we can then discuss without any real end or conclusion.

1 Like

Wouldnā€™t it help decentralize if delegators could specify a number of backup validators?

Even though they are actually staking for one elected validator, they could also be counted to bring unelected validators above the minimum. Then either split their stake between elected validators or assign it to the smallest one.

It would increase total stake, because most of what is delegated to unelected validators would simultaneously be delegated to an elected one.

That is a nice idea, however i feel like this isnt easily impemented so im not sure this can be done really, unfortunately.

As a small single BLS key validator, I would personally increase my bid if the EPoS upper bound was increased. Iā€™m currently capped at how much I can bid because my personal holdings exceed the cap forcing me to delegate the remainder to other larger validators.

In fact, Iā€™ve been discouraging delegations by increasing my fee to 10% so I can delegate more of my own holdings to my own validator.

2 Likes

I think this proposal about the 1.35/0.65 bound is a good solution to the problem where validators with 1 BLS key have a chance to grow smoothly to have enough delegation for 2 BLS, because the nice property where 1.35/2 == 0.675 which is > 0.65. So there is no ā€œgapā€ in the earning capability for small validators with 1 BLS key.

Lowering the lower bound of effective stake is also helpful in giving a better chance for small validators to get elected because as the bounds get extended, the minimum bid required to be ranked within the top 640 slots will be lower (expected to be around 0.65*EMS).

As for the security concern, these parameters (1.35/0.65) are still tolerable as in the worst case a small validatorā€™s BLS key will have ~1/2 voting power of a big validatorā€™s BLS key. And the concern that a single shard is mostly populated by BLS keys which bids at 1.35 bound is not significant as the chance is still very low (a rough calculation gives < 0.00001% if we assume at most 20% of the stake is control by a single malicious validator). And the resharding will make it even harder for malicious validator to do anything bad. So there isnā€™t much security concern for this proposal.

2 Likes

This actually sounds good then! I thought we couldnt stretch them that much, but if we can, we should do it.

Regarding the second part, does it make sense to:

  1. use stake weight like ogre proposed or
  2. incentivise upper bound or
  3. disincentivise below lower bound?

I feel we need to find a way also, that the big validators will not still try to big on the lower bound due to incentives, thus kicking out the smaller validators.

2 Likes

Agreed! We need to ensure that the larger Validators have an incentive not to occupy these lower slots, or else they will simply deploy more BLS to fill the seats which become available.

I believe that some sort of incentive already exists, but I cannot explain it properlyā€¦ @rongjian - would you mind explaining this part so we can identify how to incentivize Validators to reduce the amount of BLS keys, please?

1 Like

very fair and valid point. Out of the own interest, I donā€™t think/assume big validators would like to just stay at top instead of grabbing the highest rewards from the bottom.

1 Like

I like these suggested changes. Interested to see the effect of a 1.35/0.65 bound change for single key validators

Curious what we can do to incentivize larger Validators to not deploy more keys though

1 Like

@OgreAbroad this is exactly the reason we have to, either incentivise upper bound, or disincentivise being below lower bound. Im not sure that stake weight thing will really mitigate this issue.

1 Like

This seems like a great balance between the original objective behind the proposal, and disincentivizing large validators from deploying a high number of keys which occupy lower slots which other, smaller validators can be taking.

Iā€™m 100% in favor of this idea and would support this proposal.

2 Likes

Yes i agree. However as said, with the bounds increased we only do half the job.

Big validators can still be incentivised to extend their keys and fight for extra profits below the lower bounds if applicable. We are now looking at the 2nd parameter that would make sure big validators stay above EMS or even at the upper bound. A few suggestions so far were (one or a combination of these):

  • disincentivise below lower bound
  • incentivise staying on upper bound
  • use stake weight as an indicator and penalise big validators that extend the keys too much
  • @OgreAbroad might add more since we chatted about it in telegram
2 Likes

Iā€™m loving this discussion as someone who recently has been struggling with getting delegators Iā€™m glad to see itā€™s on the radar for change.

I canā€™t really weigh in on the EMS or EPoS or weighting as I donā€™t understand them as well as all of you but I would like to offer what my experience (and the experience of other new validators) has been recently. Iā€™ll try to be brief and itemized:

  1. Hopelessness. There seems to be no clear path to achieving election. Iā€™m a hard worker and donā€™t mind a long term grind, but the current system prevents that. When I go to look at most of the non-company based validators they all started with 1 wallet staking 3-4MM Ones. Which at this time is extremely prohibitive by cost, let alone when One continues to rise in price.

  2. Itā€™s ALL OR NOTHING. I managed to raise about 2.4MM One from networking/friends, but after not getting elected for an epoch they all wanted to pull out because they were getting ZERO rewards. I couldnā€™t in good consciousness tell them to remain and not get anything.

  3. The UI is biased. Maybe this is because in my professional life Iā€™m a UX/UI Product Manager but it seems to be a huge issue for me. Having to click ā€œallā€ just to even see unelected validators seems crazy to me.
    Even if a user makes it through that obstacle, thereā€™s also the non-elected flag, and also a BLANK ā€œup timeā€ and ā€œexpected rewardsā€.
    As a new user when I saw this I thought that meant ā€œworthlessā€, and I think a lot of others do to.

Thatā€™s just my 2 cents. I hope itā€™s useful to the discussion. If not, Iā€™ll shutup and watch and trust you all to make the right calls :slight_smile:

1 Like

We talk about the 0% fee being a marketing tool for smaller validators, but I also see a lot of smaller validators go for the higher rewards by bidding below 85% and having more keys than they probably should.

Iā€™m all for decentralization/more nodes, but sometimes more rules leads to centralization and I have a hard time understanding why a validator with 5 million staked is more worthy of a better return being in lower bound than a validator with 50 million staked being in the upper bound. Shouldnā€™t we all want whats best for our delegators? Im not sure villianizing or penalizing ā€˜largerā€™ validators for adding keys is the best motive for making a change in upper/lower bounds.

Its fairly easy to split up a validator into 2, 3, 4, 5, etc. different validators for a large holder and I would hate to see them game the system where theyā€™re earning more in the lower bound simply because they split up their total stake to take advantage of the increased earnings while our validator is left bound to the upper range earning less because we have more stake than another validator.

Therefor, the incentives for lower and upper bound need to be equal or else I canā€™t see our node voting yes for a proposal change.

1 Like

Hey guys,

I feel your pain. @Kruger i agree its really hard to start from 0, the only thing that seems to do it, is to be super active within the community and get the support of other validators. That being said, you might be in for a surprise soon :wink:

@ValidatorONE yes i agree with you, i think more prohibitive rules is bad, thats why my initial suggestion was just to incentivise upper bound, and if needed, disincentivise lower bound, so that the big validators really have no reason to extend their keys. Still waiting on this to be decided and discussed though.

Ofc any other suggestions are also welcome!

2 Likes

@mindstyle Ah, I think I understand your point about upper bounds now. Just give better rewards for splitting to less keys will naturally make more spots. Makes sense to me.

2 Likes