Discussion: reducing BLS keys

I like the Idea of a random pool, even 5%, could be 45 slots, so I think it should definitely be considered.
But idk if its feasible as @sophoah suggested above its a bad idea.

Though in the long-run I think the best option would be to just let the protocol assign Keys like @DKValidator suggested.

2 Likes

The randomness proposal and the decreased probability of being elected linked to how big a validator is comparing to the others certainly will do what actually the protocol is trying to do but relying only and purely on human behavior. I mean, the system can slash the bad actors, but only if they cross certain boundaries. In order to achieve the decentralization BASED solely on human behavior, must be more incentives be made for it. Since almost all of us are reward driven.

Why whales migrate more than 4k miles to have their babies instead of having it right there on South pole? The environment is better more secure and is more likely to be successful to give birth there. And WHY they return to a HARSH environment that at first was insecure? Because the abundancy of food. Is riskier to travel yes, but the “rewards” to do so also.

If the community wants to rely only in the human behavior to decentralize the network, so the delegation to unelected validators should be more rewarding than to the elected, give more rewards for a riskier travel. The more attractive it is, more delegators will tend to risk their in order to get bigger rewards. Many things can be done, from giving more visibility to really increasing rewards by how long a delegator is sticking to an unelected over each epoch until it really gets elected and it receives those accumulated rewards diluted over the subsequent elections, by this way, tying the delegator to the validator until it receive all the “bonus” rewards or it can migrate at risky of forfeiting it.

The “bonus” for new elected and below median stake works only after a validator is elected once and is proving to not being enough to make the validator noted by the community. If the community doesn’t look to them while unelected, how they will become elected with 3.5k median stake? Where in the earth a guy sitting behind a computer will gather 35k people with 100 ONE and convince them to delegate with him, solely on convincing power? Some extraordinary cases may apply. But and for the rest?

I don’t know if it’s the place to discuss it. But I’m trying to show the other side of the coin, the human nature is reward based and it’s nothing wrong with that. Once again, if you want to drive more inflow toward somewhere, just make it more attractive.

The consensus is that something must be done. If more than one proposal could be applied together, better.

5 Likes

This is a nice way of putting it :slight_smile:

We can’t forget however that, while incentivising the delegation on unelected validators, the stability of elected validators should be maintained. The moto would be ‘we want movement, but not too much’.

What happens once the higher rewards of freshly elected validators starts to slow down towards base levels? We don’t want a few billion ONEs jumping around trying to catch highest rewards all the time I assume.

I agree that with current incentives the movement is not enough and most of delegators sit comfortable on their old validators while new unelected ones don’t get single delegators for weeks. Maybe just cranking up the incentives for unelected validators as you describe would do the job.

4 Likes

There should absolutely be no expectation by relying on human behavior to enable decentralisation. The proof has to be in the protocol. If it cannot be possible, it cannnot happen.

5 Likes

Why not let’s put it up for a vote? There’s currently 4.4B staked. If the question is what to cap it at, that’ll be tricky. The total staked could move up over time due to the annual 441M inflation. The EPOS range right now is between 6M to 3M ONEs, so the divisor to use is 6M per BLS key slot.

If it is enforced, validators with too many delegations will be forced to open up a new validator moniker and communicate to their delegators to shift it over to their new validator.

Your vote on max BLS keys to cap per validator

  • 8 - caps out @ 48M ONEs
  • 16 - caps out @ 96M ONEs
  • 24 - caps out @ 144M ONEs
  • 32 - caps out @ 192M ONEs
  • 40 - caps out @ 240M ONEs
  • Other

0 voters

“caps out” here means reward start degrading for everyone’s delegations in that validator if they reach the max ONEs estimated.

It’ll be interesting to shake up the delegations a bit and see where things settle

3 Likes

That is interesting. I know the bigger Validators will not like this but it’s exactly like you said. Create another Validator and have them delegate to the new one. That alone shouldn’t be too much of a hassle. Now that we are all mandated by the 5% it seems feasible. This way we won’t ever see a 500 million validator eating up over 90 keys. A split will add an additional validator to our goal of 1,000 validators. It will take a bit of education for the delegators to know when to migrate to the secondary validator. I would assume the staking dashboard can be updated to reflect changes like this to make the UI easy to understand.

3 Likes

As someone who’s trying to create a one-of-a-kind project with an ecosystem around my validator, not a huge fan of any cap. The whole point was to attempt to educate users about EPOS and increase staking amounts on the network to help security overall.

