Yes, this is my main concern.
1 Like
A big thank you to each and everyone who has provided feedback already, i think we are moving a bit offtrack though.
I can see why people link this conversation to open or closed source code choices and see a vision for how smart contracts platforms should be but sadly that is not really the case.
Contracts on secret are already mutable!! This just has to be done in an opaque way that is harder to engineer. The question here is, do we want to make it easier and provide an upgradeability parameter. It is still an optional thing so immutable contracts will still exist.
On top of this id like to say that forcing open source code is not an option, just like forcing an equally weighted voting power across validators is not an option. We are a permissionless network, if people want to keep their code closed source than so be it. Atleast, that is how i see it.
Personally i think the option D i presented here is fair to upcoming dapps (who want to be able to deploy cross cosmos or have lower risk contracts they want to be mutable), the current contracts that we would love to upgrade (sscrt, bridge tokens, maybe older dapps), current contracts we dont want to be mutable (as they can stay that way), future immutable contracts (as they can still be created) and also users (as they get an easier way to check mutability and get a vote on wether or not current contracts should be mutable.
If people can provide some more precise feedback on specifically the mutability issue at hand then that would be very helpful. We can issue a poll later on with the most favourable options.
2 Likes
Definitely important to point out almost every major product on SN has upgadability via upgrade functions inserted by the devs anyway, so I support any option that makes this process less of a headache. Itâs vital as we get into usecases beyond the typical defi degen dapps and into real world products and services built on secret. It was super necessary for certup and a massive headache to implement manually. It should be enabled for older contracts as well. Unsure if we want it to be a governance prop however, since anyone can bypass this anyway by using upgrade functions as we already have implemented.
1 Like
Not all old contracts have contract upgradeability enabled via the workaround already and there is no way to find out the contract admin.
This is why the gov prop might be needed.
Also a point about code verification, with SGX we can verify the source code offline and post the proof & the source on-chain. Obviously easier said than done, but that will allow us to impose restrictions on non verified contracts, like not allowing them to send or receive any messages to/from other contracts or receive SCRT deposits.
3 Likes
I think thereâs a good reason for why this conversation went to open/closed source because it is inextricably linked to the question of upgradability. The main argument about upgradability depends on whether by interacting with a smart contract, you should be assured that the code of that contract will not ever change in the future. Thatâs only really an issue under the circumstance where code is open to begin with. With closed source it doesnât matter because there are no protections to begin with.
Also permissionless does not necessarily mean you cannot force open source, it is a decision about the design of the network. Permissionless only means that anyone can upload a contract, not that any contract can be uploaded. Secret requires contracts to be wasm and you cannot upload a solidity contract, eg. Seeing Assafâs comment, there are ways to do verification and impose restrictions, so it is really just a question about what the priorities are for the network. It sounds like it might be hard-ish to implement, but on the other hand that hasnât stopped Secret from doing things in the past. Personally, I like the idea of Secret innovating in these ways but I certainly can see other people wanting different things to be priority.
EDIT: and also while I agree in practice you can build contracts that are upgradable depending on changes in data state, the manner in which a contract can be upgraded is fixed by the source code as it is written originally. If the code is open, then people can see exactly what kind of upgradability is possible. This allows contract developers granularity in terms of ensuring for users that some aspect of their application is immutable. This is manifestly different from being able to arbitrarily change any contract in any way you want. Iâm on board now with the option of making things mutable, btw, just making that a point of clarification because thatâs technically different from saying that contracts are already mutable (apart from a chain upgrade).
Thanks for the feedback. Especially the edit is a helpful detail in deciding on the upgradeability parameter.
Just want to clarify that i think forcing open source is an interesting and novel idea and that the network is free to think about implementing something like that.
My statement was merely my opinion, i think its not the good way to go. If we want institutional apps then we need to keep the possibility for closed source code imo.
1 Like
I have one more question about upgrading. Will there be a way to specify that the upgrade is a one time operation? I still havenât heard any examples of old contracts that need upgrading, except one mention of sscrt. In the case of sscrt, I would assume that is to make it a snip24? However once youâve done that, isnât there essentially a backdoor introduced to the sscrt contract because if it can be changed once, it can be changed again?
It would be really nice if there were guidelines, perhaps in the form a snip, that lays out when upgradable contracts should NOT be used. E.g. I would think it is a no go for most token contracts due to the ability to essentially break all privacy and steal all tokens in one go.
1 Like
Hey developer community,
It took over 6 months but upgradeability for Secret contracts is back on the top of the list after much design consideration was put into it and other issues and requirements were solved.
The method most agreed solution to upgradeable contracts seemed to have been D but unfortunately due to technical complexity this wont really be an option. - Verifying governance outcomes is an untrusted data problem not solveable with the current verification (light-client etc.) stack.
This is why Labs has thought of a method that works similar but different and would love to get some final comments and feedback before implementing.
- New contracts will be upgradeable based on admin-key choice similar to vanilla cosmwasm contracts. - Please follow best practices to minimize privacy and value risk to users.
- old contracts may become upgradeable but there is only one moment at which people can decide to do this and it will be shortly before the upcoming upgrade after which a signalling proposal for it has to pass on SCRT governance. Contract hashes will be matched to the chosen admin key and added to a list which will be hardcoded inside the enclave to reference. From the upgrade moment there-after all these contracts will have upgradeabillity similar to vanilla cosmWasm, all other old contracts will remain non-upgradeable indefinitely.
After this post i will get in contact with all dApp teams on Secret to collect potential upgradeable contracts alongside an address, its security scheme (multisig, dao etc) and the reason for wanting this feature. I will make a strong suggestion to all dApps to take this security matter very serious and only opt-in for this feature if really required. SCRT governance will have to decide upon the final list for all contracts + admins.
A timeline for the coming upgrade (v1.10) has not yet been set but id expect it no sooner than end of August.
Please donât hesitate to contact me directly or reach out here with any questions.
Best regards,
Gijs - Ertemann
4 Likes
Hoi Gijs,
great news, this will really make life of dapp developers simpler. For ActiList, since we are on testnet, old contracts wont be an issue. We launch after SN uprade, and then hopefully this feature will work for us out of the box.
2 Likes