Relayer support for non-Cosmos based chains

[andynog]

Relayer support for non-Cosmos based chains

In the near future, it's expected that IBC will be implemented on non-Cosmos based blockchains, e.g. Substrate and Celo based blockchains. In order to support this scenario, we need to start thinking how this can be possible from a relayer's perspective. In particular with Hermes, we currently support Gaia chains. There are a lot of logic that is still coupled with Gaia chains (e.g. calls to the gRPC endpoints, watching events, etc.). We need to start thinking how these things can be better abstracted away in order to allow Hermes to relay packets between a Gaia to a Substrate chain for example.

I believe the most affected crate will be the relayer since it has logic to connect with the chains. But in this discussion thread we can try to outline the required effort, missing pieces, blockers, etc.

[andynog]

@jackzampolin started to implement some interfaces here for the Go relayer that might be a good start for Hermes https://github.com/strangelove-ventures/relayer/blob/6e2b3393eeffa7beaec6fa2537e222ac31ddf4e1/relayer/provider.go

we should setup a meeting with Hermes team and Jack to discuss this.

[livelybug]

One issue raised about non-Cosmos support in Hermes: #1456

[adizere]

Continuing here the thread from https://github.com/informalsystems/ibc-rs/issues/1214#issuecomment-975427666

Hey @lightyear15

Thank you for your patience.

As last point: I would argue that the relayer is not in charge of verifying anything as this is a duty the light-clients are in charge of, misbehaviour detection included.

This sounds right: client-related verification should be be encapsulated in the light client. Misbehavior detection is fundamentally an off-chain process, but that's a different story so for the purpose of this discussion we can just ignore that component.

The Hermes relayer runs a light client for all chains it communicates with, for the reasons I described above. It's feasible to have a relayer that does not run a light client, so I guess that's your question here, namely: can we modify Hermes to support IBC relaying without running a light client for Wasm clients? The answer is: probably yes, most of the changes would need to be supported at the level of these traits:

• pub trait ChainEndpoint
• pub trait LightClient, in particular most methods therein would probably perform nil verification and simply fetch/prepare headers.

More specifically, I think we need new implementations of these traits that handle communication and interfacing with non-SDK chain and non-Tendermint clients. Does this make sense?

[lightyear15]

Thanks @adizere,
yes, it makes total sense.
As long as hermes can deal with an internal light client approving an header (for instance), while ChainEndpoint::send_messages_and_wait_commit rejects it, I don't see any issue.
I understand the reason for Hermes to take up the duty of (pre-)validating headers and consensus states so to relieve some work on the on-chain light clients and save fees, yet Hermes must be ready to deal with headers and states rejections, due to imperfect internal light-clients.
Side note: I don't get your point about misbehaviour 🤔 . Why is it an off-chain-only task? can't an on-chain light client recognise a misbehaviour?

[adizere]

Side note: I don't get your point about misbehaviour 🤔 . Why is it an off-chain-only task? can't an on-chain light client recognise a misbehaviour?

An on-chain client is a simple method. To be able to do misbehavior detection it would need to have access to a full node IP of the chain this client is targeting, so that whenever the client receives an update message with a consensus state at a new height H, it can do the following (these steps are roughly speaking misbehavior detection):

• connects to the full node,
• fetches the block header for height H,
• computes the consensus state corresponding to this header,
• cross-checks the locally-computed consensus state with the consensus state from the update message.

This sequence of steps is non-deterministic (for example, the full node may be responsive sometime, and unresponsive at other times), and so it's not appropriate for running on-chain, at least not in the way I described it above. Intuitively, misbehavior detection is about cross-checking on-chain state with off-chain state. Maybe misbehavior detection can be done in a deterministic fashion, but not sure how. Does this make sense?

[livelybug]

An issue about client update based on a consensus other than Terdermint: https://github.com/informalsystems/ibc-rs/issues/1775

[livelybug]

An issue about on-chain storage verification based on a consensus other than Terdermint: #1845

[livelybug]

An issue about the data structure of commitment proof from non-cosmos chain: #1945