Since the open staking launch on Harmony mainnet, we’ve seen tremendous growth of validator and delegator activities in the network. So far, we have a total of 108 unique validators with more than 4 billion ONE tokens staked (Harmony – Open Consensus for 10B). The EPoS mechanism worked well to evenly spread the stake among 800 validator slots across 4 shards. The rule for validator election is that the top 800 bids for validator slots will eventually win the slots and bidding validators become elected. However, the unique design of EPoS where a single validators can bid for multiple validator slots lead to a problem: a validator with lots of stake can bid for less slots at first and only at the last minute before election add bids for more slots, which causes failure of election for the validators who underestimated the real amount of stake required to be successfully elected.
Observation:
Compared to other PoS protocols with limited validator slots and uses the highest bidding rule for election, one significant difference the EPoS has is that validators can easily change the number of slots they are bidding for, while in other protocols, one validator is only allowed to bid for one slot. This basically makes it easy for validators with lots of stake to manipulate bidding process.
Proposed Solutions:
Add restriction to only allow 1 operation of “Add/Remove BLS keys” per validator per epoch. This will effective make it impossible for validators to game the election because they only have one chance to edit their bid count. On the other side, assuming the stake of a validator doesn’t change often every epoch, 1 operation to add/remove bls keys is enough to make the current adjustment based on their stake.
Add in the staking dashboard an estimated minimum stake to get elected safely, which is based on the history election result, rather than the pre-election setting. A note can be added to the estimate to clarify the risk of losing election if only bidding for the minimum and encourage to add more stake for better chance of election.
Hey RJ, i like your proposal under point 1. However there is a limitation to editing the BLS keys (edit-validator --add-bls-key, in that it only allows doing it for one key per command. So basically we need to send out multiple of edit-validator commands to just do it once.
A very valid concern, but this can still be gamed. Validators simply add a bunch of BLS keys with their one —add command… and then remove a bunch at the very end.
I like this for the most part. Even if it means that we can only add 1 BLS per epoch.
The only problem that I will see with this, is during a time when KuCoin drops again, as we know they will, or any time when we have a large number of seats open up… as they just did.
Every time we add a shard, that will be 250 extra seats. If we can only add 1… we may not be able to fill all available slots.
If there is some sort of “exception logic” where a condition exists (like more than 20% or 30% of all available seats open on a single epoch) which will allow us to add up to three BLS or something to that effect.
I kind of like the principle behind the idea but this could also make it hard to switch shards. Maybe there could be an allowance for switching keys to a different shard as long as the key count remains within plus or minus one.
Another consideration is that this could hurt large validators more than smaller ones in the sense that the amount they can change their bid per slot will be smaller than validators with fewer keys so it could be harder for large validators to adapt to changing circumstances such as the one @OgreAbroad just described.
if a big validator drop of the committee, then there wouldn’t be a need of all validator community sync to remove keys before end of epoch. smaller validator will just be elected. Today, many big validator are gaming the system to use as much key as possible towards the bottom and maximize the reward.
for me I would say : let’s not target the bottom, smaller validator would be elected and will have an insane reward, however delegator will slowly move their delegation to them and this would eventually even out.
@rongjian I like both option. For 2) and to make it more effective, I would hide (if possible) the validator bidding for the next election, so no one can actually game the system and can only do guesses based on past election.
For number 1 I think this is not really a viable solution at all (if so only when we can add/remove multiple keys in one run…), because imagine you will receive a big delegation just after you send in your bid, after this you will be underearning and this might trigger delegators to remove their stake after the epoch, this is something we don’t want of course… Also it can be worse, just before epoch change a big delegation will be removed and you already send in your bid, this might possibly leave you unelected due to ineffective bid already made!
For option 2 I like this, we of course can still show EMS and I surely would love the option to bid blindly. If you want to be sure to be elected you will set your bid slightly above EMS and if you want to play dangerous you set your bid anywhere below! There’s a position for anyone and validators need to inform their users on the risk they are taking! (With DSLA from Stacktical this may just add an extra dimension because delegators and validators could insure this by creating DSLA contracts, making the ecosystem even more attractive and imo a bit “safer”!).
I would like to see as an alternative for option 1 that validators with “only” 1 BLSKey could be automatically delegated to or removed from, from a stakingpool provided by the Validator DAO to make sure they can match when EMS is changing too much within the bands and they seem to fall out of committee! (I know this is not easy to do, but this is just to start the conversation and possibilities about this)
That’s a valid point. We may loose the restriction to allow 3 times of modifying BLS keys. For a few validators trying to game the system, 3 keys for each of them still help a lot with protecting the new validators from being fooled.
Right, but it actually is good for the stability of the system as big validators are natural source of centralization and them being volatile on their setting will lead to potential network instability too. Adding some restriction like this can force big validators to plan to carry out moves slowly rather than suddenly all at once (which is not good for stability of the network).
But we can think about what’s a good threshold for the limit, I agree that 1 key per epoch may be too restrictive.
For option 1, we can also considering loosing the constraint to be more than 1 key every epoch (like 3, or a percentage of the total keys e.g. 20%). The point is to not allow crazy changes on the number of keys at once to prevent manipulation.
we can do no. 2 yes, for no. 1 i would wait, im not sure its a necessary step at the moment, lets first see the epos bounds in action since the proposal will likely pass.
I want to echo what OpenFi said as it was my first thought.
The current system rewards you for staying with a validator until the last moment before an epoch and then unstaking so that you lose less rewards.
Almost every epoch if I get a undelegation it’s right before the election, so not being able to adjust again could be fatal.
I love changing things though.
Has any thought been made to limiting # of BLS Keys you can have?
The biggest problem that I observe is the way keys scale.
The more keys you have, the more keys you can get.
Your first 4 keys you are reducing bid by HUGE chunks, 50%, 33%, 25%. Once you get to 20+ keys you can add so many more keys per number of delegation. So maybe if keys # can’t be limited, the way they split can be standardized?
@mindstyle the only problem with waiting is I’m hearing that even after the vote, which takes 2-3 weeks, it’s going to be 3-4 more months before it’s implemented. At that pace it will be years before we figure out proper balance.
I think a good solution would be to limit the maximum amount of keys each validator can have. This way we can achieve much better decentralization. Maybe limit each validator to 10 slots, and still encourage high reward system for those that are .85 below median stake.
If only adding more slots would solve the problem. Unfortunately mega nodes have plenty of keys and plenty of delegators to ensure that those slots still wouldn’t get filled by smaller nodes. This is a tough dilemma, and I personally have never been elected, nor do I see election in the near future unless the system is changed.
