HIP32 - Complete Decentralization of Validator Network

HIP: 32

Category: Core

Created: 8 Feb 2024

Abstract

This HIP proposes a comprehensive overhaul of the Harmony Validator Network towards achieving complete decentralization, significantly reducing internal validator influence and increasing community involvement in network consensus mechanisms.

Motivation

Since its inception, the Harmony network has shown a solid commitment to decentralization. However, the current validator network structure, dominated by internal validators, challenges this ethos. Harmony aims to foster a more secure, efficient, and community-driven ecosystem by transitioning to a fully decentralized validator network.

Specification

Background

  • Genesis and Progress: The Harmony network, since the genesis block on June 28, 2019, and the subsequent introduction of open staking on May 16, 2020, has gradually reduced internal vote power from 68% to 49%.
  • Need for Change: Despite these efforts, further steps are essential to minimize centralized control and fully empower the Harmony community.

Proposed Changes

  1. Validator Slot Adjustment per shard:
  • Reduce the internal Harmony validator slot count to zero (0).
  • Allocate the available slots to external validators, increasing total slots from 180 to 200 on the mainnet

There will be a total of 400 slots available in total for external with two shards (Shard 0 and 1)

  1. Voting Power Adjustment:
  • Reduce internal Harmony slot voting power to zero (0).
  1. External Leader Rotation:
  • Implement external leader rotation to enable democratic and fair leadership among validators.

Operational Challenges and Solutions

  1. Risk of Network Hard Forks:
  • Implement coordination and contingency planning to prevent network forks while transitioning to external validators.
  1. Network Synchronization:
  • Transition reliance on internal nodes for network sync to a community-driven approach by designating volunteer validators as sync nodes.
  1. Security Measures:
  • Transition blacklist/allowtx list feature management to external validators for enhanced network security and governance.

Rationale

The proposed changes aim to eliminate central control over the validator network, enhancing network security, efficiency, and community governance. This transition is a critical step towards a fully decentralized, equitable, and sustainable blockchain ecosystem underpinned by community-driven innovation and collaboration.

Implementation

  • Hard Fork: A hard fork will be required to implement external leader rotation and adjust validator slots and voting power.
  • Community Involvement: Active engagement with the community to designate sync nodes and transition security measure management to external validators.

Security Considerations

  • Risk Mitigation: Careful planning and community collaboration are essential to mitigate risks associated with the transition, such as potential network hard forks.
  • Enhanced Security: By decentralizing control and involving the community in crucial network functions, the proposal aims to improve the overall security and resilience of the Harmony network.

Conclusion

Achieving complete decentralization of the Harmony Validator Network is a monumental step towards realizing our vision of a fully inclusive, transparent, and community-governed blockchain ecosystem. This HIP represents a commitment to these principles, inviting all stakeholders to participate in this transformative journey.

8 Likes

Where can in find info about H1 Foundation voting power / delegation ?

1 Like

The harmony internal vote power doesn’t have any “delegation” because the internal node operates differently from external nodes, which need to register to become active participants in the network.

1 Like

Bullish AF :fist_right::blue_heart::fist_left:
Thanks Dev Team

3 Likes

Thanks for putting forward this proposal.

As there is no mention, does this mean double sign and downtime slashing is not being considered at this time?

Could we get some detail on the external leader implementation please? Some initial questions:

  • What happens to unresponsive leaders?
  • How are leaders selected (random / stake weighted etc)?
  • Any plans to reward successful block proposers?
  • What happens when a proposed block doesn’t get enough signatures, how does the next block get produced?

The validator community voted to remove the blacklist functionality (see HIP17). Harmony decided to ignore this particular HIP so I wonder will maintaining the blacklist be enforced in some way? Is the black list used during block production only, or will the blacklist also be used by nodes validating the proposed blocks?

1 Like

That is correct

Expected leader are assumed to have sign the past few block before, if they were not they will be skipped. If leader are are unresponsive while they are supposed to proposed, view change will kick in and a new leader will be chosen

All elected keys will become leader at one point, hence validator with more keys are expected to be leader more often.

None at the moment but that can change, ie a certain % of the block reward or portion of the fees.

when that happens, the current consensus round will fail and view change will kick in to select the next validator

Oh i see good, I completely forgot about that thread … We never went for snapshot vote on this one right ?

2 Likes

Hello Everyone, sending here a quick poll. Thanks

  • Yes for full decentralizations !
  • No, stay at is, please explain why
0 voters

Will leave it one week then we’ll go for the snapshot vote !

3 Likes

Thanks Soph.

HIP17 was voted on and passed (as far as I recall) but it’s on the old snapshot fork which doesn’t seem to be loading results at the moment.

