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”.
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.
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.
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.
Please let us know what you think! We plan on submitting this as a motion proposal in a week.