Discussion: reducing BLS keys

[mindstyle]

Hello everyone,

due to the fact that many validators still extend keys far below median, we are proposing a method to further limit the amount of BLS keys a validator can have.

The reason we want to do this is because the median stake is high and due to it, many validators bid around it or below it, while there is no incentive to do that since getting below the lower bound is near impossible anymore. The impact of that is that validators with 3-5M stake cannot be safely elected to further secure the network.

This is not a complete proposal as we would like inputs from the core team and other validators on what the best possible solution would be, before we put it up for a vote. Options:

• generally limit the amount of bls keys (absolute reduction to eg 30 - just an example) → this will affect only a few validators while others that are extending keys for no good reason would still be intact

• dynamically limit amount of bls keys:

  • based on stake size considering median
  • based on bid size considering median

As i said this is just an example and we are looking for good suggestions from everyone. I personally think some kind of a dynamic mechanism would be better, as an absolute reduction will affect only 3-4 larger ones maybe, the rest will still be able to extend keys too much. This is why im 100% for a dynamic change that takes into consideration stake size/bls keys deployed/median.

Lets discuss!

@leo @rongjian

[Abraham]

Hey

After see all your message (this and from other validator on telegram) I was thinking about one thing .
All we know the big issue it’s the number of keys . “But it’s not possible to change that until there’s some protocol level changes”

---

I think we need to think seriously about this issue. If not few validators can take the control of all and will be hard for don’t say impossible for the new validators to be elected. You can add 900 slots , 1000 slots or more if we don’t resolve this issue first I’m not sure there will have real changes.

Ex : if 32 validators have 25 keys or if 25 validators have 32 keys it’s the end for the others validators and can be dangerous for the network.

---

So I was thinking about this solution :

Reduce the number of the max delegation . If not the bigger validators will be probably more bigger and they will need more keys .

I want to add something to be clear :

I don’t critic the big validators .
If one member of the community have much success I’m happy for him . And I don’t say this proposal for create a war. Just I think for find the best solution for all the validators and for the network.
I don’t say that for create panic but for preventing what could happen in the future.
“I think” nobody will be happy if only ~30 validators manage all .
The community , the investors , the others validators working hard since month etc …

I think seriously if we continue like this in few time (keep calm it’s not for tomorrow) we will see down the number of validators .

(It’s just an exemple )

If we reduce the max supply at
200M I think it’s enough.

I leave you take one & and count how much you will win with 5% fee and with 200M staked / month with the currently price and when / if one will reach 1 or + . It’s not enough?

Results = the bigger validators will don’t need to have more keys than they need , more validators elected etc…

Say me if I’m wrong with something.
If yes I’m sorry I’m new as validator so I don’t know all. But I try to learn and understand some things .

Maybe I’m not wrong but I’m forgetting something etc…

I want just to create a healthy debate like @mindstyle , do research , learn and try to find good solution for the good of all (validators , network etc …)

Thanks all

[Crypto_Gainz]

I think there definitely should be a limitation somewhere. ADA does this in a similar manner and even though validators can just create multiple validator nodes, it will still create this extra line of defense which might prove to be good. Maybe people will think it’s too much of a hassle to setup extra nodes so they just won’t do it.

I think 200m is still a bit too much. In my opinion, 150m should be the upper limit.

[Maffaz]

I 100% support this proposal. How it will be implemented is another question.

I would propose even going a step further and having the protocol automatically assign keys, distributed evenly amongst all eligible validators (that fall within a secure range) before assigning ‘extra’ keys.

Something akin to a round robin allocation, cycling through until the number of keys are exhausted.

This is of course an over-simplification but I hope you get the idea.

And of course, with the current disproportionate key bids amongst shards may also present challenges.

[IDEAL]

Nice proposal!

I know from Cardano that hard caps on validators/ stake pools don’t work. People will spin up a new one under the same brand (or a different brand and boosting it). It’s all appearances and no actual fix.

Adjusting or limiting BLS/ voting power/ slots based on total stake could well work. I don’t know what a workable implementation would look like but I can it protecting the health of the blockchain while also allowing some wiggle room for validators to play with.

