Querying the WASM module from a canister snapshot?

I’m implementing the Canister snapshots API in order to facilitate safer delivery of upgrades to the various Personal DAOs deployed to the internet computer.

The snapshot functionality has the potential to streamline the creation of the “Wapps” or “Wallet Apps” that @dominicwilliams has been such a proponent of. To do so, the snapshot functionality would need to be extended to include one feature.

currently, snapshots can only be taken, loaded, and deleted. Is it possible to make it so the wasm module stored within a snapshot can be queried by the same actor(s) authorized to take, load, list and delete that snapshot?

The addition of this feature would allow for ease of propagation of updates across multiple replicas of a single application.

1 Like

Can you be a bit more explicit about what you want to achieve? Canister controllers can take and load snapshots, but that still means that they will load the snapshot into the canister where the snapshot was originally taken, it does not allow moving state from one canister to another.

If you want to apply the same wasm module update to different canisters (but not the data), then what exactly is the relation to snapshots?

1 Like

My goal is to be able to query a canister’s wasm module so that I can retrieve it and programmatically install that wasm module to other canisters.

I suppose the functionality I’m looking for doesn’t have to bare any relation to the canister snapshot functionality. I just imagined that since the canister snapshot functionality already captures the wasm module of a canister that it may be easier to add the ability to query the wasm module to the snapshot function.

Nevertheless, the feature i need is the ability to query wasm modules. That’s what’s most important

Well, I guess the difference is that if it were integrated with the canister snapshot feature, the expected semantics would be that one retrieves the wasm module in that snapshot, whereas outside of the module one may expect to get the wasm module that is currently installed.

Note that the hash of the wasm module is already exposed through the canister_info API method and the subnet state tree. So if you expose the canister module in some other way – such as on the application layer – then verification of integrity can be achieved easily. You can also use the canister’s chunk store to store the wasm module, including installation on other canisters by specifying a store_canister in when installing the module.

1 Like

A further alternative to using a canister’s chunk store is to use an asset canister for storing and distributing a canister module.

The trade-offs between a canister’s chunk store and an asset canister are as follows:

  • a canister’s chunk store can only be used by the canister’s controllers to deploy canisters on the same subnet
  • a canister’s chunk store can be used to deploy canisters via a single inter-canister call (e.g., in Rust)
  • an asset canister can be used by anyone to deploy canisters on any subnet
  • deploying canisters with modules fetched from an asset canister is more complex and requires multiple inter-canister calls (see, e.g., Orbit)
2 Likes