Motion to enhance replica version management

Governance
1

Background

The Internet Computer replica software is constantly being further developed, and the nodes powering the Internet Computer regularly switch to a new version. This happens via two steps:

  • First, a replica version is “blessed”, via a “Bless Replica Version” proposal to the NNS (a recent example is 77589). This adds the replica version to the list of blessed replica versions.
  • Second, a subnet upgrades to the new replica version with a “Update Subnet Replica Version” proposal to the NNS (a recent example is 78517). Such a proposal only works if the replica version has previously been “blessed”.

Problem 1

Currently, replica versions are never removed from the blessed list, and the blessed version list contains more than 100 versions. This poses a small risk: a node that first joins an old subnet may believe (under especially bad networking conditions) that the version that the subnet started out with is still the currently active version, and “upgrade” to the very old version. If this very old version contains a security vulnerability, this creates a security risk.

Problem 2

The NNS uses “topics” to group different proposal types together. Neurons can define following based on the topic. For example, many community neurons choose to vote manually on the topic “Governance” (which contains motion proposals), while following the DFINITY foundation on all other topics.

Currently, the vast majority of proposals (excluding exchange rate proposals) are in topic “Subnet Management”. This topic includes “Bless replica version” proposals, “Update subnet replica version” proposals, and other frequently used proposal types like “Add/remove node to subnet”. This makes it very difficult for a neuron holder to commit to manual voting on this topic: it contains many proposals, and of many different types, each of which you need to inspect and vote on. This may partially explain why the vast majority of neuron holders choose to follow the DFINITY foundation on this topic. This is not desirable, because voting should be as decentralized as possible.

Proposed changes

We propose to make two changes: (1) introduce a new proposal type that removes replica versions from the “blessed” list, and (2) split the NNS proposal topic “Subnet Management” into more fine-grained topics.

Retire replica versions (addresses problem 1)

We propose to add a new proposal type called “Retire replica versions” that performs the opposite of “Bless replica version”. More precisely, such a proposal can specify a list of outdated replica versions, and if the proposal is adopted, all outdated versions will be removed from the blessed versions list. The proposal will fail if:

  • The payload is empty
  • The payload contains a replica version that is currently not blessed
  • The payload contains a replica version that is currently in use

With this new proposal type, a node will never use a replica version that is not blessed, meaning that vulnerabilities in old versions that are no longer blessed cannot pose a security risk anymore.

New NNS proposal topics (addresses problem 2)

To make it simpler for neurons to vote manually on certain topics, we propose to split the “Subnet management” topic into multiple topics. More precisely, we propose to add two new topics:

  • “Replica Version Management”: This topic would contain the existing proposal type “Bless replica version” and the new type “Retire replica versions”.
  • “Subnet Replica Version Management”. This topic would contain only proposal type “Update Subnet Replica Version”.

All other proposal types that are currently in topic “Subnet management” will remain in topic “Subnet management”.

Some neurons may have defined following for all the individual specific topics but not the catch-all “all topics except governance”. With the introduction of these new topics, such neurons would not have any following defined for the new topics, and risk missing out on voting rewards. To avoid this, we propose that with the introduction of the new topics, the followees for topic “Subnet management” are copied over to the new topics “Replica Version Management” and “Subnet Replica Version”. Neuron holders can of course manually adjust their following on these topics after that.

Overall, more fine-grained topics allow neurons to specialize on some topics and manually vote on those topics. For example, with these changes we could imagine that some neurons will decide to manually vote on “Replica Version Management”. Other neurons can now follow different experts on different topics, further decentralizing the vote.

Next steps

Please let us know what you think! We plan on submitting this as a motion proposal in a week.

13 Likes
2

Thanks for this explanation @Manu. It seems like a good idea that is a step in the direction of further decentralization of the IC.

I didn’t see it explicitly stated (perhaps I missed it), but I assume the new proposal topics would be included in the All Topics Except Governance catch all category. That would make sense because I’m not aware of anyone who markets themselves as an expert on these topics. However, when experts do emerge in the community some day, what will cause people to choose to follow them instead of continuing to follow DFINITY on these topics via the All Topics category? I’m sure incentives will be needed to motivate people to become experts, but are there going to be plans to incentivize people to change their following as well?

I’m curious if there are any ideas that have emerged? Decentralization of Governance was quite effective and I’m interested in knowing if other topics will follow the same path.

3 Likes
3

I didn’t see it explicitly stated (perhaps I missed it), but I assume the new proposal topics would be included in the All Topics Except Governance catch all category.

Yes, these new topics should be included in “all topics except governance”.

when experts do emerge in the community some day, what will cause people to choose to follow them instead of continuing to follow DFINITY on these topics via the All Topics category?

This is a great question. I see this proposal as step 1, without this we cannot hope that anybody votes on eg bless replica version proposals. How we further incentivize people to manually vote and follow other voters than DFINITY is in my view a second step. But I do think that there are already a lot of people that put effort into participating in governance just for the good for the ecosystem and without any direct compensation, so if we’re optimistic perhaps step 1 will already help decentralize the vote on some of these topics. If not, then we could consider other strategies, such as incentivizing manual voting, or doing something similar to what was done for the governance topic.

1 Like
4

I have a couple related questions:

  • Why not automatically retire a replica version as soon as no subnet uses it anymore? Is it so rolling back can be done quickly in the event of a security vulnerability?
  • Does it make sense to even have manual proposals to update subnets with a new blessed version? Is there no way to make this rollout automatic following industry-standard practices of deployment? The vast majority of users would not be interested in these proposals, I suspect. Once I vote to bless a replica version, I would certainly want it deployed without delay.
1 Like
5

Hey @jzxchiang!

1: I think it would make sense if the NNS has a bit more control. I imagine that most of the time a new version is blessed and the oldest blessed version is retired, but if for any reason a new replica version is bad, i think it makes sense to have the ability to retire the new version while keeping the older ones.

2: I agree, I think at some point the NNS should just do this by itself, but we’re not quite there yet. So for the time being i think its better to put it as a separate topic, but i indeed expect most voters to follow on this topic.

3 Likes
6

The proposal is now submitted: 80639

2 Likes
7

Ngl, I saw the title of this on the NNS proposal bot and thought it was another fake proposal. I was very glad to see that’s not the case. Will definitely vote to adopt.

I appreciate y’all taking the time to address this.

1 Like
8

Reviewed by 8yeargangDAO

1 Like
9

Hi everybody! I’m happy to share that the changes related to this motion proposal are implemented and active. Some examples:

  • 91004, a regular subnet upgrade, is now listed as “subnet replica version management”, one of the new topics.
  • 90485, which elects a new replica version, is now in the new topic “replica version management”
  • 90481 shows that the new “retire replica version” proposal has been implemented and all the old replica versions have been cleaned up.

Hope some of you will consider manually voting on the “replica version management” topic!

1 Like