Will keep track of this discussion and add a post when I have some interesting suggestions to share.

[Jimbo_JCR.one]

Blind elections is one way. It amplifies the risk in the risk/rewards calculation when bidding keys.

Another is just integrate an autobidding system that automatically assigns an appropriate amount of keys like Maffaz said.

I’m leaning more towards the latter. We already have autobidder from robovalidator. Maybe a bounty for him to reconfigure it and add it into the harmony service.

Another option is limiting the number of keys per node. This increases infrastructure costs and de-incentivizes running more keys than necessary while adding more nodes to the network increasing security.

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.

[DKValidator]

I came here to suggest key limits per node.

The protocol is meant to put a greater burden on larger validators by forcing them to add more keys to be competitive. But actually, allowing 10 keys per node makes the cost of keys cheaper for larger validators and does nothing to increase network resilience. If one server goes down, we could loose 10 keys in a shard.

A bigger burden would be forcing validators to run one node per key. This would increase network resilience and the cost of each key would increase encouraging better key utilisation.

[Bagelhole]

I dont have the technical background to give any useful input regarding this matter, so im only here to support the issue by saying im very happy that you guys brought it into awareness.

The main care should be the health of a fully decentralized harmony blockchain… I quess the more elected validators the better right?

You guys are amazing!

[armstrhu]

The issue with smaller validators getting elected is a perpetual problem, none of the proposals are going to fix the issue which is why it keeps coming up. I run one of these small validators and have only just finally gotten to the point where I am being elected regularly, but this is very fragile because I have a single wallet that is responsible for that and if they leave I wont be elected anymore.

If we add more slots, large validators just split their stake and suck them up. If we limit the total stake or keys all they have to do is create another validator (this is a very low cost relative to their earnings), this is what is being done on other networks. For lack of better words, all of the proposals that come out look to be classic cases of trying to put lipstick on a pig. The real issue isn’t about trying to control total stake or keys, the pig is the process in which elections are performed.

Community members are simply not going to stake with validators that are not elected; if they do it will be a very small amount so they can feel they are doing their part to help decentralization, but not large enough nor enough people to really get these validators elected. We can sit and brainstorm and discuss all day, but the proof is in the pudding and we can all see what the community is doing, they are staking with validators that get elected.

The only fair way to solve this issue is to have the election process be random, this is because it removes control of the elections from the validators. Right now, validators with more than 3-4 keys have complete control over whether they are elected or not, simply by adjusting their keys. Randomization would remove this control…a large validator will have some control over their probability of election, but they cannot control whether or not they actually get elected. A good system IMO is outlined below, but there are tons of ways to implement a randomized election process.

I propose a random election process where your probability of election is proportional to your bid. This will accomplish several things…

• Very small validators will still need to work to get enough stake such that their probability of election is not negligibly small
• Once a validator starts approaching the stake needed for compete that final election slot, they will start to get elected at random. Once they are elected, that validator will begin to show up on the dashboard and will be earning a large reward. This will incentive people to stake with them, pulling them into that group that is being elected on a regular basis.
• A validator that does not get elected for 1 or 2 epochs will not trigger a mass exodus of people pulling their stake, this is the main issue right now with small validators. Once they finally get elected, people pile in because of the high reward; but once they go one or two epochs without being elected everyone pulls out. A random system will mean that every validator will go through epochs where they are not elected. But if this is done fairly, the average return will be unimpacted and delegates will have no incentive to unstake…they will actually incur a penalty because they will lose an additional epoch worth of rewards.
• Having election probability being proportional to the stake WILL lead to large bidders being elected more frequently. However, this can be balanced by reducing the reward inversely to bid as is currently done. So yes, they will be elected more frequently but the average return can be throttled down so that people will be incentivized to stake elsewhere.

This proposal matches the spirit and intent of the original election bidding process. It is clear that, for whatever reason, the current election process is not actually accomplishing what it was intended to, that is to disincentive the community from centralizing around a handful of validators. I really think there should be serious consideration given to not attempting to fix the current system, but rather brainstorm improvements that will fulfill the original intent.

