On November 21st, Bifrost supported the $MOVR/$GLMR liquid and cross chain staking, opening the minting of vMOVR and vGLMR, ushering in a new set of vToken series after vETH, vDOT, and vKSM.
MOVR (Moonriver) and GLMR (Moonbeam) are the native tokens of their respective protocols. Moonriver, a Kusama parachain, is the canary network of Moonbeam, a Polkadot parachain. vMOVR/vGLMR is the first set of vToken instances implemented by Bifrost based on XCMP (the current version is HRMP). The previous vDOT/vKSM was implemented based on VMP.
XCMP (Cross-Chain Message Passing) is a cross-chain message transmission protocol on Polkadot for cross-chain communication between parachains/parallel threads. VMP facilitates cross-chain communication between the parachain/parallel thread and relay chain.
XCM is a general cross-chain message format formulated by Polkadot.
XCM is not only for communication between parachains but also for communication between any two Substrate chains. Therefore, communication based on XCM is a broader concept.
We will now explain how Bifrost will support the minting and redemption of vMOVR/vGLMR with XCMP, then illustrate the process using vMOVR as an example.
As mentioned above in this article, all vTokens are native assets on the Bifrost chain and will be issued on this chain by default, to provide more convenience for cross-chain staking and integration.
Let’s start by listing the required components.
Bifrost Chain: This refers to the Bifrost Kusama Parachain. (Bifrost also has a Bifrost Polkadot Parachain)
Moonriver Chain: The chain is the canary network of Moonbeam, the parachain of Kusama.
Bifrost Sovereign Address: Bifrost chains have a Bifrost sovereign account under the control of runtime deployment. Each parachain/thread has its sovereign account.
Bifrost Sovereign Address on Moonriver: Each parachain/parallel thread has its sovereign account on the relay chain and other parachains/parallel threads. The code of the sovereign chain controls this address. Therefore, Bifrost does not need to create a hosted address on Moonriver but can use the Bifrost sovereign address on Moonriver to perform cross chain stakings and unbonds.
SLP Module: This is a runtime on the Bifrost chain and is responsible for issuing instructions related to vToken casting/redemption.
XCMP: We transmit XCM instructions through it.
Users who want immediate access to their MOVR and do not want to wait for the unlocking period opt for a flash redemption, which is essentially a swap and therefore requires a fee to compensate the liquidity provider.
As both Bifrost Kusama Parachain and Moonriver are Kusama parachains, direct XCMP communication between the two is possible. vMOVR/vGLMR uses XCMP for both minting and cross-chain communication during redemption. We know that XCMP is the native communication bridge between polka-parachains, and using XCMP does not introduce new security risks like other third-party cross-chain bridges.
The security of vMOVR/vGLMR is Polkadot Relay Chain level security.
To understand how XCMP works, it is important to first understand a few core concepts.
If two parachains (A and B) need to communicate, they must establish a unidirectional channel. For bi-directional communication, parachains A and B must create two channels (A→B Channel & B→A Channel).
When parachain A creates an A→B Channel with parachain B, an egress (exit queue) establishes on parachain A and an ingress (entry queue) on parachain B.
XCMP uses a message tree structure, where all pending messages form a Merkle tree as leaf nodes, and the root of the tree is called MR (Massage Root), and each new message inserted as a leaf node creates a new MR.
Let’s look at the message lifecycle in XCMP: (Take A→B Channel as an example)
A user on Chain A initiates a cross-chain request via an application on the source chain and wants to send a message M to Chain B. Chain A hosts the message. The message will be put into a dedicated egress queue for Chain B on Chain A (we abbreviate it as Egress A→B), with its inclusion in the latest MR.
The collector of Chain A will put the latest MR into the block header when packing the current block. When the verifier assigned to Chain A by the relay chain verifies the block, it will be submitted to the relay chain and contained by the relay chain blocks. At this point, we consider the relay chain to have verified the MR.
The collector of Chain B continuously polls the exit queues created for Chain B on all other chains, including Egress A → B. The collector of Chain B puts the original message and MR queue from Egress A → B into its own corresponding entry queue: Ingress A → B. (* There is another argument that this process is not done by the collector but by the verifier; the design of this point partially determined in XCMP, but who does it is not a crucial point in the XCMP format, as the task is trustless and anyone can do it).
The verifier of Chain B gets the latest MR of Channel A→B verified by the relay chain from the relay chain.
Chain B uses this MR to determine which messages of Ingress A→B have been included in the relay chain and then updates the status of these messages to verify.
The validated messages are then ready to be executed by the target application.
For ease of presentation, we describe the message flow of only one Channel. XCMP processes all Channels simultaneously when processing messages across the chain. The relay chain maintains a CST (Channel State Table) to store the MR of all Channels.
We have found that XCMP has a strategic design to make cross-chain messaging between parachains/threads fast, efficient, secure, and cheap.
Fast: the time it takes for a block packing from the sending chain, validation, submission to the relay chain, and finalized at the relay chain is so short that the delay is almost imperceivable.
Ordered: With Egress and Ingress, all messages within a Channel follow a strict queue structure with a clear order of precedence. (There is no timing property between messages in different Channels.) Messages remain in Egress until the target chain executes them and remain in Egress until the target chain runs them. The model captures all messages.
Secure: the relay chain validates all cross-chain messages.
Inexpensive: Although the relay chain validates all messages, the message tree mechanism allows the relay chain to validate only the MR and not the original message directly, and the original message is passed through the sending and receiving chains themselves, not through the relay chain. The process avoids taking up the resources of the relay chain to the greatest extent possible, thus keeping the cost of cross-chain messaging at a low level.
Cross-chain messaging is the basis for cross-chain interoperability, be it cross-chain asset transfer, cross-chain function invocation, cross chain staking, or cross-chain computing. As such, XCMP provides interoperability across a multitude of parachains.
Bifrost, one of the first DeFi projects based in the Polkadot ecosystem, has a solid belief in Polkadot’s multi-chain architecture, which stems from our knowledge of multi-chain interoperability. Cosmos is also a multi-chain architecture and can achieve good interoperability through IBC; however, the security of each Zone of Cosmos is fragmented, and there is a trust issue between each Zone. Zones have to choose which Zone to trust and which not to trust.
Although Cosmos 2.0 added the option to rent security from the Hub, this still does not ensure that all zones renting security are at the same security level. Conversely, the first feature of Polkadot’s multi-chain architecture is shared security. The security level of each parachain is consistent with that of a relay chain and can be trusted unconditionally, and on top of that, the level of security for interoperability provided by XCMP is also consistent with that of a relay chain.
Gavin Wood mentioned in a presentation that XCMP is only half of the Polkadot cross-chain solution. The other half is XCM, a message format standard developed by Polkadot. In XCMP, all cross-chain requests are formatted as XCM before they can enter Egress, and the XCM can contain a set of instructions that the target application will execute when it receives the XCM message.
XCM is the standard format for XCMP communication and cross-chain communication between all Substrate chains. Wood hopes that XCM’s application will include more heterogeneous cross-chain scenarios. Thus, XCM-based communication will be a broader concept than XCMP, which can be extended to all Substrate chains, thus building its pan-Substrate ecosystem. It may even have the potential to break through the Substrate ecosystem and connect more heterogeneous ecosystems, including the EVM ecosystem.
While select Web3 applications, such as games and social, may not require much interoperability, DeFi applications are the most demanding. Interoperability is the foundation of DeFi applications. Bifrost, a DeFi application, needs interoperability and its vTokens to circulate widely, be integrated with more DeFi applications, and interact with more DeFi applications.
A parachain ecosystem connected by XCMP would be a multi-practice system with seamless interoperability and no cross-chain credit considerations. We believe that such a system would empower Bifrost and vTokens. In addition, XCM-based communication can take us to even greater horizons. vMOVR/vGLMR is where we set sail and where we will end up in the stars.
