Should we include a higher limit? The original discussion was based on a 10% limit per shard and that’s already been cut by more than half with the option of 4.8%. The reason I say that is because I’d rather see a validator vote on an actual % if they think it should be higher than 6.4% rather than abstain altogether.
1 Like
I like this idea. 
1 Like
That is not a problem but we should also include higher % as @ValidatorONE recommends so as to include all options…
2 Likes
Thanks for the feedback all. Here’s what it could look like if we add two more options above 6.4%:
4.8%
5.6%
6.4%
7.2%
8.0%
No
Abstain
Since there are so many options in this scenario, it’s probably more fair to make the final result a weighted average instead of choosing the one with the highest stake weight in case there is a close tie but the percentages are far apart.
3 Likes
If you’re interested in the current key/slot % per validator per shard you can view that here: Shard Stats by DK Validator (shardstats-vaba4.ondigitalocean.app)
3 Likes
Has the code been pulled into Validator Mainnet to allow multiple choice voting that is stake-weighted? I see only multiple choice votes from past proposals that were 1 validator = 1 vote but no stake-weight vote has been done with multiple choice. I think that strategy needs to be pulled into Snapshot before a multiple-choice stake-weighted vote can happen. If not, then we will have to come to a consensus on a single % to vote on with Robo’s proposal.
3 Likes
Since this affects the protocol, would this go up on Staking Mainnet instead which I assume supports multiple choice stake-weight voting?
We have stake weight… It is currently in Hip-20
So you could have
- 20%
- 20%
- 20%
- 20%
- 20%
if you desired.
2 Likes
For HIP-20 is there a UI bug with displaying the results? It shows up as empty for me. I do see there are votes and I just voted 
Also if VDAO mainnet is the primary space for proposals now, we should get the Harmony team to move VDAO mainnet to the first row, instead of being buried in the second row where it’s hard to find:
Filed this github issue for it: Validator Dao Mainnet space should be prioritized in the governance website · Issue #44 · harmony-one/snapshot-spaces · GitHub
2 Likes
I am not sure if it is a bug or if it does not show the results until the ene so as not to influence peoples choices…
Maybe @giv can confirm?
1 Like
I’m not sure about the results issue. I’ll take a closer look. I will also move the v-dao space to the top.
4 Likes
Should we consider raising the upper bound to 1.50xEMS and lowering the lower bound to 0.50xEMS in conjunction with key restrictions?
The higher upper bound would allow validators to use less keys without risk of reduced earnings and by lowering the lower bound to 0.50x, it would make the extra lower bound rewards less attainable for larger validators due to the key restrictions per shard. Without the incentive of extra lower bound rewards, larger validators may be more inclined to remove excess keys to consume less processing power. This would improve the chances of validators with less delegation to earn extra lower bound rewards and/or make election due to their ability to add keys and less competition from larger validators.
EDIT: We could make a seperate thread if any validators think its worth considering as a standalone proposal.
6 Likes
Pardon if I´m reading this the wrong way. But lowering the lower bounds even more, wouldn´t make it more attractive to the ones that want improve their rewards by adding keys? Since it will make it lower, will increase the gap and the space that they can fill? I believe that if you want the desired effect, you must increase the lower bound %, not decrease it? Per example, a validator with 100m stake, with the lower bound of 0.65, will try to reach it for max rewards, that´s 3.4kk bid with 29 keys. If you lower it even more to 0.5%, it´ll mean, it can go to 2.5kk, and can set 40 keys…using another 11 slots, instead of 29?
Hey all, I drafted a proposal on the dao testnet:
https://gov.harmony.one/#/dao-testnet/proposal/QmZuuStjTLQs3CMrZyGNNhTRNr76tovsn1P4dvCVc6fErf
Which uses the snapshot fix I put up on github. What do you all think? Is it ready to put up for a vote?
I think we should remove the 8% option. It’s too high imo.
I know some would prefer to give the larger validators a chance to vote rather than abstain, but by giving a 8% option, it is an easy way out.
If they want to abstain or vote no, sure go ahead. Even if the proposal doesn’t pass, the results can be made public via the community channels so that everyone knows who these validators are. It is going to be poor PR for these validators in the eyes of the community as they chose to be self serving instead of for the betterment of Harmony.
4 Likes
Okay how do people feel about leaving out 8.0%? So the votes would be:
4.8%
5.6%
6.4%
7.2%
No
Abstain
2 Likes
This is an interesting idea. I hadn’t really considered approaching it this way. I could see many of the keys that are dropped to put people closer to the new upper bound being used by others to get below the new lower bound. Can you provide insight on how it played out when it was moved from .85-1.15 to the current .65-1.35?
Personally I’m more in favor of removing the lower bound incentive for validators with more than 5 keys. One way of doing that, which shouldn’t be difficult to implement, would be to update the command for adding BLS keys to throw an error if it would give the validator 6+ keys and put them below the current lower bound (0.65 * median stake).
I read your comment (Discussion: reducing BLS keys - #39 by ValidatorONE) and think it’s a great idea, but I wonder how difficult the implementation is. My suggestion above would keep people from adding excessive keys, but it wouldn’t incentivize people to drop keys which is covered in your suggestion.
Perhaps we should open one or more separate threads to discuss these ideas in more detail since they’re a bit off-topic here.
4 Likes
These options look good to me.
Our preference would be for the options to be +1/-1 from 6.4% so something like:
5.6%
6.4%
7.2%
A key restriction as low as 4.8% is too restrictive of a limit considering we’re coming down from no cap per shard. There’ll be a lot of unforseen challenges that we don’t think are being closely vetted enough. For instance, smaller validators with 5+ keys will be forced to run multiple shards or else risk key manipulation by larger validators who can add/remove keys and hurt the ERs of smaller validators who may only be on 1 or 2 shards. This can be done in the last few seconds of an epoch which means those validators won’t have the time to spin up additional nodes on other shards.
The argument for a lower key cap will be 'it’s good for decentralization because it means more nodes are spun up", which isn’t false, however, a higher key cap % of 7.2% or even 10% as originally discussed would resolve the primary security concern of a single validator takeover while providing us with an opportunity to explore other proposals designed to encourage decentralization that don’t create as many challenges for validators.
We’re only one validator’s voice and not asking you to significantly alter your proposal based on our voice alone, but these are some of the concerns we have with a too restrictive key cap.
3 Likes
One slight benefit of keeping the limit larger is that it also allows large validators to balance their keys across shards to ensure that shard rewards remain the same across all shards. At 4.8%, a few large validators including myself would be forced down to 10 keys per shard or 40 keys total and we would be forced to bid over the upper bound.
It also does seem to simplify the vote if we boil it down to three choices. So how do we all feel about these choices?
5.6%
6.4%
7.2%
No
Abstain
4 Likes