Interchain Gmbh Backstop Ending Tracker

[colin-axner]

Interchain Gmbh stepped in to backstop the relayer in order to support IBC mainnet launch. Now that Hermes and the TypeScript relayer have showed tremendous capacity to be the future relayers of the ecosystem, we believe we can soon end Interchain Gmbh's backstop to prioritize development in other areas, such as ibc-go.

Here are the concrete features that need to be supported before our maintainership of the go relayer will end:

• Confirmation that one of the relayers (Hermes/typescript) is fully functional and stable for chains that use IBC right now
• Support for ORDERED channels (ibc-rs#839)
• Support for IBC Upgrades (proposal submission & client upgrades)
• Dynamic IBC (inspired by Agorics needs)
• IBC Client refreshing/auto update (preventing expiry)

In addition there is a tracking issue for UX Feature gaps between Hermes and the go relayer

Please comment if there are any additional features not mentioned above that should be noted.

[ancazamfir]

Confirmation that one of the relayers (Hermes/typescript) is fully functional and stable for chains that use IBC right now

How do we measure/test this? Are there requirements, tests, configurations available that we can try?

Asynchronous environments (inspired by Agorics needs)

Could you clarify what this means?

[colin-axner]

How do we measure/test this? Are there requirements, tests, configurations available that we can try?

I believe manual testing is sufficient, but CI testing is ideal. My main concern with stability is a relayers ability to stay active > 1 week. The go relayer historically has had a tough time being active for longer than a day

As far as configurations go, support is needed for:

• trusting periods >= 1 week (maybe even less, but I don't see strong incentive for small trusting periods)
• trust level of all trypes (it sounds like hermes will do bisection to determine a valid update? go relayer does not do this (it attempts to update to the latest height and will fail if the trust level is not valid for that update)

@AdityaSripal anything else?

Could you clarify what this means?

I'm not entirely sure all the requirements, but I think this issue probably covers all the necessary items. Would be great to hear from @michaelfig if there is anything Hermes (or TypeScript) currently do not support that Agoric would need.

I'm primarily concerned with ensuring Agoric has a reliable relayer to use with the "Asynchronous environments" section as they have been the primary voice of async and dynamic IBC. If they feel good about Hermes or TypeScript then I think we can check it off

Edit: I updated "asynchronous environments" to dynamic IBC. I think the terminology I used was incorrect and "dynamic IBC" is what I was going for

[michaelfig]

I'm not entirely sure all the requirements, but I think this issue probably covers all the necessary items. Would be great to hear from @michaelfig if there is anything Hermes (or TypeScript) currently do not support that Agoric would need.

Our most problematic requirement (the one we had to hack up a shell script to wrap the Golang relayer) would be solved if there is a way for the relayer to start an instance that runs continuously and relays all channel handshake/setup and data packets on a given IBC connection, keeping the light clients up-to-date. With that, it's just a devops process to support an eternal IBC connection with as many channels in either direction over that connection as desired.

That feature is crucial for allowing dIBC to initiate an outbound channel across a preconfigured relayed connection.

Relaying a single inbound channels is the easy case, and I'm pretty sure all the relayers support that fine... that's what makes them relayers.

Tagging @ethanfrey to ask if the TypeScript relayer supports this, since I believe the cosmwasm dIBC is in the same boat. Also @ancazamfir or @andynog to ask if Hermes supports this.

Sorry for being lazy and not just running out and testing both the relayers myself, but I'd rather hear a "yes, this should be possible" from the other projects so that I know I won't be wasting anybody's time barking up the wrong tree.

Thanks!

[ethanfrey]

Please do check out the ts-relayer. We have a new quick start and working on an overview feature matrix (in pr).

Short answer is the ts-relayer is designed to handle 1 connection. It relays all packets on all channels over that connection. (And acks and timeouts too of course)

It picks up channels dynamically. What it does not do is auto-create new channels, we have another tool ibc-setup that does the connection and channel handshake. Someone has to run this to create the new channel.

Let me know if something is missing for your use case. And I strongly invite Agoric to try this out and feel free to contribute small enhancements if they need it, as it is in your language of choice and designed to be easy to customize. (We can follow up on discord).

And cuz it was mentioned above somewhere, it does an auto-update of clients even in the absence of packets to keep the connection alive

[michaelfig]

It picks up channels dynamically. What it does not do is auto-create new channels, we have another tool ibc-setup that does the connection and channel handshake. Someone has to run this to create the new channel.

Thanks, that's great! If ibc-setup can do the connection handshake only, and then report the connection identifiers, that's all we need for the "outbound-from-Agoric" dIBC use case I'm interested in.

That's what I wanted to hear. I will be sure to take a look (in my copious spare time 😉), and ping you if I have questions/results to report.

[ethanfrey]

Thanks, that's great! If ibc-setup can do the connection handshake only, and then report the connection identifiers, that's all we need for the "outbound-from-Agoric" dIBC use case I'm interested in.

That's what I wanted to hear. I will be sure to take a look (in my copious spare time wink), and ping you if I have questions/results to report.

If you try to run another relayer on any testnets, just use ts-relayer. It will save you time.
Using the quick start guide should be 15 minutes max and give you a good overview of the capabilities, then --help or looking at the spec on how to create a connection without a channel. (ics20 happy path is client/connection/channel at once, but there are other commands to only create one)

[jackzampolin]

Looks like some of this was undone, but 🤷‍♂️ @cosmos/strangelove has this now.