2 Likes

Validator.ONE is in favor of this proposal. To clarify below, HIP32 would increase external validator slots from 180 to 200 per shard, and from 360 to 400 in total, including shards 0 and 1, correct?

HIP32 only seems to acknowledge internal validators on shard 0. We may want to provide additional clarification in the final revision if its also removing internal validators on shard 1.

2 Likes

Given the risk of double signing and thus forming the chain, I think it’s very important that we:

  1. have a method to locate double signers. @sophoah I know we spoke of a tool you had that may work. Did you manage to refine it to have the latest peer id’s?

  2. reach out to all those who are likely to be elected to make sure they are aware that live back ups are strictly prohibited or we have a large problem.

In my opinion both those need to be in place prior to anything going live or we could hit a chain fork on the first epoch!

2 Likes

yes that is correct, the proposal is per shard. I’ve updated the proposal accordingly

1 Like

Yes, we should be able to share the ones with backup node this week.

1 Like

Wasn’t that the purpose of the IsBackup flag under General in harmony.conf to be able to have a backup running on a complete decentralization of the network ?

A node with this flag enabled should not sign anything, it was the intention of it at the time was made but not sure if it works properly now

And in a case of the main going down a script swapping that flag should do the trick, something like this:

os.system(“sed -i ‘s/IsBackup = true/IsBackup = false/g’ harmony.conf”)
os.system(“service harmony restart”)

and vice versa. The problem will always be when the main gets online but because the main being being behind in blocks doing a simple alive check system script between main and backup should work

Something like the main gets online and be 100 blocks behind, when it gets to ex 4 or 6 blocks send the message to backup to swap the flag. The node will miss those remaining blocks but its a ok “price to pay”

But the important question is if the IsBackup flag is working as intended

1 Like

We can check if the flag is doing its job.

I’m a bit worried about relying on this flag because, as you said, it depends on an external process. If something goes wrong with that process, we’ll have active and backup running at the same time.

Sure, we can make sure the flag is working, but I think it’s important for everyone to know the risks involved.

How possible is it that on a protocol level you could lock out any additional nodes from signing ? Maybe using IP’s ?

1 Like

I’m in favor of this as it’s something Harmony has been working towards for a long time. My main concerns are mostly the same as others and I hope that we can address them before moving forward.

  • We need to make sure we have the backup node situation figured out fully before we activate this change.

  • We should consider changes to the staking dashboard for the uptime stat due to the higher possibility of a node dropping offline if we do not have more than one instance running as well as not having backups as mentioned above.

  • I have been told that hardware requirements would not change if selected as a leader node but I just want to confirm by asking here. Are there any changes to the minimum hardware requirements for shard 0 or for shard 1 with the new changes or when selected as leader? As both shards have different hardware requirements I have to ask about both separately. If there are any changes, what would the new requirements be for each shard?

Just some side thoughts that may want to be considered:

Could we possibly look into the ability to change the wallet attached to a validator and also maybe having the ability to use a hardware wallet for a validator? This is possible on some other networks and could potentially be useful. I would like to hear of anyone’s thoughts on drawbacks to this as well.

Since the network will be fully on the external validators nodes we may want to rehash some information such as:

  • Sharing information or creating a document on good security practices and proper security settings for nodes.
  • Security measures of a data center vs proper security measures to consider when running a node from home.
  • Redundancy of power/internet and other infrastructure of a data center and what redundancies a node runner is capable of achieving if running a node from home.
  • Consider and talk more about the implications of decentralization or lack thereof when it comes to using the same hosting providers/locations of data centers. Ideally we want as many unique node locations as possible, but due to many constraints it is not possible for some to effectively run from home without the possibility of downtime of their main location. Due to the limited amount of hosting providers and constraints of running nodes from home, these are all things we may want to talk about again as we move forward.
2 Likes

i guess that’s possible but let’s work out something with the validator first and let’s not complicate more the current codebase

Hey, there is no major changes in the hardware requirement which I’ve revamped here : Requirements - Harmony I just would like to highlight the importance of having dedicated CPU when using a VPS which i hope by now, for shard 0, everyone one is doing so.

When leader rotation is activated, there will possibly more signature loss if the leader is not performing.

Just curious, can you can share which network allow the change of validator address and the use of hardware wallet for validation (ie I am referring to the BLS keys).

Note, you need to differentiate the validator address used to perform the staking transaction related to the validator and the keys used by the node to validate on the network (aka the BLS keys).

The BLS Keys must be on your node as they are loaded when the node start, however, the validator keys (used to do staking transaction) doesn’t have to on the node. And this one can be a hardware wallet wallet eventually.

for the other proposal, i think we can use a separate thread to discuss them.