We are building these contracts under the assumption that each Cosmos chain will have their own deployment, as such, the contracts should be migrated the governance of these chains. (Note that this means that in theory ICS02Client.sol can be removed.) There are two types of migrations we need to think about:
Adding new features to IBC while IBC is functioning normally. (We call these upgrades.)
Recovering from a broken state such as a frozen/expired light client, or any other issue that shuts down IBC.
These two cases should be handled separately because in the first case, we don't need to introduce any additional trust assumptions.
Case 1
A trivial way of implementing Case 1 would be to have an interchain account hosted in EVM and controlled by the governance module of the Cosmos chain, and then give the migration rights to this account. The only difficulty with this implementation would be the requirement to build ICS-27 (for Eureka) in Solidity. Another implementation could have us proving governance proposals using the SP1 Light Client.
Case 2
In this case, we cannot use an on-chain light client or any other type of trustless mechanism as we are working under the assumption that IBC itself is unusable. This means that we can no longer trust the light client representing the cosmos chain (for example, it may be frozen or expired). Then we propose that in this case, a security council (multisig) takeover the admin privileges. However, we don't want the security council to have the ability to steal any funds while IBC is functioning properly, this is why we propose:
Security council only has admin rights if light client is frozen/expired or there hasn't been any successful transfers in 2 weeks.
While IBC is active (i.e. light client is active and there are successful transfers), the Cosmos chain's governance module has the right to change the security council.
Proposal
We should study the docs and tools here to add migrations to our contracts. We should also probably move IBCStore to it's own contract
Description
We are building these contracts under the assumption that each Cosmos chain will have their own deployment, as such, the contracts should be migrated the governance of these chains. (Note that this means that in theory
ICS02Client.solcan be removed.) There are two types of migrations we need to think about:These two cases should be handled separately because in the first case, we don't need to introduce any additional trust assumptions.
Case 1
A trivial way of implementing Case 1 would be to have an interchain account hosted in EVM and controlled by the governance module of the Cosmos chain, and then give the migration rights to this account. The only difficulty with this implementation would be the requirement to build ICS-27 (for Eureka) in Solidity. Another implementation could have us proving governance proposals using the SP1 Light Client.
Case 2
In this case, we cannot use an on-chain light client or any other type of trustless mechanism as we are working under the assumption that IBC itself is unusable. This means that we can no longer trust the light client representing the cosmos chain (for example, it may be frozen or expired). Then we propose that in this case, a security council (multisig) takeover the admin privileges. However, we don't want the security council to have the ability to steal any funds while IBC is functioning properly, this is why we propose:
Proposal
We should study the docs and tools here to add migrations to our contracts. We should also probably move IBCStore to it's own contract