You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add a 6% max keys per shard limit for each validator. The computed limit will be an integer floor of the percentage times the total number of external slots divided by the number of shards. At 900 external slots and four shards, the max keys will be computed as the floor of (.06 * (900 / 4)) resulting in a max key limit of 13. The limit will be the same across all shards regardless of each shard's individual population.
Context
Background
Currently a large validator can dominate the voting power of a single shard by assigning all their keys to that shard. This is undesirable because for example if a shard becomes dominated by two validators with more than 1/3 voting power and they both go down for maintenance then it could stop consensus. Also if a large validator dominates a shard and proceeds to run underpowered nodes they can possibly slow down the block times as we may be currently seeing on shard 0.
Motivation
To further decentralize Harmony protocol and prevent scenarios like the above from happening we propose a 6% max keys per shard limit to decrease the likelihood of a shard being taken over by a small group misbehaving validators. This rule will also help with the node decentralization goal on the roadmap by making it safer to ramp down the internal nodes: https://open.harmony.one/strategy-roadmap/launch-dates-weekly-updates/decentralized-nodes
https://talk.harmony.one/t/hip-16-enforce-a-6-4-max-key-per-shard-limit-for-each-validator/6454/154
https://gov.harmony.one/#/staking-mainnet/proposal/QmfCBuPFnAx9N5GKBrFBtCkjyff2UzxULhwhsEcGWYdTRY
Description
Add a 6% max keys per shard limit for each validator. The computed limit will be an integer floor of the percentage times the total number of external slots divided by the number of shards. At 900 external slots and four shards, the max keys will be computed as the floor of (.06 * (900 / 4)) resulting in a max key limit of 13. The limit will be the same across all shards regardless of each shard's individual population.
Context
Background
Currently a large validator can dominate the voting power of a single shard by assigning all their keys to that shard. This is undesirable because for example if a shard becomes dominated by two validators with more than 1/3 voting power and they both go down for maintenance then it could stop consensus. Also if a large validator dominates a shard and proceeds to run underpowered nodes they can possibly slow down the block times as we may be currently seeing on shard 0.
Motivation
To further decentralize Harmony protocol and prevent scenarios like the above from happening we propose a 6% max keys per shard limit to decrease the likelihood of a shard being taken over by a small group misbehaving validators. This rule will also help with the node decentralization goal on the roadmap by making it safer to ramp down the internal nodes: https://open.harmony.one/strategy-roadmap/launch-dates-weekly-updates/decentralized-nodes
6% was also chosen since it is the stake weight average (rounded to the nearest tenth) from a previous version of the proposal: https://gov.harmony.one/#/staking-mainnet/proposal/QmPxUyTGqmEmBi4p1cvvoUg8aXy5oGbhC2R7VS6o8jEHVM
Acceptance Criteria
Reward
TBD by Harmony Core Team
The text was updated successfully, but these errors were encountered: