Introducing a hard key cap that reduces the number of maximum keys per validator from 106 to 24 is an admission of fault in the original design of EPoS. EPoS was intended to limit the “rich get richer” problem described by @Manumix. If EPoS isn’t working as designed, perhaps a complete overhaul is a more realistic approach rather than death by a 1,000 cuts to only the largest of validators. If the goal is 1,000 unique validators per 1,000 validator slots, why is the protocol not just 1 key per validator? 24 keys is like picking a number out of a hat and using that to build your whole protocol around. I would like to see more basis for change rather than choosing a number that just looks OK based on current delegations, which can change at any moment given the fluidity of elections.
We’ve never supported a hard key cap and will advocate against one if this proposal goes to vote.
The technical aspect of this issue is above my head but i do sincerely hope that, the individuals who have a vote in this will find the wisdom and heart to support the choice that is beneficial for the whole rather then the individual.
Allow me to remind you Harmony’s vision: To scale trust for billions of people and create a radically fair economy -.
This is exactly the point and I have addressed this idea at some point, but it was received as a heresy. Why try to amend the thing now in a distributed and decentralized manner given that the base is flawed instead of changing the base itself? I like how you put it, death by a 1,000 cuts
I’m not sure I follow your argument @ValidatorONE. As you’ve pointed out the protocol in it’s current form already exists with a hard cap of 106 keys.
Where did the number 106 come from? Out of a hat?
Why is it admitting failure in the entire protocol, to think that 106 keys is too high? For me this is a parameter that can be changed whilst keeping the idea behind the protocol intact… Namely that security is increased by having a single entity divided up and validating in multiple independent shards.
When the situation changes again in the future, parameter changes will continue to be voted on just as they are with most blockchain projects.
I think 10% key limit per shard would be a good start and would be very likely to pass. How about we approach this one step at a time and re-evaluate from there? It would be a significant improvement over the 50 keys that Kucoin has on shard 0 today. We can perhaps negotiate on what threshold the community can agree on if we need to go below 10%.
I’m new to the validator community and don’t have as much experience as many of you here, but I do understand the situation. Currently with mid to large validators taking the keys they don’t need is resulting in small validators not being elected on and off. This is very discouraging and many people don’t even bother to setup one or even if they have one, once they see the greed they just shut it off.
I see some arguments here trying to protect these validators. But for what, really? If the goal is to secure the network with more validators and also limit the greed some validators are displaying, I don’t see a reason to be against this.
10% key limit per shard is 25 keys
I am open to the discussion but the initial proposal was about 6 keys maximum to guarantee a minimum of 14 validators to halt the network.
Comparison is not reason but on the BSC it requires 8 validators and 19 on solana to halt the network.
Your proposal : 10% limit = 4 validators to halt the network.
My proposal : 2.4%. = 14 validators to halt the network
If we really want to move forward, maybe 5% can be an option.
If you disagree with that, well I don’t know, after all you guys have most of the voting power so I will let you decide for us but I won’t continue to participate here.
How about a max of 6.4% keys per shard. This would allow for 14 slots per shard at 900 slots and 16 slots per shard at 1k slots which would be cost efficient for machines that have 8 cores / 16 threads.
Another rule to allow for a smooth migration could be to evict one key over the max shard key limit per epoch. @leo might have some better ideas on this as well in terms of what would be the easiest to implement at the protocol level.
This looks like a good step in the right direction to secure the network.
We could probably reach a consensus here, maybe 12 slots per shard is the magic number but 14 is pretty close I must say, so it’s a good news.
This should help to lower the risks with the resharding and external leader nodes and we could potentially move forward safer. I think we need some inputs from the team here.
Also I am not sure what will be the implementation of the resharding, if someone can explain.
Will a validator will still have to create X number of keys and then the keys will be spread equally between the shards or randomly?
I think in both cases, this proposal makes sense.
Thanks @ONE4All. Do you want to create a follow up HIP? Or one of us can as well. I talked to @leo recently and he says evicting keys is too risky. Maybe we can leave it to Harmony team to choose the best path for the migration and enforcement of the shard key limit rule.
I think all the large validators that this would affect are active on social media, so I don’t think we’d have any issue with communicating the new rule and transitioning except for the case of Kucoin. It seems like they usually respond once they see their reward rate go down though.
I think it will be cleaner to have one proposal and one suggestion. if not things tends to go south. It’s best to have one proposal and have a list of pro and cons that are summarized in one post when everyone agrees with it.
now there are some technicalities to considered into all the above discussion
the 10% keys per shard is good because :
the 4 validators to halt the shard is ONLY if we assume those are 4 big validator all owning the 10% max keys.
I really doubt the 4 would purposely try to bring down the shard.
Kucoin with its 50 keys in s0 today can bring the shard down in the future (today they can’t because external still only has 60% total voting power, in the future with 100% voting power fully external it will).
with 250 slots all external and 100% voting power we need 250 x 33.34% =~ 84 keys not signing to bring the shard down.
24 keys max per validator doesn’t help in anything here. A validator can still decide to create another validator with a different address and now have 48 or 72 keys. So we need to find here a good balance and not hurting unnecessary the big validator. That key issue will be best addressed by having a proposal that target the BIG delegator (ie binance or others), I believe there will a much bigger impact into decentralization if we force the big delegator to spread out their delegation. In a way how you guys did by influencing wallet #19 but now done on the protocol level. VDAO, please start a new thread on this. (example of proposal, a given validator can’t delegate more more than x ONE, and if they are during election their bid to that validator will be cap to that max).
the key of the security and decentralization of the network is the number of nodes and different validator entities as possible from my point of view. today the 10 key pax per node can be changed so a different thread to discuss only this with a number is a must. Having more node running less keys will be more secure that running 50 keys in one node or two nodes.
in terms of technical feasibility of the 3 proposed solutions, they are all implementable. However, more rules means adding more complexity to the chain and hence means as well more burden to the chain.
also I voted no here because there are too many proposal in one, please have one proposal and one vote
Always thougt about limiting max delegation in a way that just stops the option to delegate at some point, but better would be to only get rewards for X One, while still being able delegate more?
I am voting no for the same exact reason that you stated. It’s a yes or no vote, and I’m not very clear at all on what I would be saying yay or nay to. So I’ll just say no to be on the safe side for Harmony’s sake. I can’t believe it has this many yes votes tbh. How were you all able to determine exactly what you were saying “yes” to?
Don’t take this the wrong way, I’m not knocking anyone for doing so, but the fact that there are so many yes votes on this as it is, is quite concerning tbh. We truly have to take care when voting for changes to Harmony. Especially when it comes to changes this significant.
Okay I started a new thread tagged with HIP-21 just to address the per shard key limit rule. I set it at 6.4% based on what we ended the thread at but feel free to push back on 10% if you think that’s better @sophoah
I do believe that I’ve now made more sense of what this vote was for exactly, so my apologies. It is more specific than I initially realized. But how can we allow validators more than 10,000,000 ONE staked on each, if we plan to have 1000 validators online? There’s not enough ONE in existence to accomplish that. Doing the math, the real max number of ONE delegated to a validator should be 5-10 million, in order for there to ever be 1000 Validators online. If we are going to limit keys, shouldn’t we limit them to a number that makes it possible to reach a goal of 1000 validators online eventually? That would literally be impossible if any one validator has over 5-10 million ONE delegated to it. Correct? If so, I’m confused as to why we are allowing validators to grow beyond these numbers while having a goal of 1000 validators online one day? This makes it impossible does it not?
I agree that it probably is best to just separate all of these into separate proposals so there is no confusion and we can get a true feeling for exactly what the community would like to be done. But at the same time, none of these proposals make much sense to me at all. Not with the goals we have and the numbers involved. None of BLS key limit proposals seem to align with the goals that Harmony has. Or am I missing something here?
Regardless, we do have to be careful with changes that we make to Harmony, and I feel like sometimes people just go with the flow and vote just because others that they know are supporting it. I’ll tell you right now that you could be my best friend in the world, but I will not support you or anything that you do here if it’s not what’s best for Harmony and I’ll be the first one to question it or raise concerns. I hope you do understand. Nothing but for you all!
If you have better ideas, please go ahead
There is the theory (utopia?) and the reality.
1000 validators implies to limit the number of bls keys to 1.
I am not against the idea but… did you read what @sophoah (from the harmony team) just said?
If a limit to 24 keys is not acceptable, I doubt a limit to 1 key is…
I am running a validator since April now for harmony and I am active like 7/7 since then.
I am not the more experimented validator out there but my proposals have been made based on my experience.
Also as a member of the Validator DAO, we have an objective of 200 validators for our mandate and I am pretty confident with all the proposals I made, if they were adopted, that goal will be reached.
The maximum keys per shard per validator is a good thing to help in the security of the network but it won’t help with the number of validators on the network, so we have to continue to find solutions if we want to meet our goals.