[Symphony.One]

There’s so much to say that have been said. We support the opinion of Maffaz for the protocol to automatically assign keys to validators thereby removing this choice from us. This will make eradicate the irresponsible grabbing of keys by large validators like binance and all.

Also, we support the opinion of Abraham, to limit the maximum stake to 150m per validator. Actually we would support any proposal to limit this to 100m per validator.

With this two initiatives passing a vote and implemented, it will reduce the issues we’re currently facing (not totally eradicate) and enable smaller validators like us get elected.

This will also enable the network to be more stable and truly decentralised.

While we understand that bigger validators can simply erect another node and redistribute their stake, this won’t be long term as the higher the price of $one, the more expensive it will be to create a node and less attractive it will become to run multiple nodes.

[Babylonode]

I would not say this is an issue of the protocol but the EVOLUTION and I’m glad to read so many input here.

I addressed previously my proposal on how I see the possible solution and want to share that with you guys here again

---

What if elected (earning) slots (aka BLS keys) will be selected randomly among all the eligible validators to get a slot. Random selection for a BLS key(s) of a certain validator but not an exact validator with all the keys that are participating in bidding.

Here I mean that if the validator has 30 keys the randomness can assign from 0 to 30 keys to this validator, e.g. 4 keys this epoch, 28 keys the next epoch, 16 keys the epoch after the next epoch, and so on.

Randomness it’s always a fair game for every applicant, and random selection makes Harmony Open. Staking really open for everyone - I’d like to participate, I go there, I create a validator, stake on it, get delegation, and I play a slot lottery. I can win or can play again next epoch. And nobody can affect that except a random selector (generator) only that could be coded on the protocol level.

So, there's no limits on keys or delegation is required, but simply we can make a single change in the protocol design that will enable again all the features of the original EPoS ideas, where the richest doesn't become reacher every epoch!

Guys, won’t randomness for BLS keys election mitigate the influence of the validator’s overall stake and as a result can initiate the whole stake redistribution?

The detailed proposal is quoted below. I just notify you that it’s dated by May 20, 2020 and it includes a few inaccuracies caused by the previous design of the EPoS and the staking setup dated as at May 2020.

Source link Open Staking: Improvement Proposals - #14 by nickv;

---

hey everyone there!

inspired by the word “open” in the name of Harmony product #Open
Staking

I don’t pretend to resolve the issues raised relatively to fairness of election in our openstaking by this one message on the forum, also I’m not really sure how technically difficult to implement the idea i’m sending here, but i’d like to try to deliver my thoughts to all are presented dudes on this thread who are caring about the current situation.

Key problem #1 highlighted by @nickw

1. Minimum stake - the amount of stake needed to get elected is going up, leaving behind smaller validators to start getting unelected, and over time churn out.

For me #Openstaking means that everyone validator, whether it’s a big staker with lots of bls keys or a single key node should be in equal conditions at the bidding stage when slots are going to be filled by validators. Also I totally support the initial design of Harmony EPoS that mentioned here, see an extract below,

This statement definitely suits our tokenomics that has on its aim to go to 0 issuance and incentivizes stakeholders to stake more assets they have on Harmony staking.
But at the same time this statement caused the issue we have right now - only because of this we have big validator with many BLS keys bidding for numerous slots and get them - there’s no problem with that if it’s not so painful for the small validaotrs.

And here’s my suugeston, that I see could be a good start point for finding the solution. What if earning slots will be distributed randomly among all the eligible validators to get a slot, that are participating in bidding. Randomness it’s always fair game for every applicant, and random selection makes OpenStaking really open for everyone - I’d like to participate, I go there, I create validator and stake on it and I play a slot lottery. I can win or can play again next epoch. And nobody can affect that except an random selector (generator) only. But there should be compliance terms definitely, to avoid cases when 10k ONE stake validator can get elected and earn when median stake is about 3 000 000 ONE.

Let me describe a RANDOM SELECTION for Harmony validators

