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

[RoboValidator]

The proposal has been posted here:

https://gov.harmony.one/#/staking-mainnet/proposal/QmPmHnuS1ayrBJ9cL16S39xiUbwcSKx5hnPKFLVKtN489o

Thank you everyone for your feedback and help in shaping this proposal!

[RoboValidator]

No worries I don’t mind if you do But I went ahead posted in a separate thread:

Cap the amount that can be staked per validator for each delegator

Summary: Add a per validator staking cap for each delegator to encourage large delegators to spread their stake more evenly to encourage decentralization. Background: Currently large delegators such as exchanges and hedge funds control a large percentage of staked ONE. Unfortunately these large wallets have not spread their stake as evenly as many in the community would like. To encourage these delegators to diversify their stake, we propose a maximum cap on how much ONE a delegator can stake t…

[Validity]

@Embiei

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.

Humbly, respectfully, and as a fellow Harmony friend,

I totally get where you’re coming from.

From my point of view though, I don’t see this proposal primarily as mitigating risk of a shard attack. I think the primary purpose is to support decentralization of the network.

Of course, this does go against larger validator short term interests. However, I don’t think there will be any “pie” to split if this network does not start getting more decentralized.

The incentive structure, as it stands, promotes a Pareto distribution. Increasingly, the largest validators will be able to continue with the lowest fees (due cost at scale advantage - ignoring the 0% X first epochs), continue increasing keys, and small/would-be validators will get pushed out.

NOT capping the keys per shard could very well serve the interests of the larger validators… but only for a short time. There’s likely a breaking point, where, if overtaken by a truly decentralized network alternative, ONE would plummet. This surely is not in the best longer-term interest of the large validators.

Just my 2 cents!

I’d love to chat about it via message or whatever if you’re open to it. It’s quite possible I do not have your full perspective.

Tom

[AffinityShard]

Hey Tom,

Thank you for your input, you make great points that we should consider.

From reading some of your comments, I just want to make sure you fully understand how Max Keys Per Shard affects things, so I will explain here to hopefully help everyone understand it better.

This proposal will help with decentralization in several ways:

-First it will stop one or more large validators with many keys on one shard from going offline and causing consensus to stop. Currently this is a problem that can occur. This proposal forces large validators to spin up new nodes(servers) and split their keys between those servers on different shards, this will slightly help decentralize by not having so many keys signing on one server.

-Second it will make it more difficult for validators to work together to act maliciously towards the network. As noted in one example above if we are going by our current 900 external keys, as a rough estimate 4.8% keys per shard which is around 10 keys cap per shard, takes 8 validators to jeopardize the network.
Currently the network is vulnerable to a malicious attack from potentially one or a couple large validators. (though we all agree it is unlikely, we have to change that fact)

-Third it may help with decentralization as noted in the topic, by allowing Harmony to release the last of their keys to public validators. (Though this might not happen just from this one proposal passing)

What limiting the BLS keys per shard really does in this proposal is causes a large validator with more than around 10 or 15 keys(depending on which % passes) to split their keys over to new nodes(servers) on different shards. There are 4 shards currently 0, 1, 2, 3. Each validator can have (for example) at 4.8% of the keys for each shard which is 10 keys per shard, that is 40 keys total split between 4 shards.

Each server will run on each different shard with those 10 keys, so they will need to run 4 servers total now to get 40 keys instead of potentially one server on one shard with 40+ keys.

This change depending on the percent chosen may not limit the total amount that can be delegated to a validator and it does not cause them to have to start a new validator from scratch and start out unelected.

Lets say at 900 external keys we are able to pass 4.8% and get 40 keys total. with an estimate of 40 keys x 5 Million ONE staked per key. The validator can have 200 Million Harmony total on their validator. At 6.4% a validator can have a total of 280 Million ONE.

When they drop the last 100 keys and we get to 1000 external keys the numbers get higher. At 4.8% it will be 240 Million per validator and 6.4% will be 320 Million per validator.

The level of decentralization of which you speak, will not be achieved by limiting BLS keys per shard unless they drop the % per shard down far below 4.8%.

The way to achieve getting 1000 validators online and fully decentralize is by getting delegates to somehow spread their stake across many validators so that there are no validators with such disproportionate amounts of ONE delegated to their servers.

How we achieve that is a different topic of discussion.

For example in a previous post I posed a mathematical question asking how in the long run we could sustain 1000 validators profitably, with no caps at all on how much a validator can have delegated to them. This is just one of the many things that I said:

@AffinityShard

If even 40 validators had 200 Million each that is 8 Billion and exceeds the total supply to be staked and is not even possible.

[Maffaz]

The end date on that proposal is 29/12/2022

Is that a user error or snapshot? @giv can this be changed?

[RoboValidator]

Oops nice catch… I suppose we can take a snapshot of the results on 12/29/2021 8:15pm? Hopefully we will reach 51% participation by then.

[Maffaz]

We can do but obviously it’s best to change the time

[RoboValidator]

I don’t think IPFS can be changed since it’s a hash of the file content.

Maybe we can just delete / hide these two HIP-16 proposals and start over? @giv

