ICS 031: Extending cross-chain queries to support IBC Casting

[angbrav]

This issue sketches how to extend cross-chain queries to support IBC casting.

A few definitions for context:

• Querying chain: The chain that is interested in getting data from another chain (queried chain). The querying chain is the chain that implements the Cross-chain Queries module.
• Queried chain: The chain whose state is being queried.

Goal: Maintain the nice properties of cross-chain queries, such as permissionless and minimal queried chain work.

Extensions:

• Currently, queries are ONE-SHOT. We need a new type of query: PERSISTENT queries.
• A querying chain can issue persistent queries only on a special key. The set of special keys can be modified by transactions at the queried chain.
• When a querying chain issues a persistent query, it emits an event. This is the same for one-shot queries.
• Every time the queried chain updates a special key, it emits an event.
• Between a querying and a queried chain, relayers keep track of the persistent queries issued by the querying chain. Thus, every time the queried chain emits an event for a key for which the querying chain has issued a persistent query, the relayer submits a query result transaction to the querying chain.
• When the querying chain receives an update for a key k, it should be able to verify that it is not missing any update in between. Assume that the queried chain updates k to v' at height h'. Consider also that k was previously updated at h to value v. To enable such verification:
  • The queried chain stores the latest value for a given key, together with the previous height at which it was updated. Thus, it stores under a public path that k's current value is v' and that it was previously updated at h.
  • Assume that the querying chain receives an update for k and that the previous update it received was v'' at h''. The querying chain then verifies using its local client of the queried chain that h''=h.
  • If the verification passes, then the querying chain accepts the update and updates its private store accordingly.

[AdityaSripal]

together with the previous value and height at which it was updated

Does it need to store both? Or only the previous height of last update. Seems like checking the previous value is unnecessary, unless we want to prevent sending packets if the publisher updates key with exact same value multiple times

[angbrav]

together with the previous value and height at which it was updated

Does it need to store both? Or only the previous height of last update. Seems like checking the previous value is unnecessary, unless we want to prevent sending packets if the publisher updates key with exact same value multiple times

Yeah, I think it is not needed. Regarding the optimization, it is not that useful considering that if eventually the key is updated to a different value, we will have to send all packets in between anyway.

I've updated the description, thanks for the comment ;)

[crodriguezvega]

Superseded by #889

[schnetzlerjoe]

@angbrav @crodriguezvega What is the state of the Cross Chain query spec here? https://github.com/cosmos/ibc/tree/main/spec/app/ics-031-crosschain-queries . Is this finalized? We at Defund are looking to make the few tweaks that would put us 100% in line with the current spec.

I am asking because many protocols are adding various different forms/tweaks of interchain querying versions, creating a ripple effect of having to handle multiple versions on validators running relayers. It would be great to create a uniform module to eliminate this. Defunds query module is 70-80% of the spec (since we initiated it) thus if we can make it uniform with the ics-31 spec, the IBC Go team can freely take it and create a uniform querying module.

Let me know! Thanks!

[crodriguezvega]

@schnetzlerjoe Yes, the ICS-31 spec is finalized. This PR was closed because the approach to do pubsub that is being worked on in https://github.com/cosmos/ibc/issues/889 was considered better.

Working on an implementation of ICS-31 is currently not in the plans of the ibc-go team. If Defund implementation follows ICS-31 that would be great, and we would be happy to include it in the application registry we keep in the README of ibc-go. Working on the pubsub design specified in https://github.com/cosmos/ibc/issues/889 is in our scope for 2023.