Proposal to Permit Time for Reviews of Replica Updates

Governance
1

TL;DR

This is a proposal to help advance decentralization of the NNS by creating a new proposal topic that will permit people to review and vote for replica updates without DFINITY triggering Absolute Majority when they vote on Replica Version Management proposal topics.

Background

Yesterday and the day before yesterday, DFINITY chose to vote on Replica Version Management proposals within 24 hours of creation. Proposal 116135 was a typical replica update that was submitted a few days later than normal. Proposal 116294 was the hotfix that added the NNS root as a controller for the Taggr canister as approved in governance motion proposal 115067. Normally, for this proposal topic DFINITY has an operating discipline to wait until day 3 or 4 before voting since they trigger 99.4 % of the voting power in the NNS due to liquid democracy and default following on All Topics. The exceptions have been when DFINITY determines the proposal to be a Critical Update, which typically gets executed within a few hours as per the policy approved by the NNS in proposal 48792. Neither proposal in the last few days was identified on the forum as a Critical Update and there were people participating in the CodeGov project who were conducting reviews of the proposals at the time they were executed. Our goal is to complete our reviews within 2 days of proposal submission so they are complete prior to when DFINITY elects to vote, but that wasn’t possible on these two proposals.

Clearly as can be seen in the chart below, voting within 24 hours for proposals that are not Critical Updates is an anomaly for DFINITY. The chart shows the actual proposal execution period that has been observed on all Bless Replica Version proposals that have existed since the Replica Version Management proposal topic was first used 158 days ago. DFINITY introduced the Replica Version Management proposal topic in Sept 2022 with proposal 80639 and implemented it 2 months later. The stated objective was to “make it simpler for neurons to vote manually…further decentralizing the vote.” Hence, there is no doubt that the intention of creating this new proposal topic was to enable people to review replica updates.

image
image901Ă—540 19 KB

I think a logical next step to advance decentralization would be to implement a code based mechanism that permits NNS participants sufficient time to conduct reviews of the replica updates before it is executed. The voting period on any proposal is 4 days except when it is extended due to the wait for quiet mechanism. However, the execution of proposals will occur by Absolute Majority the moment it is no longer possible for the opposing party to change the outcome. DFINITY configured all neurons at genesis (as well as the first 14 months after genesis) to follow the DFINITY neuron on the All Topics catch all category. Of course, everyone is able to freely change this default selection. When the Replica Version Management proposal topic was created by DFINITY 6 months ago, all neurons were set to follow the same target they had configured on All Topics. To make a long story short, this default following configuration leads to 99.4 % of total voting power in the NNS voting the moment DFINITY casts their vote, which means that All Topics and Replica Version Management proposals execute by Absolute Majority as soon as DFINITY votes. This is not very decentralized and can be improved with a couple simple changes to proposal topics.

Proposal

  1. Create a new proposal topic called Typical Replica Updates
    a) No default following
    b) Include any proposal Type that DFINITY determines to be a typical update
  2. Rename Replica Version Management to Critical Replica Updates
    a) Keep current following
    b) Include any proposal Type that DFINITY determines to be a critical update

Explanation

These changes do not change any neuron configuration. They only change the proposal topics that exist in the NNS. The Replica Version Management proposal topic already exists with neuron Followee configurations that make sense for Critical Updates. Hence, this proposal will preserve the safety feature that is built in to the NNS that enables DFINITY to quickly respond to critical issues. From a decentralization perspective, the key is to create a new proposal topic for typical replica updates, but do not assign any default following. Hence, when DFINITY votes they will only cast their own voting power plus any voting power from neurons that actively choose to follow them. Since DFINITY owns 22.45 % of total voting power in the NNS, there is a high probability that they will not trigger Absolute Majority on the Typical Replica Update topic. This means that these proposal will likely execute after 4 days no matter when DFINITY chooses to vote and it will give time for other neuron owners to review the replica update and vote independently before the proposal is executed.

Not in Scope

There is no intent for this proposal to define what is considered a Critical Update. The current policy for Critical Updates was approved by the NNS with proposal 48792. DFINITY has broad privilege to decide what is considered a critical update and there is no intent to change that with this proposal.

Terminology Variations

Feel free to recommend alternate terminology if something makes better sense. I’m more interested in the concept than the terminology that is applied.

DFINITY Participation in Deliberation

I would appreciate hearing from folks at DFINITY on this proposal. Would DFINITY be willing to implement this proposal if it passes? Are there details that need to be improved or clarified? Can you think of any downsides? Are there other alternatives that should be considered? @diegop @bjoernek @lara @Manu @bjoern @dominicwilliams

Deliberation Period

I will leave this proposal open for deliberation in the forum for at least a week before submitting it to the NNS. The details may change depending on what comes up during deliberation.

13 Likes
2

I think this is a great idea, with one wrinkle. Since the Typical Replica updates has no default following configuration, would there be enough VP to push proposals across the finish line in the beginning?

1 Like
3

This proposal doesn’t prevent DFINITY from voting. It would just mean they won’t trigger Absolute Majority on typical replica updates.

4

Right, but there will still be a slight transition period during which neurons set up their followers for this topic and DFINITY will not be able to pass anything. Maybe the solution is they go through the emergency route until they can pass via the typical route?

Also, this now means all voters have to go back in and configure followees for yet another neuron topic for each and every one of their neurons. I’m not opposed to this, just know it will have an noticeable effect on the voter participation rate (and many voters will lose” a noticeable amount of icp rewards).

1 Like
5