1. Not to hurt our EPoS design and tokenomics I suggest to code on the protocol level eligibility to be elected not only for the highest 320 stakes, but for unlimited number of stakes that bounded by the lowest border at 0.7 * effective median , which is 70% of effective median stake. This means that all stakes which are equal or higher than 0.7 * median stake can participate in bidding for slots.

This doesn’t mean to change our median gradation. In opposite this opens validators with stakes as higher than 1.15 median and less then 0.85 median be involved into elected and EPoS will work as it designed for yellow, blue and green zone validators.

2. The next statement can limit the number of bls keys per validator because I assume that all the keys of validator will get slots if the validator is elected (if not and validator can bid for number of slots accordingly to the number of keys, but gets less slots - there should be no limits for keys).

So let’s imagine the model when each validator has 4 bls keys max allowed. this time RANDOM SELECTION comes on the scene and the lottery will choose 320 lucky slot winners. It means that all the validators with stakes from the highest and to the last 0.7*median stake will participate in bidding, but slots will be distributed randomly (4 per validator max in our case).

So, in our case we can reach the desired situation when even 1000 of validators can participate in bidding and get elected. Only 320 keys will win. Next epoch it will be other 320 keys (based on random selection)

You can say that big stakers can create more 4 keys validators and share their stake on them, but it doesn’t mean their newly created validators 100% be elected, because of the random selection.

You can say that median won’t grow, but it’s not true, because in this particular case big stakers are more likely to delegate their stake shares to other validators than to spin up more new nodes. Why? - because more validators for them means more paid instances - more expenses, but doesn’t guarantee their validators to be elected every epoch. So, those who doesn’t want to spend money for extra instances will delegate to other and hope for getting income from different validators.

Quote thoughts “I’m not elected now, but couple of shares I delegated to other validator this epoch could be elected and earn for me.”

As a result you can see how simple randomness election for validating slots makes everyone stakeholder to share their stakes among maximimum possible number of validators, because if they don’t do that their stakes won’t earn oftenly.

No more for stake centralization!

Is not randomness a fair choice for OpenStaking?

Guys, share your thoughts below and comment, probably this solution has hidden stones, that are not obvious for me yet.

Thanks in advance

[Jimbo_JCR.one]

Coming back to this, I propose a max keys per node of 4 and max nodes per wallet of 8. Shard distribution of those nodes would be up to the validators discretion as far as shard placement. At no time should more than half of a validator wallets nodes be on any single shard.

This has multiple tertiary effects:

1. Maxes out the total staked per validator wallet before incurring upper bound penalties.
2. Increases the number of nodes on the network.
3. Incentivizes using the least number of keys to stay within the bounds.
4. Reduces any singular validator wallets concentration of stake on any given shard.
5. Creates a demand for larger validators to support the Beacon shard.
6. Conserves keys for the election of new validators.

This proposal causes the least amount of harm, while creating the most net positive effect for the network. This also still allows for validators to grow and have a choice in how they operate their nodes while maintaining a delegators choice of who to delegate with.

[mindstyle]

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 (and we arent far from that now).

Due to this i would suggest a hard bls key reduction to a small amount of about 25 bls keys max which will also limit stake sizes and solve any fears about binance etc. It will affect all of us and reduce our stake sizes, but we are fine with it. I know in any case anyone can spin up another validator (whether publicly or just keep it secret), but this way we make everyone to do more work and have more costs involved (which will really come to light in a bear market).

I dont think my proposal is the most optimal ofcourse and looking forward to some others, but i think dynamically limiting bls keys will not help with the issues we have, from what i saw.

[mindstyle]

something like this is already better than my proposal that would be 32 keys, but we can change that in the future also as we see what kind of an effect it has!

[Jimbo_JCR.one]

So essentially 6 nodes per wallet is your proposal. Given current EMS and bounds that would put max delegation at roughly 140mil. Still a very large amount of one and a lot of maneuver room.

[Jimbo_JCR.one]

Options that have been discussed:

1. max delegation per wallet to an individual validator

This would reduce the chance of any large delegator such as an exchange manipulating the outcome of any key governance vote or driving a 33% attack against any single shard. @ValidatorONE and @RockTheBlockchain are the proponents.

