Remove dependency on 08-wasm from ibc-go

[colin-axner]

Summary

Currently the feat/wasm-clients has a dependency on 08-wasm within the ibc-go go.mod. This should be removed.

The dependency is due to self client and consensus state validation in the connection handshake. I will update this issue later with references to consideration on the long term and short term solutions

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[colin-axner]

A followup on this:

The crux of the issue at hand is that the ibc protocol has not put much emphasis on the consistency of the structure of the client and consensus state types. By this I mean the encoded structure set in the ibc store representing the client and the consensus states has been somewhat loosely defined, or at least loosely interpreted.

07-tendermint does define the types it expects to be set in the ibc store, but due to the design of ibc-go, these structures are also used for routing purposes. This forces the 08-wasm client to define a new structure to meet the routing requirements while also allowing the original type to be embedded. This alternative structure breaks down in the couple of instances the ibc protocol asserts the structure of the client and consensus state types

The first instance is in the connection handshake where a chain can self assert the type it expects to be set in the ibc store. It is not intuitive that a chain may need to expect a counterparty to use a variety of structures to represent itself. This would require chainA to register all structures counterparties may use to represent chainA. In this case, it would require any chain with a counterparty using a wasm client, to also import the wasm client module to register the correct types. This circular dependency defeats the purpose of making the wasm-client a standalone module

The second instance is in a client upgrade. The same issue will occur, where only 1 client/consensus state type is expected to be set, but the counterparties may be using various structures.

The primary reason to modify the connection handling of this situation is to allow 07-tendermint contracts to represent a chain for testing purposes. Given that native 07-tendermint clients exist, the logic added will be removed and we will find other ways to test the wasm client.

It's very possible this issue is naturally solved when transitioning towards a more generic IBC. Currently there exist 2 forms of communication IBC relies on:

• communication with light client modules
• communication with ibc applications

Both use different routing structures. A third routing structure will likely be needed to interact with a wider variety of consumers of the ibc module (expanding beyond sdk) and in such a situation, it makes more sense to consolidate these forms of communication into one standard routing module

I suspect this will be closer to how ibc applications are routed rather than how the light clients interact currently. It's more flexible to allow light client modules to register themselves then to use interface functions from a type set in store. This would have been useful in the 08-wasm case as you could remove the need for globals, as the light client module could not be initialized with whatever information it needs

If you transition 02-client to be more of a router than a guardian of the client stores, then you could likely remove the requirement of setting a certain structure to fulfill routing requirements and thus 08-wasm would be able to have contracts that store different client/consensus state types then 02-client interacts with

[colin-axner]

closed by #4801