IBC queries

[tac0turtle]

IBC has enabled many chains to talk to many chains, but to query state of an account on another chain the user must either query an exposed rpc endpoint or run a node themselves. This present a UX issue for third party integrators that would like to integrate one chain but use tokens of many.

Allowing a client to submit a cross-chain query for data of a specific account or state could provide better UX for the end user.

Opening this to get thoughts on a new message type for this. It would be useful in our use case of interchain custody.

[zmanian]

There are going to be applications on other chains that are going to depend on reads from other chains

[ethanfrey]

I agree it would be useful.

I wonder if it is better to have some interchain account like protocol, where we expose different queries for each module, or to just expose raw state queries (which are also exposed on the tendermint rpc layer).

The advantage of the raw queries is no code is needed on the chain to be read. Raw queries can generate Merkle proofs already. One could develop a protocol to verify any state key using the same clients.

This reader could be deployed to one chain, a relayer updated, and it will be able to read account balances from other chains in a trust less manner

[zmanian]

So if we aren't going to use the full IBC stack for queries across chains, then the query system still needs to share access to the IBC client infrastructure and thus we need to define an architecture where interchain queries can use the IBC client.

[zmanian]

The issue I see with a protocol that just uses the IBC light client without the rest of the IBC stack is the strong coupling of the internal data schema of the module to external applications.

[vshvsh]

I would trust the interface of the state machine over the internals. There's no guarantee internals will keep the spec they have currently, which will eventually make for dependency hell (esp with smart contract enabled chains where permissionless and chaotic upgrades happen all the time).

We did historical state proofs for Ethereum, it was a horrible experience. Strongly support having interchain queries - without them interchain applications won't be useful.

[ethanfrey]

Allowing a client to submit a cross-chain query for data of a specific account or state could provide better UX for the end user.

Then this is not a simple "get account" but perform any application-specific query (which is also not guaranteed to remain stable over time). But more akin to Interchain Accounts, and them using the protobuf-encoded messages as the unit of communication. Just protobuf-encoding gRPC-like queries?

[mconcat]

IBC queries are better to be key-value access, instead of turing complete application specific, but with additional layer of converting virtual key position into machine key position. ICS 24 is actually a kind of this conversion scheme; there is a string form of interface key format, which each host translates into machine specific key format.

