I believe a holistic approach to decentralization is necessary. Dynamic key limitations AND max individual stake by individual delegators. These could both be part of one proposal. I would still like to hear @sophoah full proposal on ER as well.
7 Likes
@ValidatorONE first off, thanks for the response and help with the issue related to my keys the other day 
I agree that there is an issue, but I am very skeptical that it would lead to much change in terms of the centralization issue. I guess first, Binance can only vote using its validators it controls, so even though they have a huge total stake spread out across multiple validatorsâŚit does not exercise control over the network unless it is also the puppet master of those. If Binance is scheming behind the scenes, then capping the max stake wont help because Iâm sure whatever their end game is will not be foiled by this. All they will have to do is create more validators to distribute that over. At the current levels of the median stake, they could start a bunch of new validators and get elected on their first epochs, probably eating up most of those new slots that become available and pushing out a bunch of the existing validators that are thrashing around those 795-800 election slots. If they just have that stake invested in validators because they helped seed Harmony to get off the ground, then those validators are independent entities and there is not a huge centralization concern other than what you brought up about multiple being have the same ownerâŚbut I do not see how capping the max stake would make a meaningful impact (not to say it will have no impact, I just donât see how it would be large).
In terms of helping new validators get established in order to truly help decentralization, I also am very skeptical that a proposal such as this will help. The medium to large validators that are already well established can easily create new keys much faster than these small validators can attract delegates. They can collectively split their stakes to the point where they push out all of the small validators and still be relatively safe for election. So yes those slots will be somewhat better distributed, but it will likely be among the existing set of well established validators, and very likely a bunch of smaller validators will have been pushed out even further from electibility.
Edit: I re-read the post and not sure I 100% followed, so please correct me if my response is just way off base, but I think my points stand. Also, if Binance does control that stake, and lets say we get an extra 220 slotsâŚwhat would make us believe that Binance would distribute that in any sort of reasonable or equitable way? The simplest option would be that they sayâŚwe did our part to seed validators and get Harmony off the ground, now lets go create a second and third and fourth validator so we can keep all of those rewards for ourselvesâŚnot to mention have direct control over all of that voting power. Right now, they are sort of sitting happy and complacent with the status quo. If we nudge them and force them to take some action, they will probably re-evaluate their entire strategy and the outcome of that could be a lot worse than the current situation.
3 Likes
Bringing over some conversation from the telegram here. In the last 24 hours there were some very heated conversations by some individuals that genuinely care about the blockchain. Decentralization has been thrown around a lot there and on Twitter but this was not mentioned in HIP-16. I am curious what is the motive behind this proposal? What are we trying to achieve?
I think this is a really critical reflection and can help us drive the conversation in a progressive direction.
I can see it going three ways
-
Consolidation of BLS keys
-
Decentralization of power
-
Decentralization of stake
In order to propose and achieve the goal of this conversation it is absolutely essential we work together and not clash. We can all carry different views and opinions but need to be able to set aside previous biases to work to understand each other or else all of this is just wasted time. We all have to be agreeable to the changes (P-Ops has to be able to agree with Rocktheblockchain and Validator.one and likewise they need to agree with P-Ops).
If the proposal is truly to just drive existing validators to consolidate BLS keys, it may not be needed to go after anyoneâs bottom line. A revamped bidding system can be the solution here, something like a blind bidding system would drive for the consolidation of keys towards the top. Most of the individuals in this chat engaging are cognizant of the impact of a high key load and do work to consolidate them when appropriate to let small validators in. The bls key issue comes from a handful of validators that either do not understand the blockchain or are asleep at the wheel. There are solutions to this issue and itâs possible to do so without hurting anyone here.
If the goal is decentralization of power, we likely can create a solution within the boundaries of the EPOS system that would allow us to distribute power without hurting stake. A difficulty of a key limitation in this regard is that individuals with large delegations (Binance) still maintain the ability to have power over the the blockchain consensus simply by making multiple validators. Multiple times it was mentioned to âtrustâ this would not happen⌠I struggle to do this because if we are working to a decentralization of power, the goal should be that we do not have to trust anyone. A solution that would not address this is, in my opinion, not complete.
Now decentralization of stake is another discussion. Itâs hard to discuss talk about decentralization of stake as there is a difference in delegators on the blockchain. A concept of competitive stake vs non competitive stake. Competitive stake is much more in flux, you must provide high levels of services to be able to compete against other validators. There is less money to be made off of competitive stake and as a result validators are more likely to be protective of this stake. Now non-competitive stake, ie Binance stake and a few other wallets, these wallets are not seeking highly competitive validators and have shown that they rarely move their funds around. As a result, validators with these stake have a tendency to run higher fees, it is a far more lucrative stake. For example YellowSinsâ validator (stake here) earns an equivalent value from 15% fees as a 195mil validator at 5% fees.
If we do not resolve these disputes among our biggest validators we will get nowhere. I would like to propose a moderated call between the three parties⌠this is needed for us to be able to get past this and work towards a better future for the blockchain. @mindstyle @JB273 @sophoah @RockTheBlockchain @ValidatorONE
5 Likes
I think these are valid questions which, unfortunately, I cannot answer fully. Iâm unsure of what the primary concern is between P-OPS members as the argument seems to shift between them.
This HIP was created with the idea of limiting keys, only then for the creator to accuse and berate others in a Telegram chatroom:
If P-OPS is going to engage in conversation, this is not the way to go about it.
The shifting goalpost makes it hard to determine what weâre trying to accomplish as a community.
So hereâs my opinion on what should be accomplished:
- Increase our total validator count and train newcomers properly.
- Help distribute stake in a fair manner that makes the most significant and positive impact.
Here are my concerns with the proposals and arguments made today.
- Certain individuals are targeting two validators while ignoring the TWO BILLION Binance ONE wallet prime for distribution across 100+ new validators.
- Taking any action on two validators will not onboard new validators, which is my primary concern above. However, finding ways to distribute the the 1B+ super-whale wallet will immediately allow the safe on-boarding for over 100 new validators, likely 200.
- Certain individuals are talking about hard caps as if our total network stake percentage is fixed. Our total stake is dynamic, which means what is âlargeâ is relative to that amount, thus itâs logical for limits to be dynamic as well. Further, we have seen what occurs when slots are opened â the lower bound is consumed by existing validators and no newcomers are elected.
I think we can resolve these through a combination of efforts.
I think we need multiple solutions here.
- Setting a limit to how much a single wallet can stake with a validator.
This could force Binance to distribute their stake to multiple validators instead of the 40 currently holding over 40% of total stake. This would release around 1.2 Billion ONE as Bryan/ValidatorONE mentioned above, leading to enough stake for onboarding over 200 validators.
This accomplishes one of our goals in a more immediate and direct manner.
This is what everyone was hoping for when Binance unstaked hundreds of millions of ONE a couple months ago when Crypto ONE Babe contacted CZ. Many validators were hoping to catch a piece of that - but that never happened unfortunately. Instead, it went to existing Binance-backed validators, some of which increased fees immediately after receiving their additional stake.
However, this alone wonât fix our issues. We also need:
- Dynamic key limiting (as mentioned earlier) based on median or total staked on the network. Iâve read some folks say â200M stake is too muchâ, but not only is it purely subjective, itâs also very short sighted. What if our total stake grows from 44% to 70% like Cardano? Is 200M still too much, or is it now 250M or 300M?
This is why dynamic limiting is better than a hard cap.
Because âenoughâ is not a measurement.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++ Make an event out of it. Aim to double our total validators. ++++++
++++++ Use the Binance wallet as a --tool-- to expand our network ++++++++
-
Schedule a date for when Binance stake will be distributed, leaving Binance-backed validators with 20M ONE each from the Binance wallet. This comes to around 1.2 Billion ONE for distributing to newcomers.
-
Announce the date on social media and hold a public âValidator On-boarding Sessionâ to attract more validators. Promise that up to 200 new validators will receive at least 5M stake each upon completion of the training sessions.
-
Hold the training. On-board 200+ validators to the network. Schedule the hard fork to occur after all new validators are up and with newly received stake.
-
Open up to 900 slots and have a high number of newly elected validators.
-
Open up to 1000 slots and have even more newly elected validators. Harmony now has over 100 (near 200) new, stable, and elected validators and Binance is distributed in a manner that grew our network x2.
This could be a marketing gem for Harmony
This would not only greatly increase our validator count, but it would also make crypto headlines, raising awareness of Harmony and getting the project into the spotlight.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
TLDR: We have a wallet holding TWO BILLION coins staked with validators with fees of up to 25%, and yet some people choose to ignore that fact while pointing fingers at a couple of validators. This tactic wonât bring more validators to Harmony.
Weâre ignoring the most obvious way to double our total validators on network.
I think we should see this as an opportunity to on-board new validators in preparation for 900 and 1000 slots. We do this by limiting the stake amount a validator can receive per-wallet and working with Binance to distribute stake. Weâre told âBinance wonât do thisâ but forgive my skepticism.
Communication with Binance should be done by the Validator DAO to ensure fairness and an unbiased approach is taken. Currently, this is being handled by individuals who not only benefit from Binance stake through their primary validator, but also through side/personal Harmony validators configured with high fees to maximize profit on a CEX delegator.
Combine this with a dynamic key limiter and we could have a solution that a) prevents excessive keys and b) brings 100+ validators into election very quickly.
@WellnessOne If you want to moderate, Iâm more than happy to discuss it further on a phone call, but I would ask that members of the P-OPS team remain respectful while refraining from finger pointing, accusations, and excessive hostility consistently displayed in previous chats. Though I would still like to read a response from @mindstyle @JB273 @sophoah to your questions on intent and goals.
==Edits made to add clarification==
6 Likes
@RockTheBlockchain you have lots of good ideas and Iâll answer to a separate thread to those, however as mentioned on telegram I wonât answer any personal demand as it doesnât help in the discussion. What was done is done and I donât want to explain ourselves on what we think was a good intention from us. Letâs focus on the future.
1 Like
I will be short replying to this.
First this is not a binance delegation proposal so stick to the topic, do not steer it somehwere else, rather create a new thread for that, if you still want to blame it all on binance except US, the big validators (yes we always included ourselves into this, not just you and bryan). Secondly, to put it to rest quickly, you really think you can spin up a delegation program and that a multi billion dollar company like Binance will âworkâ for you? I can already tell you they will not. And they also are not the issue as they have been delegating for two years and they didnt make any plans to overtake the network either.
To iterate the next point, nothing has changed, the goal is the same since this started, you are just manipulating with the data and a few screenshots of the conversation. It is quite obvious why, as said before, you and bryan are the only one against any bls keys cut (i wonder why). And again, this also hurts us, not just you. This is not just about you two as you would like to portray it. As @WellnessOne mentioned this was opened to help decentralization, not gun for two validators. Its just that the two validators in question are the ones that are very much against this and keep blaming it all on binance, while the fault is in us, the biggest validators.
We are here, we are ready to take the cut to make the network more decentralized, are you?
PS: the binance stuff does not belong here, the next post throwing binance proposals and smokescreens here will get deleted by the moderators, as that is offtopic.
8 Likes
Thanks @mindstyle I am just finished reading this HIP threads now.
First of all, I donât think we need to limit the max total delegation (as some suggested above) as a dynamic max total key is sufficient because :
- the max delegation will be limited by the upper bound and the max key limit
- it will over complicate the protocol logic with possible more bugs being introduced eventually
- dynamic is a must because of the network total delegation changes over time and will account for the median stake, total network delegation, etc âŚ
I idea of dynamically limiting the maximum number of keys could be a good solution amongst other to help out with our future decentralized network.
and I will answer in this post only things related to that HIP
there are pros and cons on any new ideas and we need to list them down so we can discuss those here.
Pros:
- avoid putting the network at risk ie single validator with too many keys in a given shard and on the entire network like Kucoin issue right now with s0
- allow the last few slot to be taken by small validator (ie and here to provide more chances to those with 10k or way below the lower bound)
Cons:
- nothing can prevent a validator to spin up a new validator
- it only address a problem concerning the big validator.
It is hurting only the big validator, Yes, but this is for a greater good. And having this coupled with an incentives (which I will try to detail in a different HIP) should help to have the big validator to always try to reduce their keys usage. The idea was detailed here : Open Staking: Improvement Proposals - #4 by sophoah
I will also highlight some ideas discussed above that should help with our decentralization problem.
please donât do any personal attack or target to anyone in the community when discussing those pros and cons. Thanks.
1 Like
@Jimbo_JCR.ONE @ben2k_Stakeridoo
max keys per node of 4
or whatever we think a good max is is great idea to make sure the network is more robust. Please create a new HIP thread for that
However I donât like
max nodes per wallet of 8
because 1) it is redundant with max key per node as the concept of keys and delegation are linked. and 2) i feel we are really adding too much complexity
max delegation per validator per wallet is better and linked to that idea
Lastly reserve slots. Last 5 - 10 keys reserved for single key validators that are below the lower bound. Idk how that could be implemented, but it seems like a promising way to see how they do and ensure theyâre signing well while giving them a chance to earn rewards for their early supporters as they grow.
is really good one, please have a new HIP so we can discuss pros and cons
@Maffaz, @Jimbo_JCR.ONE @armstrhu @Babylonode The randomness and the blind election of keys assignment to all eligible validator is a bad idea since protocol has no sure way to say the node will be running smoothly to help the network. Also if you go with that idea, no points to use keys anymore or even individual validator delegation, just have all delegator to delegate to the protocol doing the an auto delegation to all validator. And then think about this, big validator or experienced one can just spin up more nodes/validator with random names, and the more they have the more chances they will get a slot to this
An auto-bidder that works on a given node/validator is more something that I an seeing valuable because it can really help to make sure the validator stay elected and at the same help out to minimize the number of key usage.
Setting a limit to how much a single wallet can stake with a validator.
is the max delegation per validator and per wallet i suggested above, I like that one, same as above, please create a HIP so we can discuss the Pro and Cons
Your binance delegation proposal is also a great one, however this is a work that need discussion with Binance. Maybe start a new thread (not a HIP), and put yourself in binance shoes when writing the pros and cons. We tried to deal with binance and itâs painful when it comes to doing activities that requires using their private key. We, POPS, had the same idea as yours with PVA and went that path I hope you will be more successful as this one will have to be taken by the VDAO.
3 Likes
I agree this thread has gone a bit off the rails, Iâm not part of telegram, but Iâm assuming the intent of the proposal and everything suggest is to help with several things that are all somewhat related to power and decentralization.
@Babylonode, @sophoah mentioned that randomization is a no go and I donât know the details but if it is true that is a huge disappointment. However, it isnât clear whether this is truely a fundamental limitation that cannot be overcome, or whether there is simply not support to invest the effort in getting it done.
But to your points, Iâd have to disagree with them all. I work with Monte Carlo modeling and randomized sampling all the time, and I think you may not have an appreciation for what can be done using randomized draws, and all pretty simply with simple adjustments to your weights.
First, to implement randomness, you donât need to include every validator, can still add constraints to make validators eligible for election. This could be related to stake, uptime, or whatever shard they are bidding on with their BLS keys. Election is 2 parts, first is assessment for eligibility for election and second is the actual election. That first step will filter out all validators that do not qualify and then assign a probability of election for each validator that does, and then the second step will actually go and perform the election. Over time, governance can tweak the criteria for election as well as how probabilities are determined and assigned, and tweaks like this allow us to steer the election process towards whatever goals we have, whether it be on boarding new validators or building stability amongst the current set of validators.
Second, you point about a large validators spinning up another one is valid but that is an issue with every single proposal. AFIAK, this problem has not been solved by anyone and the only way I can see to âsolveâ it is if you implement some sort of KYC on the validators. This would be the death of Harmony as it is essentially an acknowledgement of a failure to decentralize.
Given that, random elections is the best way to address ALL of the issues being brought in this thread (including single owner with multiple validators, it doesnât solve it but it mitigates it), with only a single and elegant solution. Right now, there are only 3-5 slots that are available to be contested during any given epoch, this is will below 1% of everything available. The critical failure of our current election process is that once a validator get 3-4 keys, they can pretty much guarantee their success at being elected. Nobody is going to willingly drop out of election in order to help the little guy. The only reason why those 3-5 slots existing is because no established validator wants to drop that low and even risk not getting elected. Randomization does not punish anyone, it makes the election process fair.
The idea of reserving a set number of slots for single key validators is also not great. Single key validators have another issue that once they split their bid is cut by half, so they have to wait until they they are getting pounded with reward penalties before they can spilt and still land in a place where they can get elected. If we lock those slots down, it will be nearly impossible for new validators to grow past a single key because all their delegates will flock away as their rewards get nuked even more severely.
Every single proposal related to capping or throttling stake or keys has a lot of side effects that are negative towards new validators. If we cannot onboard new validators, the project will never get legitimacy and will fade away as other shine and gain adoption.
@RockTheBlockchain there are a lot of ideas there, but to me it is only an indication that we are on the wrong track. We are trying to treat symptoms of the problem and failing to address the actual illness. Working in this manner will lead to nothing but a perpetual firefight as issues pop up and we need to brainstorm a way to resolve them. We could do 5 different things for now, and then make a new proposal every month to deal with new issues and unintended consequences that arise (like I highlight above), or we can just focus our efforts on addressing the root cause which is how validators are being elected.
Again, Iâm not sure the technical details of why it cannot happen. Other blockchains implement some level of randomization so it feels more like a a matter of will, but I could be wrong.
3 Likes
While reading my response, know that Iâm not coming from a place of hostility. Weâve engaged in many productive conversations with others and always with the goal of understanding the other person and trying to come to an agreement.
That said, I sense some miscommunication so please allow me to clarify a few things.
-
The purpose of asking âintentâ is simply to understand the ultimate goal of the proposal - it is not asking personal questions or making personal attacks. The question is simply âwhat are we aiming to resolve here?â
-
The reason for this question was due to confusion. In a follow-up response above, the creator changes the intent of the proposal. Below illustrates this point:
Understanding the ultimate purpose (what issue are we aiming to solve) is crucial to having a constructive conversation. This is what @WellnessOne highlighted above.
To ensure weâre all aiming to resolve the same issue here, I must ask the question:
Is this HIP attempting to create safe passage for 3M to 5M validators, or is it now an attempt to reduce the likelihood of overtaking a shard?
Soph - my questions were not intended as personal demands. Iâm simply trying to get solid footing here after yesterdayâs discussion and HIP comment re: overtaking shards, and understanding motivation for the proposal (i.e. intent) so I can know where to focus.
Also, thank you @sophoah for following up with more feedback on my thoughts. The added perspective is much appreciated.
Finally, in case it wasnât understood in my previous response, I am in favor of dynamic key limiting so long as the method used is rational, fair, and resolves the issue weâre aiming to fix through this HIP without introducing additional problems or complexities.
2 Likes
given what i saw in a debate earlier, i think an absolute key reduction is necessary, because otherwise it will just mean some validators can grow big enough that they can take over a shard or boycott a proposal to not pass
As the vdao council member, I obviously donât want the folks here donât realise the real THREAT of the issue raised by @mindstyle.
Correct me anyone but the real danger for the network if not to limit keys/stake is a possible âtaking controlâ over a shard by a few big validators (no matter who are the individual(s) behind them, if theyâre ppl) who can sabotage/move forward any protocol changes.
cc @RockTheBlockchain, @ValidatorONE:
Iâm too disappointed with that a few of us canât admit that and try to point the issue to other direction blaming everything around except agreeing that limits are necessary.
@RockTheBlockchain, glad youâve asked this question, and yes, the issue of keys is much more complicated and initiates the bigger problem weâve faced already - they are TAKING OVER SHARD, MANIPULATING TRANSACTIONS, even STEALING OF TOKENS.
In the end of the day, this is not a well designed HIP ready to voting yet. This is just a GREAT CONVO and a PROCESS of SEEKING a SOLUTION, thatâs painful, long but still possible to be resolved together.
1 Like
Even if I have received a feedback that randomisation is not feasible I still support that path and yes, maybe we need more clarity from @leo and @rongjian why no or why yes.
I do agree that in its design the randomisation can select eligible validators (set of eligible parameters); maybe validators will need some adjustment, like minimising key number per node to avoid conflicts, and so on.
The randomness and the blind election of keys assignment to all eligible validator is a bad idea since protocol has no sure way to say the node will be running smoothly to help the network. Also if you go with that idea, no points to use keys anymore or even individual validator delegation, just have all delegator to delegate to the protocol doing the an auto delegation to all validator. And then think about this, big validator or experienced one can just spin up more nodes/validator with random names, and the more they have the more chances they will get a slot to this
In the perspective of randomisation I never meant to combine all together @sophoah.
- The randomness and the blind election of keys assignment to all eligible validator is a bad idea since protocol has no sure way to say the node will be running smoothly to help the network.
Currently, every epoch protocol assigns eligible validators based on signing rate. If itâs not enough the validator loses the chance to be elected but it gets back in the epoch after the next epoch. Adding random selection for keys even will allow 10k validators to join the committee (def then we will need to adjust a lower median bound to 10k or whatever we decide is valid to be elected).
- Also if you go with that idea, no points to use keys anymore or even individual validator delegation, just have all delegator to delegate to the protocol doing the an auto delegation to all validator.
Then I ask why? If not keys then let nodes (limited by keys number, for instance 4 keys) be randomly elected. Would not this work for validators with 108 keys like selectiveness and not a permanent election for all the keys/nodes? No automatic delegation pools required. Yes, some part of validators stake might not earn but as a result weâll have 1000 validators and completely new staking distribution, because every delegator will be highly. interested to redistribute his stake to as many validators as he can to increase chances to earn every epoch.
- And then think about this, big validator or experienced one can just spin up more nodes/validator with random names, and the more they have the more chances they will get a slot to this
Why is it not ok? More nodes - better decentralisation. More nodes - better chances, but itâs really possible to design a randomiser that can equate chances of nodes/keys in the long run.
2 Likes
Thanks for the response Babylonode. It hasnât been a matter of admitting - Iâm happy to have an open and honest conversation. Iâm just simply trying to understand which issue weâre trying to address here. The HIP mentioned nothing of overtaking shards until mentioned by P-Ops halfway through the conversation. Thatâs fine, but I want to have a productive conversation. In order to have a productive conversation, we must all be in sync on the issue weâre addressing.
This was unclear so thank you for the clarification and I would like to understand this better. Are you referring to the possibility of a validator owning > 34% of keys on a single shard? If so, thatâs certainly a conversation worth having and thank you for bringing it up.
++++++++++++
That said, because we have a number of contributors here, we need to all agree on the issue weâre attempting to solve.
The direction of our conversation changes depending on whether our focus is the potential for overtaking a shard vs. allowing safe passage for some with 3-5M total stake.
Are we all in agreement that our primary concern is the potential overtaking of a shard, and that our conversation should focus on that issue?
++++++++++++
Thanks again.
1 Like
Hey guys, ill be short since im on vacation and typing on phone.
Initial design was for minimizing keys as well as limiting all of us bigger validators, so smaller/new ones can get the stake they need to get elected.
The other valid concern is the over taking of a shard by 1, 2, 3 or more individuals with high stakes (eg kucoin on shard 0 currently - we requested they move some keys to another shard already). In this regards, all of us big validators can be a threat, either alone or working together.
This proposal wasntade to simply limit keys, i made it to start the conversation and find rhe best possible proposal, that may or may not include bls keys in the end. Why i mentioned bls keys is because from the very beginning we werent that happy with bls key introduction for this very reason, and we knew that this will be a problem at some point. The current limit is 106 keys total, so quite enough to overtake a shard if one or more are big enough. Limiting bls keys also somewhat dissolves any issues with binance taking over, although like i said i dont believe that would ever happen nor do they intend to (to quote them they said they dont want to interfere too much with the network and governance while minimizing ops/work for themselves). The current situation of how they delegate isnt ideal i agree, and we asked for a more fair delegation when i even prepared a list of 100+ validators for them to delegate to, and undelegate the big delegations in the proccess. Unfortunately this didnt happen and i can understand that from their point of view.
One other threat is governance but afaik theres already a quadratic proposal in the making that will mitigate that.
This is why i say that in long term, the network health should be the first priority, well above any of our personal wishes and earnings from the nodes and why we are willing to take the cut, for the benefit of the network security and stability.
4 Likes
@mindstyle @RockTheBlockchain I think it is also important to point out that Binance controls all of that stake. This is obvious, but it seems like like people are under the impression that putting limits on stake or keys will force Binanceâs hand and make them to do what we want. If a proposal is passed that forces Binance to take some action, Binance is going to do what is in Binances best interest, and that is likely only partially aligned with what is in Harmonys best interests. Iâm pretty sure there is no proposal that will change the fact that Binance controls all those tokens, so no matter what limitations we put in place they can very easily get around all of this if they wanted to.
I donât think anyone feels Binance has bad intentions, but a bigger concern for me is destabilizing the network if they pull a large portion of that stake for whatever reason. With what looks to be a lot of legal issues coming down the pipe, this is a valid concern IMO. The only way to really get past this is to drive adoption so that Binanceâs stake is diluted, and in order to do that we have to prove we can self govern and dig ourselves out of this situation.
2 Likes
I hope we can be united in some meaningful changes. The people at the top today, may not be the people at the top tomorrow. Harmony is still a small market cap crypto and once the bigger investors start rolling in are ability to make changes is going to diminish further.
2 Likes
First of all, thank you for opening this proposal.
In your current position, you could just have closed your eyes and we would have continue like that.
As that was mentionned before by mindstyle, that would be nice not to divert the attention on binance, everytime we speak about the keys limitation.
That being said, I see 2 majors problems in our current situation :
1- Only 9 validators control 1/3 of the stake (if we exclude the internal nodes) :
This number could be even lower because there is no restriction in the protocol.
There is nothing in place to prevent a very few minorities to control the whole stake.
2- It is difficult to onboard new validators and to grow as a small validator :
The largest validators keep swallowing the delegations while there is no incentive at all to stake on a small/unelected validator.
As a newbie delegator I will always choose a large/medium validator for more safety.
The smaller validators are also in trouble because they cannot add a second key because the lower bound is occupied.
This can hurt a lot their ER and so their validator, no matter the work they do for the community, marketing etc.
If your ER is 30% lower that can hurt a lot.
Solutions :
a) Limit the max number of bls keys.
I am all in favor of this instead of limiting the max stake and delegations.
With a limited number of keys, a validator can still grow following the raising EMS and if it gets too large, the rewards will just diminish giving less incentive for new delegators.
We could start from 30 and decrease that number over time (like minus 1 key every 15 epochs) to a lower number such as 10 or 12.
12 keys still represent almost a 100M validator without rewards penalties which is enough incentive for 99% of the population to run a validator.
By doing a smooth transition, the largest validators will have enough time to communicate with their delegators and adjust in consequences their delegations.
Moreover, this will allow to release new slots progressively for the new incoming validators, instead of releasing 200 slots in one shot.
A validator will still have the possibility to start a new validator, I heard this argument many times.
While, I hope you wonât do it if you truly support the project, I still prefer you start a second validator over the current situation.
For at least 3 reasons :
- We will have more nodes, so a better security.
- The largest validators will have less control over the election. Right now it is really for them to manipulate the election if they want to.
- This will make the servers cost a bit more fair. Because right now you can run 30 keys on a single node, almost dividing by 30 your server cost, and that makes it easy to run on lower fees.
b) Penalize the validators with multiple keys bidding in the low bound (or even below).
With 10 or 12 keys available for a validator, you have still the possibility to bid low and kick out the smaller ones for almost no reason.
The more your stake grow, the more you should bid closer to the high bound.
I see 2 possibilities :
- first we enforced the validators to bid high enough (dynamic limit number of keys),
-
second we penalize them if they bid too low (considering the size of the stake, the current bounds, etcâŚ).
I want to mention that I did some calculation and there is almost no difference when bidding close to the high bound compared to bidding at the EMS or lowerâŚ
Only if you bid below the lower bound, you will get a real boost.
Conclusion :
The solution for the hard cap is pretty easy to find, but the solution for the dynamic cap (or rewards penalties) is looking a bit more complex, but is also ideally needed.
1 Like
@sophoah, Validator.ONE is in full support of exploring your idea, as you described here: Open Staking: Improvement Proposals - #4 by sophoah. We were considering a similar proposal until you brought your suggestion to our attention.
Our suggested proposal for HIP-16 offers a few modifications to your initial suggestion but shares the same principle, which is to incentivize validators to reduce keys.
As one of the larger validators, Validator.ONE recognizes its responsibilities to exercise responsible key management. We also recognize the immediate gains in available keys when we or any validator reduces their key count. Weâve learned both these lessons through months of self-imposed key limitations and consistently bidding above 1.0x Effective Median Stake (EMS), often as close to 1.35x EMS as possible. We seek opportunities to help unelected validators gain election by holding keys before releasing them near the end of an epoch. The reason we wait until the end of the epoch to remove the held keys brings us to our other lesson learned. Weâve learned through our key management that when we reduce keys, it doesnât always benefit the unelected validator.
When we reduce any extra keys early in an election for the benefit of an unelected validator, another elected validator typically adds additional keys, thus consuming whatever extra keys we had removed, resulting in zero net benefit to unelected validators. These other validators who consume our forfeited keys range in all key and stake sizes. It is not just larger validators but rather typically small to mid-sized validators who compete for the best expected return (ER) despite limiting the opportunity for unelected validators to become elected. It is a frustrating and discouraging cycle to do your part only to see it benefit an unintended party, especially one who needs no such benefit. Key changes are not fun nor a hobby and require editing our validator, which takes time and effort.
When we spend our time and effort to reduce keys only for them to be consumed by another validator who doesnât share the common goal of electing more validators, you learn that itâs not just the large validators that need to take responsibility for decentralizing the network, itâs all validators from single key validators and up. For this reason, we strongly reject a hard cap on a validatorâs total stake or key count as it does not address the underlying problem, which is the reward system for bids within the lower and upper bound range of 0.65 â 1.35x EMS.
The problem is validators have no disincentive to occupy the lower range (0.65 â 1.0x EMS) other than the chance of non-election, which doesnât appear to be a concern to those validators based on their actions. Conversely, there is a financial incentive to add keys, which reduces the total network or shard stake for a better expected return. On the flip side, validators are offered no financial incentive to occupy the upper range (1.0 â 1.35x EMS), but rather are presented with the risk of an inefficient bid if the bid exceeds 1.35xEMS and reduces a validatorâs earning potential by raising the total network stake, which lowers the networkâs average ER. These factors have led us to conclude validators are operating within a system that incentivizes lower bids and disincentivizes higher bids.
To fix the problem, we need to fix the system. Therefore, we consider a system designed to disincentivize lower bids and incentivize higher bids to be the most effective solution towards creating a sustainable, responsible key management solution.
Our solution serves as a credit system. If a validator bids in the upper range (1.05-1.35xEMS), they receive part of a credit funded by validators with 5 or more keys who bid in the lower range (0.95-0.65xEMS). The protocol would fund this credit by slashing a validatorâs bid. Validators with elected bids in the 0.95-1.05xEMS range would be unaffected by this proposal as their bid would neither be slashed nor would they receive any of the available credit. Additionally, the normal EPOS rules for bids below 0.65xEMS and above 1.35xEMS would still apply and remain unchanged by our solution. Therefore, this would only adversely affect validators that operate in the 0.65-0.95xEMS range, where the most key mismanagement occurs.
There are certain rules from a logic standpoint that we consider important to include to make this a complete solution:
- Those with 5 keys or less wonât be subject to a slashed bid for operating in the lower range, which provides them with a bidding advantage over validators with more than 5 keys;
- Despite not being subject to lower range bid slashes, validators with 5 keys or less would still be eligible for the additional credit for elected bids in the upper range;
- Validators with more than 5 keys and elected bids in the lower range (0.65-0.95xEMS) would be subject to diminishing rewards the lower they bid with the severity of the reduction in rewards based on the validatorâs key count. For example, if there were two validators with the same bid amount in the lower bound, the validator with a higher key count would earn fewer rewards per key than a validator with a lower key count;
- Credits rewarded to those bidding in the upper range diminish based on a validatorâs total key count. For example, if two validators with the same bid amount in the upper bound, the validator with a higher key count would earn less of the upper range credit per key than a validator with a lower key count.
Our solution is intended to achieve the following objectives:
- Incentivize all validators to bid as close to 1.35x as possible;
- Disincentivize validators from adding keys to the lower range without cause;
- Minimize key usage without cause by all validators;
- Provide validators an opportunity to gain an ER advantage over validators with higher key counts than their own;
- Minimize disruption to delegators; and
- Incentivize delegators to choose validators who minimize key count.
Our solution ensures that a validator always carries an advantage over a validator with more keys than their own while holding validators of all sizes accountable for responsible key management. Medium-sized validators will hold an advantage over larger validators, and smaller/unelected validators would hold an advantage over medium and large-sized validators. This creates a system where validators are encouraged and incentivized to bid as closely to 1.35xEMS as possible.
Weâve begun modeling a potential reward calculation to provide an example of how the rewards would fluctuate based on bid and key count; however, we think it may be prudent to first obtain feedback on feasibility from a protocol logic standpoint. To that point, we welcome any feedback from those on the team or others who work on the protocol code.
@sophoah, as a member of POPS who presented the initial HIP-16 and presented a similar suggestion, I welcome your thoughts on our suggestion.
As for a max key limit or max total delegation suggested above by others, we feel a solution like ours is a more sustainable approach towards increasing the total unique validator count while also providing an opportunity for all validators who exercise conscious and responsible key management to benefit and only adversely affecting those who donât. We also believe our suggestion limits the impact to delegators compared to the impact that would be realized by hard capping validator keys or delegator delegations while achieving a greater effect in decentralizing the network.
7 Likes
Hello here,
I concur with what you said above whatever we do to help the small validator, there will be other validator who will try to add more keys thinking they can earn more or maliciously prevent small validator to be elected
I like how you extended my original proposal to reduce the reward of folks near the lower bound only targeting the validator with keys above 5. I think the number of 5 shouldnât be static but instead dynamic like the the proposal of this HIP 16 to limit keys with a number that is dynamically defined.
A simple calculation during the epoch election could be :
given k = total number key the validator wants to elect
if k - 1 or k - 2 give him a stake per key below the upper bound (smartstake is already doing that by the way), then reduce its reward. This could be proportional to the number of keys it could have removed (ie 5%, 10%, etc âŚ)
so yeah I would definitely support that idea, can you maybe create a HIP 17 so we donât mix that HIP 16 with this fantastic idea.
On the max key limit, I believe it still required because of the risk of a validator over taking a given shard (ie kucoin issue today)
5 Likes
These proposals keep getting wilder and wilder. At least now we can acknowledge that there is a REAL problem, and that the large validators hold too much power, and there is almost no chance that a slot that is released doesnât get gobbled up by someone other validator and doesnât really do much for decentralizationâŚnow there might be actual progress in fixing things. For one a start is a system that is inherently fair in terms of the election process, not one that relies on everyone following a set of unspoken rules.
1 Like