Agree with the options and they should be low enough to address the original motive of this proposal, which is “to decrease the likelihood of a shard being taken over by a small group misbehaving validators”.
1 Like
@RoboValidator @ValidatorONE don’t take me wrong.
But the issue being addressed is the takeover of the shard by the least number of validators. The less the %, the mostly unlikely it will happen. We all agree on that right?
The impact must be foreseen for sure. And we all know were lies the decision for this hip to be successful or not.
The biggest 12 validators has around 50% of the voting power. Not all elected validators vote. So you guys being active, represent most of the voting power. Now.
Would be interesting that we, as a community, come to an agreement that will benefit the protocol and as secondary effect us all. Since, May/21 it’s has been ventilated. 7 months now. We all know that you guys “lifted” harmony, did a great service and ARE still doing it. Nobody denies that.
But once again. We are waiting for 7 months for a decision like this. How many months more to take another that will actually solve something? Why not take this chance to finally solve more than one problem at once? 6.4% means that the 15 biggest validators can overtake a shard. That means 10 validators must be fully operational at ALL time. 5 validators is a big number? We already saw today a big server having issues, this is not so “avoidable” as it seems. And if this happen on the beacon shard? Why not minimize the risk for once with less %? 6.4% could sounds a good idea but in fact it isn’t. I strongly support something below must be included.
*OBS: must remember that the consensus need for 2/3 of the validators to sign.
6.4 - 14 keys cap - 5 validators can jeopardize the network
5.6 - 12 keys cap - 6 validators to jeopardize the network
4.8 - 10 keys cap - 8 validators to jeopardize the network
3.2 - 7 keys cap - 10 validators to jeopardize the network
1.6 - 3 keys cap - 25 validators to jeopardize the network
4 Likes
In the Moment we have 10.6% but not a shard limit. So 1 Validator can grab 106 Keys for one shard and halt it or even the whole network. Those % are on total Keys but if the balance in shards are not optimal those % will increase so let calculate with 190 Keys in worst Key instead of 250 Keys
7.2% - 18 Keys per Shard – 9.47% - 3.5 Validator to halt
6.4% - 16 Keys per Shard – 8.42% - 3.9 Validator to halt
5.6% - 14 Keys per Shard – 7.37% - 4.5 Validator to halt
4.8% - 12 Keys per Shard – 6.31% - 5.27 Validator to halt
3.2% - 8 Keys per Shard – 4.2% - 7.91 Validator to halt
What I don’t understand how Robo calculate Keys based on hardware and cost. Does this mean you run all keys on one machine? If so we have there a higher risk if one machine goes down.
2 Likes
At the moment is 1/3 of the total external slots. So any validator can get 300 keys if they want. At least it’s in the docs.
Those calculations and the poll you posted earlier are based on 1000 slots. Currently we are at 900 slots so 4.8% would map to 10 keys and not 12 keys for example.
In a 1000 slot world it’s very unlikely we’d get shard with 190 keys especially since the shard 0 signing issues have been resolved with recent upgrade so that rewards are now more balanced. Shard 0 is currently as 212 keys out of 900 total.
Pretty good point here.
In the current situation 6.4% will be in reality 8.42% which looks high.
I am in favor of 12 keys (for 900 slots and 1000 slots). 10 keys is too low to start with.
12 * 4 * 7 = 336M
@RoboValidator you should not be placed in a situation of overbid here but I agree that you won’t have a lot of margin to rebalance the shards if necessary. But the other validators below you will be capable to do it.
4 Likes
Why I always calculate with 1000, because this is what we have. Just in the moment 100 of those are on internal nodes but this will be open up with HIP-19. So I think we should calculate with this because this is our target
where do you have this from? If you calculate with 900 Keys you need to use the upper number which is 204. Those 229 includes the 25 internal Keys and this would reflect our target with 1000 Keys.
1 Like
I see, I intended the calculation to be based on the number of external slots, not internal slots. I’ll update the proposal to make this clear.
My reference to the 212 internal slots on shard 0 was from the election previous to that. You screenshot is from the next epoch change.
Since the display issues with stake-weight voting results haven’t been resolved with the DAO mainnet, how about we post this proposal on staking mainnet tomorrow instead?
2 Likes
I dont understand why dont we want to set the number as low as possible right now?
5 Validators being down stopping the Chain seems really unsecure, why do some want that?
1 Like
Epoch 786, 787 and 788 show all 204 Keys on Shard0. Did you may checked during the Epoch? Because during the Epoch like some hours ago it was 212 but know at epoch change over again 204.
Hmm I’m not sure where to see the history of slots. I guess my main point was in a world where there are 1000 external slots, as long as block times stay near 2s we should hopefully see slots on shard 0 closer to 250. The reason it is lower now is because there are validators with large keys on that shard which boosts the effective stake more compared to the other shards and hence diminishes the rewards per slot but after this proposal passes it will force the large validators to spread their keys so shard 0 remaining underpopulated will be less of a problem.
But since there seems to be a bit of push back on removing 4.8%, we can add it back to the proposal.
1 Like
Caveat: I’m not a validator, just a delegator, I’m a pure investor who has an interest in seeing Harmony ONE becoming decentralized, and I believe this is the goal for all involved.
I think we really should push for as low as possible (Ideally 1-2% max per shard). Reason being, true decentralization can only be obtained when the voting power is distributed and the validation is distributed. I realize that this is much easier said than done and a large part of the reason why it is so concentrated is to help save on cost of running multiple nodes with small number of BLS keys. It also allows for better control of stability. At some point, we got to push forward with the vision of decentralization, opening up slots is just part of the solution. The other is to get the validation distributed.
There is nothing more frustrating to me to see stake weights of 2-7%. That is some serious risk not only in voting power, but also in validator failure. Minimizing the keys is a step in the right direction to help reduce the risk and spread the distribution of validation. At some point, the big validators need to step up and help the ecosystem more by distributing the validation.
I think Harmony is moving in the right direction in stepping out of the validation business, but I also think that the big validators need to do the same and help distribute the vote and validation process. If this means cutting back on profits for the greater good, then I think it needs to happen for everyone. This goal could also be achieved by setting the max to something more reasonable for their node(s). To help get more validators up and running independently.
I know this is being done, but we are a community and we need to think about how to build up a strong community by spreading the validation and voting power to get a true representation on the network. There will always be a portion of the community that simply doesn’t care about voting, only profits, but for the better of the community, decentralization is the goal and should be the focus.
11 Likes
As discussed in other related threads, I think the way to further decentralization separately is to impose a maximum cap on how much a single delegator can delegate to a validator. If Binance distributed their 1.5 billion ONE currently staked more evenly to 5m per validator for example they could get 300 validators elected alone. If we had a max 5m per validator staking cap, we could make this happen.
https://harmony.smartstake.io/address/one1tvhgyvt94gkf7sqgude5tu6709kt9vg66pzwfv
I don’t like the idea of using a key cap alone to enforce decentralization because I feel like my delegators (myself included) shouldn’t be penalized by the action of a single large delegator that didn’t spread their stake. So the penalty should be focused instead on the delegator that didn’t spread their stake evenly to encourage them to do so.
Also I feel it’s nice to keep the ceiling high for the incentives so that any validator can dream of making it big and therefore would be willing to invest more into building the ecosystem.
5 Likes
Will never happen, could only pass this if the big Validators agree and they wont for obv reasons
2 Likes
This also is something that must be discussed and also targeted. And is a great approach for sure. I’m really happy that we’re coming to an understanding about what need to be done. But it alone won’t bring the system to a level where can be fully trusted, to rely solely on human nature. For the decentralization to happen, more than one feature must be implemented. And in due time, adjusted if needed. As the others said before, is easier said than be done.
I assume it’s pretty much clear for everyone that the future of the network is being shaped now, and the network will demand more and more from you guys, please don’t be fooled. It’s not something that will stop here on this hip and now. It will scale. And after some time will come for everyone, the big and the small alike.
Once I started learning about this community I was amazed, I didn’t lied when I said that what brought me more closer to Harmony Network, was the community, the engagement, the friendly approach, and most of all, the commitment.
So I really trully believe that you and all the others will do what’s necessary when the time comes. It’s now a matter of survival. We can strive together or die alone…
3 Likes
I agree. This is another way of ensuring that the voting power is spread out more evenly and forces decentralization. Another HIP discussion for sure.
3 Likes
I like this idea, there are easy ways around capping delegations per address but at least it would force the delegator to at least think about splitting their stake across multiple validators.
Would you be willing to create a new topic for this specifically?
Without this idea though, there is already a maximum stake setting the validator can use so no delegator can take their total stake above a set value. So this should stop validators and their delegators from being penalised by a single large delegator hurting their returns.
3 Likes
We’ve been a proponet of max delegation per delegator, but 5 million seems kind of low. It would impact a lot of retail investors whereas our concern is institutional investors who hold enough ONE to materially influence governance. I understand your point about taking 1.5 billion from the largest delegator and dividing it by 5 million, but I find it unlikely that Binance will delegate to 300 unique validators. A max delegation of 20-30 million is likely to affect only a handful of delegators while still encouraging those delegators to participate in decentralization. If this becomes it’s own thread, I’m sure everyone will have varying opinions on what’s the right amount, if any at all.
5 Likes
I can do it. Just don’t want to steal RoboValidator’s idea.
1 Like