We have 2 updates to share with you and are looking for your thoughts and feedback.
Update 1
Sumary
The existing Crescendo test network will be used as the stable environment for new app development and general experimentation with Cadence 1.0, while the staged contract upgrade mechanism will use Testnet and dedicated upgrade testing network, to facilitate iterative testing of already deployed dapps.
Details
The initial Cadence 1.0 upgrade plan (published 13th Dec 2023) introduced a testing network for the Crescendo release that Cadence 1.0 is part of. The purpose of this network is to enable developers to test their dapps with Cadence 1.0. As we are planning the steps for the test network launch we realize that we need to support 2 distinct scenarios that have different requirements on the test network.
The first scenario is development of a new app using Cadence 1.0, general experimentation with Cadence 1.0 and the Crescendo release, not considering existing on-chain data, created with pre-1.0 version of Cadence. This scenario benefits from stable test environment with minimum disruptions / outages.
The second scenario is testing of a dapp that is already deployed and active on Mainnet. This scenario benefits from a testing environment that enables iterating on the upgrade process - it is likely that developers working on upgrading their dapps to Cadence 1.0 will need multiple attempts to get it right.
We propose an adjustment to the testing plan that enables both scenarios.
The existing Crescendo Release test network will become the Cadence 1.0 environment where we attempt to cause minimum disruptions to the network as we are stabilizing the release. In practice this means that this network will be upgraded to new Cadence 1.0 release candidates, but will maintain its state between upgrades (same as Testnet).
To enable the iterative upgrade testing, we propose to deploy the staged contract upgrade mechanism to Flow Testnet. We will take a Testnet state snapshot at regular intervals (weekly) and migrate the state to Cadence 1.0, including upgrading all contracts that are staged for upgrade. We will keep this temporary network running for some time (until the next iteration) after each upgrade, so that developers can query on-chain state and test the functionality of their dapp post migration. We will start with relaxed (or removed) update checker rules to make this as flexible as possible and will gradually strengthen them as we get closer to the Testnet upgrade. Please note that the purpose of this network is to test the dapp upgrade process, not general experimentation with Crescendo release.
Update 2
Summary
Staged contract updates will be executed using a state migration during the network upgrade, instead of via a transaction. This simplifies the migration process and avoids the need for multiple network stops during the upgrade. The transparency of the overall process is maintained through public migrations in the Flow repository.
Details
During the dry-run of the network update process we realized that we need to change the way existing smart contract will be replaced in their respective accounts during the upgrade.
Our initial proposal in the staged contract update mechanism introduced a 2-step process for upgrading contracts to Cadence 1.0. In the first step dapp developers stage their contracts for update by submitting a transaction. In the second step the contracts are updated through a special transaction triggered after the network is upgraded to Cadence 1.0.
The problem with this mechanism is that Cadence 1.0 state migrations need contracts to be updated to Cadence 1.0 in the account storage, which would make this upgrade mechanism very complex. We would need to migrate core-contracts and the related on-chain state just to be able to bring the network up with Cadence 1.0 image (the state would be only partially migrated at this point), then run the transaction to update the staged contracts in their respective accounts to their Cadence 1.0 versions, then we would stop the network again to complete the migrations for the rest of the state.
We can achieve the same result by turning the second step into a state migration. All the migrations are pubic in the Flow repository as always, so this change does not compromise on the transparency of the overall process but makes it considerably simpler and less error prone.
Please let us know what you think, especially if you have any concerns, by commenting on this post or on developer-questions Discord channel, using “C1.0 upgrade” at the beginning of the message to help us categorize questions related to Cadence 1.0.