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
(from the original alternative #3) NNS Dapp
(from the original alternative #3) Internet Identity
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.
(adopted) 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.
Thanks @Lorimer and @tiago89 for the suggestion for a simpler process for adding ckERC20 tokens. Here are our considerations:
For the approach to dynamically invoke any function from any canister, it could be risky - for example such canister can be malicious and choose not to reply. It might be possible to not wait for the response, but then failures won’t be propagated back to the proposal.
We could introduce a new dedicated proposal type and topic for update calls only directed to ckERC20 orchestrator, but we believe that creating such a proposal type can be controversial. This would be a new paradigm that NNS making calls to a canister that we generally don’t consider being part of the protocol.
Given the above reasons, we feel it’s best to leave this idea out of the scope for the changes we outlined in this thread.
Hi @jasonzhu, thanks for entertaining the idea. I have a few questions about your feedback just to make sure I’m following.
But we’re just talking about privileged canisters aren’t we, for System Canister Management proposals? If the NNS has a malicious system canister on mainnet then there are bigger problems. Perhaps I’m not following correctly.
Regarding the dedicated proposal topic for ckERC20 (as an alternative to the above suggestion)…
This would be a new paradigm that NNS making calls to a canister that we generally don’t consider being part of the protocol.
But we’re just talking about privileged canisters aren’t we, for System Canister Management proposals?
Just to clarify, in my previous message I was referring to a potential approach of having a proposal type to call any update method on any canister.
On the System part of the “System Canister Management” topic, there is no restriction on what the target canister is. For example, the taggr canister is upgraded in Proposal 116534.
My reasoning is that the bitcoin_* apis are part of the ic system API, and calls to those apis get routed to those 2 canisters. In other words, a part of the system API would be broken if those 2 canisters are not working correctly. I believe the same thing cannot be said about the ETH integration, even though they are still very important to IC.
The actual splitting of the topics should be implemented in a way that affects the voting of those proposal types as little as possible (as opposed to, let’s say, after an NNS governance upgrade proposal, all proposals of topic A gets changed to topic B, which can mess up voting and rewards). A potential approach is to (1) create new proposal types with the new topics while preventing those proposals with new types from being created (2) leave some time (1-2 weeks) to let neurons change following if needed, with some communication (e.g. banners on NNS Dapp) (3) only then, allow new proposal types to be created and make old proposal types obsolete.
A neuron’s followees on the new topic doesn’t inherit the ones on the old ones but will start as empty, although the catch-all following will still work for the new topic, as one might expect.
Thanks @jasonzhu, I see where you’re coming from with the suggestions I’ve put out so far. Thanks for considering them and explaining their limitations. Given the importance of ETH integration canisters (and the huge incentive for an attacker), I still think this is worth tackling.
What would you think about making the WASM (and corresponding hash) in canister management proposals optional? If they’re not provided then the proposal just uses the existing WASM (restarting the canister and applying the config payload).
What would you think about making the WASM (and corresponding hash) in canister management proposals optional? If they’re not provided then the proposal just uses the existing WASM (restarting the canister and applying the config payload).
It does make a lot of sense from the perspective of the proposer and voter. However, it would require one of:
The execution layer allows upgrading without specifying the WASM. This is not currently supported. Honestly, I don’t know whether it’s possible or how difficult it is.
Some other system needs to be the source of truth for what the current WASM is (e.g. NNS Governance), so that it can be used for calling install_code when the WASM isn’t specified in the proposal. There can be multiple ways to get the current WASM, but having another source of truth (other than the target canister itself) for what WASM is currently running sounds problematic.
Overall, I agree with you that it sounds important, but I think most likely it will not be a low-hanging fruit that we can tackle WITHIN this project of refining topics.
Update: a recently executed proposal made it possible to set following on the new topics through calling NNS Governance directly. An upcoming NNS Dapp upgrade proposal will make it possible to set such following through the NNS Dapp.
