Description
We internally discussed different approaches to aliasing v1 channels to v2 and weighed the potential complexities in ibc-go with the potential complexity of retaining a channel layer for new users of IBC.
We decided that having a channel layer was unnecessarily complex for new users, and that conceptually the idea of creating two clients and then directly connecting them together was much simpler. Thus, we are moving back to the CounterpartyInfo struct that we had discussed before which will be keyed directly against the clientID.
There will thus, only be two clients and counterparty information signalling the path to verify against. The packet handlers will remain and will directly retrieve and use these structs for processing.
We will also retain the idea that there is only a single identifier to create a Eureka connection between two chains in the standard case (rather than having a client identifier and a separate channel identifier)
In order to support existing channels, we will create an exceptional case handling in ibc-go that will create a direct map from the channel-id to the clientID to retreive the underlying client and counterpartyInfo
The counterpartyInfo itself should have only the merklePathPrefix and the counterpartyId
The counterpartyId is to be interpreted as the provable path under which the counterparty will write all outgoing packet messages toward us.
Thus, in the aliasing case; the counterpartyId should be the counterparty's original channel-id since the counterpartyId need not be strictly linked to the clientID.
Furthermore, given the new key formats introduced in cosmos/ibc#1155 and the changes we made to supporting broader tree types; we should be able to have just a single field of the counterpartyId which should be explored by the implementor writing up this approach.