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

Yup that’s correct. The formula is 6.4% * (total number of slots / total number of shards)

3 Likes

Majority meaning whoever has the most ONE staked?

1 Like

Yeah this is my understanding as well. Anyone who has more than 16 keys (or w/e amount we decide on) would be forced to add keys to another shard. If they don’t already have keys on that shard they’d have to spin up a new node and incur more server costs.

Realistically speaking though, isn’t that a negligible cost for a validator that has grown that big? Based on some quick napkin math a validator of that size would be getting over $90K USD worth in rewards annually with current ONE prices - certainly enough to cover the additional cost imo.

5 Likes

I think this 6.4% (16 keys) limitation is pretty reasonable, and definitely a step forward toward external leaders. I’m curious to hear more opinions though. I’m sure some will want the % to be lower and some will want it higher depending where they are on the spectrum, but this sounds a nice middle-ground to me for now.

Although I hear your logic here, you cannot use the price of ONE as justification. It wasn’t that long ago the price was a fraction of todays price and with no true guarantee it won’t go back down ( I hope not but we must be mindful ). With the ever increasing db size and thus costs involved I’m just saying this % shouldn’t go TOO low as it either won’t pass or god forbid if the price crashes some validators will give up. Like you say I think each validator will have their opinion on what they are happy with.

EDIT: of course if the price rockets then the issue diminishes on a costs perspective.

1 Like

But one Server per Shard is already, you can not have Server on several shards. So this is only if you have like KuCoin 50 Keys on Shard0, but most have already splitted into several shards wich is healthy and sustainable for the network.

Yes and by so I wrote % by 250 Keys per Shard and prefer to speak about Keys because % are in real flexible be over or undersaturation

I completely agree with you - was just illustrating that point with those numbers to show that even if we went back down to $0.02 those validators would still have more than enough to cover server costs. Hopefully we won’t have to worry about that though :sweat_smile:

FortuneValidator, you’ll need to do better imo.

If you do your math, a large validator with an efficient setup and 5% comm is more than sufficient to cover infra costs and still make a profit, even at 4.8% max key per shard. This is even when ONE was at 0.05, so I’m not sure what you are smoking here.

Let’s just be upfront and call a spade, a spade. The resistance is about profits, no matter how you justify or sugar coat it.

This proposal is for the betterment of Harmony, and it’s the right thing to do.

5 Likes

I hope you understand that my comments are not of my own agenda. As I mentioned, I belive its important to choose a percent that appeases the majorty. Without it then it will not pass, then who does that help?

4.8% will cause the top staked validator to be in the upper bounds and for the next 5 or so leaves no room to grow. I understand that them growing may be the furthest thing from what you want BUT you must remember you need their support to pass the vote. So why not choose a respectable percent like @RoboValidator has already suggested.

I dont argue that profits come into many validators goals and thus again surely finding a happy medium percent is the goal to get it passed and not going so low that this proposal doesnt go anywhere.

I agree although 4.8% is winning in this equal weight poll I doubt it will pass the staking-weighted vote. CPU cores also usually come in powers of two and 12 and 14 keys also aren’t a power of two so it won’t be as cost efficient as 16 keys which will be well suited for machines with 8 cores / 16 threads.

1 Like

I already said this in the other talk thread, but you are worried for the sustainability and the servers costs for the validators with 16 keys (16*7 = 112M+) or more.

Again :

  • 126 validators are below 5M
  • the validator median stake is 5.3M

Before it becomes not sustainable for the 100M+ validators we will have an other problem with the vast majority of the validators…

2 Likes

So if large delegated validators don’t like the proposal, doesn’t matter what the majority of all others say, it won’t pass. Right?

Definitely. Thanks for being upfront about it.

Eroding profits is a valid concern for larger validators. I just cringe when a validator tries to reason about not being able to sustain the costs, when we all know it is about the margin of profits. It is hypocritical.

Let’s not dilute the discussion with smoke screens. Back it up with true facts and numbers. It is not helpful and diverts the matter at hand (unless of course diversion is their true motivation to further their own agenda).

3 Likes

I’d like to say I don’t speak for any other validator. I was only stating and this is the same with any proposal that you need to try and find a happy medium that is likely to pass, otherwise there is no point. This proposal can do some good and it would be a shame to see it fail.

My vote is for 12 keys per shard. 12 keys x current upper bound entry point of 7 mil x 4 shards =336 million one total Validator wallet stake across potentially only 4 nodes. That is sufficient to cover even the largest validators.

1 Like

Keep in mind 12 keys is assuming 1000 total slots. At 4.8% and 900 slots the limit would be 10 keys per shard in the current state.

If we really proceed with 4.8% I don’t see this passing and we will have wasted two weeks and potentially add a ton of delay to the node decentralization work and potential listing on Coinbase.

1 Like

Looks like almost all of us are on board for the need for a max key limit but there is disagreement on the exact limit.

How about we change the voting in the proposal to:
4.8%
5.6%
6.4%
No
Abstain

The percentage that gets the most stake-weight votes will be the final limit.

The proposal passes if it has more than 51% participation and combined votes for 4.8%, 5.6%, 6.4% are more than 2/3. The final limit will be the percentage that has the most votes.

So basically all the percentage votes will be treated as “Yes” but the percentage with the most votes will be the actual max keys limit.

6 Likes

I like the idea. Let’s see what the rest thinks.
Thanks for facilitating this Robo.

At the end of it, we should broadcast the results to the various community channels along with the votes of each validator, regardless of which way it goes.

The community can then decide who are the self serving validators, and whether it still make sense to support them.

2 Likes

So i’m curious about the data. Potentially we could see a drop in the bounds with the final 100 keys. Say we go with 14 keys and the upper bound drops to 6 mil. Would equal 344mil and cover. 4.8% would only cover 288 mil if the bounds drop that far. Median would be about 4.5 mil for this scenario to play out during the key additions. If total stake rises and we keep the same general curve everything should scale. The biggest concern is after we recieve the last 100 keys and that settling period. 16 keys would cover 384 mil. Overkill.

1 Like

Ahh didn’t catch that variable! Definitely 14 keys then or 5.6%. I like the 3 way vote idea as long as we meet quorum of 51%. However I think the winning choice still needs to get 66% of that quorum or we’ll need an amendment vote.

2 Likes