1 Like

To go that extra step, think of governance in it’s current state, it favours the bigger validators by a large majority and squashes the opinions of smaller validators and their delegators.

I think Capping total stake isn’t a viable fix as it barely applies to many validators unless the change is dramatic. It’s good in the sense that it can limit voting power and promote growth for people with less staked, but just by judging the previous vote by @Jacksteroo you can see the consensus leans towards power and greed which could lead to duplicate validators or just more elected validators achieving higher stakes. This is not a good recipe for long term growth, sustainability and especially decentralisation.

Even the interfaces alone such as the staking dashboard do not promote unelected validators. The process to even delegate require more clicks and uncertainty for the end user. Think about it, the first time someone opens up the staking dashboard they will most likely never click all validators, they might filter by rewards or by staked amount and then stake with who they see fit. Unfortunately delegators sway towards rewards and large stake. All whilst most likely not even being aware of or considering unelected validators, unless they are grinding and promoting day in day out or giving away free things. Which in itself isn’t the most effective means of attaining delegations and leads to people coming and going, but this is the only means for most of us. Feels like we are pushed to the side.

There is a notion that unelected means “Unsafe” and you should “do your own research” or you might “lose” your staked ONES. I’ve seen all these thoughts play out multiple times and even seen some validators fuel such beliefs, that most of the time are not even close to the truth.

As an unelected validator myself it feels as if I do not even have a chance to shine and grow with the network as large and often soulless and autonomous validators seek to do the opposite and are fuelled by commissions/profits and do not prioritise governance.

Overall I think the issue is much larger than reducing keys and reflects on the future of the network. This issue will require many minds to solve. There needs to be a greater emphasis on small and unelected validators. This is my take on things as more of a humanistic approach, as for the technical side I am not well versed to provide further thoughts.

6 Likes

I had an idea I think could encourage decentralization more than capping BLS keys per validator which would also avoid bad side effects such as harming delegators to large validators who are forced into an efficient bid due to the BLS key cap.

Currently one major issue is that validators are receiving huge delegations from whales as others have alluded to in this thread and apparently whales such as large exchanges are not good about spreading their stake. The simple solution to tackle this problem head on would be to cap the max stake that each wallet could delegate to a single validator which would force the hand of large ONE holders to spread their stake more evenly.

The cap could be dynamically adjusted to something like 4x the current median stake per validator so that the rule can scale with the network. Another addendum to consider would be that this cap wouldn’t apply to self delegations so that anyone would still be able to validate their own ONEs if they wanted to.

Really though, It does pain me to propose this rule since it would hurt my validator more than anyone else and maybe I should have my head checked :slight_smile:.

11 Likes

Hey Robo! It definitely sucks but with the bigger picture in mind, it does sound like a good idea. We won’t have ti cap Keys with this type of move and it will encourage delegators to diversify their portfolios

6 Likes

Agreed, this sounds good

2 Likes

Hi Robo,

this idea has been discussed before and I personally think that this implementation will create a change in how big wallets delegate but won’t tackle the issue of bringing into election unelected validators.

if I am a big wallet (e.g. an exchange) and have let’s say 500mill ONEs but can’t put more than 50mill into the same validator, I just distribute 50mill into the 10 biggest validators. That is easy, doesn’t takes me long and it feels safe. If those are the biggest, they must be the best or safest.

Those delegations won’t land on the 30% (currently more than 100) of unelected validators IMO.
This idea introduces more of a hassle for bigger wallets but the end result won’t be that different to what we have now.

Between this idea of limiting max delegation on a single Val. and the limitation of Keys, I tend to lean towards the latter.

Adding to this: If the network plans to have 1000 Validators running and lets say we achieve 60-70% of staked ONEs (as an example, let’s say 8.5bill ONE) that corresponds to 8.5mill ONEs per validator distributed equally.

4 Likes

The newtork is still young and IMO hasn’t evolve into its final version. To plan and create concepts and businesses on top of the current state could be risky.

To build projects on top of current state and count with having a validator with 50,100 or 300mill ONEs delegated incurs into the risk of being negatively impacted with future changes. On the other hand, it starts to “osiffy” the protocol itself by loosing flexibility and change capacity because of codependent protocols or business running on top of it.

This shows that there is not eternal time to make structural changes. People like you need a stability to conceive ideas and business models and the later we introduce those changes the more difficult it will be to implement them and the bigger the impact in those already deployed codependent projects.

