We propose to break down the existing “System Canister Management” NNS topic into 4 different topics, to make it easier for voting neurons to commit to voting on all proposals under a topic.
Goal
Facilitate the emergence of expert neurons on different aspects of the protocol.
Problem
Today, if a neuron owner wants to get rewards by following another neuron on a topic, the followee has to vote on all proposals under a certain topic.
On the other hand, under the “System Canister Management” topic, 27 different canisters have been upgraded with 270 proposals over the last 12 months (plus 45 proposals published to SNS Wasm). It is very difficult for anyone to be able to build enough knowledge on all those canisters and meaningfully review all of those proposals in terms of technical accuracy.
Proposed Solution
We propose to break down the System Canister Management topic into 4 separate ones (with proposal count in the last 12 months):
Upgrades of other canisters that are under NNS control
Includes all the ck*** canisters
Alternatives Considered
SNS Aggregator can be categorized to the Protocol Dapps Management because its main client is NNS Dapps, and they are in the same repository. The main consideration of putting it under the SNS category is their domain proximity.
ICP Ledger Suite can be its own dedicated topic. The main consideration of not doing that is that the volume of the proposals is low (8 upgrades in the last 12 months), and we generally try to avoid having too many topics.
Do not create a “Protocol Dapps Management” topic, but instead let II and NNS Dapp fall into the catch-all topic, since the protocol can still function without them. The main reason to have this separate topic is that they run within a system subnet.
Other Related Work
Deprecate Existing Topics
We also propose to deprecate 2 existing topics:
Exchange rate proposals: it’s no longer needed because the exchange rate canister automates the process.
Node provider rewards: it’s no longer needed as it has been automated by periodic tasks in NNS Governance.
Next Steps
Get feedback from the community
If no concerns, the changes will be proposed as part of the normal NNS release process
This is a welcome change for the CodeGov team. It is a challenge to review all System Canister Management proposals since it ranges from 2 - 15 per week on any weekday. It will become more manageable to form different teams that can each focus on the new topics without being too overwhelmed with the volume of proposals. Thank you for proposing this change.
This idea sounds great. Given that you’re planning on shaking up the ‘System Canister Management’ proposal topic anyway, in addition to deprecating other topics and associated NNS functions, I’d love to see the addition of a new NNS function to support smoother ‘System Canister Management’ proposals (specifically proposals that are intended to only update canister config, as opposed to also updating the WASM). A single new NNS function that dynamically invokes an update function (specified by the proposal) on a system canister (specified by the proposal) would be useful in a range of use cases. This would minimise the moving parts in some System Canister Management proposals, providing:
a simpler proposal process
a simpler review process
a smaller attack surface
At least these first two points seem to be very well aligned with the intentions that have already been outlined above (the third is a bonus).
This was well expected since it first got mentioned. We have been tracking all SCM proposals in a spreadsheet and grouping them by Type like NNS Canister Upgrade, Bless New SNS Deployment, Set Bitcoin Config and so on with the canister Id’s and names. I’d be inclined to go for Alternative #3 since there are only the two, the rest makes perfect sense to me.
I would also go for alternative 3. Don’t see much difference between “Protocol Dapps Management” and “Application Canister Management”, even the name is overlapping
I do see a big difference though on ck*** canisters and the rest. One thing is to review code and having technical / domain expertise, and another very different skill is just a config change / addition, that many ck*** proposals will be.
Lorimer has expressed concerns and a desire for it to be much simpler and also easier for any IC Token Holder to manifest it’s desire. It’s more of a “governance” topic than a “technical” topic (the ck*** addition).
Right now I see two best ways of solving it:
to request a Motion proposal to pre-approve the creation of a ck*** coin, and then the passing of the ck*** upgrade proposal on the “Application Canister Management” is just a technical formality/checking.
Or perhaps, a way to ensure this will not spam the “Motion” topic and have a direct “approval → consequence” flow, it should have it’s own topic with specific inputs that make it easy/safe for all.
Just some food for thoughts. Thanks for the attention.
I see it the same way as @ZackDS and @tiago89 and prefer alternative 3, because the difference between “Protocol Dapps Management” and “Application Canister Management” seems unclear.
