Feedback for contract upgradeability design

Secret Contracts and Secret Apps
1

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?

  1. Improved dev ex, especially for dapps which dont work with user funds like games, real life apps.
  2. Ability to easily migrate snip-20 tokens to the newer snip-24 standard enabling permits and time stamps.
  3. Ease of integrating the new Axelar bridge.
  4. Reiteration to 1, will bring us up to par with other CosmWasm chains.
  5. Removes the opaque current mechanism that teams use to make code upgradeable.

What risks does it bring?

  1. Any contract that has an admin with upgrade functionality can steal basically all data and tokens in the contract.
  2. Open source code will become more important, same for the contract verifier function.

So… now for the reason of this forum post.

  1. 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.

  2. How do we handle backwards compatibility/ contracts that are already live.

Options:
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 :slight_smile:

EDIT/NOTE:
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.

6 Likes
2

Thanks for this post @ertemann! Personally I like option D the most for old contracts, as it provides more consistency with new contracts that can choose the admin on init.

2 Likes
3

I’m highly in favor of contract upgradeability, option C and D seem the most balanced ones to prevent abuse of the feature. We have to careful though on what teams to trust (if we stick with option D) as this will leave possible backdoors still open.

4

Can you please share the link to the documentation on how upgradeability works in CW 1.0? Personally I am not a fan of making smart contracts mutable, if that is what is meant.

There are many existing patterns for upgradeability that a smart contract developer can use already without making contracts mutable and I don’t understand why any dev cannot use these with Secret Network already: Upgrading smart contracts | ethereum.org.

Are there known examples of old contracts that are already deployed that devs want to upgrade? If the decision is made to make old contracts upgradeable, then I believe that should only be done with user opt-in. Definitely there should be a mandatory timelock of some kind to allow users to remove any funds before the upgrade goes into effect.

2 Likes
5

I dont plan on dying on the hill of either side but I think I lean more towards contracts being immutable.

It is true that if some fatal vulnerability were to be found, then this would be easier to patch with upgradeable contracts, however at the same time I think it’d be much easier to have malicious contracts and so the tradeoff wouldnt be worth it.

6

The thing is, if we can actually get dApps using the contract verifier to prove which contract is on-chain, surely the flexibility is worth it?

It means that users have the option to use dApps that have upgradeability or not.

7

Contract upgradabiliity is a must for real world applications, especially if one day we want to see secret network being used for real application rather than small toy dApps. Good developers can ALREADY implement patterns for upradability into their contracts, this, unlike existing methods will at least make it clearer to a user what is going on. There are no downsides to enabling this; for simple projects or projects where users are scared of their data or funds being stolen, the developers can always set the admin address to a null address during instantiation.

As for open source contracts, OF COURSE we need opensource contracts, but we would also need that anyways. The biggest flaw of the entire cosmos is how hard it is to retrieve the source code of a contract. Frankly I find it completely crazy how so few people seem to care about this, and how so few people are talking about the fact that most contracts on Secret Network aren’t even open source… This is code that we’re trusting to keep money and private data (even PII, or heck wallet seeds in some dApps) safe, of course all contracts should be open source and of course they should be upgradable. It’s just a no-brainier to me, and to any developer that has been around the block for longer than a few years. “Just trust me” is not something that you want to hear from a developer with access to important data. Yes, you can download a wasm binary and analyze it, but that is such a complicated (and error-prone) process that very few developers would ever bother doing it, especially because today’s tools to analyze wasm binaries aren’t even close to tools for x86 binaries.

I believe that I have a better idea perhaps, but an idea that will take Secret Labs 100 times longer to implement (sorry :smiley:). Require all new contracts to be put on chain alongside a public repo with the source code and compiler version used, then have validators compile the contract and check the hash BEFORE the contract can be instantiated, then do the same thing before upgrades. That way each new contract is linked to their source code and developers can see and understand the changes that have been made, and we can find malicious developers/scammers more easily, especially when combined with option C or D (however I would like to see an expedited proposal for this, rather than the normal 7 days).

