Interchain/Cross-Chain Queries #2866
womensrights
started this conversation in
General
Replies: 1 comment 1 reply
-
|
is there an open discussion or ADR/ICS draft for the pubsub approach? (though I think pubsub can be implemented unilaterally, so it may not be needed) |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
There is a discussion open on the spec repo about pubsub, although a little inactive, and there are a couple of relevant issues #823, although now closed and replaced with #889 |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This discussion aims to present the main findings from use case research of interchain/cross-chain queries and invite further discussion of this topic. This discussion was prompted by a request for maintainership of the packet queries implementation.
Background
There are currently two broad categories of cross-chain queries, the key value client queries (spec, implementation) and the packet queries (spec, implementation).
On a high level, the key value queries approach functions between IBC enabled chains with only the querying chain needing to implement the cross chain query module by making use of relayers RPC clients. The querying chain creates a query request, a relayer will then fetch the data for the query and generate the proof and submit the query result as a transaction on the querying chain. This triggers application logic in the cross chain query module to store the query result and verify it is correct. Once the query is verified, the original caller of the query can retrieve the result from the store.
The packet queries approach functions between IBC enabled chains, which both have the interchain query module implemented. The querying chain creates an ABCI query request which is relayed to the queried chain. The interchain query module on the queried chain authenticates the query and routes it to the appropriate module to execute the query using the BaseApp query router. The query response is sent back to the querying chain using the IBC transaction acknowledgement.
Use Cases
We reached out to 16 different projects, 6 did not have any immediate use case, of the remaining 10 projects, 2 are using KV in production, 3 projects are not yet live, of these 3 projects, 2 will launch with kv with 1 adding packet queries after the kv launch, and 1 will launch with packet queries, the remaining 5 projects showed interest in implementing some form of cross-chain/interchain query in the future.
To consider the use cases envisioned for these projects, queries can be broadly split into two groups - queries that many users would want to perform or access the result of, referred to as generic queries, and queries a single user would want to perform and see the result of, referred to as individual queries.
Individual Queries
Generic Queries
The oracle data and price feed use case was expressed most frequently. This use case would be optimised with a pub sub approach rather than having to request data every N blocks.
Pros and Cons
The following pros and cons of each approach are presented:
KV Queries Pros
KV Queries Cons
Packet Queries Pros
Packet Queries Cons
Some other important insights on the topic of cross-chain / interchain queries were that the majority of queries would need to be updated every N blocks to ensure up to date information. There is also a class of query where neither query approach solves the problem of not being able to verify that the result is correct. This is for queries which would filter specific transactions e.g. all transactions from a sender greater than a threshold amount. Currently it cannot be proven that all relevant events were included in the query result.
Concluding Thoughts
Based on this research, we have drawn the following conclusions:
KV queries have the great benefit of not requiring the queried chain to implement anything and for generic queries scale better without needing a packet round trip for each query - we see this approach well suited to generic queries.
Packet queries have the main benefit of providing better dev ex for more complicated queries and we could see a future benefit if queries could be batched - we see this approach best suited to individual complex queries.
The main use case sighted by future users for cross chain / interchain queries was for streaming oracle data and price feeds, neither approach optimally covers this use case, and a pub sub approach would be better here, perhaps with a new broadcast style channel type. This is because:
Having to request price feed data every N blocks to receive it seems inefficient, particularly as it is likely many users would be requesting the same data
Moreover the insight that many queries need to be frequently updated also aligns with benefiting from a pubsub query approach.
Similarly using cross chain queries for automation - waiting for a variable to reach a certain value and then performing an action would benefit from not having to request data every block, rather receive the data once the threshold is reached.
As there are benefits to both approaches and still space for a pub sub query implementation to be made, we are not convinced that one implementation should be favoured over the other by being in the ibc-go repo. Moreover, with production ready code, it is also already possible to use either implementation without the modules being in the ibc-go repo, the modules need to be wired up to app.go manually. An example of a module which have been developed outside the ibc-go repo but can be wired up in app.go is interchain nft-transfer, with an example of the wiring in app.go on IRIS hub.
Cross-chain, KV queries are already used in production by Stride, with the corresponding wiring in app.go and Persistence, with the corresponding wiring in app.go for instance. The packet queries can be found in a feature branch in Strangelove’s repository, not yet a module for use in production.
Beta Was this translation helpful? Give feedback.
All reactions