HIP-16: Enforce a 6.4% max key per shard limit for each validator

Governance
1

Summary: This proposal is for adding a max keys per shard limit for each validator.

Background: Currently a large validator can dominate the voting power of a single shard by assigning all their keys to that shard. This is undesirable because for example if a shard becomes dominated by two validators with more than 1/3 voting power and they both go down for maintenance then it could stop consensus. Also if a large validator dominates a shard and proceeds to run underpowered nodes they can possibly slow down the block times as we may be currently seeing on shard 0.

Motivation: To further decentralize Harmony protocol and prevent scenarios like the above from happening we propose a max keys per shard limit to decrease the likelihood of a shard being taken over by a small group misbehaving validators. This rule will also help with the node decentralization goal on the roadmap by making it safer to ramp down the internal nodes: Decentralized Nodes

Specification: Add a max keys per shard limit for each validator. The computed limit will be a percentage based on the total number of external slots divided by the number of shards. The limit will be the same across all shards regardless of each shardā€™s individual population. This proposal passes if the combined stake-weighted votes for any limit reaches 67% and the total votes is 51% or greater. The final limit will be a stake-weighted average of all the limits.

Voting Options: 7.2%, 6.4%, 5.6%, 4.8%, no, abstain

  • Yes
  • No

0 voters

16 Likes
2

Changed to HIP16 as that was reserved for this type of proposal.

Also HIP21 is already taken :stuck_out_tongue:

6 Likes
3

Thanks Maffaz. I also updated the Motivation section to link to Decentralized Nodes

I think this rule will help with this goal on the roadmap by making it safer to ramp down the internal Harmony nodes. cc: @leo

4 Likes
4

Does everyone think we have enough support to create the official proposal on chain in staking-mainnet?

3 Likes
5

I put up the proposal on chain here: Snapshot

4 Likes
6

:smiley: I like what you did there Maffo.

1 Like
7

After a min of7 days here and if feasible and if you, the proposer still wants to. Sure.

As written in the vdao charterā€¦

1 Like
8

While I like that this is addressing a part of the problem, it still leave the wound open. Still a pseudo decentralization. With this cap of 6.4% per shard and 1k slots , in a dystopian but not far future, it open room for the network to be ā€œownedā€ by 15ā€¦maybe 16 validators, and it will be totally legal. This is not the way I believe it should be addressed. It can be part of some other measures. Maybe if presented with some other proposals, could be feasible. The numbers sounds dangerous, 6.4% = 15 validators. Better than what we have today, thatĀ“s 0 cap. But IF we need to implement something like this, better to implement with some real effect. Why not cut it in half? Or even in 75%? 3.2% would need 30+ validators far more balanced than 15. Or 1.6%? 60+ validators. And applying for something like that would bring real consequences right now, opening spots for small validators AND balancing the shards population. So, I think if something would be done, should be addressed properly, not applying band-aids to the hemorrage.

6 Likes
9

I agree with this, in that the current proposal percentage is too small and or further measures must be taken to properly decentralise the network, not just through keys but voting weight as well. A rate lower than 6.4% and a max stake penalty makes much more sense to me. These are not drastic measures and we must do what is right and fair for the network. Even having a pop up message before someone stakes indicating that the max stake has been reached you will have diminished rewards.

6 Likes
10

Honestly I feel this is not really a good explain. Because may in future this will more ressources and then? Just think of the Disk size and also the RPI is no more powerfull enough for shard0.

Iā€™m wondering where the max key per shard come from it is like assume a good spread like 250 Keys on each shard or is this flexible? Today we have total 200 keys on shard 0 so max per validator is 12.8 keys?

Also have all Validator got the chance to react before itā€™s now live on snapshot? Letā€™s check who has over 14 keys KuCoin, @mindstyle , GGA, @ValidatorONE , äø‰ę½­ę˜ ęœˆ , @USSHarmony @spitus @mlotis @Embiei @FortuneValidator @StrongMindsHold @ChainodeTech @SmartStake

2 Likes
11

I read these proposals quite carefully, but in the end, as it involves my validator I am afraid that I am not totally objective, and that is why I usually avoid to comment in the BLS limit topics. But here it is my opinion.

If there is a real danger that one validator could take over one shard, that risk must be minimized or removed. But we are talking about a group of validators joining together to take down one shard. In which interest they would do that? Being a validator is a responsible and, in the end, a profitable business. Having the power of doing that would mean that you have such stake/delegations that the last thing i would like to do is to risk my position, or invest a large amount of money to perform wrongly (and probably risking it). I am a naive person and I am sure there could be malicious intentions behind taking down one shard in which the attackers could benefit of course.
So i vouch for safety, but I dont think it is a real risk that a group of different validators come together to act against harmony, damaging themselves in the process.

