Introduce XCQ #126

indirection42 · 2024-10-25T01:39:55Z

Looking for feedback.

Summary

This proposal introduces XCQ (Cross Consensus Query), which aims to serve as an intermediary layer between different chain runtime implementations and tools/UIs, to provide a unified interface for cross-chain queries.

Related RFC

A related XCM-format RFC is drafting.

Related Discussions

https://forum.polkadot.network/t/wasm-view-functions/1045

PoC implementations

https://github.com/open-web3-stack/XCQ

franciscoaguirre · 2024-10-28T23:32:37Z

text/0126-introduce-xcq.md

+Therefore, tools and UI developers often access storage directly and reimplement custom computations to convert data into user-friendly representations, leading to duplicated code between Rust runtime logic and UI JS/TS logic.
+This duplication increases workload and potential for bugs.
+
+Therefore, A system is needed to serve as an intermediary layer between concrete chain runtime implementations and tools/UIs, to provide a unified interface for cross-chain queries.


Suggested change

Therefore, A system is needed to serve as an intermediary layer between concrete chain runtime implementations and tools/UIs, to provide a unified interface for cross-chain queries.

Therefore, a system is needed to serve as an intermediary layer between concrete chain runtime implementations and tools/UIs, to provide a unified interface for cross-chain queries.

franciscoaguirre · 2024-10-28T23:33:14Z

text/0126-introduce-xcq.md

+
+## Explanation
+
+The overall query pattern of the XCQ consists of three components:


Suggested change

The overall query pattern of the XCQ consists of three components:

The overall query pattern of XCQ consists of three components:

franciscoaguirre · 2024-10-28T23:38:29Z

text/0126-introduce-xcq.md

+```rust
+decl_runtime_apis! {
+    pub trait XcqApi {
+        fn execute_query(query: Vec<u8>, input: Vec<u8>, weight_limit: u64) -> XcqResult;


Suggested change

fn execute_query(query: Vec<u8>, input: Vec<u8>, weight_limit: u64) -> XcqResult;

fn execute_query(query: Vec<u8>, input: Vec<u8>, gas_limit: u64) -> XcqResult;

Is this limit the PVM gas instead of the weight?

It seems that the metrics of the PVM gas are in development now, and the gas value is an inner value that should not be exposed to users.

franciscoaguirre · 2024-10-28T23:45:23Z

text/0126-introduce-xcq.md

+```
+- `PermController`: Filters guest XCQ program calling requests, useful for host chains to disable some queries by filtering invoking sources.
+```rust
+pub trait PermController {


Maybe Authorizer is a better name? Or PermissionsController (not abbreviated)

franciscoaguirre · 2024-10-28T23:53:08Z

text/0126-introduce-xcq.md

+  - Integration tests to ensure proper interaction with off-chain wallets/UI and on-chain XCM, including the aforementioned use cases in **Motivation** section.
+
+- Security:
+  - The XCQ system must enforce a strict read-only policy for all query operations. A mechanism should be implemented to prevent any state-changing operations within XCQ queries.


Could the execution of the program be sandboxed?

Yes, we can do the query in a transaction, and rollback finally.

franciscoaguirre · 2024-10-28T23:54:32Z

text/0126-introduce-xcq.md

+
+## Future Directions and Related Material
+
+Since XCQ are supported both in off-chain and on-chain, a related XCM-Format RFC should be proposed.


We recently merged XCM RFCs into the fellowship RFCs. So the new instruction and behaviour of XCM could be described here.

jsdw · 2024-11-13T10:02:57Z

text/0126-introduce-xcq.md

+`xcq-types` is a meta-type system similar to `scale-info` but simpler.
+It enables different chains with different type definitions to work via a common operation.
+Front-end codes constructs call data to XCQ programs according to metadata provided by different chains.


I'd like to know more about xcq-types, ie what are the existing issues with scale-info here? Since it just describes the shapes of types, one can compare two sets of scale-info types across chains already, or is there more to it?

Adding a separate system to describe types adds overhead when everything else is built to work around scale-info already, so I wonder how necessary it is (ie we already have tools to do codegen, encoding and decoding with scale-info and it'd be a pain to reimplement them all for this).

jsdw · 2024-11-13T10:14:06Z

text/0126-introduce-xcq.md

+}
+```
+
+- `ExtensionExecutor`: Connects extension implementations and `xcq-executor`.


If one wants to expose pallet view functions or runtime APIs to the XCQ programs, do extensions have to be written which call into them (and then those extensions are what is exposed in the XCQ program)?

