FLIP 179: Staged Contract Updates

[sisyphusSmiling]

FLIP Issue: #203

This proposal outlines a mechanism for automated and efficient contract updates to take effect at or beyond a specified
block height with the goal of minimizing recovery time following breaking improvements. Included in this FLIP is a
design enabling contract developers to pre-define a sequence of contract updates across an arbitrary number of contracts
and accounts, and either execute these updates themselves or delegate deployment authority to some trusted party.

[bjartek]

@JeffreyDoyle this is very interesting for flix.

[sideninja]

Nice idea! 👍
The part that worries me a bit (but is not really improving or making it worse to the current state) is what happens when one contract update fails, but maybe there can be a CLI tool supporting this and it can leverage mainnet/testnet emulator simulation to dry-run the updates. This is however out of the FLIP scope but I feel related to its integration.

[franklywatson]

Are we saying we would want others to build this? Seems tenuous?

Without at least some of the above tooling seems like a pretty risky scenario?

[sisyphusSmiling]

My hope is that if implemented, there would be some integration with @onflow/flow-develop-experience-tools with things like @sideninja mentioned above.

As proposed, simulated configuration and updates will be possible with existing/planned dev tooling via Cadence 1.0 local Mainnet mirroring AFAIK. The real addition here would be 3/ as a nice to have IMHO, and, if widely adopted, could be a grant candidate that I don't see taking too long to implement - likely a simple FE + indexer with event views filtered to the authenticated Updater.

IOW I don't believe the lack of the tool is a blocker to this FLIP or any worse than the current state given adopters understand they should own their non-core dependencies.

[joshuahannan]

Really well designed and written! I hope we can have something like this

[sisyphusSmiling]

maybe there can be a CLI tool supporting this and it can leverage mainnet/testnet emulator simulation to dry-run the updates

Love this idea @sideninja! That would be really helpful to prevent failed updates.

[bjartek]

There is a stable cadence emulator now so the suggested code snippets and repo should be updated to use stable-cadence clmpatible syntax. In particilar the entitlements on Account permissions.

[bjartek]

I would slso like to add that in order to have a stable migration path to stable-cadence we need a way to test this process. I belive @joshuahannan created an issue about adding an invalid contract to emulator, but i could not find it now.

[joshuahannan]

@bjartek onflow/flow-emulator#468

[franklywatson]

maybe there can be a CLI tool supporting this and it can leverage mainnet/testnet emulator simulation to dry-run the updates

Love this idea @sideninja! That would be really helpful to prevent failed updates.

cc @m-Peter

[sisyphusSmiling]

There is a stable cadence emulator now so the suggested code snippets and repo should be updated to use stable-cadence clmpatible syntax. In particilar the entitlements on Account permissions.

Thanks for the callouts @bjartek! I've got a draft PR here: onflow/contract-updater#6

It's currently in draft bc there's a bug in the CLI pre-release related to passing transaction args that prevents running through manual testing.

If we're leaning toward approving this mechanism, though, I can start working on a test suite for pre- and post-Cadence 1.0 since we'll need both versions

I would slso like to add that in order to have a stable migration path to stable-cadence we need a way to test this process. I belive @joshuahannan created an issue about adding an invalid contract to emulator, but i could not find it now.

Agreed on this. Very necessary to put together guidance on upgrade paths and ensuring devs know how to prep contracts for updates.

[sisyphusSmiling]

Closing the comms loop here to point to the updated Cadence 1.0 migration plan. The contract detailed in this FLIP may still be useful for the purposes of coordinated contract upgrades whether it's Flow-managed or otherwise. Deployment of this contract is deprioritized in favor of a contract supporting network migration and will be revisited post-Cadence 1.0

See the latest changes to the staging contract interface here - onflow/contract-updater#14

Update: Forum post covering the new staging mechanism