I don’t understand this comment. Simple Majority only requires 3% of total voting power to Adopt and Dfinity owns 22.45% of total voting power. Hence, when they vote with the voting power they own they will exceed the simple majority threshold requirement. There is no transition period where there is risk of a proposal not passing.

1 Like
6

How many acredited testers(reviewers) have you got at CodeGov and how many hours does one review usually took in average so far ?

2 Likes
7

You’re correct, I understand now. I’m in full support of this proposal then.

1 Like
8

Everyone who has a stake in the NNS is accredited to review and vote on these proposals. Expectations for CodeGov participants is that they have the ability to build the ic replica locally (and verify the hash) and are willing to perform a sanity check on the Release Notes. These activities take about an hour at this stage. I would like to find more reviewers, so if you are interested then please apply. I also would love to see other individuals or organizations spending time reviewing these proposals and voting independently.

2 Likes
9

Ok cool, thanks for the info I saw the DSCV portal and for sure will apply in the near future just to much going on right now with Motoko, that aside I support this proposal also.

1 Like
10

Thank you for sharing this post @wpb
I am currently off for an extended weekend and will come back to you by middle of next week.

3 Likes
11

If I understand correctly this won’t decrease DFINITY’s theoretical capabilities to bless any replica version? In this case, can’t the proposal be simplified to DFINITY waiting for 4 days for non-critical upgrades instead of one day without changing anything else?

1 Like
12

Yes, but the new topic creates a mechanism for enforcing this behavior on behalf of DFINITY or any future contributors to the IC protocol instead of relying on “good intentions” and trust.

Then, the IC community can more easily differentiate normal upgrades vs. security patch fixes and there’s an additional level of accountability.

1 Like
13

I’m saying this is exactly the part that stays unchanged.

14

It sounds like you might be using the word trust in a different context. DFINITY is the major contributor to the IC and this proposal is not intended to jeopardize the trust requirement we have for DFINITY to lead the strategy and implementation of replica updates. What would change with this proposal is how the proposals are executed.

DFINITY recognized and created an opportunity for the community to engage in reviews and independent votes on replica updates over 6 months ago with the “motion to enhance replica version management” in proposal 80639. I have greatly appreciated the fact that DFINITY has use operating discipline to wait until day 3 or 4 to vote on these proposals (as validated in the chart in the OP) and I do hope that continues.

However, I think it makes sense in the spirit of decentralization, which I believe was the purpose of that motion and ensuing community efforts, that we create an environment that is enforced by code where typical updates are not executed the moment DFINITY votes. This proposal would make it highly probable that Typical Replica Updates will be executed by the rules of Simple Majority (end of voting period) instead of the rules of Absolute Majority (immediately).

So to me this proposal is not rooted in a lack of trust in DFINITY as a leader of replica updates. It’s rooted in believing those updates should be implemented by a mechanism that that is more reflective of intentional community consent. To me that means we have to remove the default following on this proposal topic. Default following makes a lot of sense for Critical Replica Updates since they require immediate action, but I see no reason why Typical Replica Updates can’t be implemented after the voting period ends (4 days).

2 Likes
15

Let me first give some context on the two upgrades that were voted in after leaving the proposals up for deliberation for only a single day instead of the usual 3-4 days. The first proposal was a regular update; however, due to technical issues in the CI system, the build was not ready on Friday as usual. To minimize impact on the usual upgrade procedure, DFINITY decided to vote on this proposal after a single day. The second proposal included only the fix for getting Taggr unstuck, and we applied a similar reasoning. In both cases, one could legitimately say that we should have kept the usual 3-4 day window, as there was nothing security critical to the upgrades.

I also explicitly support Wenzel’s goal of improving the decentralization of votes on non-governance/SNS topics. I think it is absolutely vital for the IC to eventually have real decentralized votes on technical proposals.

That said, I do not like the proposal above. The main reason is that it adds complexity (introducing a new topic with different rules) but does not actually change any hard rule, since one can still submit proposals under the “old” topic.

I would prefer focusing the discussion on how we can implement periodic follower confirmation in a way that does not entirely inhibit security fixes. And that should solve the above issue as well.

5 Likes
16

Thanks you for your feedback @bjoern. It is very helpful.

I wasn’t too worried about the fact that one can still submit proposals under the “old” topic because DFINITY makes that decision anyway no matter what we call it…which I think is appropriate at this time.

I thought this proposal would have a side effect that it provides a solution to the flaw with the proposal for periodic confirmation of followees. However, I intentionally didn’t make that the main focus of this proposal because it’s not the driver. I also recognize there could be a change in opinion within DFINITY regarding that previous proposal that has lead to it not being implemented after such a long time. Hence, it didn’t seem necessary to focus on that side effect.

Anyway, I appreciate knowing your thoughts on this proposal. Thank you for sharing. I highly respect your opinion.

1 Like
17

It has been over a week since I first posted this proposal idea. Since it has not generated much traction in deliberation nor any support from DFINITY, I will table the idea for now. There is no point in pursuing something that doesn’t have support. My hope is that DFINITY will voluntarily wait until day 3 or 4 to vote on non-critical Replica Version Management proposals so the community has time to review and vote on these proposals. I appreciate everyone who has participated in the discussion.

3 Likes
18

@wpb, your request was heard. I just spotted one of the trusted neurons internally saying I believe our new policy is that we always wait 3 days to vote in proposals

3 Likes
19

That is great news. Thank you for sharing.

20

And here’s the official announcement:

4 Likes