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!
No worries I donāt mind if you do 
But I went ahead posted in a separate thread:
1 Like
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
3 Likes
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:
3 Likes
The end date on that proposal is 29/12/2022
Is that a user error or snapshot? @giv can this be changed?
1 Like
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.
2 Likes
We can do but obviously itās best to change the time 
1 Like
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
1 Like
Hmm, actually I donāt have permission to post to staking-mainnet for some reason.
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
1 Like
Sorry guys, Iāve been away this week. Everything OK now?
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
2 Likes
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.
1 Like
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?
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.
1 Like
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.
1 Like
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.
7 Likes
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
- Set up a new vote between 4.8% and 7.2% and hope to achieve on one a 2/3
- 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%
4 Likes
@RoboValidator
Another option here is to have a vote between the 2 options that were clearly favourable
-
- 4.8%
-
- 7.2%
-
- Abstain
7 Likes
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?