Centralized Contract Pipeline

[l-monninger]

Summary

One of the top priorities for our centralized launch is ensuring our contract pipeline is reasonably stable and secure. The purpose of this discussion is to work towards a specification of the contract pipeline design.

Initial Proposal

1. Contract upgrade workflow MUST be triggered from a commit on main or a tag.
2. Contract upgrade workflow MUST not continue if any tests fail.
3. Contract upgrade workflow MUST not attempt deploy new implementation contracts if the implementation has not changed.
4. Contract upgrade workflow MUST trigger AWS KMS managed signers for a multisig that can execute Timelocked upgrade of the proxy contract.

Outstanding Questions w/ Approach:

• How do we want to handle devnet and testnet? Should this all be based on patterned tags?
• Do we need to complete Semantic Versioning #400 for consistency of tagging?
• What break-glass measures should we put in place?

[l-monninger]

What do we want to use to implement this in particular? Custom script? Something from OZ?

[l-monninger]

This means that the branch coming in has to be named upgrade-{contract-name}-V{version} and contract names do not have to stay the same but have to follow and standard for an upgrade to happen.

I would prefer to do this on a tag. But, yes, tagging with the unit upgraded is probably a good idea for a mono.

[Primata]

I know a few protocols that do 48hrs.

Versioning is kept with historical onchain data. I do prefer calling whatever was Legacy and the latest being just the contract name. Older versions are held onchain and it also prevents people from using older versions.

[Primata]

I think that other orgs are not really automating to this degree because there are too many variables in place and this ends up being counter productive. Just changing the fact that you'd like to make a call during an upgradeAndCall breaks the whole thing.

[l-monninger]

I know a few protocols that do 48hrs.

Let's provide a list.

In theory, this kind of thing is also actually good for an MIP, because it covers governance standards we adopt for ourselves as maintainers of the canonical chain.

[l-monninger]

I think that other orgs are not really automating to this degree because there are too many variables in place and this ends up being counter productive. Just changing the fact that you'd like to make a call during an upgradeAndCall breaks the whole thing.

Deployments should also be tested in the CI. Which orgs are you referring to though? If you're talking about things like DEXs, the bar is a bit different.

[l-monninger]

@0xPrimata, let's talk about a possible tagging strategy, because a lot of the concerns with automation I have and I'm guessing you have can be attenuated via the usage of tags and releases.

Have you seen the Aptos release strategy?: https://github.com/aptos-labs/aptos-core/blob/main/RELEASE.md

[l-monninger]

@0xPrimata

This means that the branch coming in has to be named upgrade-{contract-name}-V{version} and contract names do not have to stay the same but have to follow and standard for an upgrade to happen.

I would prefer to do this on a tag. But, yes, tagging with the unit upgraded is probably a good idea for a mono.