Summary : This Proposal is to limit the maximum number of keys per validator, per node and per shard. And also to limit dynamically the maximum number of keys per validator.
Background : Currently, we have large validators with a lot of keys. This represents a risk for the decentralization of the network and his security. Some crucial incoming features, such as the resharding and the external leader nodes depend directly on the decentralization of the network.
There is no limitation of number of keys per node.
There is no real limitation in terms of number of keys per validator (it’s currently 100+)
Motivation : These changes will help in the decentralization of the network and its security. By capping the maximum of keys and dynamically limit the number of keys, there will be more opportunities for the new validators to secure the network. Limiting the number of keys per node will strengthen the resilience of the network.
Specification :
Maximum cap of 24 bls keys per validator, starting from 32 (minus one every 10 epochs). The protocol will ignore all the keys added over the maximum. This will free 98 keys considering the current situation.
The maximum will decrease over time to transition smoothly. This will give the chance to the validators with some extra keys to communicate with their delegators and this will allow to onboard progressivily the new validators.
Dynamic key limitation : The protocol will prevent to add a new key if that makes your validator bid below the 0,65xEMS. Note : If a validator looses some stake and bid below the 0,65xEMS, the protocol won’t delete automatically his keys, but this validator will likely have to delete manually his keys to stay elected and once done he won’t be able to add a new one (if the bid is under 0x65xEMS)This dynamic limitation is required to guarantee that the released keys (by the max cap) are not all taken by the medium size validators. This limitation will also give some relief to the validators who were fighting for keys and less stress/tension is expected in the validator community.
Maximum of 6 keys per node : The protocol will limit the number of keys per node to 6. This will guarantee the validators to split their keys across the shards improving the security. Why 6? Because 4 (shards) x 6 (keys) = 24 maximum keys.
Maximum of 6 keys per shard per validator : The protocol will limit the number of keys to 6 per per shard per validator. This limit will apply once we reach the maximum of 24 keys.
This is an incredibly restrictive proposal that would significantly increase operating costs for many existing validators and negatively impact thousands of delegators with respect to their power of validator choice and earnings potential. We also question its sustainability indefinitely considering the rising costs of operating Harmony nodes due to increased storage capacity requirements and potential for ONE price deprecation.
We need to ensure the network can support validators long-term, which is why we prefer a more free-market approach to achieve decentralization rather than hard caps which centrally govern the number of validators on a network. As ONE price rises and validating becomes more profitable, we fully expect to see an increase in the number of validators without the use of such restrictive hard caps. That’s been evidenced by the significant increase in validator counts over the several few months while ONE has reached its all-time high price.
As we discussed in an earlier thread, a maximum number of keys per shard that eliminates the possibility of a single validator takeover, such as a maximum of 10% of keys per shard, is a more natural step towards decentralization without negatively impacting existing validators and delegators.
You are worried about raising the servers cost for a very few minorities of validators, the ones with more than 42M running on a single server (6*7 = 42).
Ok let’s do the math, with such a validator you can earn about 500 one/day , so basically 135$/day, 4050$/month.
I think we are good to pay for the servers here.
In case of bear market etc, I would worry more for the 124 validators running below the 5M.
Do you know how much is the median stake for a validator? 5.3M
No offense but I think you are living in an alternated reality.
Not to mention we can still make a new proposal to make the base fee higher to make it sustainable for everyone.
The team also said that it was a possibility to reduce the size of the shard0, because we don’t need the full history to run a validator.
The intention here is not to raise the servers costs but to strengthen the security of the network.
In my opinion it is a fair proposal, I personally voted for a max of 8 keys but I decided to follow the majority.
Your delegators will have the possibility to keep delegating on your validator, they won’t be blocked, only you rewards will be slightly lower.
If you’ve followed recent elections, you’d know that the reason we haven’t increased validator count isn’t because of the largest validators, it’s because many validators compete for the highest ER by bidding near or below the 0.65x lower bound. KysenPool reduced its bid to 1 key and it resulted in no new validators. I don’t see how this proposal does anything to address the root issue of why so many excess keys are consumed and how to discourage validators from bidding below effective median stake. Cutting the stake of the largest validators may seem like an easy solution, but it doesn’t always achieve its intended effect.
Also, what is the source of your poll? Can you add a link in your original post?
The reason for this increase is due to one wallet, wallet#19. The wallet#19 is reason for 20 validators being elected. The price of $ONE is NOT tied to the increase in validator numbers. The ease of election due to wallet#19 has increased interest from new validators. Newly elected validators encouraged other new validators to jump in or hold out and wait for wallet#19 delegations.
Since wallet#19 is not capable of bring on new validators anymore, growth has slowed significantly.
Higher market price encourages new validator participation. What we may need to do is lower barrier to entry by reducing minimum 10,000 ONE self-stake.
you know it’s feasible when all the staking data are stored on chain. And even if it was offchain, it would still be feasible but need to trust a 3rd party.
This is one of my primary concerns with proposals designed to influence how and where delegators stake their ONE. As a delegator myself, I’d prefer unlimited validator choices with no minimum fees vs. limited validator choices with fee manipulation. With each rule that’s added, you lose an element of decentralization.
I agree with @ValidatorONE and also think there are too many restrictions here that would also make it difficult to implement, keep track of and understand. I think something along the lines of 10% restriction on the number of allowed keys per shard would address the problem of shard takeover that @leo initially mentioned directly and should be simple to implement and for other to grok.
With your proposal of 10%, only 4 validators will be required to halt the shard which is very low.
With this proposal, this will require a minimum of 14 validators to halt the shard.
This proposal also addresses the problem of the keys consumption by preventing validators to bid below the 0.65 EMS. It’s not only about limiting the maximum number of keys like it is explained in the description.
You know I don’t want to spread the FUD here, but if I start losing faith in harmony it won’t be because of the team but probably because of the validator community, I’m afraid.
Tried to list the cons we have so far, did i forget some?
Cons:
-Increases Server costs for Validators with more than 6 Keys (<40)
-reason for not getting more Validators isn’t because of the largest validators
-does not address why so many excess keys are consumed
-no unlimited choice for delegators without fee manipulation
So far this still seems doable, biggest con against this for me would be that delegators would loose some rewards if they had to redelegate or wait for it to balance out again.
With al due respect to wallet #19 there are other wallets doing the heavy lifting. Wallet #19 jumps in when the election is basically secured when a validator is already close to 2mill coins. The risk taken of bringing the delegation count from few 100k to 2mill is done by other wallets. The risk is taken by others and wallet #19 finishes the job and gets all the credit. I just think we are not being fair here.
It’s off topic, but I thought it was needed to bring it up.
I amend, without a few community wallets making the effort (and loosing money doing so) to onboard new validators, we would be sitting still closer to 100 elected validators. And yes, the coins of these wallets are drying out so the increase in elected validators will slow down.
The biggest issue of PoS compared to PoW is that the richest get richer. This a is a huge fundamental difference and benefits the people on top that tends to coincide with the oldest in the game.
I could agree that some sort of advantages has to be granted to those joining the game earlier (not talking only about the status quo, thinking about validators like me me joining this year will have a huge advantage compared to a validator joining in 5 years) but the advantage is just too big, almost unsurpassable with how thing are. A no rule PoS blockchain organises the wealth distribution only based on seniority and that is the biggest flaw of PoS.
A mitigation is needed to balance that inherent injustice of PoS protocols. @StrongMindsHold would say that it’s not written anywhere that a blockchain has to be just, but I say that we aren’t here to replicate the oligarchic and monopolistic structures that made the whole blockchain technology appear a decade ago.
-reason for not getting more Validators isn’t because of the largest validators
-does not address why so many excess keys are consumed
This isn’t just about getting more validators, it’s also about security and resilience of the network.
At the moment two validators can halt shard 0. The 10% max per shard idea only limits this to four.
When people/institutions/developers evaluate Harmony as a place to put their money/dApps, are they really going to be happy that a shard can be halted by four validators?
For the second point: keys being consumed. This is actually addressed by all of the proposed changes in some way.
Dynamic key limit - stops validators adding keys to get under the lower bound which may discourage some mid sized validators sitting near the lower bound waiting for that opportunity.
Max keys per shard and node - makes it more expensive to run extra keys, so will encourage validators remove unnecessary keys. Should hopefully stop the mid sized validators sitting just above the lower bound as a number do currently.
The max keys per node/shard removes my concerns about shard 0 being underpopulated as it will force more validators into shard 0. Another thing the 10% limit per shard restriction idea doesn’t do any thing to address.
I personally agree with this and i am realizing that many validators are not aware of what this protocol is trying to achieve and what would that mean for the biggest validators.
I repeat the calculation I have done before and it seems it hasn’t been understood.
4,6bill coins staked divided among 1000 Validators equals 4,6mill per validator.
Now add all the shards you want. We can use one mechanism or another, try to make it organically or cut through at once, talk about it with euphemism trying not to offend anybody but the math is there, and it means what it means. If the coins count keeps distributed the way it is, with 52% of total in the TOP15 Validators, we will never reach a number near that 1000 Validators (with current system this will take a decade at 100 extra validators a year)
