Feedback for contract upgradeability design
At this moment in time, in contrast to other CosmWasm chains in the cosmos ecosystem, Secret does not support smart contract upgradeability. This choice, originally taken in 2020 with the launch of secret contracts on mainnet is one for both security and user fund safety. However, it has become clear that many in the wider developer community have seen the non-existence of this function as a blocker in application development.
Contract upgradeability forms a risk for user funds as admins are allowed to change contract code without user consent. Besides this is privacy is also at risk as detailed in this section of the documentation. However, for other smart contract layer 1s like ethereum, juno etc. these risks have existed since inception and accepted in order to promote the overall dev experience. Because of this some od SCRT labs argues that there Secret could also implement this. As, if security risks are accepted then risks to privacy might be as well since ownership/fund safety > privacy.
Enabling contract upgradeability is relatively trivial and SCRT labs has shown willingness to develop it. The feature could be backwards compatible to all secret contracts and this is exactly why i am making this forum post.
Contract upgradeability is optional, its something developers of the contract can enable if they want to. An admin address is chosen who has the ability to perform upgrades. This address does not have to / is often not the same as the creator of the contract (the wallet that put it on chain). This makes it so that the chain cant determine the correct admin for the contracts already launched. Further down i will lay out some options we have in the design.
Why do we want/need contract upgradeability?
- Improved dev ex, especially for dapps which dont work with user funds like games, real life apps.
- Ability to easily migrate snip-20 tokens to the newer snip-24 standard enabling permits and time stamps.
- Ease of integrating the new Axelar bridge.
- Reiteration to 1, will bring us up to par with other CosmWasm chains.
- Removes the opaque current mechanism that teams use to make code upgradeable.
What risks does it bring?
- Any contract that has an admin with upgrade functionality can steal basically all data and tokens in the contract.
- Open source code will become more important, same for the contract verifier function.
So… now for the reason of this forum post.
Can people provide feedback on of they want to see upgradeability enabled on secret. Most people i have spoken to so far lean to a yes, but its good to ask everyone in the network.
How do we handle backwards compatibility/ contracts that are already live.
A. Dont enable contract upgradeability for contracts that are already live.
B. Enable upgradeability for live contracts and set the admin key to the issuer of the original contract.
C. Enable upgradeability for older contracts but SCRT governance has to vote on the upgrades (could be batched).
D. Enable upgradeability for older contracts but SCRT governance will have to vote on the admin key setting. Meaning each dapp would have to provide an admin address, make a gov prop to set that too all their old contracts and SCRT governance would vote on it.
E. Go wild in the comments, there are probably even better solutions.
I will post my opinion in a separate post, i hope to hear from many developers and apps in the network
Like mentioned in risk 5, current secret contracts can be made upgradeable by a work around. Honestly not too sure how it works but i heard teams are implementing it differently across the board and its relatively opaque. If one did not set this up correctly or just did not do it when the contract launched they cant upgrade (for ex sscrt contract). So this discussion is specifically about enabling contract upgradeability as specified in CW v1.0. A simple parameter that states a contract can or can not be upgraded. Making the method standardised and easily accesible by all developers and potentially easy to implement in dao governance as well. Soo… contracts can already be designed to be upgradeable by a workaround, but not as simple ws the method described here.