# Cross-Consensus Query Language (XCQ)

**URL:** <https://forum.polkadot.network/t/cross-consensus-query-language-xcq/7583>\
**Category:** Tech Talk\
**Created:** [April 26, 2024, 4:39am UTC](https://forum.polkadot.network/t/cross-consensus-query-language-xcq/7583 "2024-04-26T04:39:17Z")\
**Posts on this page:** 1\
**Showing post:** 18

<div class="post-metadata">

**Author:** ![indirection42](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/indirection42/32/4894_2.png) [@indirection42](https://forum.polkadot.network/u/indirection42)\
**Post date:** [August 27, 2024, 7:16am UTC](https://forum.polkadot.network/t/cross-consensus-query-language-xcq/7583/18 "2024-08-27T07:16:34Z")

</div>

## Progress between May 23th - Aug 23th

### [xcq-executor](https://github.com/open-web3-stack/XCQ/tree/master/xcq-executor)

XCQ executor is the execution environment connecting host functions and guest programs.

### [xcq-extension](https://github.com/open-web3-stack/XCQ/tree/master/xcq-extension)

The extension system includes some macros to declare and implement extensions as well as useful structs connecting the executor.

- `decl_extensions` macro defines an extension as a Rust trait with optional associated types.
- `impl_extensions` macro generates extension implementations and metadata API.
- `ExtensionExecutor` connects extension implementations and `xcq-executor`. Host functions are aggregated under a unified `host_call` entry. Guest call requests are dispatched to corresponding extensions.
- `PermController` filters guest XCQ program calling requests.

### [xcq-types](https://github.com/open-web3-stack/XCQ/tree/master/xcq-types)

`xcq-types` is a meta-type system similar to [scale-info](https://github.com/paritytech/scale-info) but much simpler. A meta-type system is required to make different chains with different type definitions work via a common operation. The front-end codes will know how to construct call data to XCQ programs according to the metadata provided by different chains.

#### Limitations

- No generics support yet
- No type registry to compress type info and represent self-referential types

### [xcq-api](https://github.com/open-web3-stack/XCQ/tree/master/xcq-api)

Since the Polkavm program ABI only supports several numeric types, we need to pass pointers for passing custom types between host and guest. However, pointer operations like moving and reading the correct size of bytes are error-prone. So, we provide some macros to simplify the usage.

#### Example

The following XCQ program sums up the balances of several accounts and calculates the percent of the total supply.

- Every program is declared in a separate Rust mod
- `[xcq::call_def]` declares a host call to be used
- `[xcq::entrypoint]` declares an entrypoint function that executes the main logic

```rust
#[xcq_api::program]
mod sum_balance {
    #[xcq::call_def]
    fn balance(asset: u32, who: [u8; 32]) -> u64 {}
    #[xcq::call_def]
    fn total_supply(asset: u32) -> u64 {}

    #[xcq::entrypoint]
    fn sum_balance(balances: Vec<BalanceCall>, total_supply: TotalSupplyCall) -> u64 {
        let mut sum_balance = 0;
        for call in balances {
            sum_balance += call.call();
        }
        sum_balance * 100 / total_supply.call()
    }
}

```

#### Limitations

- No unified support yet.
- If the number of calls is not known in compile-time, the XCQ program bloats to several KBs because we need a global allocato ar to support `alloc::vec::Vec`.

## Upcoming tasks

- XCM use cases need to be considered. Ideally, we will have an XCM instruction for XCQ.
- Sumbit an XCQ RFC.

---

_[View the full topic](https://forum.polkadot.network/t/cross-consensus-query-language-xcq/7583)._