A Brief Overview of Auditing XCMv2

Introduction

Parity Tech is actively working on developments related to the Polkadot ecosystem. Polkadot recently launched the crowdloan process as part of the long-planned objective of creating a network of blockchains interconnected via a relay chain to perform cross-chain exchanges.

In this context, Parity is working on XCM (Cross-Consensus Messaging) which provides a common format enabling Substrate-based blockchains to communicate with the relay chain and between each other. This component from the original Polkadot design is essential for Polkadot's multichain network. It enables both fungible and non-fungible asset transfers and also remote extrinsic calls.

Bridges and cross-chain technologies, in general, will play an essential role in the upcoming months or years to interconnect blockchains that are not necessarily working with the same technology or consensus rules. Among these are Hop for EVM blockchains, Interlay to bridge Bitcoin to Polkadot or Axelar Network, which aims at bridging multiple blockchain technologies.

XCM follows a similar goal and aims at bridging any kind of consensus in the future. Polkadot's founder Gavin Wood provides insights of XCM goals as "a language communicating ideas between consensus systems" [1].

Quarkslab conducted an audit of XCMv2 before parachains obtained a slot on the Polkadot relay chain and thus before the activation of the support in their blockchain. An additional security audit had already been performed by another security company.

The audit aimed at finding any cross-chain-related security issues, like incorrect lock/unlock or burn/mint on both chains, or any fairness issues between chains. This also includes logical bugs, denial-of-service and any misconfiguration (of default settings) that can have a security impact. The audit did not reveal any meaningful security-related issues.

This blog post aims at providing a glimpse of the internal working of XCM transactions and more especially the VM-based design for processing messages. It also highlights the key security and sanity checks to be performed before activating XCM on a parachain.

A Quick Dive in the XCM Virtual Machine

The XCM design and the two main use-cases — reserve transfer assets and teleport assets — have thoroughly been described by Gavin Wood in a blog post trilogy [1], [2], [3] and a workshop by Shawn Tabrizi [7]. Moonbeam also provides multiple educational contents about XCM and their usage with XC-20 tokens [4], [5].

While user applications of XCM (assets transfers, etc.) have been well described, let us focus on what's happening under the hood when transferring assets between two chains. The core component is the XCM virtual machine (XCVM). Indeed, messages exchanged are scale-encoded [6] instruction opcodes. A message is essentially a list of instructions that perform various actions like withdrawing assets from an account, depositing them, initiating a transfer, etc.

When receiving a new message, a new VM is instantiated for the lifetime of the message execution. Some instructions update registers of the VM. These registers hold the origin (identity performing the action), holding (assets manipulated), and a trader handling weight costs, surplus, and refunded amounts. The VM also contains an instruction pointer addressing the current message instruction to execute. Similarly, it contains registers pointing to error handlers and appendix handlers.

Let's consider a teleport asset transfer from the relay chain to a parachain. In this scenario, the user withdraws funds from its local account and transfers them to the XCVM, which will eventually burn the asset. Then, the chain has to transmit a message to the remote chain to mint and deposit the equivalent amount of assets into the user's account on the parachain. The complete initial message is the following:

Xcm(vec![
    WithdrawAsset(assets),
    InitiateTeleport {
        assets: Wild(All),
        dest,
        Xcm(vec![
            BuyExecution { fees, weight_limit },
            DepositAsset { assets: Wild(All), max_assets, beneficiary },
        ]);
    }
]);

The following animation shows the broad steps performed by the XCM pallet teleport_assets call, its processing by the XCM executor and its underlying XCVM, up to the final deposit on the remote account (here Alice).

Note that in this scenario, the destination chains have to accept the originating chain as a teleporter, i.e., an origin from which the receiver can trust that the sender rightfully destroyed assets before teleporting them, in its own XCM configuration. Otherwise, the execution of ReceiveTeleportedAsset on the destination chain will reject the message as the origin register will be untrusted. That is one of the reasons why properly configuring XCM is a critical task. Let's discuss a few aspects of the XCM configuration.

Checklist before activating XCM

Parachain developers do not necessarily need to understand the deep intricacies of the XCM executor, but the pallet configuration leaves many levers of configuration that should be handled with care. Indeed, some configuration aspects are interdependent as highlighted in the report. Here is a quick memo of things to verify before activating XCM or accepting exchanging messages with a chain.

In the following list, elements of the XCM pallet and the XCM executor configuration are mixed, in fact, the XCM executor configuration is nested as a configuration element of the XCM pallet. They are marked with the "pallet" or the "executor" (or "both") annotation.

Audit Report

The audit was carried out by two security engineers for a duration of 50 days. It was performed respectively on Polkadot runtime v0.9.13 and Cumulus v6.0.0. It did not uncover important security issues. Yet, the report discusses and describes the underlying security mechanisms of multiple XCM components. It can thus be interesting for anyone to dig into XCM inner workings.

The full audit report can be found here:

Conclusion

Configuring XCM should be done in a very preserving manner by denying all by default. Then, only in a discretionary way, chains should enable some messages to pass through. Most of the XCM asset transfer security boils down to deciding who is trusted as a reserve or as a teleport origin. This needs to be done with care because, when receiving assets, there are currently no mechanisms to ensure they have been properly locked/burnt on the originating chain. In this setting, the trust is shared and both chains assume the other one to behave well.

Cross-chain communication protocols are developing fast, and most of them are in their infancy in terms of usage and potential use-cases. In Polkadot, XCMv2 is already deployed on the relay chain. Furthermore, the next version, XCMv3 [8], is already under development to bring new features and improve the current version.

We would like to thank Parity for making this assessment possible and for their responsiveness during the audit.