4 Likes
8

I agree that upgradeability should be added, especially if it’s optional. I don’t think it should apply to existing contracts, though (with the exception of public goods like sSCRT).

9

I am seeing some good arguments for upgradeability, but still no clear reason for allowing existing contracts to be changed. Why not just mark all those as not upgradeable and then allow the option going forward?

Btw, 100% agree that contracts with public users should ALWAYS be open source. There are examples of closed source contracts in dapps on Secret Network and that’s been a failing of the community imo. However there are situations between individuals who might want to keep their contract closed source I suppose, and with a permissionless chain that’s hard to argue against. But it is something that a community can determine is important enough to require. Dero puts all contract source plain text on chain because it is interpreted. There’s no real way to do that with compiled wasm. If you could put the contents of src folder and cargo.toml directly on chain that could maybe work but it is a lot of data to put on chain…

10

My opinion may not be that of many people, given that I’m personally a FOSS fanatic :stuck_out_tongue: closed source code is a bug and all code that matters is opensource.

However, my strange opinions aside, if someone wants to keep their code closed source they should know that while the human readable version of the code might be closed source, the actual code that the computer executes is not, and will never be. There is no way to truly keep a very obstinate and stubborn developer from reverse engineering your entire code by meticulously going over the wasm binary.

So why not just go all the way and make it a requirement to make the code open source?

You don’t have to put it all on chain, just a link to a git/svn/hg repo, which then validators would automatically clone, compile and check that the code hash is the same as the one for the contract uploaded.

EDIT:

also – it’s not that much data, a large contract that I’m writing right now has exactly 107655 bytes of source code (src folder) at the time of writing. That’s 107kB, the same code when zipped into tar.gz is 14 KB of data. We could EASILY store that on chain.

3 Likes
11

Yeah, I agree with all you’ve said. The idea of having an explorer to view contract source on chain is ideal. I think it would be awesome to have source stored directly on chain.

4 Likes
12

Theres no way to enforce this

13

Well there is, if Secret Labs writes the code to enforce it :stuck_out_tongue:

14

Not sure what code you’d intend for them to write, can you expand?

15

it’s not easy to implement, but it’s possible.

16

I agree with everything you’ve said, Danny.

One thing I wonder about though … there will be some companies that have proprietary algorithms and would never want those to be public (I used to work for one). Do you have any ideas on how that could be supported?

1 Like
17

You can create a public repository, upload your code, go through this check, and then turn the repository private.

18

yeah that’s definitely a big problem that I don’t have a solution for, but someone that analyzes the wasm binary can figure out the proprietary algorithm anyways if they try hard enough. So in a way, while opensource code makes it easier to figure out those algorithms, it’s not like you can’t figure them out in other ways.

After the repo is cloned it can be stored on chain as a tar.gz. Even with 1 million large contracts, that’s only 10-20GB of data. If we’re that concerned about space where even that’s too much we can compress it with brotli rather than gzip and reduce the size even more.

1 Like
19

I guess for those projects or businesses that want to have some part of their code closed source, they could run private algorithms off-chain and then submit the encrypted results to the on-chain contract?

1 Like
20

The way I see it there’s really only 2 ways to do it. 1) you upload the code, not the wasm, to the network and the nodes compile it and put both the source and the wasm on chain. 2) you switch to an interpreted language (which is kind of the same thing). Both are probably unrealistic. For the first it would probably be super easy to DOS the network by uploading a bunch of contracts at once. You’d probably have to make it really expensive in gas to upload. The second means not being a cosmwasm chain so not an option.

Nevertheless it would be nice to have an easy way for devs to upload their source to chain at the same time as the binary. And then you create a culture where that is expected behaviour and contracts that don’t do that are flagged as potentially unsafe.

4 Likes