Removed the HIP because this is not a proposal.
We will reserve HIP16 for when a proposal is formulated.
1 Like
Iāve noticed some big validators have more than 40 or 50 keys per shards. So, given one shard has 250 keys in total, it is about 50/250 = 20% of the keys in one shard. If 100% of the voting power is assigned to all external nodes, so if two of those big validator nodes in the same shard are doing maintenance and stopped the nodes at the same time, that shard will lose 40% of the voting power and the consensus will stop as consensus needs 67% of voting power to proceed.
Thatās the current risk before we have the complete resharding algorithm implemented.
To get into decentralization faster before the complete resharding, I would support the proposal to reduce the total number of keys per validator. The current max number of blskey per validator is 106. I understand a validator may start another validator in the same brand. Thatās fine with me as long as more nodes are added to the network. I am more thinking of the network security and maintenance risks in terms of the number of nodes.
Whatās the optimal number of blskey per validator needs more discussion and debate.
9 Likes
Great points 
But what if a Validator set up another Validator but using the same Node. Like 10 Keys for Validator 1 and 10 for Validator 2?
May I create a seperate proposal with my previous Idea to set a fix limited key amount per Node.
2 Likes
Of course.
Anyone can create a proposal at anytimeā¦
If it is feasible then it will go for a vote after debate.
This process is frustrating for me to watch and Iām not even a validator
This topic is 3 months old and there hasnāt been a single improvement implemented
Every election I see multiple validators drop keys immediately after the epoch begins. Is that how the devs want it to work? Does this process make the protocol ābetterā, more decentralized, more secure? Would those keys not be better utilized in the hands of additional validators? Additional validators that are currently being barred access (whether itās intentional or merely a byproduct of the system, I canāt say)
I understand why leo says heās fine with validators creating another validator as long as itās adding more nodes to the network in order to add security and reduce maintenance risks. But does that also mean new and smaller validatorsā āstrugglesā should be excluded from consideration? What I mean is, should we be trying to BOTH prevent large validators from over-keying single shards AND working to creating a more fair environment for smaller validators to compete within? Or does the fairness not matter as long as the security of the protocol is intact?
These are questions that need to be answered so that we can then decide on the solution(s). Many suggestions in here are also geared towards creating a more equal playing field for all validators. But if equality is not an objective, we can ignore those suggestions
I personally want to limit the risk that larger validators pose to consensus, and make it more fair for smaller validators to participate and further decentralize Harmony. However, I think most of the proposals above would need to combined with another proposal or two in order to see substantive change.
I would like to see the following all implemented:
- I like the idea of randomization. I would like to hear more as to why thatās purportedly not feasible
- I like the idea of ādegradingā rewards as validators grow beyond a certain point (see jacksteroo post).
- I like the idea of limiting the number of validator keys per shard (this seems to be a necessary change, per leo).
- And it should not be possible for validators to load up on extra keys just to drop them post-election.
3 Likes
It is frustrating but no one has put forward a proposal to vote on so far.
If we have a proposal, then we can vote and get it implemented (or not).
until then it will simply remain a discussion.
We are, however, arranging an AMA with the core team to discuss what is and is not feasible and the output from that should give insights so a proper proposal can be created.
I hope you can attend when we have arranged a date!
1 Like
If the concern is maintenance down time, then surely it makes more sense to limit the number of keys per node server rather than validator? A validator is unlikely (although itās possible) to shutdown all their servers at the same time.
In the same way we are currently limited to one shard per node server, are people here willing to discuss a maximum number of keys each node can have?
As a validator this setup makes sense to me as Iāll spread my keys across multiple servers with the aim that if one server goes down I can maintain a higher uptime than if my keys are all on one server. It would also limit the uptime hit during maintenance because only a subset of my keys will stop signing as I roll out the maintenance across servers.
I canāt see any real security benefit to having DKValidator1, DKValidator2 etc
2 Likes
Exploring a total key cap as a way to get this moved forward.
Looking at the current bidding, lets say 20 keys is a good maximum:
- It effectively puts a total stake limit on validators at around 150m (very rough estimate)
- Looking at smart stake currently 11 validators would have keys removed:
- Six large validators would need to lower their stake (or split) to maintain a competitive APR
- Five can safely reduce their keys to 20 and stay under the upper bound
- With current bidding, 139 slots would be made available.
Who is in favour of a 20 key maximum?
8 Likes
Can you have two validators in the same server? I thought not.
1 Like
I donāt see why not.
The node will sign using the keys available on the server, I donāt think there is a mechanism to detect if those keys belong to the same validatorā¦ could be wrong.
2 Likes
Sounds reasonable to me and will help get us to the goal of 200 by year end.
2 Likes
A dynamic cap on keys by shard that reduces network security risk is reasonable, however, a total cap on keys from the current cap of 106 to something like 20 keys is too drastic and would negatively impact thousands of delegators without addressing two of the most significant underlying issues facing the network today, which is the control over the network held by large delegators and validators with 5+ keys competing for best ER by taking up all available slots below the 0.65x lower bound. KysenPool reduced his key count to 1 for an epoch and it resulted in essentially no gain in the number of elected validators. The reason wasnāt because of large validators adding keys, it was due to small and mid-sized validators adding keys to maximize their ER.
2 Likes
Yes, that would free up quite a few keys. At what point would the broader crypto-verse consider Harmony decentralized?
When we are actually decentralised.
Leo is saying we need this proposal passed to implement full external nodes. At the moment leader nodes are run by Harmony.
Having a max key limit is something that can be implemented easily, and changed easily later.
It might not be necessary when we have EPoS fully implemented, but it removes a blocker on our path to get there.
20 key max seems a high enough number to adversely effect only a small number of validators, but high enough to allow validators to get to a ādecentā size imo
1 Like
The 20 key limit would stop validators being able to hit the lower bound when they reach a certain size. I think at the moment validators over 60m stake would have trouble getting into the lower bound with a 20 key cap.
If we need another proposal to further limit lower bound incentive Iām all for discussing that as part of another proposal.
If weāre just picking a number without any basis for reducing network security risk and solely for the purpose of decentralization, why wouldnāt we just go with 1 key per validator? Not saying I agree with that, but what are we really trying to achieve with reducing BLS keys? It seems we flip flop on what weāre trying to accomplish.
How many Keys would you think are reasonable for now?
And how would you think about still limiting it now and making it dynamicly in the future?
Woul propably be alot easier to do in time for resharding etc. .
If we need 67% of voting power in each shard to reach consensus, that should be our starting basis for determining the right number of keys per shard rather than jump to an overall key cap. There are some validators who run 30-50 keys on one shard. Iām not sure why a validator who runs 35 keys evenly across all 4 shards should be met with the same level of scrutiny and restrictions as those who donāt make the attempt to decentralize the network. Itās an easy band-aid but itās not logical to me.
1 Like
Wouldnāt capping each shard at a set # of keys achieve Leoās goal while allowing 106 max still?
If you were capped at say 27 keys max on a shard, 106 total - does that solve this issue?
Iām still all onboard with other ways to get this accomplished but it seems like a per shard cap is what Leo is mostly suggesting?
1 Like
Thatās how I inferred it, but this discussion always leads to an overall key cap in the name of ādecentralizationā, even though I have my doubts thatāll solve the underlying problems with unelected validators still going unelected even when large validators drop 30-40 keys in a single epoch.
1 Like