Into_XCM_02: A Format
For blockchains to work together and form the basis of Web3, they need a common language for communication. Polkadot attempts to set the standard with XCM, a powerful format for secure messaging across Polkadot-native parachains and with external networks via bridges.
This article will provide an overview of Polkadot’s Cross-Consensus Messaging format (XCM).
basics
XCM is a cross-consensus messaging format. It is a language that consensus systems like blockchains could use to communicate with each other. XCM allows protocols to define how a message should be executed on a remote protocol.
XCM by itself cannot send messages between consensus systems but rely on transport protocols to send messages across protocols. At the core of XCM message communication is three transport protocols:
Upward message passing (UMP) allows parachains to send messages to their relay chain.
Downward Message Passing (DMP) allows the relay chain to pass messages to one of its parachains.
Cross-consensus message passing (XCMP) allows the parachains to send messages to each other.
A message itself is a program. It is composed of one or more XCM instructions. Each instruction executes until it runs to the end or hits an error and gracefully halts.
the structure
At the core of XCM message orchestration lies XCM virtual machine (XCVM). XCVM is an ultra-high-level non-Turing-complete execution environment. It is designed to be roughly at the same level as transactions, generic, and with tight constraints.
The XCVM includes several registers and has access to the overall state of the consensus system on which it is hosted. An instruction might change the state of a register, and/or the state of the consensus system.
The XCVM executes the instructions in a message and provides some guarantee that the result of this execution will be orchestrated.
One such instruction could be TransferAsset which is used to transfer an asset to some address on the remote protocol. It is told which asset(s) to transfer and to whom or where the asset is to be transferred. In a message, TransferAsset could be viewed like so:
enum Instructions {
TransferAsset {
assets: MultiAssets,
beneficiary: MultiLocation,
}
/* snip */
}The TransferAsset instruction roughly translates to: “transfer my asset described as assets to a recipient described as beneficiary".
When a message is executed, the underlying transport protocol sets the register to reflect the origin of the message.
data types
Every message is described unambiguously using specific wrappers around the details of an instruction. These wrappers are called data types, or types for short. Types are fundamental ideas in XCM. They are essentially used to represent assets and locations on the different chains. Types can also describe specific desired ideas using XCM.
XCM describes locations on-chain using the MultiLocation type. The MultiLocation type identifies any single location that exists within a consensus system. MultiLocation can represent the location of anything that exists on-chain. This includes the location of assets on a blockchain as well as places to send XCM messages.
Locations are hierarchical; some consensus systems like parachains exist within a larger consensus system like Polkadot. The parachain is said to be interior to Polkadot and parachain asset locations are said to be interior locations.
XCM's MultiLocation describes an asset location relative to the chain that interprets a message. Conceptually, locations are described similarly to the path to how a file is described but without a root folder. Like so: parent_folder/child_folder/file.
An XCM location can be described like so: parent_chain/interior_chain/location
Each component of the location (eg. parent_chain) is followed by several junctions, all separated by /. Junctions identify an interior location within its encapsulating consensus system. If there are no parents or junctions, then the location is said to be Here. Here describes the location where the message is currently interpreted.
Similar to locations, XCM is designed to describe different kinds of assets on a chain. XCM can describe assets using four types: MultiAsset, MultiAssets, WildMultiAsset, and MultiAssetFilter.
A representation of the MultiAsset type could look like so:
struct MultiAsset {
id: AssetId,
fun: Fungibility,
}MultiAsset defines an asset with two fields; id and fun. id provides the identity of the asset which is described as AssetId. For fungible asset, id is the location of an asset and an optional name that defines an asset. For NFTs, id identifies the asset class and the instance of an asset in the instruction.
fun indicate if an asset is fungible or non-fungible. If the asset is fungible, it must be associated with an amount greater than zero. A non-fungible asset must indicate the instance of the asset.
holding register
The Holding Registers serve an important function during the execution of XCM instructions. A Holding Register is a temporary location associated with an instruction that is being executed. It temporarily holds assets associated with an instruction that is being executed.
Conclusion
Polkadot’s XCM is positioned to be a language for building innovative new cross-chain applications and services. Giving applications the ability to span multiple blockchains allows them to leverage the key features and strengths of each for new interoperable use cases.
like this article?
Keep an eye out here to learn more about XCM.
kusama address: 16RTtFPL4RA6pJW7iYVnREgBteEepZFCcJtBrJq1SmvbCrq
