SNS deployment and upgrades | design proposal

Hi @lara , thank you so much for this excellent summary! I’m looking forward to seeing what people bring to this discussion.

4 Likes

Just want to confirm, each SNS will be capable of controlling multiple canisters correct? I imagine that the root canister will be capable of becoming the controller for as many canisters as desired. Then the governance canister could receive proposals that upgrade any canister which is controlled by the root canister. Correct?

And about token distribution by the ledger canister, I’m hoping there will be support for different supply and minting schemes. For example, in a dapp I’m envisioning there will not be a fixed supply, and the SNS will need to be able to mint tokens based on specific user actions. There will also need to be burning.

6 Likes

Will there be the option to convert an SNS on an application subnet to an SNS on the SNS subnet and vice versa?

I can imagine a scenario where an SNS starts off running well with the default code and configuration capabilities, and then the community deciding that they want to venture off with some experiments. And then I can imagine those experiments being upstreamed into the blessed SNS code, and thus that SNS might want to convert back to the SNS subnet.

1 Like

@lara are there any plans to generalize the voting options to allow them to be customizable?

The options we have for proposals in the NNS today could be represented as the sum type Adopt | Reject but I can anticipate wanting to make proposals with something different.

For questions that only need one answer like “How should we refer to Bitcoin on the IC?” we could use something like ckBTC | icBTC | Other Text

It also works when asking questions like, “In which order should we work on things?”. Here we could use Feature1 | Feature2 | Feature3 | Feature4 | Other Text

1 Like

Every time I read one of these proposals, I get this strange itch to purchase and stake more ICP… can’t explain it.

11 Likes

I just went over the design—I think it’s sensible. The “alternatives considered” section was especially illuminating.

A couple of questions:

  1. This design proposes two paths to deploy/upgrade a SNS: “system-deployed” and “self-deployed”. Am I correct in concluding that the whole concept of a blessed deployment is only necessary because we want to support self-deployed SNSs, and that if we hypothetically only supported “system-deployed” SNS then we wouldn’t need a blessed registry (or even SNS wasm module canisters) at all? For example, the NNS doesn’t have the concept of blessed deployments, presumably because there’s only one canonical NNS deployment at any time (in contrast to SNS, where there could be multiple SNSs, some system-deployed, some self-deployed, each potentially running a different version).

  2. Why is a SNS governance canister a controller of a SNS root canister? On the NNS, I believe the only controller of the NNS root canister is the NNS lifeline canister. The NNS governance canister is still able to tell the root canister to upgrade canisters without being its controller, I thought.

As we absolutely want to avoid that we cannot upgrade the NNS canisters anymore, we propose to avoid any control chain from the NNS to the SNS canisters as the latter necessarily need to call out to dapp canisters on less secure application subnets.

  1. I don’t see any control chain from the NNS to SNS canisters here in this design. The NNS can bless new SNS deployments by adding new wasm hashes to the registry canister, but a separate client will then upload the actual canister wasm modules to the SNS wasm module canister. Or were you planning for that client to be the NNS itself upon proposal adoption?

  2. When will the SNS ledger canister design be made available? That was actually listed as the first stage here. My guess is that the ledger canister design will be the most controversial, and will probably need the most time to discuss.

Thanks for sharing!

1 Like

Hi @lastmjs, thanks for the questions.

each SNS will be capable of controlling multiple canisters correct?

Correct. Additional canisters can also be “added”, i.e., set to also be controlled by the SNS, but just setting their controller to the SNS root too.

And about token distribution by the ledger canister

The current thinking is that in the MVP, i.e., the very first version of the SNS, there will be no voting rewards and no minting / burning. I agree with you that this should be made flexible (this is why it should be thought through and we suggest to rather do it thoroughly in a follow up than just introduce a default that people might not want now). If you think this is something that is needed urgently, it would be good to understand so that we can take this into account for prioritising next features.

2 Likes

It is not intended that this is possible, at least in the first version.

Two concerns that I see with allows this:

  1. I would say it is hard to define good criteria for what an SNS needs to satisfy to be allowed to “go back on the blessed track”. Any intermediate updates that did not follow the blessed upgrade path might have introduced some inconsistencies or bugs, so it might be problematic to put those in the same category (regard “as secure / as well tested”) as SNSs that always followed the well-tested path.
  2. Currently the vision is that on the SNS subnet there are only SNSs that follow the automatic upgrades, i.e., follow the blessed upgrade path. This ensures that there are no canisters on this subnet that have (known) bugs for too long, as they all upgrade regularly. Also, with this we can ensure that all canisters “follow the same rules”, e.g., don’t use up too much memory etc. Having canisters on this subnet that divert from this can be a security risk. One could say that one could nevertheless allow SNSs to switch between the self-upgrade and automated upgrade version but that they have to be moved to a new subnet for this. This however might be quite some effort.
