Allow (optional) upgradeable contracts

[ethanfrey]

Requested by @aaronc

"I would like to add the ability to upgrade the code behind a contract. This would simply be adding a maintainer sdk.Address on the contract. It would also be nice if this included support for a migrate function exported from the contract. With this contracts could be self-contained modules maintained by something other than validator governance. One use case is that we would like to have a contract for issuing a credit from claims. The maintainer would be the credit designer which is likely some trusted third party or a DAO. Being able to upgrade prevents ethereum-like smart contract failure cases"

[ethanfrey]

Ethan:

I have mixed feelings about upgrading contracts, as that does violate the fundamental premise of trustless, immutible contracts.

This is one discussion of the issue and some mitigating factors (controlled by a vote, opt-in upgrade): https://medium.com/coinmonks/updatable-smart-contracts-eliminating-need-for-trust-2e1925fc6d17

And here a discussion of some of the technical issues in Ethereum (most will not affect CosmWasm, but good to use them as a checklist): https://medium.com/clearmatics/upgrading-smart-contracts-c9fb144eceb7

I do see the strong desire for such contracts in the ethereum community and agree that providing some canonical way to accomplish this with as many checks as possible would be good before people try to design "hacks" like the delegatecall proxy in ethereum.

I also think the idea of contract-level migrations is also quite nice, when such an upgrade occurs. Again, all of this requires a very secure contract owner.

[4meta5]

I support this feature. It would be nice to define upgrade requirements with higher coordination thresholds than most common operations within the contract.

The first example of updatable contracts could just define a set of parameters that can be tweaked if a large enough portion of the defined stakeholder set signals interest in adjusting those parameters.

Rather than freezing up over whether the entire contract should be updatable, it would be better to define specific examples for which some part of the contract can change. I don't think this is actually any different than a smart contract which adjusts state according to stakeholder signalling and then uses that changed state to adjust its automated response.

[webmaster128]

With our code/contract split it should be easier to build such a feature than with proxy contracts. And it would be more transparent. If we make codeId mutable, the client can always check which code is installed and can also do optional version pinning (I am aware of code ID xyz and my execute message is only valid for xyz). This makes upgrades slow as a feature. A contract owner needs to publicly communicate that a new code version is used from now on and why. Client can chose to not pin the code ID and always execute the latest version.

[ethanfrey]

My current (rough) idea is to (in wasmd) provide an optional "owner" for a contract, which can be a pubkey address, a multisig, a "group" with votes. That address can approve to switch the codeID behind one contract instance.

Upon switching codeID, we can call an optional "migrate" function, which would get the wasm hash of the previous code for the contract, and allow to migrate all existing code (which can be a very expensive transaction - gas-wise).

The owner could also later "freeze" the contract by removing themself, and then give the security of immutable code.

I think allowing two different code to run under the same address, with the same storage is complex and a recipe for serious bugs. I would rather just make it clear if the contract is immutable (code is law) or mutable (trust in the code and in the owner address). I could imagine a nice workflow of uploading a mutable contract, making some initial changes based on user feedback of first small set of users, then freezing it when it starts to become popular, so people can trust that the owner will no steal the increasingly valuable contents of the contract.

[aaronc]

@ethanfrey I like that approach and it's more or less what I was thinking.

It would be great to see something like that as a starting point and I think it should be pretty simple - just adding an owner field to contract instances, two new messages MsgUpdateContractCode and MsgUpdateContractOwner, and the migrate hook.

I've also thought it would be nice to allow a contract instance to subscribe to code changes. Imagine there are a set of contract codes maintained by the validator set. When instantiating a contract you could either choose a specific code id to have an immutable contract, or subscribe to a curated "code channel" that will be updated by validator governance in the case of bugs. This would basically provide the similar guarantees as cosmos sdk go modules, but with less upgrade overhead. What do you think of that idea?

Either way, I think the simple approach you're proposing is the place to start. Happy to discuss further.

[kwunyeung]

@ethanfrey one use case we are thinking of utilizing CosmWASM is to let developers to build their social reporting systems in their own dapps on Desmos. We are tracking the issue here.

The scenario is that different dapps would have their own rules of reporting posts, whether the posts should be visible or should be consider abuse, affecting the reputation of a user, etc. These rules may change over time, the smart contract controlling this feature should be upgradable and the states of the posts of difference dapps should be migrated as well.

The idea of upgrading and migrating by the owner of the contract is good. It will be even better if it can adapt like how the gov module work on changing parameters so that the community have the rights to consider if the contract should be upgraded by going through a process of smart contract code auditing, testing, general discussion. This will also match the vision of Desmos as we the social network belongs to the users and they have rights to help setting up the rules of different communities.

We currently have a simple mechanism called subspace to separate the scope of posts for different dapps. It's great to know that each smart contract of CosmWASM would have its own states. That will further enhance the concept of the subspace.

[ethanfrey]

Thanks for linking the issue, it is an interesting use case, and we will aim to cover those cases with CosmWasm as well, either by calls between contracts (I think that would be better here) or upgrading contracts (maybe?). Anyway, nice non-trivial business logic to model.

[webmaster128]

Contract migrations are the primary user visible feature of the 0.9 release of CosmWasm. Thank you for all your input shaping the implementation. This ticket is superseded by many smaller tickets which you find in the 0.9 milestone: https://github.com/CosmWasm/cosmwasm/milestone/6 as well is on the Go side of things. We're targetting a 0.9 release by the end of this month. Cheers