Pre-HIP : Max keys + max keys per node + max keys per validator per shard + dynamic keys limitation

I see, and I suppose for the time being this does make sense. As time goes on I’m hoping it doesn’t grow into an even larger problem. I’m just concerned that this might come back to bite us in the butt later. tbh I’m not entirely sure what the best solution is here just yet. Taking all things into consideration, it’s a bit complicated to make everyone happy, and do what’s best for Harmony at the same time. We should definitely take care when making these decisions and think them through and discuss them thoroughly. I know we are pressed for time as well, but perhaps the separate proposals will get more discussion going and a better solution will be proposed. We’ll have to take it day by day and I’m sure we’ll figure it out. Lot’s of bright minds and good people behind Harmony. I have faith in us <3

1 Like

Yes and original it was MaxKeys = 4, since I think May it’s MaxKeys = 10.
But if you have a powerful machine you can adjust whatever you like and here is the problem. Let’s assume you have a very powerful machine, increase to 85 keys and have two Validator assigned to those keys. Now the needed power increase or disk is full and you go down. 85/250 is 34% so the shard or network is halted.

3 Likes

This is exactly what I was thinking. We can implement this and fix one half of the problem, but it seems to be completely avoiding the other half. I will discuss this further in the new topic for HIP-16.

We should not be voting on things until we completely understand them. We need to have discussions and learn all that we can. Make an educated decision for the best of everyone, which would then be put into a very clear and concise vote that everyone can understand.

What happens if we pass a vote that solves half of our problem, but that change somehow makes it harder to make the next change necessary to fix all of the issues?

We need to debate an issue in depth enough to have had that discussion already, putting in place a timeline for how to solve a larger issue. i.e. first we pass vote A, then once completed, we will need to pass vote B (assuming they cannot be put into the same vote).

By doing this the entire community will be better informed. Discussions and votes can be streamlined and there will be less need to keep popping up new topics on the same issues.

3 Likes

24 BLS keys was literally part of @Jacksteroo’s comment in the previous BLS key thread. And it, along with just 8 BLS keys, were the top 2 vote receivers in Jack’s poll in that thread (see: poll in the OP of this thread). Jack explained his logic in the previous thread. It wasn’t merely something that people thought “looks OK”

The “cap” is at which point validator rewards start to depreciate. Rewards would be less than the current 9-10%. I voted for 8 BLS keys. I want to disincentivize people from delegating with large validators. I want to increase the total number of unique validators. That is a simple fix. It does not require a “hard” key cap. Nor does it require a “complete overhaul” to the protocol

I understand some larger validators may not be pleased with this. But it’s about what’s best for the protocol and all validators. And in that same vein, I would support disincentivizing the largest delegators, too, like @sophoah mentioned

4 Likes

All due respect, I’m not sure I follow the point you’re trying to make. That you think it should be an 8 key hard cap? There’s close to zero percent chance that would pass.

1 Like

I informed you that it wasn’t an arbitrary number, that Jack was the one who came up with it/them, and that it’s not a complete overhaul. I further explained that it wasn’t a “hard cap”

I hope this helps

3 Likes

I mentioned my vote as additional context to explain my position. However, it was not the main purpose of my comment

Also, you can see in the OP that 8 keys was a narrow second to 24 keys, so one would imagine it would stand a chance of passing. I also said I know that larger validators won’t be pleased

3 Likes

I agree about the votes,

If you look at the world through your own personal microscope you can see that 24 keys at 33% has the most votes so it clearly won! Lets vote on it! But as you can see this is only the way that certain people tend to look at the world…

The truth is that 24 keys barely won at 33% with 8 keys being close second at 30%. In third was 16 keys with 22%.

If this vote is based off of what people desire (which it is) then we need to consider the average weight of what was voted on. In this case it seems 16 keys is the clear winner to get the most Yes votes come time for the actual vote. You will notice though that those same people who want 24 keys tell us that 8 keys isn’t going to pass. So it seems they expect us to negotiate with them, but by the simple fact that they rushed 24 keys without even considering doing a 16 key revote, shows they are not so fast to negotiate with us or even consider our opinions if those opinions hurt their bottom line.

We need to start working together more for the sake of Harmony. Stop thinking about our own pockets and fix these issues. I am sorry that some of you may lose delegates, but maybe we can lower those numbers over time until we hit 1000 validators to ease the burden of the changes? Working together on this is the best way to go about it.

