Add CI job to cover important IBC features

[adizere]

Summary

Extend the CI repertoire by adding a job that tests integration with the Hermes IBC relayer and covers the IBC features that are important for the gaiad product.

Problem Definition

Why do we need this feature? What problems may be addressed by introducing this feature?

The gaiad binary has no visibility into how it integrates (or breaks compatibility) with IBC relayers.
To fix this, it would be good to add in the CI a basic suite of tests that launch two or multiple gaiad chains and runs several IBC transactions among them, relayed by an IBC relayer. Ideally, the tests should cover the IBC applications or features that are most important to gaiad, such as ICS20 and ICS27.

What benefits does gaia stand to gain by including this feature?

The core ibc-rs/Hermes devs cannot ensure continuous compatibility with all chain binaries. This is because relayers have compatibility requirements from at least 3 dimensions: ibc-go versions (e.g., v1.2 versus v2), SDK versions (v0.43 vs. 0.42), and chain-specific IBC applications or flows (e.g., ICS20 or 27, which are captured in ibc-go, but also non-standard features such as specific signing algorithms, specific coin types, block vs. tx events processing, etc). Hermes presently tests integration with gaiad as part of its CI, but the test conditions are very basic, in particular they do not cover ICS27 (only ICS20).

There will be full support for ICS27 in Hermes (informalsystems/hermes#1410), but unclear if that will be tested continuously as part of the CI, which means there is a risk for Hermes to break (at some point in future) compatibility with ICS27 running on gaiad. The suggestion here is that the main stakeholders/users for a particular IBC feature (note that gaiad is assumed to be one of the main users of ICS27) will test integration with an IBC relayer for that feature.

ICS27 is just an example here, and not sure if this is the most appropriate, so the question is: Are there particular IBC features that are critical or important for gaiad?

The benefit gained by solving this issue is that gaiad gains more visibility into its dependencies and can help prevent breaking certain important IBC features.

Are there any disadvantages of including this feature?

Yes. The CI will run the relayer binary, which is an external software. The CI job will need maintenance and furthermore may result in creating a dependency to the team developing the relayer binary.

Proposal

1. define list of IBC applications of user flows that are highly-critical for gaiad
2. extend the CI with a script that covers the flows from point 1, by relying on Hermes to relay transactions across different gaiad instances

The ibc-rs team is happy to help, in particular with point (2) above.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[nooomski]

Bot accidentally closed this. Opening again.

[jackzampolin]

This is something we would be happy to contribute. Strangelove has extensive experience building these types of systems.

[okwme]

hey @jackzampolin we'd love that!
realizing this is in a larger category of E2E tests that we should likely prioritize our tests around core gaia functionality before getting a full relayer suite in place.
ideally we have suites for both hermes and golang.
have you taken a look at how hermes does it to see if it's the kind of thing that's easy to swap golang or would it require a new design in general?
maybe an initial task could be scoping the work itself?

[nooomski]

Could be part of the larger issue in #1248

[okwme]

latest E2E test suite cover important IBC features using hermes test, i think this issue could be considered solved at this point