So far it doesn’t look like the proposal will pass. We have a mix of validators that voted no who previously voted for 4.8% or 7.2% in the previous proposal. There are also many validators who haven’t voted yet. Curious to hear the thoughts of those who are considering abstaining.
2 Likes
In talks with our delegators is that they value Harmony’s security. They wanted the 4.8% option. Some felt that 4.8% wasn’t low enough even.
We’re here to represent our delegators and their views. So we won’t be voting so that a quorum won’t be reached.
1 Like
This is exactly my thought. I was in favor of 4.8% and will not vote for 6%. I understand that many of us want to free the roadmap, especially for external nodes. However, fIrst and foremost, I will keep my delegators stake in mind. If we have the opportunity to vote for 4.8% as originally outlined…or lower I will take that chance. Thanks @HankTheCrank , well said.
If 83 from around 100 Validators voted for 4.8% I don’t see how 6% actually reprents the consensus we reached and I think we loose out an big opportunity to decentralize Harmony by just letting this pass.
I also don’t see how we would easily reach a lower percentage in the future, when the need to pass something like this is gone.
Good ammount of larger Validators clearly favored an even higher limit and not more decentralization.
1 Like
Thanks for the feedback. My feeling is if the 6.0% proposal fails to pass one of you can feel free to put up a proposal for 4.8% and/or make any other adjustments the validator community sees fit. I should probably step out at this point since I it will be hard to be impartial because my validator’s self stake is well above 4.8% and my delegators would start seeing reduced rewards.
2 Likes
If 83 from around 100 Validators voted for 4.8% I don’t see how 6% actually reprents the consensus we reached and I think we loose out an big opportunity to decentralize Harmony by just letting this pass.
Like it or not this is stake weighted voting.
Put 4.8% up to vote and I will vote in favour… but it will count for nothing as we don’t have the larger validators on side and I see no evidence that their delegators would be willing to mobilise to force them to concede.
What I really want to avoid is further months of discussion holding up the “actual” decentralisation of the network. i.e. fully external nodes, including external block producers. This is way more important to me than 1.2%.
In talks with our delegators is that they value Harmony’s security. They wanted the 4.8% option. Some felt that 4.8% wasn’t low enough even.
4.8% looks very unlikely to pass which puts us in deadlock and while we’re in deadlock there is practically no limit to the keys a single validator can take.
There is also currently nothing to stop validators bidding low cheaply by putting many keys on a single node.
Are we going to hault progress over 1.2%?
Or can we find a middle ground?
1 Like
My understanding was the initial HIP-16 was supposed to take a weighted average rate of the different options and we’d settle on that, which was about the 6% that you proposed in the follow-up HIP-16 vote. The number of validators who voted for 4.8% is irrelevant to the protocol since someone could theoretically create as many validators as they want with only 10,000 ONE each. Ie. With 1 million ONE, you could create 100 validators. Harmony is a proof of stake network. Proof of stake governance doesn’t account for number of validators. It is highly unlikely 4.8% will pass so it looks like we’re heading back to the drawing board.
Currently to limit shard 0 operators, 4.8% would currently limit 2 validators, P-OPS (13 keys) and Kucoin (50 keys). Robovalidator is currently at 12, which would be the max assuming 250 keys/shard.
1 Like
Proof-of-stake is supposed to act as the deterrent, it’s not supposed to be manipulated into limiting keys. The deterrent being that if someone wanted to take over a shard, they’re at risk of losing hundreds of millions of dollars. The feasibility and need for this proposal is practically zero. At this point, the proposal is just throwing unnecessary costs on large validators, creating a network key max at 52, assuming 6%. Do we even know the ramifications of resharding with something like this?
My main issue with this and most proposals are that they’re haphazardly thrown together for the sake of “Decentralization” and “Takeovers”, that have longstanding ramifications with almost zero input from the Harmony core team and almost zero discussion. We’ve been through several attacks and with shard 0 block times ranging from 3-10 seconds, all of this due to underpowered shard 0 validators and unresponsive validators, we had to give back external voting power to the Harmony internal nodes because we didn’t have enough keys to restart the whole blockchain, now we want to limit keys on Shard 0. We couldn’t even get enough participation when the blockchain when we needed it most.
1 Like
We’re being told by a member of Harmony core that certain validators have too many keys, and the importance of this vote to move things forward: HIP-19: 100% external voting power and 100% external slots - Governance / Validator DAO - Harmony Community Forum
This was from several months ago and I believe he might be referencing that too many keys per node, not per shard due to the lack of power those nodes have causing slow block times, I’d need to hear from @leo and expansion of what he meant and what he believes is the best course of action today. I’ve put more keys on shard 0 due to the attack so we can have more voting power if something were to happen again.
1 Like
This whole discussion has been going on for months.
If we’ve gone off piste then it would be very helpful if @leo would chime in.
I agree. We need max keys per node for more stability.
We have many validators running like 10+ keys on 1 node with the same network connection and in the same data centres or areas.
It would be nice if we could limit 4 keys a node and 1 node per location to ensure a much global coverage as we can as well as having less points of failure.
I would hate to see what would happen if certain data centres had a problem…
Of course, this idea is separate to keys per shard
2 Likes
When we last talked to @leo on telegram he mentioned that resharding probably won’t be implemented any time soon. Meanwhile any validator with a meaningful stake can concentrate all their keys on a single shard and dominate it. With four shards, a validator with 5% stake can 4x their voting power on a single shard by placing all their keys on that shard to capture 20% of the voting power.
If resharding is going to be implemented then we probably don’t need this rule. I agree with others that it would be good to get feedback from Harmony core team on the best path forward.
1 Like
This is from November. Leo is discussing too many keys per shard
2 Likes
I don’t think it’s fair to call the push behind this proposal “haphazard”. It had early input/inspiration from both Jack and Leo
But yes, that we are on vote/iteration 7(?) of Hip-16 without any resolution is certainly an issue that needs to be addressed when putting forth future proposals
2 Likes
Technically, the original HIP-16 was about limiting keys per validator. The current limiting keys per shard concept co-opted the HIP-16 moniker
Also, are two separate ideas being conflated here? Reaching on-chain consensus is achieved via the keys. And in that regard, the number of keys is what matters, not the number of validators, per se. But this is a governance vote, and the system by which voting occurs is different than the system by which on-chain consensus is achieved
Governance voting is something that can be adjusted in order to prevent the voting preference of most validators from being “irrelevant”
2 Likes
I invite you to watch:
It talks about the security issue with Kucoin specifically having 50 keys on one shard. Not per node.
The video and screenshot above together paint a better picture of the problem and it being handed off to the community to resolve/discuss. There are other all hands meetings addressing this issue but I agree it is problematic that communication is across different platforms in different places. Understandable you might have missed it.
Now if you want to take issue with the Harmony team prioritizing decentralization over resharding you’re welcome to argue that point. However this proposal is in line with the direction the Harmony team is indicating they want to move in and the community is moving in response to that.
Now if that sentiment has changed the Harmony team has not indicated as such. Though if they do change, I hope they would let the community know.
4 Likes
Looks like I spoke too soon. We just need 2% more participation on Snapshot to get it to pass
1 Like