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
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)
Voting Power Adjustment:
Reduce internal Harmony slot voting power to zero (0).
External Leader Rotation:
Implement external leader rotation to enable democratic and fair leadership among validators.
Operational Challenges and Solutions
Risk of Network Hard Forks:
Implement coordination and contingency planning to prevent network forks while transitioning to external validators.
Network Synchronization:
Transition reliance on internal nodes for network sync to a community-driven approach by designating volunteer validators as sync nodes.
Security Measures:
Transition blacklist/allowtx list feature management to external validators for enhanced network security and governance. Note HIP-17 suggested the decommission of the feature.
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: 1 or multiple hard fork will be required to implement external leader rotation, 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.
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.
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?
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 ?
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.
Given the risk of double signing and thus forming the chain, I think itâs very important that we:
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?
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!
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:
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
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.
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.
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.
