I just went over the design—I think it’s sensible. The “alternatives considered” section was especially illuminating.
A couple of questions:
-
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).
-
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.
-
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?
-
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!