[RoboValidator]

Hmm, actually I don’t have permission to post to staking-mainnet for some reason.

[RoboValidator]

Ok Haodi helped us remove the current bad proposals with invalid end dates. I put up a new proposal but unfortunately it is delayed by one week since I did it through the web page and not the HMY CLI since there’s currently an error with permissions when creating via the CLI:

https://gov.harmony.one/#/staking-mainnet/proposal/QmPxUyTGqmEmBi4p1cvvoUg8aXy5oGbhC2R7VS6o8jEHVM

@leo I hope this won’t be too much of a delay to HIP-19 and your decentralization work

[giv]

Sorry guys, I’ve been away this week. Everything OK now?

[RoboValidator]

All good now @giv . Though I’m having some issues with voting and proposal creation via the HMY cli, however the website seems fine. Logged this github issue concerning it: Encounter "No permission" error when performing HMY CLI governance actions on staking-mainnet · Issue #277 · harmony-one/go-sdk · GitHub

[TriTDX]

You’ve got my support on this. I think its the right direction for decentralization. I’m sure Murphy will throw his wrench into the mix at some point or some eager validator will figure a way around the intent behind this, but hopefully we can at least start moving towards a more decentralized ecosystem.

[ben2k_Stakeridoo]

So when taken the Charter the Proposal is through because 51% quorom and 2/3 in favor for enforce a max key per shard.

The voting period shall last 14 days whereby the proposal must reach 51% of the total stake weight and 2/3rds in favor of the proposal to pass.

But because the Charter do not cover a multi choice option we will need an amendment vote as you was suggesting because on no option is a 2/3 favor.

@RoboValidator will you set up after this finished a new Vote for the two options with the most votings? Or should we discuss and adjust the charter for this situation right now and run it again?

[RoboValidator]

Thank you everyone for participating and voting on HIP-16.

The total participation was 30.82% + 30.56% + 1.38% + 0.35% = 63.11% which is more than the 51% required.

Of the validators that participated, each vote that is not a “no” or “abstain” is treated as a “in favor of” so of those that voted, 100% of the validators were in favor of the proposal which is more than the 67% required.

The final chosen limit will be a stake weighted average of all the “in favor of” votes which is:
(0.3082 * 7.2 + 0.3056 * 4.8 + 0.0138 * 6.4 + 0.0035 * 5.6) / ( 0.3082 + 0.3056 + 0.0138 + 0.0035 ) = 6.01%

So the max key per shard limit will be 6.01% or 13 keys for 900 external slots and 4 shards.

[RoboValidator]

The VDAO charter says:

To pass the HIP proposals requiring a coding change it will require a 51 percent of the stake weight participating and 67% in agreement.

My understanding is that since each of the non “no” or “abstain” votes were treated as in favor of the proposal and the agreement is that everyone voting on a limit will agree to a stake-weighted average at the end I think this proposal still has legal standing to pass.

[ONE4All]

If we follow the charter, a vote (and so an option) needs to have 2/3 of the votes to pass.
This is not the case with HIP-16 unfortunately.
Both options 4.8% and 7.2% are close to 50%.
We cannot just do an average and choose a number that wasn’t even included in the different options.

I invite everyone to continue the discussion for a period of 2 weeks minimum.
Then if we want to move forward with 6% (or an other number), I recommend to cast a second vote, with only a yes/no/abstain this time.

We all know the vote is stake weight but I want to point out the fact that :

• 83 validators voted for 4.8%
• 18 validators voted for 7.2%

I think the opinion of everyone is important to keep the network decentralized enough and I really expect we will be able to find a good solution to secure Harmony together.

[ben2k_Stakeridoo]

@ben2k_Stakeridoo

The voting period shall last 14 days whereby the proposal must reach 51% of the total stake weight and 2/3rds in favor of the proposal to pass.

This is what the charter say under 4) I know we spoke meanwhile a lot about the charter due the two wrong snapshot with timeframe violations.

Think the understanding is that one need’s a 2/3rds in favor to pass. We have 48.835% on 7.2% and 48.4233% on 4.8% so an enforce of a max key is decided but non of them got a 2/3 majority.

Otherwise we need to address a change of the VDAO charter to cover votings with more then a yes or no option. But then again when you look at @ONE4All data about the single votings we have to find a solution that give’s a majority out but respects the vote of the community.

So think we can have two options

1. Set up a new vote between 4.8% and 7.2% and hope to achieve on one a 2/3
2. Set up a proposal to change the charter and fix this situation for future and include by the new Vote this HIP-16 like it was in the past when the quorom was changing to 51%

[Maffaz]

@RoboValidator
Another option here is to have a vote between the 2 options that were clearly favourable

• 1. 4.8%
• 2. 7.2%
• 3. Abstain

[RoboValidator]

How about let’s put this up for a revote for ratifying the stake weighted average of 6%.

The choices will be 6% / no / abstain

It would be nice if we can also add amendment to VDAO to allow for stake weighted choice for proposals in the future so we don’t have to vote twice. Also if this still falls under HIP-16 do we really need another two weeks of discussion?