Assessing governance & voting enhancements

Which part makes you sad? Here is the most recent Subnet Update as an example. Proposal executed less than 1 hour after it was submitted…98% of total voting power in the NNS already cast…3 days 18 hours left in the voting period. This is routine business executed quickly and rightly so. Any desire for the public to be able to vote on these types of proposals or review them with capacity to stop them at this stage of the IC just doesn’t make sense.

Whose definition? Where did this definition come from and when did we ratify it prior to proposal 55651?

Never said there was an effort to do this.

I agree, see my earlier statement:

Not sure where this is coming from but ok, i don’t disagree :+1:

This will be up to the community to decide once we’ve achieve a decent size. I am not the end all be all of TFC, nor is @Pwoseidon or @weedpatch2.

What makes me sad is that you want to change the protocol so that there’s almost no chance for any orther organization to push back on these proposals. What if an organization with the power and competency to challenge one of these proposals chooses to do so? Your proposal would give them an extremely small window to build support and almost guarantee Dfinity the deciding vote.

Just because this is the standard today does not mean we should resign to it always being this way. We changed follower settings in order to increase decentralization; yet, we chose not to do the same for non-governance topics. It doesn’t make sense.

What would happen when a bad actor controlling > 3% of the voting power submits a malicious proposal and DFINITY for some reason doesn’t vote on it within that one-hour voting period? Your suggestion depends on a quorum of humans at DFINITY monitoring and voting on proposals 24/7.

I’m in favor of Periodic Confirmation of Neuron Followees, I’m just pointing out a problem with the one-hour voting period idea.

3 Likes

This is no different than today. You can go to the dashboard and open any subnet management proposal and see that they are executed shortly after they are submitted by Absolute Majority.

I agree. When that day comes, adjustments will need to be made. This is why we have a mutable governance system. Change is necessary and the NNS provides that flexibility. My point is that today there is no chance for any other organization to push back on these proposals, so I don’t see the need for the larger voting period window. DFINITY is the deciding vote and there is nothing anyone can do about it today. Nor do I think anyone wants to do anything about it today. It will take time to get to the point where that is relevant.

Would you please clarify further? Are you suggesting follower settings should be adjusted for non-governance topics? That’s what proposal 55651 would do. Do you agree with that mechanism or did you have something else in mind?

This is an excellent point. The idea will need additional consideration because we cannot let that happen.

@Dylan I modified the original comment to 24 hours instead of 1 hour. Take a look and let me know if you still see a gaping issue. I suggested 24 hours since that was the original voting period for all proposals. I would think the question that needs to be considered is if we really need to be able to implement changes to these proposal types faster than 24 hours. If so, then the idea still requires additional consideration. Perhaps there is utility in limiting the neuron IDs that can submit proposal types that are of certain critical nature or maybe there is already a limitation on who can submit that code to GitHub. I think my main point is just that we should consider a much shorter Voting Period for proposals where is is important to consider Reactivity. I don’t think that Voting Period needs to be the same as it is for Governance proposals.

1 Like

I think a 24-hour voting period addresses the concern that I had about bad actors, but then you’re back to the situation where you may have to wait 24 hours to pass important proposals. That’s better than 4+ days, but a lot longer than the current ability to pass these proposals essentially immediately. The ability to pass proposals fast is important. Imagine if some security vulnerability needs to be fixed, and every minute it’s not fixed bad things are happening.

Just thinking out loud, perhaps this concern could be addressed by changing the (proposal 55651) proposed way that the confirmation would work. For example, say that all neuron holders had to confirm their followees once a year before January 1st, but that the NNS wouldn’t actually remove followees from any neurons on January 1st unless (or until) a certain threshold of voting power had confirmed their followees. You would then set that threshold in a way that virtually guarantees the effective voting power of DFINITY with following doesn’t drop below 50%. In other words, a Periodic Confirmation of Neuron Followees would be implemented, but if not enough neuron holders confirmed their followees, nothing would happen. This way the functionality could be implemented without relying on the hope that neuron holders would indeed confirm their followees.

3 Likes

Though I suppose choosing such a threshold could be difficult.

1 Like

I agree 1000%. Also, I always said that dead voter (or many of them), who could be a whale, providing their vote to make a proposal to pass or not is 100% non sense, and is looking really bad for the entitre governance system. Dead voter need to be eliminated from voting, the sooner the better.

Hi @wpb and @Dylan,

I agree that we should focus the discussion on the criterium reactive, as this is currently the main drawback of the proposal on periodic re-confirmation of followees. So essentially, how can we ensure that very urgent fixes can be implemented immediately.

One possible solution (based on a discussion with @Manu) could be to vote on granting hotfix update permission to trusted developers on a temporary basis (e.g. for 2 weeks or a month). This way the urgency of the update would be decoupled from the prior vote.
@Manu: Did I summarise your idea correctly and would you have further points to add?

3 Likes

I like that idea a lot. It probably opens up the opportunity for the public to perform more code review on non critical updates while still enabling critical hot fixes. Seems like a move toward decentralization.

2 Likes

Building off of @Manu’s point, if we’re talking hotfixes/patches, what about a model where there’s ~10 developers that have the privilege to review and approve a hotfix/patch, and that only a certain fraction of them need to respond in order to push out the change? Maybe there’s some sort of Pagerduty integration for these chosen few.

Btw, how is the DFINITY neuron currently managed for pushing out hotfixes? What happens when it’s the middle of the night in Switzerland and an on-call alert goes off that requires an immediate patch fix? A developer submits a code change proposal, but then does someone wake up the person (or people) in charge of the DFINITY neuron?

I can’t imagine that Dom or Jan are the ones pressing the accept/reject button on all of these proposals.

1 Like

I posted this in a different thread but realized it might be helpful to post the suggestion here:

3 Likes

One of them is always at the button. 12 hour shifts.

4 Likes

Is this serious? Just the 2 of them, with only one other person/level of escalation…that sounds rough for sleep!

Don’t they both live in the same time zone?

I believe @borovan was joking. : :upside_down_face:

Phew, good one haha!

Yea I remember this answer by you from awhile back

How do those neurons vote on urgent hotfix proposals (where they need a majority of the 9 to vote for the neuron to vote)? Are they all paged and/or alerted for every single one of these votes?

That’s still a lot of people getting pages :wink:

1 Like

Quite literally, yes. They are all paged and they vote even at very odd hours. I am glad I am not one of them.

3 Likes

Thank you @rusty.scrivens, I think this is a great idea. In effect, it is a little bit similar to what I mentioned above but probably simpler to implement. Let me think about it.

2 Likes

Hi @rusty.scrivens, I suggest that we discuss your idea in the first session of the (to be established) technical working group on governance & tokenomics.

Due to the focus on the SNS work (and holidays) I suggest to have the first session in September (further communication to follow).

4 Likes

You can also look at it as an extra incentive for those people to prioritize stability :grin:

3 Likes