I truly would not even care if you had 500 Million delegated to you if there were a supply of 500 billion ONE. However, there isn’t, so we we need to do some math to figure out how this will all work, not because I want it to, but because it HAS to work.

Lets face it, if Harmony said today, “sorry everyone we only need 150 Validators total”, well I guess that is all they need and the rest of us pack up and leave. But Harmony said they want 1000 validators and 200 by the end of this year.

As per Harmony teams request to grow, lets do some math.

Lets just say there is 7.5 Billion ONE total that can be staked.
**If you want to correct the math feel free to repost new numbers.

7.5 Billion ONE divided by 200 validators = 37.5 Million ONE each, split equally between each validator.

7.5 Billion ONE divided by 1000 validators = 7.5 Million ONE each, split equally between each validator.

If 20 validators had 200 Million each (4 Billion out of 7.5) out of 1000 validators that leaves 3.57 Million each when split equally between the remaining 980 validators. You would end up needing to get validators elected at 200K Stake at that point, maybe less because there won’t be enough to go around.

If even 40 validators had 200 Million each that is 8 Billion and exceeds the total supply to be staked and is not even possible.

So you see, math does not lie. We can sit here in these forums for months(it seems we have) arguing over the same things, debating small changes here and there that will affect what happens today and tomorrow but none of that matters if you aren’t also thinking about deeper into the future than just your own tomorrow.

How can we possibly sustain 1000 validators profitably in the future if there are validators with 200+ Million ONE just on their validators alone?

The new proposal HIP-16 for 6.4% keys per shard is great for the security of each shard but doesn’t even make them have to start up a new validator. Simply just put 1 node on each of 4 shards for 6.4% per shard for a total of around 64 BLS Keys out of 1000, which if we say it is only 5 Mil per BLS key that is a total of 320 Million per validator. This number is not sustainable in the long term. We may simply need some other form of cap such as this BLS cap per validator.

Then there is the idea that if they want they can just open up a 2nd or 3rd validator. This would be great in the short term because it would bring more validators online but you are creating a false sense of security and should be very careful in this. If a large validator did manage to build 2-3 more validators each with 200+ million, not only would that person have a massive amount of voting power, but the security of the network could be at stake. While I do not believe that an attack would happen, my biggest fear would be that something could happen with a person and all of their validators go offline at the same time. This could cause a massive problem if we do not have a balance with the amount of validators elected and amount of ONE delegated to those validators.

With all of that said I do understand that there are quite a few validators currently above the 144 million that 24 keys would cap them to. I feel for them and their situation because they were lucky enough to be the first validators and they worked hard to get things started. Due to, I believe, unforeseen circumstances, they were able to grow to a size that is unsustainable. It is possible they are just now realizing this fact and it will be hard at first to accept. We need you to accept it though and work with us so that we can continue to grow.

This is why I propose that we all agree to 24 BLS keys along with a per shard limit for now to get more validators online and not 16 or 8, but only under one condition. The large validators must agree that when we reach the next point where we are no longer able to get any new validators online, we move to 16 keys, then down to 8 as we get closer to 1000 validators.

As I do not expect that every validator should have the same amount of stake spread across the board (we all know that is unrealistic), we may never have to go below 8 or 4 keys per validator as long as we can keep 1000 online profitably. That though is a topic for in the future as things progress and we know more about the profitability of being a validator at that time.

Lastly I would ask that all large validators refrain from opening up a 2nd validator to bypass the 24 key cap until after we onboard more unique validators. This simply buys us some time to add to the security of the network before we start adding more non unique validators and will also help with the unique spread of delegations in the first phases of the change.

What do you think? Could we all work together and make this happen?

Thank you all for taking the time to read this not so short post!

I look forward to working more with everyone to create a brighter future for all of us!

3 Likes

It’s disappointing to see so many validators wanting to take control over a delegators power of validator choice as a means to grow their own stake. Our node went unelected from May 2020 to January 2021 and we never thought of limiting the larger validators in any way. What we did is we rebranded, marketed, and grew our node’s delegation organically. We grew to 200 million delegates in our first 100 elected epochs without any governance proposals designed to help us. Validators can grow without gimmicks designed to move stake around that aren’t even guaranteed to do just that. Capping a validator simply for the sake of undelegations hoping they go to a smaller validator is speculatory at best and not how a network should be governed. The key cap per shard should help alleviate the most pressing security concern which is a single validator takeover of a shard.