2 Likes

Hi @paulyoung , thanks for the question!

For the first version, we envision yes / no votes as in the NNS.

Certainly, we can think about other voting schemes in the future, as the SNSs will continuously be evolved like other canisters on the IC!

I think when introducing the possibility for new voting schemes, there are a few things that we have to consider carefully. The following come to mind spontaneously:

  • we have to define precisely what the different voting schemes mean. I.e., in your example “How should we refer to Bitcoin”, would each voter only have one vote? Or can one assign weights to each possible answer?
  • we might have to bound the number of possible answers
  • we would have to think about how following would work for these new voting schemes (or maybe just say that following only kicks in for the yes / no votes?)
  • once we have a frontend, we would have to think about how we can distinguish these types of proposals from the yes / no ones so that we can have user friendly interfaces for reading and voting on such proposals.
3 Likes

Thanks for reviewing the design so carefully.

Let me try to answer your questions:

  1. Good question. Let me answer the questions regarding whether we need the blessed deployments and the SNS was module canister separately:
    a) I think even if we only had system-deployed SNSs, there are some advantages to bless the deployments. I think the main reason for this is that in contrast to the NNS deployment, there are multiple SNSs. So it could for example be that a new version is blessed, that some SNSs auto-upgrade, but that the upgrade fails for some other SNSs (for whatever reason). Having the blessed deployments, the SNSs where something went wrong can then e.g., “try again” or we can bless alternative paths to help them get back on the “blessed path”. I agree though that there might be alternatives without this, but I like that it also has the extra advantage of making the blessed path available for those who want to self-deploy.
    b) you also ask “… we hypothetically only supported “system-deployed” SNS then we wouldn’t need a blessed registry (or even SNS wasm module canisters) at all”. I would say for the SNS wasm module canister it is the opposite. If we only supported the self-deployment, I think we would not need it, as anyone on such an SNS would build the new canister wasm and include it in a proposal to upgrade the SNS (i.e., include it in an ingress message). We only have the canister for the system-upgrades: there, we don’t want a separate ingress message for each SNS that is upgraded, we want things to be as automatic as possible. Therefore, we put the canister wasms once in this new canister and the SNSs can then just “take” the version from there.

  2. This is correct. Especially, “The NNS governance canister is still able to tell the root canister to upgrade canisters without being its controller” is also correct. The reason for governance to be root’s controller is not for upgrades of other canisters but in case the root canister has to be upgraded itself. Then, we need a canister that can stop root, install the new canister code, and restart root. You are right that on the NNS we have the lifeline canister for this (adding a little more independence, e.g., the lifeline is also written in motoko). We felt that this extra indirection is not needed on the SNS and that the governance canister could just take on this job of upgrading root. Especially, once could say that if something goes terribly wrong with the NNS this is still worse that if something goes wrong with the SNS as in the latter case we might still use the NNS to recover the SNS subnet.

  3. “I don’t see any control chain from the NNS to SNS canisters here in this design.” Right, I agree that this should be the case. The “we absolutely want to avoid…” is part of the reason why we did not choose the alternative of having the SNS wasm module canister control the SNSs, as with this alternative this requirement would not be met. So to be clear: yes, in the current design there should not be any control chain from the NNS to the SNS canisters. Do you have a suggestion how I can make this clearer in the explanation of the last alternative?

  4. The vision here is to generalise the NNS ledger canister so that it can be used with other kinds of tokens and then use this for the first version of the SNS. This is already being implemented atm. I am not sure where the changes will be presented, but can ask internally.

2 Likes

Eventually this might be nice but I don’t think it’s a high priority, thanks for the explanation

1 Like

So how will the initial supply be created? And where will it go? And it will have to be fixed and all created right at the beginning?

I would think that whoever deploys an SNS can choose the initial accounts on the governance canister and on the ledger.
Thus, they could choose how many tokens are initially owned by which account on the ledger.
This will both define the initial supply and where these tokens are.
I could imagine that an SNS could e.g., have some tokens in the account that is owned by the SNS governance canister or the dapp canister, which can then be distributed as rewards or used for other means, decided by SNS proposals.

But I can imagine some use cases for which one might want minting / burning from the start. So in these cases, I guess the communities can either choose to add this functionality themselves (and got the self-deployment path) or to wait a bit until new SNS features are also available.

2 Likes

Minting and burning are crucial to the plans I have for the SNS. Locking into a fixed supply right away is problematic for me. I could possibly work with a fixed supply and allow the SNS to give our tokens from that fixed supply, but not elegant.

I don’t know what other people are planning.