The conversion scheme could be simply described in a single schema language and embedded inside the ConnectionState(so we don't have to upgrade the chain each time the schema changes). The querier uses the conversion scheme to find the machine key from the application provided key, verify the key-value pair using the ClientState, which is done synchronously and without depending on the queried chain's response.

Usual application specific query could be done using the existing IBC packets and Querier interface. Query packet contains the querier path data which the receiving chain calls the module querier to retrieve and send receipt of the result. This is done async and depends on the queried chain correctly respond.

[ethanfrey]

This is quite confusing. I don't quite get it, but it seems to combine the worst of both approaches.

IBC queries are better to be key-value access, instead of turing complete application specific, but with additional layer of converting virtual key position into machine key position

Some magic mapping handled by "someone" (ConnectionState) rather than the application logic.

The querier uses the conversion scheme to find the machine key from the application provided key, verify the key-value pair using the ClientState, which is done synchronously and without depending on the queried chain's response.

without depending on the queried chain's response. ????

Sorry, but it feels a bit like a or maybe I'm just too tired and you can try explaining better

[ebuchman]

So one way to do this would be for the SDK to support Msg based reads more generally so apps can define queries that can be done via a Msg type in consensus (the need for consensus based reads is common in traditional dbs, eg. see this issue in etcd). Then it will come for free over IBC via Interchain Accounts.

Conceivably all grpc Queries could be auto exposed as Msg-based queries as well (could be a general MsgQuery that takes a module name and method string, or a per module MsgQuery that takes a method string, etc.), but maybe apps will want to be selective about what they expose, and we need to be careful about iteration and large responses (paging over IBC is probably going to be a pain lol).

Raw kv-store queries over IBC are probably too low level, especially if an app changes its data model. But msg-based reads provide a more normalized/consistent API to the state and might be useful generally rather than making this a custom IBC feature.

On a related note, Msg-based reads combined with a stateless VM module could allow us to do conditional txs pretty nicely:

• first msg is a query
• second message is some vm code that takes the result of the query and exits if some condition about the query result is not met
• other messages execute conditionally based on whether the second message failed or not

[peterbourgon]

Strong +1 — in order to be sound reads must go thru consensus, and can only return information that's been committed, i.e. you can't just make arbitrary queries over the mempool or storage layer or whatever.

[tac0turtle]

Love the discussion that is happening here. Reading the messages and talking with people on telegram it seems this feature is in high demand. I would propose organising a working group to flush out a design.

Since the Hub is looking at using this along with a few other projects I have talked with, I'm happy to take the lead on organising the calls and taking notes.

[crodriguezvega]

I support the idea of starting a working group, but I would love to see that use cases and functional requirements are discussed and documented first before start designing a solution. There are many conversations going on in different places about uses of interchain queries, so I think it would be useful to converge all that in one place, so that everybody gets a clear picture of what (not how yet) needs to be built. Having that will be very valuable later on while we design, implement and test the solution because it will allow us to track and agree on requirement changes and check that what we build satisfies those requirements.

We had a couple of discussions about this topic in the IBC team and we would like to move in this direction with future features. I have a document explaining how I see this process, in case anybody is interested.

[ethanfrey]

so that everybody gets a clear picture of what (not how yet) needs to be built. Having that will be very valuable later on while we design, implement and test the solution because it will allow us to track and agree on requirement changes and check that what we build satisfies those requirements.

I couldn't agree more.

[ValarDragon]

I propose doing the raw KV store read method Bucky alluded to. This is basically the Solana light client approach.

We make a StateReadMsg, that takes in one of:
(1) A state key
(2) A range of state keys

The StateReadMsg emits the values at the relevant entries of states into a tx_result. These get merkelized into the existing LastResultsHash in the header.

Thus the flow for a cross-chain query will be:

Chain A wants to query state 'S' from Chain B.
Chain A sends a message over IBC to chain B to Read state S.
Chain B acks that message at height H, and then reads that state entry and puts it into a tx_result. This gets merkelized in the header for block H + 1
A relayer submits the header for H+1 to the application on chain A, and opens the LastResultsHash to the relevant leaf, and gives that state entry to the querying application on chain A. (The tx_result leaf should also include a hash of the query message)

Then afterwards, we work on sugar coating for common queries. Likely using Aaron's great work on the ORM module as an end state, and in the initial days judiciously applying the 80/20 principle for common use cases.

The interface for an application will look like:
Make "Crosschain query msg", hand off to IBC module.
Receive "Crosschain query response", ask IBC module to authenticate result (as described above). If correct, then proceed with response as you wish. If false, reject.
IBC module then handles all of the light client verification of that header really being part of the hashchain, etc.

Re: comparing to bucky's point about brittleness of raw KV store reads:

The state key here may break every consensus version for an application but so will messages. I think we can get nearly everywhere we need to be pre-ORM module by just using aliases, and I worry that an approach based on running more general messages and tracing/merkelizing outputs will take a lot longer to ship, and not have much incremental utility vs lots of helpers and then great ORM module integration.

We should be imagining GRPC queries as moving to separate queries away from the chain datastore back-end for the most part -- I'm not at all in favor of exposing these directly over IBC.

[vshvsh]

I imagine message-based interface will break much less often than storage-based. I agree that the latter is much simpler to ship and might be just the hack we need to kickstart cross-chain dapps early rather than later. I don't agree that it will have the same brittleness as message-based comms.

[ethanfrey]

NB: we removed the last usage of light client proofs in cosmjs, as the 0.42 -> 0.44 broke the proof format for accounts (to query sequence). We had just implemented that and bank denom and made them optional as everyone complained about performance. If one of those breaks on an upgrade that didn't break protobuf, seems a sign to me this is very fragile.

[ebuchman]

I worry that an approach based on running more general messages and tracing/merkelizing outputs will take a lot longer to ship,

I was imagining there would be a relatively easy way to lift all existing GRPC queries into the message handler, so a single MsgQuery with the grpc method you want would be all thats necessary. Presumably this will be much easier for folks to use since all the GRPC queries are already well documented, compared to the raw state queries.

Make "Crosschain query msg", hand off to IBC module.

Are you imagining using Interchain Accounts for this? If not, why?

[jackzampolin]

This sounds like it we wouldn't even need the IBC channel and connection, we could just use the client to verify state reads from a counterparty chain right @ValarDragon

[jackzampolin]

Ok so my proposal is even simpler than @ValarDragon's chatted about it briefly in the IBC Queries Working Group telegram yesterday but for visibility I'll write it up here. Basic idea is that we use ABCI queries and use the IBC Clients to prove the data from the queries is accurate. This should be sufficient for the same security guarantees as IBC w/o the overhead of requiring any upgrades from counterparty chains. The following is an ABCI query request:

type RequestQuery struct {
	Data   []byte
	Path   string
	Height int64 
	Prove  bool  
}

I propose we create a module that allows modules or smart contracts to create CrossChainABCIQueryRequests:

type CrossChainABCIQueryRequest struct {
	Data     []byte
	Path     string
	ClientID string
	Bounty   sdk.Coin
}

These requests would be seen by relayers who would then take the Data and Path and make an abci.RequestQuery on the specified counterparty chain. It would then use a MsgUpdateClient and a MsgSubmitQueryResults to post the resultant data back to the requesting chain. This would be checked against the specified IBC client for veracity. We could use hooks or another mechanism to return this data to the calling module/smart contract as JSON.

Timeouts would be height based in the same way IBC packet timeouts are.

Relayers could easily perform this operation and be paid by the calling module/smart contract.

[ethanfrey]

In such case, let's just make a data type for that, than one that allows many options but fails for 99% of them.

type CrossChainABCIQueryRequest struct {
	Key     []byte
	ClientID string
	Bounty   sdk.Coin
}

Would then just query for that key. Maybe even add Height int64 to get historical data (default to latest if unset/0)

[faddat]

I think that the bounty keeps this from being used as an attack vector, though I suppose one could make expensive attacks

[jackzampolin]

Well its meant more as a carrot for relayers to actually pull this data. Pushing the responsibility for funding this to the calling module keeps the ibc-query module cleaner, but prevents us from doing things like mandating that the calling module or contract puts some funds in escrow to pay query relayers.

[ethanfrey]

These requests would be seen by relayers who would then take the Data and Path and make an abci.RequestQuery on the specified counterparty chain. It would then use a MsgUpdateClient and a MsgSubmitQueryResults to post the resultant data back to the requesting chain. This would be checked against the specified IBC client for veracity. We could use hooks or another mechanism to return this data to the calling module/smart contract as JSON.

In general, I do say I agree with the design and had similar thoughts before (without considering the incentivization part.. really just the proof part). If done properly, it requires no changes on the chain that is being queried, and deploying this on one chain is already an advantage to apps on this chain.

One issue with deploying IBC protocols is the network effect, such that they only have value if a number of chains already run them. This is a nice exception to that trend.

[AdityaSripal]

I'm in favor of one-sided deployment. Creating a full IBC channel is overkill for this usecase. We can just leverage clients directly as jack proposes

[schnetzlerjoe]

Ok, so this is a quick spec (work in progress) for the interchain-query module utilizing @jackzampolin suggested method. https://github.com/schnetzlerjoe/interchain-query-spec. All suggestions are welcome.

[charleenfei]

Hey @schnetzlerjoe thanks for this initial writeup! Would you consider opening this first draft as a PR on this repo? That would make review and eventual merge easier. Thanks!