Sounds good.
Needs to be set right to force enough validators into shard 0, which is disincentivised currently.
1 Like
Sure, dropping keys is a great gesture but of course thereās always people (or bots) waiting to snag slots.
Unfortunately pulling in a lot of new validators way early only starts the clock on their APY countdown before they are ready sometimes and they may go unelected for quite awhile after that while burning the 0% fuse. I had that happen when I started but we didnāt have the countdown in place back then. I was pulled in early and then spent 35 epochs working on getting enough to go full time and eventually it worked out.
Anyways on the topic - Limiting keys per shard is probably the easiest way to get this in place sooner than later but Iāll leave that thought up to the group (and devs as to if it can actually happen) to discuss further.
1 Like
The problem here is we need shard 0 fixed and at 2s and then it would be desirable again. Might need a different post for this topic. 
2 Likes
I think even with the block time fixed (again) there will be an issue as long as everything is going through shard 0.
We need resharding and cross shard dappsā¦ which is dependant on this discussion ending in a workable proposal.
We should get an epoch here where shard 0 gets unreal returns out of nowhere when it snaps back. Thatās what happens in the past anyways, then youāll know itās ok to head back if youāre up for it.
1 Like
Just thinking about this number: 27 max per shard
We have an opportunity to put some sort of restriction on growth, keeping in mind the goal is to have a greater number of validators in the long run.
With 4 shards a validator with 106 keys is taking 10.6% of available slots. That seems a tad on the high side.
We could lower this number to 15 keys per shard to ensure a better spread and not force any validators to shrink or split in the short to medium term and lower the maximum slot take to 6%.
2 Likes
This discussion is about a cap to allow the network to progress into itās next phase and towards full implementation.
Iām also keen to address the lower bound issue, but I think our priority should be removing the current roadmap blocker.
Iām not married to any one solutionā¦ I just want the roadmap implemented.
Edit: Itās now about unblocking the roadmap (or at least for me)ā¦ I realise the topic has changed
1 Like
27 keys per shard is a good starting point because it doesnāt reduce total key cap, which could negatively impact delegators and reduce overall stake count, while still mitigating network security risk. If based on average 250 keys keys per shard (1000/4), 27 keys would be 10.8%. Would a dynamic number of keys based on 10.8% of actual keys be better from a risk perspective? For example, if Shard 0 had 200 keys, the limit would be 21 (200x10.8%=21.6, or 21 rounded down). Conversely, if shard 3 had 300 keys, the limit would be 32 keys (32.4 rounded down). That would force a validator to shift keys to another shard or risk degraded earnings.
One problem I could potentially see with this approach is how do you account for evolving key counts. Every few seconds could potentially be a new limit that would need to be micro-managed by validators and I could see competitive tactics potentially being used. The current bidding system might need a tweak if we went down a key cap per shard route, or at least weād need to consider the downside. Even so, the extra burden would likely fall on only the largest of validators and shouldnāt affect smaller validators.
2 Likes
I like that amount. Itās not entirely random based on what would be āgoodā or āniceā and it has some logic to it. Limiting keys more drastically would be probably too disruptive and this might be a good start.
Itās a step in the right direction, something that may find consensus and pass since that limitation would only affect 5-6 Validators at the moment.
2 Likes
To simplify things, we could say 10% cap per shard key count, ie. 25 keys per shard if 1,000 slots and 250 keys per shard. That would reduce total key cap from 106 to 100 per validator and encourage new nodes if a validator exceeds the key cap on a single shard.
2 Likes
Support:
- Reducing BLS keys per Validator
- Introducing randomness in the election process
- Allow Validators to combine their pools with no limit for the number of participants in these coalitions
Donāt support any higher limit for the self stake amount because it imposes barriers for new validators to start this business.
1 Like
So at the end you mean only a key cap of 100 coming down from 106?
Will this have any impact at all when currently the biggest Validator has 56keys?
10% of actual keys per shard. If a shard has 250 keys, the key cap for that shard would be 25. If a shard has 200 keys, the key cap would be 20. 10% would force larger validators to spread their keys across multiple shards. This is just a dynamic key option. We were also discussing a fixed key amount per shard as a potential option if assigning a percentage like 10% isnāt feasible.
2 Likes
This would tackle the security issue so that the shards are āprotectedā against failure or simultaneous maintenance periods of different validators on the same shard. Thats an important thing.
What about the freeing of keys for new validators? Would this measure improve that or do you have another thing in mind?
I posted my suggestion for reducing excess keys a few months ago in this thread:
@ValidatorONE @DKValidator @Manumix @armstrhu @mindstyle @Jimbo_JCR.one @easynode @CryptoTech @Babylonode @RockTheBlockchain and all other
Validator DAO Twitter Spaceā:rotating_light:
Time: Nov 20, 2021 / 3pm UTC
Today we will have a Twitter Space AMA about the HIP-16 join us under
https://twitter.com/i/spaces/1yoJMWQQWpOKQ
5 Likes
I might not be able to join, but what if you can post a recap in this thread? Will help a lot for us.
2 Likes
Iāve already shut my validator down due to this issue, itās simply not worth my time trying to claw back power from greedy individuals; Iāll throw my support behind other projects. Good luck figuring this one out before others do the same.
5 Likes
I was sure 250 keys per shard was the current implementation. If this is the case the hard cap of 25 seems reasonable from a security perspective.
@leo - Does a limit of 25 keys per shard alleviate your/Harmonyās security concerns for us to move forward on HIP-19?
This change would force 25 of Kucoinās keys out of shard 0, but are we going to get it populated enough with the current and recurring reward penalty in shard 0?
Realistically, most validators forced to move into another shard are going to choose shards 1 and 3 first, followed by 2 before they think about hitting shard 0.
It was a good spaces discussion, @sophoah popped in to answer questions. Hopefully it was recorded and it generated enough feedback for a proposal.
3 Likes