Is the reason for having extensions instead of exposing raw runtime APIs and pallet view functions to XCQ programs that extensions have associated types which can be tweaked by different runtimes, whereas runtime APIs do not? (If that were the only reason, I wonder whether runtime APIs could be extended to optionally support associated types to achieve the same without a new thing being needed?)

A1: Yes, the fundamental APIs exposed to XCQ programs are organized at the extension level.

A2: It's not the only reason. Runtime APIs cannot be recognized via some identifications, while extensions can be recognized via extension ids.

jsdw · 2024-11-13T10:17:47Z

text/0126-introduce-xcq.md

+```rust
+decl_runtime_apis! {
+    pub trait XcqApi {
+        fn execute_query(query: Vec<u8>, input: Vec<u8>, weight_limit: u64) -> XcqResult;


I guess any user can call this Runtime API and provide their XCQ program and input args? Is it expected that the runtime will have some default gas/weight limit to make it more difficult for users to supply long running/complex programs that DoS the node?

The weight_limit argument in this single API restricts the usage of a single execution. The overall resource limit is enforced by Runtime config and RPC rate limiting, which is out of the scope for a single RuntimeAPI. As for XCM usage, the gas/weight limit can be enforced by BuyExecution instruction.

indirection42 added 4 commits October 25, 2024 08:22

introduce xcq

cdf886c

update

ae88d8d

update

62174b1

update rfc number

fa97e4a

indirection42 changed the title ~~Introduce xcq~~ Introduce XCQ Oct 25, 2024

indirection42 mentioned this pull request Oct 28, 2024

RFC: Add an instruction about XCQ polkadot-fellows/xcm-format#71

Open

franciscoaguirre reviewed Oct 28, 2024

View reviewed changes

indirection42 added 4 commits October 29, 2024 19:55

add xcm section

740f5e0

rename PermissionController

bff1067

update

3678eee

add read-only execution suggestion

220f62d

indirection42 force-pushed the introduce-xcq branch from 0af3db3 to 220f62d Compare October 30, 2024 02:18

anaelleltd added the Proposed Is awaiting 3 formal reviews. label Nov 3, 2024

merge xcm rfc

6c637c3

xlc mentioned this pull request Nov 12, 2024

[tracking] Facade paritytech/polkadot-sdk#6441

Open

jsdw reviewed Nov 13, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Introduce XCQ #126

Introduce XCQ #126

indirection42 commented Oct 25, 2024 •

edited

Loading

franciscoaguirre Oct 28, 2024

franciscoaguirre Oct 28, 2024

franciscoaguirre Oct 28, 2024

indirection42 Oct 29, 2024

franciscoaguirre Oct 28, 2024

franciscoaguirre Oct 28, 2024

indirection42 Oct 30, 2024

franciscoaguirre Oct 28, 2024

jsdw Nov 13, 2024 •

edited

Loading

jsdw Nov 13, 2024 •

edited

Loading

indirection42 Nov 19, 2024

jsdw Nov 13, 2024

indirection42 Nov 19, 2024

	Therefore, A system is needed to serve as an intermediary layer between concrete chain runtime implementations and tools/UIs, to provide a unified interface for cross-chain queries.
	Therefore, a system is needed to serve as an intermediary layer between concrete chain runtime implementations and tools/UIs, to provide a unified interface for cross-chain queries.


		## Explanation

		The overall query pattern of the XCQ consists of three components:

	The overall query pattern of the XCQ consists of three components:
	The overall query pattern of XCQ consists of three components:

	fn execute_query(query: Vec<u8>, input: Vec<u8>, weight_limit: u64) -> XcqResult;
	fn execute_query(query: Vec<u8>, input: Vec<u8>, gas_limit: u64) -> XcqResult;


		## Future Directions and Related Material

		Since XCQ are supported both in off-chain and on-chain, a related XCM-Format RFC should be proposed.

Introduce XCQ #126

Are you sure you want to change the base?

Introduce XCQ #126

Conversation

indirection42 commented Oct 25, 2024 • edited Loading

Summary

Related RFC

Related Discussions

PoC implementations

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jsdw Nov 13, 2024 • edited Loading

Choose a reason for hiding this comment

jsdw Nov 13, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

indirection42 commented Oct 25, 2024 •

edited

Loading

jsdw Nov 13, 2024 •

edited

Loading

jsdw Nov 13, 2024 •

edited

Loading