Imagine you are a passionate blockchain engineer at the forefront of Web3 technology. You see countless opportunities:
30% APY liquidity mining on Acala
There are excellent lending opportunities on Moonbeam
Astar launched popular NFT projects
But to connect these opportunities, you need to face:
Smart Contract Development
The basic principle of cross-chain technology
Security of cross-chain transactions
Building practical cross-chain application scenarios
Code audit and security analysis
In order to write code more scientifically and reasonably, you also need to study in depth:
It all seems daunting!
However, you can't help but wonder if there is a tool that can allow you to bypass the complex cross-chain principles, security concerns, and even avoid the hardship of code learning, so that you can focus most of your energy on building cross-chain scenarios and optimizing user experience. Fortunately, Polkadot's cross-chain protocol: XCMP, may be the answer you are looking for.
Why should you pay attention to XCM?
Let's take a look at a real scenario: Xiao Ming is a DeFi player. He found a good lending opportunity on Moonbeam and a high-yield liquidity mining project on Acala. However, to participate in both projects at the same time, he needs to: first transfer assets from Moonbeam to a centralized exchange, wait for confirmation, withdraw from the exchange to Acala, and wait for confirmation again before he can start the operation. The whole process is not only time-consuming, but also requires high transaction fees, not to mention the risks of centralized exchanges in the middle. With XCM, this process can be simplified to: "Click "Cross-chain transfer to Acala and mine" on Moonbeam" Wait for a dozen seconds, tada! The transaction is completed! In the Polkadot ecosystem, XCM is like a "cross-chain pass" that allows your assets and operations to flow freely between different chains. Not only that, as a developer, you can even allow users to use the functions of other chains directly in your application, just as smoothly as switching between different services in the same super APP! The difference between XMC and traditional cross-chain bridges
In short, XCM (Cross-Consensus Message) is the "universal building block" of the Polkadot ecosystem. It is not an ordinary cross-chain bridge, but a new cross-chain communication format that can be freely combined like Lego blocks to build a variety of interesting applications. Traditional security bridges usually have two important technical components: 1) proof of correctness of source chain transactions 2) cross-chain message relay . Therefore, the security level of the cross-chain bridge depends not only on the chain security level of the source chain and the target chain, but also on the security level of the cross-chain bridge project. The real protocol of XCMP that supports Polkadot is the foundation of Polkadot: consensus shared security . That is to say, in the Polkadot ecosystem, the security level of all parachains is the same as Polkadot, and the correct transmission of cross-chain messages is also guaranteed by Polkadot. From the perspective of the model, if parachain is understood as a "big contract", then Polkadot and parachain are not a cross-chain network in the traditional sense. This is a super blockchain, but the communication between "applications/contracts" and "applications/contracts" is "asynchronous". This is why we can put aside the principles and security of XCM and focus only on business construction. Security of traditional cross-chain bridges: Source chain security + bridge security + target chain security = final security Security of Polkadot XCMP: Polkadot Relay Chain Security = Parachain Security = XCM Security Traditional cross-chain bridge: It’s like taking a ferry across a river. You have to queue up, buy tickets, and wait every time. XCM: Just like a city subway, you can swipe a card to get through without any obstacles XCMP can not only transfer assets, but also carry error handling, instructions, callbacks and custom information, making cross-chain communication more powerful and flexible. This leap in capabilities makes XCMP unique in the field of cross-chain communication, providing developers with unprecedented convenience and possibilities. XCM’s transmission channel is XCMP, which is an important cross-chain messaging infrastructure in the Polkadot ecosystem. The current channels are divided into two categories: Applicable scenarios: Communication between parachains and relay chains Parallel Chain <==(UMP/DMP)==> Relay Chain UMP: Upward Message Passing HRMP (Horizontal Messaging) Applicable scenarios: Communication between parallel chains currently needs to go through the relay chain. ParaA ==> Relay Chain ==> ParaB- Messages are forwarded via the relay chain
- Higher cost but stable and reliable
The protagonist appears: What is XCM
The messages transmitted through these channels are XCM (Cross-Chain Message). XCM, to be precise, is a message format and a standard for cross-chain and cross-consensus communication in the Polkadot ecosystem: it allows "arbitrary" data to be exchanged between different blockchains, and provides developers with a common language for writing across different chains, smart contract platforms, and Substrate modules. In short, by constructing cross-chain messages based on XCM, "arbitrary" messages can be routed along "arbitrary" paths between the Polkadot relaychain and parachain. 
Before you go any further, you should also know
At this point, we are only one step away from learning the XCM structure. Imagine you are building a cross-chain application. How do you accurately locate any resource on the chain? MultiLocation is a universal addressing system designed to solve this problem. Why do we need MultiLocation? The address of the traditional blockchain is represented by: 0x742d35Cc6634C0532925a3b844Bc454e4438f44e If you want to optimize further, you can identify the network: eth:0x742d35Cc6634C0532925a3b844Bc454e4438f44e sep:0x2a01008eaf04151687736326c9fea17e25fc5287 But there are still disadvantages to doing this:- Can only be used within a single chain
- Unable to express cross-chain relationships
In order to solve the above problems, MultiLocation chose the relative path description scheme: To understand this more vividly, assume that we now have two accounts, Alice on the Acala chain, and Bob on the Bifrost chain, and their account locations are as follows: If we look at it from the perspective of Polkadot, the relative paths of Alice and Bob are (counting downwards from child): Child -> Parachain(acala_chain_id)-> Account(alice) Child -> Parachain(bifrost_chain_id)-> Account(bob) If we look at it from Acala's perspective, then Bob's description is (Parent means counting upwards): Parent -> Parachain(bifrost_chain_id) -> Account(bob) That is to say, for the source chain, knowing the target account of the sending destination means knowing the path of this XCM message; similarly, the target chain will know the information of the source chain from the representation of the xcm sender, and use it to complete some security operations such as asset and account isolation on the target chain. From this, we can also summarize the key design principles of MultiLocation:- Positions are always relative to the current link
- Navigate up using parents
- Use interior to navigate downward/parallel
- Avoid unnecessary relay chain jumps
- Reduce the number of positioning levels
- Unified addressing format
- Support various on-chain resources
- Facilitates cross-chain interoperability
More importantly, MultiLocation not only involves the design of account identification in the cross-chain system, but is also an important cornerstone of cross-chain assets. It can help the target chain accurately locate the source information of cross-chain assets, thereby ensuring secure mapping on the target chain. The security risks unique to cross-chain systems usually include: account confusion, asset fraud, and routing hijacking, and the design concept of MultiLocation is a good solution. A Preliminary Study on XCM
XCM is a "cross-chain language" and it is quite simple. We can think of XCM as a bunch of instructions, and "executing XCM" is a virtual machine executing instructions. So we often see XCVM and XCM appear in pairs in many articles. The XCVM here is not a real virtual machine, but a virtual concept. To be precise, it is xcm-executor. When a bunch of XCM messages arrive at the target chain, they are taken out in order and executed one by one. https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/src/v5/mod.rs#L393 Directly looking at the specific instructions of XCM, we can roughly divide XCM instructions into 6 categories: asset operation, error handling, process control, permission control, general operation, and others. SetAppendix(Xcm < Call > ),
Other classes include some instructions related to query status, custom routing, and gasfee processing. We can see from the instruction classification of XCM that XCVM (XCM executor) is almost an asset-specific "simple virtual machine". With XCM, developers can be freed from the heavy labor of "cross-chain system principles", "business research", and "manual contract", and only need to focus on "how to combine XCM instructions to complete the business". At this point, we have touched the essence of XCM - the composability of XCM. Cross-chain Lego: XCM’s composability
At this point, we all have a basic understanding of XCM. Based on the combination of various XCM instructions, we can build a variety of cross-chain scenarios. In practical applications, Polkadot uses the composability of XCM to construct some basic XCM combination paradigms for the cross-chain asset transfer scenario. It has now become the de facto standard for cross-chain assets between relay chains and parachains, and between parachains. In Polkadot, there are two modes for cross-chain asset transfer: 1. Burn-mint 2. Reserve-Deposit. As the name implies, the behavior of these two modes on the target chain is not much different. What is important is whether the cross-chain assets are destroyed or locked in a certain "custodial account" on the source chain. From the difference between these two modes, we can see that burn-mint has very high trust requirements for the source chain and the target chain. Therefore, this mode of cross-chain transfer usually occurs in the cross-chain transfer between the relay chain and its system parachain, while the other three-party parachains usually use the withdraw-deposit mode. The Burn-mint transfer mode has a specific name in Polkadot, called teleport. 
Each teleport usually completes the business functions by the following three instructions: This lock-release mode of cross-chain transfer can safely transfer any asset. More specifically, the asset issuance location is on any Polkadot chain, and it is not limited to transferring assets on the source chain or the target chain. The figure shows the scenario of cross-chain transfer of C-chain assets between AB chains. It can be seen that only 5 XCM messages are needed to complete this relatively complex cross-chain asset transfer: Brainstorming: How does XCM construct sexy cross-chain applications? The XCM combination given here is for illustration only and cannot be used directly in a production environment. At this point, we have a basic understanding of how to construct XCM for cross-chain transfers. Now let’s imagine some interesting cross-chain applications and how to use XCM in combination to implement them. Scenario 1: Cross-chain liquidity aggregator Imagine a cross-chain trading system that can automatically find the best price among multiple DEXs: Scenario 2: Cross-chain lending agreement Depositing collateral on one chain and lending assets on another chain: Scenario 3: Cross-chain DAO governance Implement cross-chain voting and proposal execution: 
XCM, a new opportunity for Polkadot developers
Polkadot develops a new paradigm: from "chain building" to "bridge building" In addition to the above scenarios, we have endless cross-chain opportunities: cross-chain NFT transactions, cross-chain flash loan arbitrage solutions, asset income multi-chain configuration... In the past, in the Polkadot ecosystem, developers worked hard to learn substrate (polkadot-sdk) and develop their own app-chain.- The number of parallel chains has reached 45
- Coretime auction lowers entry barriers
- The demand for inter-chain interoperability is surging
- Cross-chain applications are experiencing explosive growth
At this time, a new door is opened: "Integrate the functions of multiple parallel chains and construct a cross-chain entrance" , which is deeply in line with the current development direction of the blockchain world - chain abstraction . In other words, we only need to understand the business code of other parallel chains and reasonably combine XCM instructions to create sexy cross-chain applications, and even become Polkadot's unicorn application. The future is cross-chain, and it starts with XCM. Getting started with XCM: https://wiki.polkadot.network/docs/learn-xcm-index