3 Likes

I’d also be interested in some clarification around fixed token supplies. I suppose people who aren’t expecting minting and burning activity may be satisfied with this (I’d be interested in hearing about anyones plans that don’t require these mechanisms btw), but I’d prefer to at least have the option - early on - for a variable token supply.

3 Likes

Thanks, this is useful feedback.
Are you able to elaborate a bit on what you would need from minting / burning (just in case you want to share)?

I.e., would you just require some fixed operation (such as rewards in the NNS) that can mint, or are you looking for something like a method “mint X tokens now” that can be called by the governance canister, or even something that just automatically mints a certain number of tokens per time period to some account ?

2 Likes

Thanks for this feedback!

I think at the moment there is not much more clarification that I can provide, rather than stating that this is probably not feasible for the initial version of SNS governance canister that is also discussed here.

But as already stated in my other answers, it is valuable to get the feedback that there is some need for this, so that we can take this into account when prioritising next steps.
Also, in case you have particular use cases in mind for minting / burning, I would be happy to learn those!

1 Like

What I have in mind is the governance canister being able to mint/burn anytime at will. This capability will be used to issue tokens when users have performed certain actions, and those tokens will be minted and added to the supply in real time. Other user actions will cause tokens to be burned, removing them from the supply in real time.

I also think it would be valuable to have a “mint X token now” governance method, so that proposals can be made to pay out ad hoc.

The projects I have in mind are probably all going to have a variable supply, minting and burning programmatically based on user actions and proposals.

4 Likes

Thanks for clarifying for 1 and 2. I think we’re basically on the same page now.

The “we absolutely want to avoid…” is part of the reason why we did not choose the alternative of having the SNS wasm module canister control the SNSs, as with this alternative this requirement would not be met.

I think the confusion lies when you say that “with this alternative this requirement would not be met”.

Let’s say the SNS wasm module canister controls the SNS canisters. How does the NNS control the SNS wasm module canister? Is it when a new deployment is blessed? For example, when a blessed deployment proposal is adopted, the NNS will not only update the hashes in the registry canister but also upload the actual wasm modules to the SNS wasm module canister (on each SNS subnet)?

  1. The vision here is to generalise the NNS ledger canister so that it can be used with other kinds of tokens and then use this for the first version of the SNS. This is already being implemented atm. I am not sure where the changes will be presented, but can ask internally.

Oh interesting, I had assumed you would share the ledger design proposal on the forum, like you have done with the SNS governance canister and the deployment/upgrades in this post. In my mind, the ledger design proposal might be the most controversial, not the least.

1 Like

Also, +1 on minting & burning tokens.

I.e., would you just require some fixed operation (such as rewards in the NNS) that can mint, or are you looking for something like a method “mint X tokens now” that can be called by the governance canister, or even something that just automatically mints a certain number of tokens per time period to some account ?

I think both are valuable. In fact, the heartbeat “cronjob” feature of the IC is pretty unique and could lead to interesting tokenomics.

At least for me, I’d like a variable token supply mostly for token rewards. The alternative is a fixed token supply, where token rewards (e.g. for posting valuable content on a social dapp) are provided by a treasury account. I think that’s much more limiting and even risky, as you can’t predict how many users and thus rewards your dapp will have to give out. With a variable token supply, you could vary inflation based on user activity, time, etc.

Just like NNS rewards, I expect a variable token supply to be more useful for most dapps. After all, it’s a generalization of a fixed token supply.

or are you looking for something like a method “mint X tokens now” that can be called by the governance canister

I think this is an interesting question.

Let’s say a dapp wants to algorithmically reward a user with X tokens for something they’ve done. Which approach is better?

  1. The SNS ledger canister exposes a “mint token” method that only the dapp canister can call. (The governance canister wouldn’t call it because the tokens are minted as a result of some business logic algorithm, not a governance proposal.) The dapp canister then calls that method, which mints X tokens and directly deposits the tokens into the specified user’s account.

  2. The SNS ledger canister exposes no custom method, and instead algorithmically mints tokens, depositing them into the account of the dapp canister (i.e. the reward pool or “treasury”). The dapp canister can then choose to transfer X of the newly minted tokens to the user.

Approach 1 is less safe, as the dapp canister could get hacked and then mint a bunch of tokens into the account of the hacker by calling the “mint token” method.

Approach 2 is less flexible, as the SNS ledger canister now needs to implement the algorithm to decide which users get how many tokens. What if that algorithm needs to be updated? Upgrading the ledger canister is possible via SNS governance proposals (the same way the dapp canister would be upgraded), but it’s arguably more risky to upgrade a highly sensitive ledger canister than a dapp canister.

What do you think? I’m not sure which is better.

2 Likes