2. Modulating rewards multipliers.

I’ll let @sophoah discuss this idea as he is the proponent and my understanding of the tertiary effects are not complete at this time.

3. Dynamic keys/node limitiations as seen in my post above.

4. Random key assignment

As proposed above by @Babylonode. I’ll let him discuss the tertiary effects of his proposal.

This is the appropriate place to drive these discussions. Please provide feedback.

[ben2k_Stakeridoo]

Thanks @Jimbo_JCR.one for comming up with this.
Our Idea was 8 Keys per Shard and max. 4 per Node, saw your was bit faster than me to figure out all the effects.

One point in here which is really to look for is that Beacon needs more support. Last time when a Validator had 10 Keys on a Shard0 and went of several time he was forced to split his keys over other shards. Now we have a Single Validator with 50 Keys on 5 Nodes on Shard0 this means we have over 34.4% BLS Keys on Shard0 hanging on this single Validator. If this single Validator stop his nodes right I think I don’t have to explain… That’s why we had the idea of maximal 4 keys per Node and 8 keys per Shard. To ensure big one will spread keys over all shards.

But our Idea was not finished with this, cause by spreading the network and the idealogy of having 1000 Validator on chain per shard this would mean we need in future also to lower the keys and spreading it more.

@ValidatorONE brought the input that 1000 Slots on 1000 Validator would mean everybody has just one Key. And that would be may the tartget 1 Key per Node and one Node per Shard.

When thinking of the target of 1000 Validator and I divided totals supply through validator we should also have a limit of 100m. But would rather see a Key limitation instead of delegation limitation, cause by key limitation EPos will take the rest.

And one point in here, cause some are quite fresh to PoS and EPos and some just having not the samle knowledge may we can discuss a monthly validator webinar or meet up to bring all on the same knowledge level. Cause when we was asking about removing keys some didn’t know their are in bound and less keys would be more stable.

[armstrhu]

Small validators like myself are getting elected simply because of one or two large wallets. Its horrible, but it is reality with the system in place. Capping the amount a single wallet can stake would effectively mean that it will become even harder for us to get and remain elected. The community is NOT choosing to stake with anyone other than the well established validators. Forcing the large wallets to split their stake will not help IMO. I doubt these owners will want to deal with the hassle of moving their stake around to help decentralization, so I think they will just split it amongst some subset of the already elected validators…this will drive up the median and put election even further out of reach (I believe, I’d need to think about this more).

I do not see a way to fix this without randomization. Randomizing on slots/keys as @Babylonode suggests is a perfectly fine way to do this, and there are dozens of other ways to randomize the election process that would work. Randomization is fair and you can easily control the process to drive towards the desired outcome (decentralization) by simply adjusting weights.

[Babylonode]

I took some inputs on randomisation and it looks like NOT FEASIBLE to implement that’s a pity to me

[ValidatorONE]

I’ll respond in greater detail within the next few days, but the max delegation per delegator is only meant to apply to the largest delegator(s), such as Binance, which currently stakes 2B out of the 4.7B ONE in total network stake with only 39 validators. That’s over 42% of total network stake spread across a limited number of validators, some of which are operated by the same people. You can see where Binance delegates by looking here:

https://harmony.smartstake.io/address/one1tvhgyvt94gkf7sqgude5tu6709kt9vg66pzwfv

Of those 39 validators, 25 receive delegations of more than 20 million from Binance for a combined total of 1.78B in total network stake across those 25 validators alone. If those 25 validators were capped at 20M in Binance delegation, that’s approximately 1.28B in additional ONE that could be spread to other validators. At 5.8M effective median stake, that’s 220 additional validators from that extra stake alone.

Simply put, Binance controlling that much network stake is a greater risk to decentralization than an independent validator like ourselves with 200M+ stake and over 2,600 unique delegators. By capping 3 or 4 of the largest validators, we may be able to produce an extra 15-20 available BLS keys, which pales in comparison to the impact that spreading the largest delegations across more validators could have.