HIP29 - Increase of External slot to 952 and voting power to 74%

Hello Harmony ONE Community,

Summary
This proposal is to

  1. increase the external slots from 900 to 952 (harmony internal will have 48 slots)
  2. increase external voting power from 51 to 74% (harmony internal will have 26%)

Background
As one of our long term objective to fully externalize the harmony validator network, Harmony foundation have to let go on of the internal slot and internal voting power. This HIP help to achieve this vision and requires network validator community vote. A hardfork will then be scheduled after a positive outcome.

Process
Any change in behavior for existing network protocol feature will require governance vote to ensure the community are fully aware of the update.

This proposal will remain on the Talk forum for 2 weeks for community engagement purposes and feedback.
A poll will be attached to gauge sentiment, which is not to be considered as an official vote and an AMA may eventually happen if there is a need to.
After 2 weeks, a snapshot vote will be posted, at which time validators will have a week to vote.

How to obtain quorum

  1. the total_stake and validator_stakes from all validators in the network is captured on a given block
  2. all votes (Yes/No/Other) received needs at least 50% of total_stake minus stakes from known CEXes and big Validator who don’t wish to participate into governance
  3. and 66.67% consensus vote (Yes) from point 2)

Note: There are some ongoing discussion with a group of core validator to revamp our governance and avoid the manual removal of the non participating validators. Additionally, they will finalize the list of the non participating validation. Hence, the above is subject to change in the future.

Known consequences
There are multiple drawback that the community needs to made aware. With the increase of the external voting power, there will be a larger dependency on the external validator community. During the January 2023 mainnet shard 1 and 3 incident, network shard recovery was delayed due to the lack of voting power. Without a prompt action from the external validator, network may sustain longer network outages.

3 Likes
  • Yes
  • No

0 voters

1 Like

@sophoah The path towards decentralization will increasingly rely on external validators, if this is a problem we should find a mechanism to contact the relevant validators as quickly as possible

1 Like

Every time Harmony releases more keys, they’re entirely absorbed by large validators. No new validators are ever elected despite all the new keys becoming available.

What does Harmony plan to do to ensure this won’t happen again?

Is there any concern on Harmony’s part about the stake centralization on the protocol? The 10 largest validators comprise 7.2% of elected validators and control 49.1% of all stake. The 14 largest validators (10.1% of elected validators) are all above 100 million stake and control 56.4% of all stake.

Nearly half of all elected validators are single key validators (66 out of 139). And close to 2/3 (87/139=62.6%) are below the upper bounds of 1.35xEMSx2, which gives an approximation of the total 1- and 2-key validators. These 87 validators account for 674 million stake, or just 10.9% combined.

Is this imbalance good for Harmony? Is it what Harmony wants? If it is, can you explain why? If it is not, can you detail what Harmony’s ideal distribution would be?

“Is this imbalance good for Harmony? Is it what Harmony wants? If it is, can you explain why? If it is not, can you detail what Harmony’s ideal distribution would be?”

Exactly! @sophoah Harmony can’t ignore this anymore, it has been raised for so long now and we never had any feedback from the core.

1 Like

Slightly off topic - I’ve been wanting to create a proposal to remove the multi-bls feature from nodes, but have had a hard time getting info on the reasoning behind its inclusion. Could you share your thoughts here please?: https://talk.harmony.one/t/is-epos-a-broken-governance-model

we implemented a hard fork to have a high limit of BLS key per shard https://talk.harmony.one/t/hip-16-enforce-a-6-4-max-key-per-shard-limit-for-each-validator/. We are doing small updates with the capacity we had

Additionally, there are other discussion in talk that we can resume :

However I can’t commit on the implementation once we have discussed fully on the parameters and conditions.

1 Like

A limit of 6% of keys per shard means there is the potential for just 17 elected validators to run the entire Harmony blockchain.

Is that what Harmony wants? Is that best for Harmony? If yes, please explain why. If it’s not, please state what Harmony’s ideal distribution would look like.

There are already 3 validators at the current 52-key max (it would be 4 validators if Binance actually utilized all the keys they’re permitted to acquire). There are 3 more validators at 40+ keys. Those 7 validators account for 5% of all elected validators but ~34% of all external keys at present (and ~37% if Binance used their full allotment).

Is that what Harmony’s team wants? Is that what’s best for Harmony? Please explain.

Based on past hard forks that increased the number of external keys, we know that they are essentially entirely acquired by currently elected multi-key/large validators. Specifically regarding HIP-29, validators will be able to increase from 52 to 56 keys.

Does Harmony have any concerns that the 52 externalized keys will be acquired by larger validators and that HIP-29 could have a deleterious impact on decentralization of the protocol? Please explain.

As you’re aware, those discussions are up to 3 years old and have failed to fix the issues at hand.

Thank you for your questions>

I agree wit you this is not ideal definitely, and we can all agree a better split of all the slot available in the network is preferrable.

However there is no perfect system, if you have one, please let me know, I’ll take the time to analyze it and see how we can update the harmony staking protocol

There are some proposal and even that they are not perfect, ie if we were to

  • limit the total keys for a validator
  • limit the number of reward for a validator
  • limit the max a whale delegator can delegate per validator

Nothing will prevent that whale to create a second validator ie binance-validator1 binance-validator2 (I’ve seen in other network really …) or create a 2nd/3rd delegator account if they only want to delegate to the same set of validator.

A very good community validator may also be impacted but nothing will prevent him to create a second community validator that he manages.

Most have been suggested and we, Harmony and the community, will need to continue working together to discuss and implement some of those proposal. They are not bad and I am sure they are working good towards a better decentralization.