That is also an option but maybe some discussion would be useful to ensure that there is at least a general consensus.
All Votes apart from the Governors vote are stake-weighted but there has to be a clear 2/3 majority of an option for it to pass. In this case of HIP16 there was not.
However, it has enabled us to move forward and we are now closer to achieving this proposal that clearly everyone is in favour of, we just need to agree on a % so congratulations for that.
If you keep this under HIP16 then there is no need for the 7 day waiting period (the 14 day timeline is to debate and get a feasibility review. It should be viewed as max 14 days or at least that is what we dreamed of at the time ) and we can go straight to another vote but I encourage some discussion before this to align as best as possible with the communityâŚ
I will send out a tweet linking to here and try to drive some validators into the discussion but ultimately the decision is yours!
I think the first vote should of been, are you in favor of BLS key restrictions? Yes/No â Otherwise you get this two party system where validators feel forced to select an option even when they donât agree with the proposal to begin with. After that, it then moves to how much of a restriction, and then finally a vote on the top two choices but it has to pass a Yes/No vote first.
What I also like with the 4.8% option is it corresponds to the maximum of 10 keys by default in the configuration file.
Limiting to 4.8% ensures a shard overtake is more complicated but it also help in the resistance of the network by making sure a maximum of 10 keys are running on each node.
I doubt 4.8% will pass. How about lets try 6.0% first since it was the stake weighted average of the previous vote. If it doesnât pass we can try putting forward another proposal at 7.2%.
Why not going straight to 7.2 since it was the option winning the first proposal? Itâs better than nothing, and quess that once this feature is implemented itâs easy to change if needed.
Whatever restrictions are possibly implemented, community should be collecting before - after -metrics to get some information about the influences.
The way the vote for HIP-16 was set up it did not allow the validator to vote their true preference. The single choice vote when there are more than two options often will push an individual to just vote with the masses because the alternative is to throw away their vote on unpopular option that will not win.
I feel like the results of the previous vote where not indicative of validators true preference. In my opinion, the vote should be a multi choice vote (a voter can select more than one option). That will allow us to see a validators true preference and which ever option had the most selections would be selected as the winner.
In the state we are in now, I think we either need a run off election between the two leading options OR another election with better vote design.
I think it is worthwhile to make a vote between the most favorable options. I agree that 4.8% vs. 7.2% vs. abstain is a good choice going forward. Thank you @ONE4All for pointing out the majority of nodes agree on 4.8%. So what do we believe is more important here, number of individual nodes or stake weight?
Side note: I think it would be worthwhile informing the community of this and educate them that their stake is represented via validators; ultimately they drive the governance proposals.
The deadlock may be a symptom of the improvement not being enough to enable decentralization. This has been a major hurdle for the network and needs to be solved ASAP.
The way voting works for now is difficult to get the right option. Mos of us small validators have voted for 4.8% and the big ones have voted for 7.2%, so what does count more stake or numberâŚi see both view point as valid btw
I think we will run into the same problem again if we introduce a poll with many options. It will be hard to get a 2/3 majority unless itâs a yes/no/abstain type of proposal. I put up a proposal for a 6% vote. Others can feel free to put up a proposal with 4.8% or 7.2% in case you donât think 6.0% will pass or if you think 4.8% will get support. We can then go along with the lowest passing threshold.
I meant a poll here in talk and find out whatâs in favour of the Validator DAO Community as we used it before. And then go to a vote on Snapshot. Those first two options would be a yes/no/abstain type of proposal
Thanks for clarifying. I think my problem with doing a poll here is that thereâs no way to verify if the user is a validator. Also the real voting on chain uses stake weight and we donât have a way of conducting stake weight poll in talk.harmony.one
I feel like we are getting dangerously close to changing the rules of the vote based on the outcome. I would really recommend against that as it will set a terrible precedent.
The two options I see are:
Run off of the top two votes (7.2% vs 4.8%)
A confirmation vote for the leading vote ( 7.2% limit - approve or deny)
If these fail that is because we do not have consensus as a network and need to keep discussing until we can reach consensus. We should not look at the results and think of different ways to run the elections to get the results that we want.
As a VDAO Governor I was researching for DAO tools and we spoke earlier about this problem in the Twitter space and I mentioned it could be easy possible that we set up a space on Aragon and have a stake weighted poll there
I donât think 4.8% will pass, and I donât think 7.2% will pass. Neither will garner the support of the larger or smaller validators, respectively
I think taking the average of ~6.0% and voting yes/no/abstain on that is the best compromise. And I think itâs the only option that has a chance of reaching 2/3
And we need this to reach agreement so we can further decentralize the network. This is holding up HIP-18. Inaction is not an option
I agree with this and @ben2k_Stakeridoo option to create a poll. 18 validator nodes voted for 7.2% and 83 nodes voted for 4.8%. The vote we originally agreed upon was for 7.2%, 6.4%, 5.6%, 4.8%; not 6%. The network clearly favors a lower number when looking at individual nodes. What is more important, individual nodes or a stake weight?
Weâll be voting yes to 6% on the basis that this frees up the roadmap and getâs us a step closer to implementing the Harmony whitepaper.
The expectation is that this limit will be configurable, and later votes could adjust this value as the landscape changes.
Weâre currently in favour of a lower limit and will vote for 4.8% (or potentially another number) if that is taken forward to snapshot in a later HIP.
Letâs not make this more complicated than it needs to be.
) and we can go straight to another vote but I encourage some discussion before this to align as best as possible with the communityâŚ