1 Like

Another extreme variation of this rule could place a 1 bls key cap on the amount of stake from a delegator to each validator.

Binance currently has 1.5b ONE staked: https://harmony.smartstake.io/address/one1tvhgyvt94gkf7sqgude5tu6709kt9vg66pzwfv

The current median bid for one key is 5.2m. 1.5b / 5.2m is around 288 keys or at least 288 validators. This is almost twice the number of currently elected validators, so it would force Binance alone to spread their stake to 139+ unelected validators.

4 Likes

That kind of cap that would definitely make the amount of elected validators rise drastically.
I haven’t thought about such an extreme case. Good point.

I guess that this would be too extreme given that we haven’t enough validators to cover the complete Binance stake yet. But with 2 bls key cap that would already work.

Another possibility would be a gradual reduction, step by step. But that would be maybe too much of a hassle and worse that changing the system only once and see what happens. That would give the chance to introduce some stability for everyone.

So, when do we vote? :slight_smile:

3 Likes

Yea that type would be on extreme level for today’s validators. I believe your first approach could be a start. From there let the amount of validators grow and catch up. Theres now way we can generate that amount of validators for just one wallet at the moment.

1 Like

That is exactly what Harmony wants people to do, which is why they launched a 300 million dollar campaign for people to innovate and bring unique ideas to Harmony. Regardless, forcing equity into a system that thrives on free market growth will only stifle participation in the ecosystem. Proof-of-Stake isn’t meant to be “fully decentralized” like Bitcoin or what people think it means, it’s meant to be a counterattack against malicious actors and for people to have enough stake in the game to not act maliciously. PoW was far too easy to buy hash power and overtake a network, it was cheap compared to Proof-of-Stake. I’m all for creating tools to better educate people about how EPOS works or even preventing validators from taking up too many keys while they sit in the median. However, a validator is not a right, most validators that have been around since the beginning have worked extremally hard to get to where they are now, it’s not a right to be a validator, however it seems that a lot of new validators have that mentality. I suppose all of this depends on how you define decentralization, most validators run their servers in all of the same datacenters, one datacenter goes down and you lose half the network. I’d be more concerned with that sort of centralization than bls keys.

3 Likes

Yeah, most of the effort that was made by the big ones was not to be forgotten. But unfortunately you can’t expect a different result, doing the same stuff over and over. In the end the decision falls in the delegator. Even enforcing some of the caps, still the decision is in delegator hands.

Unless a hard cap is implemented and a validator that had grow after a certain threshold, won’t be able to receive ANY delegations any more.

1 Like

If I were a large investor with a lot of ONE to delegate, I’m going to look for maximum returns and the “security” of a more established validator. Period. Dealing with large amounts of ONE like that, small percentage differences can add up to a huge amount of money. Therefore, regardless of any limit imposed per wallet, I’m going to stake with the most profitable and large/stable validators. Even if I have to create many wallets to do so. It only takes minutes to create a wallet, send ONE to it, and delegate it to the same validator as your other wallets.

Hmm… :thinking: perhaps an age limit to wallets before they can delegate could help to discourage this. For example, a wallet would have to be at least two weeks old before they can delegate their ONE. Or it could be coded to detect activity such as “whales” sending ONE from a certain wallet to a bunch of other smaller wallets and trying to delegate to the same validator. Giving them a “Please start staking with a smaller or unelected validator to help ensure network stability and security” when they try to delegate to that same validator again once the activity is detected.

Maybe the answer is as simple as putting a message on the staking portal before they delegate, asking them to please spread their ONE evenly across validators and support smaller validators or something along those lines. This problem may not be as complicated to solve as it may seem and we might be thinking way too far into this.

Maybe there is something that we can do from the wallet side of things to help control the delegation balancing issue. Not change the protocol itself or the way that validators work, but the way that the wallets and delegation work.

My apologies, I’m just running ideas through my head and figured that I would type them and share them with you all as I do lol

3 Likes

Rather than make drastic changes to solve this problem, I wonder if we put more effort into “educating” delegates before they delegate their ONE, it would gradually correct itself. Perhaps simply putting a message on the staking portal as I mentioned, when they click on the “Delegate” button, a message pops up with a short message briefly explaining the importance of evenly delegating ONE across validators and kindly asking them to do so, would solve this problem.

2 Likes