And second, I donā€™t like restrictions unless-totally-neccesary. Do you want to spread the nominations? Then I am sure there are better ways than forcing people/companies to split their stakes against their will or imposing hard limits just for the shake of descentralization. I know the way harmony is designed, but there are other protocols that they incentivize staking to smaller validators, and punish to delegate to oversaturate validators. That is for me where you get the real descentralizacion. Do you want to stake with a validator because you feel safer even if you get 2% less rewards? Thatā€™s totally fine, it is up to you. A little like substrate projects.

In the end, currently lage validators are the most interested in having the highest uptime and the best performance. In the past I invested heavily in my own two bare metal servers, one in Spain and one in Amsterdam, two countries where I live/work/move between. Some months ago I had to move to VPS because the traffic increase was too much for one of my ISPs at one location and I didnt reach the uptime I wanted, so I moved to VPS temporaly. Again, two server, different providers, heavily oversized.

I just want to stress that I dont believe that large validators would join to overtake one shard. But I do believe that one large validator could be offline for some hours/day not on purpose, and this is the point that we have to avoid.

About this proposal, I agree with the idea that set up a limit having a X% of the total shard, but I dont think 6.4% is a lot. I remember that we were looking for shard leaders, and the requirement was to have at least an amount of keys in the required shard. Are these two ideas compatible with the 6.4% limit? To lose consensus with the 6.4% limit at least 6 large validators have to be disconnected at the same time, which I dont see it realistic.

PS: honestly this is not affecting me at all, because I have exactly 14 slots and I could go for lower if I wanted. This is just my opinion about all the limits that we are reading about lately.

6 Likes
12

This proposal should be discussed much further. Instead itā€™s now a live Snapshot vote with a block time-frame from back in February and with no abstain option? This will prevent many validators from even voting due to that block snapshot if Iā€™m not mistaken. This should be up for discussion for 7 days as required by the ratified VDAO charter then posted to appropriate Snapshot location with current block time and abstain option.

10 Likes
13

Gladly the snapshot is not active at itā€™s supposed to be otherwise yes @RoboValidator had just exclude us from Voting.

14

Hey all sorry about the mistakes made along the way in creating the proposal. This was my first time and I didnā€™t mean to use February snapshot. I used the HMY CLI and probably messed up the configuration. Iā€™m glad this started discussion how the topic so we can unblock @leo 's work on the decentralized nodes goal in the roadmap. Someone else can feel free to volunteer to do this the right way.

7 Likes
15

The max key limit as described in the proposal is based on the overall number of slots divided by the number of shards. So for 900 slots this is (900 / 4) * 0.064 ~ 14 slots. Even if shard 0 is underpopulated, all shards including shard 0 would have the same max key limit which always stays fixed until the number of slots increases or the number of shards changes.

3 Likes
16

Okay itā€™s a assumed 250 per shard and fixed 16 Keys per shard and not a fixed % on the flexible spots?
That would mean if people drop from a shard like what happen several times on Shard0 those 16 keys are getting more weight than 6.4%.
So by this we actually need like 4 Validator to halt shard0.
If so I personally would suggest to go to 4.8% to increase the number thatā€™s are needed

1 Like
17

Hopefully shard 0 underpopulation will be resolved by the recent work to improve block times. Also we should eventually arrive at a point where traffic is evenly distributed across shards which would even out the block times and thereby the rewards as well as the shard population.

4 Likes
18

Iā€™d be very careful setting this % too low. Your going to be increasing a lot of validators operating costs. It needs to be one that will be accepted by the majority to pass a vote.

19

Operating cost in which way? itā€™s not a per node limitation itā€™s a per shard limitation.

The good thing we just ask everybody in here. But this % are so not fixed. If people run away from a shard (donā€™t remember but think 180 slot was lowest) those 6.4% will be 8.9%.

  • 16 Keys per Shard (6.4% by 250 Keys per Shard)
  • 14 Keys per Shard (5.6% by 250 Keys per Shard)
  • 12 Keys per Shard (4.8% by 250 Keys per Shard)

0 voters

3 Likes
21

Are they not one in the same. One shard per server. Those forced into two so double their costs if renting or purchasing servers. Iā€™m not adversed to a limit, but the right % needs to be decided. Indeed a vote on that is a good idea.

The % is based on the total slots / 4. 900 / 4 = 225. 6.4% of 225 is the max keys you could have irrespective of how many are actually on that shard are the time ( under or over populated ). Correct me if Iā€™m wrong and miss understood robo proposal

1 Like