Hermes compatibility

[MiguelRocha2001]

I am planning on using this module to support a non-IBC connected blockchain, using an external state-machine that uses this module to bring the non-IBC connected blockchain to the IBC ecossystem.
I am still not sure how much can I use of this, but my question is about the Hermes relayer.

The blockchain is Bitcoin, which is not part of the Cosmos ecossystem. I've read that Hermes only supports Cosmos chains.

Is my approach viable?

Thank you in advance.

[rnbguy]

Thanks for taking an interest in ibc-rs.

my question is about the Hermes relayer.

ibc-rs does support hermes relayer. we use a mock cosmos-sdk blockchain in Rust (https://github.com/informalsystems/basecoin-rs) with ibc-rs to test out stack with ibc-go chains.

also, recent versions of hermes (1.11.0 and 1.12.0 at https://github.com/informalsystems/hermes/releases) are released with namada and penumbra which are non Cosmos-SDK chains -- both use ibc-rs at some extents.

The blockchain is Bitcoin

I am not sure what exactly you plan to do. ibc is a protocol -- and ibc-rs is a rust implementation of the core ibc stack. It is meant to be used as a module or contract inside a blockchain (ledger) runtime that supports Rust compilation target.

Apart from this technical constraint, you also need to have a finality gadget and light client for your blockchain (ledger). This is a general requirement of ibc protocol. You can learn more about it at https://ibcprotocol.dev

[MiguelRocha2001]

Thanks for the reply.

We know that Bitcoin does not support IBC. My plan is to leverage a set of external validators which implement the IBC module (that's why I want to use ibc-rs to run the IBC in each validator), and they will also interact with Bitcoin to store the proof of IBC packets.
Given this, I don't plan on running any Tendermint process, since the packet proofs are going to be stored on Bitcoin. Instead, the Hermes would query one of my validators to get the client state, so it could update the counter-party LC state (using headers).
The problem is that the Hermes only supports Tendermint. So, whenever I run the Hermes command to create a client, he tries to query the Tendermint process for client info.

Therefore, this forces me to use Tendermint, even when I don't need it, since the IBC packet proofs will be stored on Bitcoin.
An option would be to run Tendermint on each of my validators and store the IBC state there. Is this a good approach?
The second option would be to emulate the used tendermint endoints, which are used by the Hermes but modified to send Bitcoin headers, since I store IBC proof state there.

Also, can I ask one more question? Where is the IBC state stored? Tendermint, right? The relayer relayer IBC packets, packet proofs, and Tendermint state (client state). Then, to verify if the packets are authentic, they use the LC state (of Tendermint) to verify if the packets are stored there. Is this correct?

I know that Bitcoin does not support IBC, so we developed this solution where the IBC proofs are going to be stored on Bitcoin (using merkle trees or something). The problem is that Hermes expects me to use Tendermint, so how can I send the Bitcoin headers to the counterparty chain if the Hermes tries to get it from the Tendermint, which I don't even use? Should I use Tendermint?

Then, why does ibc-rs supports costumn LCs (non-cosmos sdk), and Hermes does not?
The composable team don't use Hermes, but hyperspace. What about Namada? I think you adapted the Hermes code to support Namada but it's hardcoded. It would never support my consensus state, which is implemented by my validator-set.

Thank you and have a good weekend.