Dependency on the staking and auth modules

[Pitasi]

Hi!

As far as I know, ibc-go is pretty coupled with the staking module for accessing HistoricalInfo data (i.e. block headers). Still, I think I can easily implement a new module that satisfies the required StakingKeeper interface, so on chain I should be fine.

My problem now is that all relayers I found make some assumptions about the modules installed, i.e.: auth and staking.

I understand my use case is different from the bigger chains we're used to, but do you think it would be possible to provide an alternative implementation to the query logic?

So for example instead of receiving a query on path cosmos.staking.v1beta1.Query I can pick a different one, and maybe even provide my custom parsing logic to deal with the response. I guess in a sense I want a relayer SDK 🤣

On a side note: if these informations are needed by IBC protocol itself, why are they not being provided by ibc-go modules themselves? Am I missing something?

Thanks for all the great work so far!

[Pitasi]

I'm also available for forking the repo, making it satisfy my exact needs (so we have a second usecase), and then later on we can discuss how to build abstractions and make it possible (and easier) for everyone. If you can provide any tip or guidance on where to look I think it can save me a lot of time 😄

[romac]

My problem now is that all relayers I found make some assumptions about the modules installed, i.e.: auth and staking.

At the moment, we only issue gRPC queries to the staking module for Cosmos-based chains (the only instance is here), and this only used in the health check so you can either just ignore the warnings.

As far as I know, we don't issue any queries to the auth module, we just relay on some protobuf definitions for the accounts.

I understand my use case is different from the bigger chains we're used to, but do you think it would be possible to provide an alternative implementation to the query logic?

One way you can go about this is to implement a new instance of the ChainEndpoint trait for a struct which wraps the underlying CosmosSdkChain struct and forwards most method calls to it and only override the ones you deem necessary to handle in a special way. You can take a look at our WIP psql-backed implementation which does something similar.

Then you need to register this implementation as a new type of chain and hook it up in various places. I can provide more info on that if needed, but grepping for CosmosSdkChain should already get you somewhere.

That does not quite give you a Relayer SDK but it would allow you to customize how the relayer interacts with your chain.

We do have plans for modularizing the relayer and essentially turn into a framework/SDK, but we are not there yet.

I'm also available for forking the repo, making it satisfy my exact needs (so we have a second usecase), and then later on we can discuss how to build abstractions and make it possible (and easier) for everyone.

Sure, I would be happy to look at what you end up with! That said, I can't guarantee that we will integrate it into the relayer or base our next abstractions on it since we already have a pretty good idea of how it is going to look.

[Pitasi]

Perfect, so I was right on picking Hermes as the most "advanced" relayer implementation existing at this time :)

You answer is really helpful, I'll try and see if I'm able to build my own ChainEndpoint implementation. The psql one is also a nice example and it's not that far from what I need!

As far as I know, we don't issue any queries to the auth module

Well you actually need to retrieve the sequence numbers, before being able to send any tx. Given your pointers I was able to find the code:

hermes/crates/relayer/src/chain/cosmos/query/account.rs

Line 52 in 2677eb5

pub async fn query_account(

I'm also happy to hear that you already have plans on supporting different relaying needs.

Thanks @romac, exactly what I needed for now. I'll get back to you if I encounter any particular problem.

[romac]

Well you actually need to retrieve the sequence numbers, before being able to send any tx.

My mistake!

[adizere]

Thank you opening this discussion!

I see that most of the conversation so far is centered on the gRPC requirements. The Cosmos SDK implements these gRPC endpoints. In addition, Hermes also requires several other, non-gRPC, endpoints for Tendermint-based networks. These endpoints are provided by Tendermint's RPC and Websocket interfaces. We document these here, in case you need a handy reference: https://hedgedoc.informal.systems/FmNN0xuESR2wS1ZoRhuU8g

[Pitasi]

Hey @adizere, I'm trying to figure it out how the proofs work, in particular from your doc for the /status endpoint:

c. In connection handshake (open try, ack, confirm), for both the source chain (to update client), and destination chain (to construct proofs).

Am I correct to assume that it relies on the app hash somehow? My current thinking is that it expects the app hash to be a merkle root.
I did a simple test by basically overriding the app hash and append a 01 byte at the end, and that prevents IBC to work (proofs verification fail during handshake).