Effortless SNS Updates

Governance SNS Project Governance
1

TLDR; We propose a better process for SNS upgrades. (1) Each SNS stores a target version that can be changed via a new type of AdvanceSnsTargetVersion proposals. (2) The SNS is responsible for performing upgrades in the background, until the target version is reached. (3) Users can monitor and audit upgrades of their SNS via a single new endpoint.


Dear SNS communities,

Our team is working on an exciting new feature that will simplify keeping the SNS framework canisters up to date.

Background

The SNS framework consists of multiple canisters (Governance, Ledger, Swap, etc.) that are regularly upgraded with new features and security enhancements. SNS upgrades come in the form of canister WASMs that are published (via NNS proposals) to the SNS-W canister. Each SNS is responsible for pulling the next available upgrade from SNS-W (via an SNS proposal called UpgradeSnsToNextVersion).

What’s currently the problem?

Currently, to upgrade multiple SNS canisters, the SNS community needs to approve each SNS upgrade by an individual UpgradeSnsToNextVersion proposal. While the SNS framework consists of multiple canisters (Governance, Ledger, Swap, etc.), a single proposal UpgradeSnsToNextVersion upgrades just one SNS canister. Since SNS canisters are always upgraded in order, upgrading the whole SNS to the latest version might require multiple proposals.

A lot of manual work is required from those submitting and voting on upgrade proposals, especially since adopting upgrade proposals should be timed to avoid races, i.e., concurrent proposal failures, and the need to re-submit more upgrade proposals. Simply put, it is hard to understand what voters vote on.

We propose to simplify the process by allowing SNS communities to send just one proposal to convey the intent to upgrade their SNS to the newest available version. To this end, we propose to introduce a new SNS proposal type called AdvanceSnsTargetVersion. Submitting such proposals will be trivial: similarly to the current UpgradeSnsToNextVersion proposals, no input arguments are needed. If such a proposal is adopted, the SNS will update its target, i.e., the version this SNS should eventually reach (as opposed to actually performing any canister upgrades). The SNS will then automatically perform the required upgrades of its SNS canisters in the background, ensuring upgrades are done in the right order, until the version of this SNS reaches its target version. This background process would not require any additional proposals or manual work. Users will be able to monitor and audit this process using a single new SNS governance endpoint.

Example scenario

  1. The SNS receives the newest available SNS version (v3) from SNS-W.

  2. Initial information from the upgrade journal:

    • Current version is v1 (this is the currently running version of this SNS).
    • Target version is also v1 (this is the version the SNS has committed to reach).
    • Newest version is v3 (i.e., two upgrades are possible from the p.o.v. of SNS-W, where the SNS upgrades are published).

  3. Community submits an AdvanceTargetVersion proposal.

    • The SNS sets the new target to the newest version, v3 (at the time of proposal submission).

  4. The community adopts the AdvanceTargetVersion proposal. It is then executed, updating the target to v3.

  5. The SNS performs upgrades via background tasks, until the target is reached.

  6. Users monitor the progress via the upgrade journal.

sns-upgrade.png739×1149 79 KB

Next steps

We plan to propose the SNS governance wasm that enables AdvanceSnsTargetVersion proposals as part of the normal release process.

If this feature is adopted by the NNS community and when SNS projects receive this new wasm, the legacy proposal type UpgradeSnsToNextVersion will still work as before for some time. This ensures that a battle tested upgrade mechanism is in place for upgrading SNSs (in the unlikely event that of a bug in AdvanceSnsTargetVersion that will not be caught in code reviews and testing) and that integrations have some time to update if needed. Eventually, we will propose to obsolete UpgradeSnsToNextVersion proposals.

If you have any questions or suggestions in the context of this design proposal, please let us know in this thread.

10 Likes
2

Cool!!
We had to manually perform 28 upgrade proposals over a few hours.

1 Like
3

Awesome feature. Can there be an optional parameter in the new proposal type: opt target, that lets the proposal specify the target version instead of using newest available version?

1 Like
4

Can there be an optional parameter in the new proposal type: opt target, that lets the proposal specify the target version instead of using newest available version?

Yes, that’s the plan. Glad you hear the proposal sounds useful to you!

5

As someone currently exploring how to upgrade an SNS, this sounds like exactly the improvement we need! I have two questions:

  • Is there a target release date?
  • Could this new method assist in upgrading an older SNS, or will I still need to submit multiple proposals one last time to reach the WASM implementation for that method, if that applies to my situation?
1 Like
6

Great questions, @Seb.

  1. Improving SNS upgrades is a high priority for the team. There is no target release date yet, but I’m going to update this thread when I know more.
  2. If the community adopts this feature, the corresponding SNS Governance WASM would be published in the SNS-W canister. Then, each SNS would first need to be upgraded using the legacy feature (i.e., adopt a sufficient number of UpgradeSnsToNextVersion proposals), and only then would the new feature (AdvanceSnsTargetVersion) become available. In other words, there would be one last SNS upgrade marathon.
1 Like
7

Any efficiency gains are, of course, welcome, especially when that efficiency is gained in work that does not directly impact the user (kinda).

1 Like