Hi all,
I am excited to report that we are working on implementing the last few pieces of this feature that are needed to get the SNSs going!
As we are implementing some of the details, we notice that we can slightly simplify the design compared to what we originally proposed above thanks to some improvements that happened in the meantime. We therefore wanted to share these updates with you.
Blessed version in one SNS-W on the NNS subnet.
In the original design, we proposed to hold the SNS canisters’ wasms in an SNS wasms modules canister (SNS-W) that is hosted on each SNS subnet and to hold the blessed SNS versions in the NNS registry. For upgrading the SNS to a new version, one would need to first update the registry with a new blessed version and then add the wasm of this version to all SNS-W canisters by an ingress message (and repeat this on all SNS subnets if there are multiple at some point) .
The main reason for this was that we thought that the SNS canister wasms were too big to be sent in cross-net messages from the NNS to the SNS.
In the meantime, we were able to reduce the wasms of the SNS canisters with some improvements. Therefore, we propose to now have one SNS-W canister on the NNS subnet rather than many of them accross SNS subnets. This allows that NNS proposals that bless new SNS versions also directly add the new wasm in SNS-W, without further user interaction. Also, as we only have one SNS-W canister, this simplifies synchronization across all SNS subnets (once there is the need for more than one).
As the SNS-W canister is already on the NNS subnet, we also propose to record the blessed SNSs in this canister rather than in the registry. This nicely separates concerns and allows to hold all the information relevant for SNSs in the same canister.
The type of the SNS subnet
Originally, we proposed that the SNS subnet will be a new type of subnet. We argued that this is needed as we needed some bounds that are the same as on a system subnet but other properties from an application subnet, for example that cycles must be paid for canisters.
Again, in the meantime we made some improvements that eliminated the need for special bounds. Therefore, we now propose that the SNS is of type “application subnet”. This means that it is like a regular subnet with the only difference that only blessed SNSs can be deployed on it.
This is beneficial, especially as the SNS code should anyways work on other application subnets to allow anyone to self-deploy an SNS.
SNS upgrade triggering
Finally, the original idea was that SNSs upgrade themselves, by checking on every heartbeat if there are new blessed versions in SNS-W. This would not only cause a lot of cross-net traffic but it would also take away some power from the SNS communities.
Therefore, we now suggest that the SNS communities decide, with SNS proposals, when they want to upgrade to the next blessed SNS version. The SNSs can still only be upgraded according to the blessed deployment path, which also means that the SNS communities don’t have to be concerned with too much maintanance burden, but the SNS communities can decide at which moment they would like the upgrade.
We hope all these small improvements make sense to you and are happy to answer any questions that you might have!