Recommended process for upgrading a smart contract in practice using ZOS

Archive SDK
1

Hi,

As we come close to finishing writing our smart contracts and test suite for our project using ZeppelinOS I just wanted to check what the recommended way of structuring our code and deployment/upgrade process.

From the tutorials and guides we have followed so far the suggestion has been to have only one code file per smart contract (eg, MyContract) which if it ever needs updating/fixing/upgrading is amended directly and then pushed and updated via the following commands:

npx zos push
npx zos update

Although Circle/USDC used the Zeppelin upgradeability proxies (but not ZeppelinOS) they used a pattern whereby they created their initial contract version as ‘FiatTokenV1’ and then it looks like new versions of the contract which had bug fixes, etc would be ‘FiatTokenV2’, etc… This seems to be more structured but I am just wondering how that affects the upgrade process and commands now required as you may not be able to do exactly the same as before?

Are there any guides/tutorials out there which show how to use ZeppelinOS to upgrade contracts on one of the public networks (mainnet or testnet) using the V1, V2 structure?

Cheers
Rick

2 Likes
2

Hey @roy.batty! Unfortunately we don’t have documentation or guides on that practice, but you may want to rely on contract aliases in zOS for managing this.

You can use zos add FiatTokenV1:FiatToken to add the V1 of FiatToken to your project, while referring to it just as FiatToken, as in zos create FiatToken. Then, when you want to go with the new version, you can just zos add FiatTokenV2:FiatToken and update the deployed version to the latest using zos update FiatToken.

Hope this helps!

3 Likes