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.
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.
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.
- 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
- 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
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.
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.
Feel free to recommend alternate terminology if something makes better sense. I’m more interested in the concept than the terminology that is applied.
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
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.