What would you think about making the WASM (and corresponding hash) in canister management proposals optional? If they’re not provided then the proposal just uses the existing WASM (restarting the canister and applying the config payload).
It does make a lot of sense from the perspective of the proposer and voter. However, it would require one of:
- The execution layer allows upgrading without specifying the WASM. This is not currently supported. Honestly, I don’t know whether it’s possible or how difficult it is.
- Some other system needs to be the source of truth for what the current WASM is (e.g. NNS Governance), so that it can be used for calling
install_codewhen the WASM isn’t specified in the proposal. There can be multiple ways to get the current WASM, but having another source of truth (other than the target canister itself) for what WASM is currently running sounds problematic.
Overall, I agree with you that it sounds important, but I think most likely it will not be a low-hanging fruit that we can tackle WITHIN this project of refining topics.