1 Like

Please don’t put words in my mouth and assume I want to take control of anything. I am trying to solve a math problem and that is all, please help me do it.

I don’t mean to argue with you but you once again ignored the math. How can you possibly have that much for yourself and others achieve the same and there be enough ONE for 1000 validators? Please enlighten me. I just put the math out there for everyone to agree with or dispute freely. So lets keep the facts strictly based off of math and not emotions or perceptions.

Tell me how we can have 1000 validators online under your idea of how Harmony should be and what do you perceive will be the amount of Harmony that the smallest elected validators will be able to sustain? Do you even care?

I would not be the first to suggest that we simply avoid all of this and give incentives to delegators to go to smaller validators such as higher rewards percentages based off of the size of the validator. But we are told that this will not work either otherwise, wouldn’t we be talking about that instead of this?

4 Likes

My point is, if a validator is suggesting key caps to achieve 1,000 validators, than why is the only option not 1 key per validator? Do you think those with more than 1 key would be as receptive to that idea as they are to a 24 key cap?

2 Likes

I suggested higher than 1 key per validator to save the bigger validators from being forced out of almost everything they have earned.

You can simply slowly step down over the next year or so as we bring all these new validators online. It will be a process and will not happen over night, so why do you need to give up all of your delegates overnight? I do not believe this is fair so I suggest a step down approach until we reach 1000 validators in a manner that is fair for (mostly) everyone.

I understand that things cannot be perfect and some will get left out etc. I also understand that there is room for negotiating more with you as well on the numbers as we do not have to be so combative about how we approach this.

1 Like

Not trying to be combative, but if you’re passionate about a delegators power of validator choice, you tend to stand up for the delegator. There are many validators who do not believe validators should have control over a delegator’s delegation, we are not the only ones. We’ve suggested many solutions to decentralize the network that don’t involve hard key caps and negatively impacting delegators.

2 Likes

I believe Harmony needs you, you are the backbone of Harmony right now. We need you too, we need your help to bring us all online and make Harmony amazing for the whole world to see. If we solve the math problem above I believe we will all make out in the end as we watch Harmony grow to what it is meant to become.

1 Like

Appreciate the fact we’re all working towards a more decentralized network, but blockchain has certain ethos we feel strongly about and that wouldn’t matter if we were a small or large validator. If we are looking to control where delegators place their stake, we should first consider a max delegation per wallet. There is a delegator who controls 1.5B of the network stake and 2 wallets with +160M delegated to the top 3 largest validators. If there were a security concern, it lies within those delegators much more than a validator who has 3,300 unique delegators like ourselves who has no influence in where our delegators place their delegation.

1 Like

I actually do not disagree that a free market approach seems fair and non restrictive but if left unchecked can cause an imbalance to a system.

Freedom is only free until someone becomes big enough to use their own freedom to take the freedom away from others, at which point someone is now paying the cost.

I also do not disagree that a delegator should be able to choose where to delegate. But with that said once again it has to work within the parameters of the system. With the idea that a delegator should get free choice, theoretically all 7.5 billion ONE could be on 1 validator leaving the rest with zero. With this I would say a fix would be rewarding those who stake with smaller validators.

There has to be safeguards in place if you want a system to work properly. If all you are interested in is a for profit approach then a few people may make it to the top and profit, but at what cost to the entire system and everyone else in it?

1 Like

This is where the key cap per shard comes into play, a solution with which we agree. In the end, the key cap per shard will provide the key cap overall that decentralizes the network by alleviating security risk, but anything more than what’s necessary to alleviate that security risk is subject to opinion and why the topic of BLS key caps has been discussed since EPoS launch with no solution to-date.

2 Likes

I have to respectfully disagree.

You say that anything beyond what is necessary for security is opinion. If that is true then solve the math problem above for me.

Math is not opinion it is fact.

1 Like

Perhaps you could clarify your equation on how you determine profitability. Profitability is variable and can change per block. Proposals should be designed to withstand extreme market highs and lows in order to avoid constant proposals that increase or decrease key caps. Ultimately a blockchain should be designed to last indefinitely even if all but 1 validator remains.

1 Like

My math problem does not involve profits, yes one part of it does, in the end once we need to determine the lower bounds of small validators to stay alive, but we cannot predict that currently. My question is more to the idea that there is a limited supply of Harmony but you want to be unrestricted on how much of it you can have delegated to you alone.

1 Like