-
Notifications
You must be signed in to change notification settings - Fork 328
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow (optional) upgradeable contracts #77
Comments
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. |
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. |
With our |
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. |
@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 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. |
@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 We currently have a simple mechanism called |
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. |
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 |
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"
The text was updated successfully, but these errors were encountered: