Files
pezkuwi-subxt/polkadot
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
..
2023-11-28 14:23:25 +01:00
2023-09-04 12:02:32 +03:00
2023-12-12 14:29:56 +00:00
2023-12-12 14:29:56 +00:00

Polkadot

Implementation of a https://polkadot.network node in Rust based on the Substrate framework.

The README provides information about installing the polkadot binary and developing on the codebase. For more specific guides, like how to run a validator node, see the Polkadot Wiki.

Installation

Using a pre-compiled binary

If you just wish to run a Polkadot node without compiling it yourself, you may either run the latest binary from our releases page, or install Polkadot from one of our package repositories.

Debian-based (Debian, Ubuntu)

Currently supports Debian 10 (Buster) and Ubuntu 20.04 (Focal), and derivatives. Run the following commands as the root user.

# Import the security@parity.io GPG key
gpg --recv-keys --keyserver hkps://keys.mailvelope.com 9D4B2B6EB8F97156D19669A9FF0812D491B96798
gpg --export 9D4B2B6EB8F97156D19669A9FF0812D491B96798 > /usr/share/keyrings/parity.gpg
# Add the Parity repository and update the package index
echo 'deb [signed-by=/usr/share/keyrings/parity.gpg] https://releases.parity.io/deb release main' > /etc/apt/sources.list.d/parity.list
apt update
# Install the `parity-keyring` package - This will ensure the GPG key
# used by APT remains up-to-date
apt install parity-keyring
# Install polkadot
apt install polkadot

Installation from the Debian repository will create a systemd service that can be used to run a Polkadot node. This is disabled by default, and can be started by running systemctl start polkadot on demand (use systemctl enable polkadot to make it auto-start after reboot). By default, it will run as the polkadot user. Command-line flags passed to the binary can be customized by editing /etc/default/polkadot. This file will not be overwritten on updating Polkadot. You may also just run the node directly from the command-line.

Building

Since the Polkadot node is based on Substrate, first set up your build environment according to the Substrate installation instructions.

Install via Cargo

Make sure you have the support software installed from the Build from Source section below this section.

If you want to install Polkadot in your PATH, you can do so with:

cargo install --git https://github.com/paritytech/polkadot-sdk --tag <version> polkadot --locked

Build from Source

Build the client by cloning this repository and running the following commands from the root directory of the repo:

git checkout <latest tagged release>
cargo build --release

Note: if you want to move the built polkadot binary somewhere (e.g. into $PATH) you will also need to move polkadot-execute-worker and polkadot-prepare-worker. You can let cargo do all this for you by running:

cargo install --path . --locked

Build from Source with Docker

You can also build from source using Parity CI docker image:

git checkout <latest tagged release>
docker run --rm -it -w /shellhere/polkadot \
                    -v $(pwd):/shellhere/polkadot \
                    paritytech/ci-linux:production cargo build --release
sudo chown -R $(id -u):$(id -g) target/

If you want to reproduce other steps of CI process you can use the following guide.

Networks

This repo supports runtimes for Polkadot, Kusama, and Westend.

Connect to Polkadot Mainnet

Connect to the global Polkadot Mainnet network by running:

../target/release/polkadot --chain=polkadot

You can see your node on [telemetry] (set a custom name with --name "my custom name").

telemetry: https://telemetry.polkadot.io/#list/Polkadot

Connect to the "Kusama" Canary Network

Connect to the global Kusama canary network by running:

../target/release/polkadot --chain=kusama

You can see your node on [telemetry] (set a custom name with --name "my custom name").

telemetry: https://telemetry.polkadot.io/#list/Kusama

Connect to the Westend Testnet

Connect to the global Westend testnet by running:

../target/release/polkadot --chain=westend

You can see your node on [telemetry] (set a custom name with --name "my custom name").

telemetry: https://telemetry.polkadot.io/#list/Westend

Obtaining DOTs

If you want to do anything on Polkadot, Kusama, or Westend, then you'll need to get an account and some DOT, KSM, or WND tokens, respectively. Follow the instructions on the Wiki to obtain tokens for your testnet of choice.

Hacking on Polkadot

If you'd actually like to hack on Polkadot, you can grab the source code and build it. Ensure you have Rust and the support software installed.

Then, grab the Polkadot source code:

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

Then build the code. You will need to build in release mode (--release) to start a network. Only use debug mode for development (faster compile times for development and testing).

cargo build

You can run the tests if you like:

cargo test --workspace --profile testnet
# Or run only the tests for specified crated
cargo test -p <crate-name> --profile testnet

You can start a development chain with:

cargo run --bin polkadot -- --dev

Detailed logs may be shown by running the node with the following environment variables set:

RUST_LOG=debug RUST_BACKTRACE=1 cargo run --bin polkadot-- --dev

Development

You can run a simple single-node development "network" on your machine by running:

cargo run --bin polkadot --release -- --dev

You can muck around by heading to https://polkadot.js.org/apps and choose "Local Node" from the Settings menu.

Local Two-node Testnet

If you want to see the multi-node consensus algorithm in action locally, then you can create a local testnet. You'll need two terminals open. In one, run:

polkadot --dev --alice -d /tmp/alice

And in the other, run:

polkadot --dev --bob -d /tmp/bob --bootnodes '/ip4/127.0.0.1/tcp/30333/p2p/ALICE_BOOTNODE_ID_HERE'

Ensure you replace ALICE_BOOTNODE_ID_HERE with the node ID from the output of the first terminal.

Monitoring

Setup Prometheus and Grafana.

Once you set this up you can take a look at the Polkadot Grafana dashboards that we currently maintain.

Using Docker

Using Docker

Shell Completion

Shell Completion

Contributing

Contributing Guidelines

Contribution Guidelines

Contributor Code of Conduct

Code of Conduct

License

Polkadot is GPL 3.0 licensed.