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.
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.
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.
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.
Transition reliance on internal nodes for network sync to a community-driven approach by designating volunteer validators as sync nodes.
Transition blacklist/allowtx list feature management to external validators for enhanced network security and governance.
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.
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.
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.
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.
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 ?
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 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.