Files
pezkuwi-subxt/cumulus
Branislav Kontur 575b8f8d15 Ensure xcm versions over bridge (on sending chains) (#2481)
## Summary

This pull request proposes a solution for improved control of the
versioned XCM flow over the bridge (across different consensus chains)
and resolves the situation where the sending chain/consensus has already
migrated to a higher XCM version than the receiving chain/consensus.

## Problem/Motivation

The current flow over the bridge involves a transfer from AssetHubRococo
(AHR) to BridgeHubRococo (BHR) to BridgeHubWestend (BHW) and finally to
AssetHubWestend (AHW), beginning with a reserve-backed transfer on AHR.

In this process:
1. AHR sends XCM `ExportMessage` through `XcmpQueue`, incorporating XCM
version checks using the `WrapVersion` feature, influenced by
`pallet_xcm::SupportedVersion` (managed by
`pallet_xcm::force_xcm_version` or version discovery).

2. BHR handles the `ExportMessage` instruction, utilizing the latest XCM
version. The `HaulBlobExporter` converts the inner XCM to
[`VersionedXcm::from`](https://github.com/paritytech/polkadot-sdk/blob/63ac2471aa0210f0ac9903bdd7d8f9351f9a635f/polkadot/xcm/xcm-builder/src/universal_exports.rs#L465-L467),
also using the latest XCM version.

However, challenges arise:
- Incompatibility when BHW uses a different version than BHR. For
instance, if BHR migrates to **XCMv4** while BHW remains on **XCMv3**,
BHR's `VersionedXcm::from` uses `VersionedXcm::V4` variant, causing
encoding issues for BHW.
  ```
	/// Just a simulation of possible error, which could happen on BHW
	/// (this code is based on actual master without XCMv4)
	let encoded = hex_literal::hex!("0400");
	println!("{:?}", VersionedXcm::<()>::decode(&mut &encoded[..]));

Err(Error { cause: None, desc: "Could not decode `VersionedXcm`, variant
doesn't exist" })
  ``` 
- Similar compatibility issues exist between AHR and AHW.

## Solution

This pull request introduces the following solutions:

1. **New trait `CheckVersion`** - added to the `xcm` module and exposing
`pallet_xcm::SupportedVersion`. This enhancement allows checking the
actual XCM version for desired destinations outside of the `pallet_xcm`
module.

2. **Version Check in `HaulBlobExporter`** uses `CheckVersion` to check
known/configured destination versions, ensuring compatibility. For
example, in the scenario mentioned, BHR can store the version `3` for
BHW. If BHR is on XCMv4, it will attempt to downgrade the message to
version `3` instead of using the latest version `4`.

3. **Version Check in `pallet-xcm-bridge-hub-router`** - this check
ensures compatibility with the real destination's XCM version,
preventing the unnecessary sending of messages to the local bridge hub
if versions are incompatible.

These additions aim to improve the control and compatibility of XCM
flows over the bridge and addressing issues related to version
mismatches.

## Possible alternative solution

_(More investigation is needed, and at the very least, it should extend
to XCMv4/5. If this proves to be a viable option, I can open an RFC for
XCM.)._

Add the `XcmVersion` attribute to the `ExportMessage` so that the
sending chain can determine, based on what is stored in
`pallet_xcm::SupportedVersion`, the version the destination is using.
This way, we may not need to handle the version in `HaulBlobExporter`.

```
ExportMessage {
	network: NetworkId,
	destination: InteriorMultiLocation,
	xcm: Xcm<()>
	destination_xcm_version: Version, // <- new attritbute
},
```

```
pub trait ExportXcm {
        fn validate(
		network: NetworkId,
		channel: u32,
		universal_source: &mut Option<InteriorMultiLocation>,
		destination: &mut Option<InteriorMultiLocation>,
		message: &mut Option<Xcm<()>>,
                destination_xcm_version: Version, , // <- new attritbute
	) -> SendResult<Self::Ticket>;
```

## Future Directions

This PR does not fix version discovery over bridge, further
investigation will be conducted here:
https://github.com/paritytech/polkadot-sdk/issues/2417.

## TODO

- [x] `pallet_xcm` mock for tests uses hard-coded XCM version `2` -
change to 3 or lastest?
- [x] fix `pallet-xcm-bridge-hub-router`
- [x] fix HaulBlobExporter with version determination
[here](https://github.com/paritytech/polkadot-sdk/blob/2183669d05f9b510f979a0cc3c7847707bacba2e/polkadot/xcm/xcm-builder/src/universal_exports.rs#L465)
- [x] add unit-tests to the runtimes
- [x] run benchmarks for `ExportMessage`
- [x] extend local run scripts about `force_xcm_version(dest, version)`
- [ ] when merged, prepare governance calls for Rococo/Westend
- [ ] add PRDoc

Part of: https://github.com/paritytech/parity-bridges-common/issues/2719

---------

Co-authored-by: command-bot <>
2023-12-12 17:04:26 +02:00
..
2020-05-18 17:17:34 +02:00

Cumulus ☁️

Doc

This repository contains both the Cumulus SDK and also specific chains implemented on top of this SDK.

If you only want to run a Polkadot Parachain Node, check out our container section.

Cumulus SDK

A set of tools for writing Substrate-based Polkadot parachains. Refer to the included overview for architectural details, and the Connect to a relay chain how-to guide for a guided walk-through of using these tools.

It's easy to write blockchains using Substrate, and the overhead of writing parachains' distribution, p2p, database, and synchronization layers should be just as low. This project aims to make it easy to write parachains for Polkadot by leveraging the power of Substrate.

Cumulus clouds are shaped sort of like dots; together they form a system that is intricate, beautiful and functional.

Consensus

parachain-consensus is a consensus engine for Substrate that follows a Polkadot relay chain. This will run a Polkadot node internally, and dictate to the client and synchronization algorithms which chain to follow, finalize, and treat as best.

Collator

A Polkadot collator for the parachain is implemented by the polkadot-parachain binary (previously called polkadot-collator).

You may run polkadot-parachain locally after building it or using one of the container option described here.

Relay Chain Interaction

To operate a parachain node, a connection to the corresponding relay chain is necessary. This can be achieved in one of three ways:

  1. Run a full relay chain node within the parachain node (default)
  2. Connect to an external relay chain node via WebSocket RPC
  3. Run a light client for the relay chain

In-process Relay Chain Node

If an external relay chain node is not specified (default behavior), then a full relay chain node is spawned within the same process.

This node has all of the typical components of a regular Polkadot node and will have to fully sync with the relay chain to work.

Example command
polkadot-parachain \
	--chain parachain-chainspec.json \
	--tmp \
	-- \
	--chain relaychain-chainspec.json

External Relay Chain Node

An external relay chain node is connected via WebsSocket RPC by using the --relay-chain-rpc-urls command line argument. This option accepts one or more space-separated WebSocket URLs to a full relay chain node. By default, only the first URL will be used, with the rest as a backup in case the connection to the first node is lost.

Parachain nodes using this feature won't have to fully sync with the relay chain to work, so in general they will use fewer system resources.

Note: At this time, any parachain nodes using this feature will still spawn a significantly cut-down relay chain node in-process. Even though they lack the majority of normal Polkadot subsystems, they will still need to connect directly to the relay chain network.

Example command
polkadot-parachain \
	--chain parachain-chainspec.json \
	--tmp \
	--relay-chain-rpc-urls \
		"ws://relaychain-rpc-endpoint:9944" \
		"ws://relaychain-rpc-endpoint-backup:9944" \
	-- \
	--chain relaychain-chainspec.json

Relay Chain Light Client

An internal relay chain light client provides a fast and lightweight approach for connecting to the relay chain network. It provides relay chain notifications and facilitates runtime calls.

To specify which chain the light client should connect to, users need to supply a relay chain chain-spec as part of the relay chain arguments.

Note: At this time, any parachain nodes using this feature will still spawn a significantly cut-down relay chain node in-process. Even though they lack the majority of normal Polkadot subsystems, they will still need to connect directly to the relay chain network.

Example command
polkadot-parachain \
	--chain parachain-chainspec.json \
	--tmp \
	--relay-chain-light-client \
	-- \
	--chain relaychain-chainspec.json

Installation and Setup

Before building Cumulus SDK based nodes / runtimes prepare your environment by following Substrate installation instructions.

To launch a local network, you can use zombienet for quick setup and experimentation or follow the manual setup.

Zombienet

We use Zombienet to spin up networks for integration tests and local networks. Follow these installation steps to set it up on your machine. A simple network specification with two relay chain nodes and one collator is located at zombienet/examples/small_network.toml.

Which provider should I use?

Zombienet offers multiple providers to run networks. Choose the one that best fits your needs:

  • Podman: Choose this if you want to spin up a network quick and easy.
  • Native: Choose this if you want to develop and deploy your changes. Requires compilation of the binaries.
  • Kubernetes: Choose this for advanced use-cases or running on cloud-infrastructure.

How to run

To run the example network, use the following commands:

# Podman provider
zombienet --provider podman spawn ./zombienet/examples/small_network.toml

# Native provider, assumes polkadot and polkadot-parachains binary in $PATH
zombienet --provider native spawn ./zombienet/examples/small_network.toml

Manual Setup

Launch the Relay Chain

# Clone
git clone https://github.com/paritytech/polkadot-sdk

# Compile Polkadot's required binaries
cargo build --release -p polkadot

# Generate a raw chain spec
./target/release/polkadot build-spec --chain rococo-local --disable-default-bootnode --raw > rococo-local-cfde.json

# Alice
./target/release/polkadot --chain rococo-local-cfde.json --alice --tmp

# Bob (In a separate terminal)
./target/release/polkadot --chain rococo-local-cfde.json --bob --tmp --port 30334

Launch the Parachain

# Compile
cargo build --release -p polkadot-parachain-bin

# Export genesis state
./target/release/polkadot-parachain export-genesis-state > genesis-state

# Export genesis wasm
./target/release/polkadot-parachain export-genesis-wasm > genesis-wasm

# Collator1
./target/release/polkadot-parachain --collator --alice --force-authoring \
  --tmp --port 40335 --rpc-port 9946 -- --chain rococo-local-cfde.json --port 30335

# Collator2
./target/release/polkadot-parachain --collator --bob --force-authoring \
  --tmp --port 40336 --rpc-port 9947 -- --chain rococo-local-cfde.json --port 30336

# Parachain Full Node 1
./target/release/polkadot-parachain --tmp --port 40337 --rpc-port 9948 -- \
  --chain rococo-local-cfde.json --port 30337

Register the parachain

image

Asset Hub 🪙

This repository also contains the Asset Hub runtimes. Asset Hub is a system parachain providing an asset store for the Polkadot ecosystem.

Build & Launch a Node

To run an Asset Hub node, you will need to compile the polkadot-parachain binary:

cargo build --release --locked --bin polkadot-parachain

Once the executable is built, launch the parachain node via:

CHAIN=asset-hub-westend # or asset-hub-kusama
./target/release/polkadot-parachain --chain $CHAIN

Refer to the setup instructions to run a local network for development.

Contracts 📝

See the contracts-rococo readme for details.

Bridge-hub 📝

See the bridge-hubs readme for details.

Rococo 👑

Rococo is becoming a Community Parachain Testbed for parachain teams in the Polkadot ecosystem. It supports multiple parachains with the differentiation of long-term connections and recurring short-term connections, to see which parachains are currently connected and how long they will be connected for see here.

Rococo is an elaborate style of design and the name describes the painstaking effort that has gone into this project.

Build & Launch Rococo Collators

Collators are similar to validators in the relay chain. These nodes build the blocks that will eventually be included by the relay chain for a parachain.

To run a Rococo collator you will need to compile the following binary:

cargo build --release --locked --bin polkadot-parachain

Once the executable is built, launch collators for each parachain (repeat once each for chain tick, trick, track):

./target/release/polkadot-parachain --chain $CHAIN --validator

You can also build using a container.

Parachains

The network uses horizontal message passing (HRMP) to enable communication between parachains and the relay chain and, in turn, between parachains. This means that every message is sent to the relay chain, and from the relay chain to its destination parachain.