In practice, inbounds, outbounds will fail after upgrade before the gateway is upgraded (we should consider adding a pausing step in the playbook).
In the upgrade tests, we should add somewhere a place to specify instruction of upgrading the gateway contract.
Solution envisaged
Adding a method UpgradeGateways, this method is called in the upgrade test.
In this method, when upgrade is necessary, the gateway contract on EVM or ZEVM is redeploy with version currently defined in go.mod, and upgrade with the new implementation contract.
Describe the Issue
In v2 contracts, we add the ability to upgrade the gateway contracts on ZEVM and connected chains.
It can happen protocol modifications like https://github.com/zeta-chain/node/pull/2904 are based on the assumption that the gateway contract is upgraded.
In practice, inbounds, outbounds will fail after upgrade before the gateway is upgraded (we should consider adding a pausing step in the playbook).
In the upgrade tests, we should add somewhere a place to specify instruction of upgrading the gateway contract.
Solution envisaged
Adding a method
UpgradeGateways, this method is called in the upgrade test. In this method, when upgrade is necessary, the gateway contract on EVM or ZEVM is redeploy with version currently defined in go.mod, and upgrade with the new implementation contract.