XCM+

Cross Consensus Messaging

The inter-chain communication modules of ATLETA will be engaged once fundamental operational processes are finalized in mainnet.

Originally developed by the Web3 Foundation, XCM (Cross Consensus Messaging) is a generic communication framework that enables the transference of arbitrary information between compatible and non-compatible blockchains through the use of a trusted relay point.

XCM is the basis for interoperability used by ATLETA.

XCM is NOT a protocol and it is not the element responsible for passing messages; it is the outline that standardizes how messages are structured, interpreted, and what is included in them. XCM relies on a composition of external transportation methods.

Transportation Methods

XCM currently utilizes 3 different transportation methods, HRMP, XCMP, and VMP, with plans to actualize a broader implementation capable of leveraging Web 2 modalities (such as TCP and HTTP).

HRMP (Horizontal Relay-routed Message Passing) The original message passing protocol responsible for allowing parachains the right to communicate pseudo-directly. HRMP is resource intensive and partially permissioned, demanding the nomination of a relay point through the governance module for messages to hop through. HRMP is being phased out as XCMP becomes production ready.

XCMP (Cross-Chain Message Passing) The idealized version of communication intended to replace HRMP. Instead of having a relay point deal with the reception, processing, and dissemination of messages, with XCMP chains utilizes a queuing mechanism that removes the burden of processing and validating, allowing validators to simple relay messages from one chain to the other. Moreover, XCMP removes the governance requirements and allows for chains to establish connections permissionlessly (permissions between networks will still be required, but no permissions from the source chain {ATLETA})

VMP (Vertical Message Passing)​ VMP applies only whenever the nominated relay point is ATLETA and specifies the direction of the message passing. Directions only have two options, they are either UMP (Upward Message Passing) or DMP (Downward Message Passing). UMP implies the transfer of a message from a parachain to the relay chain and DMP implies the transfer of a message from the relay chain to a parachain.

Bridges Even though XCM implies direct information transfer channels, the framework can be used in conjunction with other, external transportation methods outside of the substrate ecosystem to enable asset transfers between non-compatible networks.

XCM Design Principles

Designed to be capable of handling any arbitrary message type (remote contract calls, data sharing, asset transfers, et al.); XCM is based on four (4) key design principles:

1. Asynchronous: Remove the dependencies of networks having to align their schedules. XCM messages do not assume that origination source, nor their destinations will be completing a block.

2. Absolute: Remove potential issues with message delivery or interpretation. All messages sent using XCM are processed accurately, chronologically, and timely.

3. Asymmetric: By using a "no expectation of response" approach, XCM messages remove automated communicative burdens from involved parties. When a message is sent, there is no immediate response of its delivery; thus leaving it up to the entities involved to engage in further communication.

4. Agnostic: By generalizing the informational load itself, we are removing assumptions about consensus mechanisms and enabling otherwise non-compatible networks with direct communicative capabilities.

It is important to note that XCM, in its current state, relies on strong Trust Assumptions between communicating entities. Thus, making it a promising solution in trusted environments; XCM is not intended to be used in hostile settings.

XCM Asset Logistics

XCM has two methods of transferring assets based on the logical demands of the extrinsic call being made; Teleporting and Transfer Reservation. Both provide the same level of guarantees in terms of results but utilize fundamentally different instruction sets, exhibiting different behavior.

Teleporting Teleportation is a two-step process not dissimilar from bridging: 1) Taking tokens out of circulation (burning) on the source chain 2) Bringing token into circulation (minting) at a specified address on the destination chain. While the perfect set-up would have some form of atomicity (both events happening, or else the transactions revert); the current logical model demand sequential processing. Given that assets on one chain could have different inherent properties on another (due to architectural primitives or asset standards); Teleportation implies the presence of absolute trust between both of the involved networks. The networks must conduct additional independent verifications that tokens have been burned and minted.

Transfer Reservation Transferring assets via reservations implies delegating trust to a credibly neutral third party. Here, assets being destroyed or minted, rather they are held in transitory custody/escrowed and re-balanced on their respective destinations equally. Under the Transfer Reservation model, atomicity becomes possible, but requires an additional service to ensure balanced on the destination chains do not exceed the reserve holdings.

Ex: Party A want to convert their USDt (on Tron Network) into $ATLA. Party B wants to convert their $ATLA into USDt (on Tron Network). Rather than risking the fees, slippage, front running, and other implications of engaging in open market activities, they negotiate an OTC deal. Party A send their USDt to a destination address, while Party B sends their $ATLA. Once both actions have been confirmed by their respective networks, ATLETA would unlock the transaction; atomically balancing both side's destination addresses with the assets.

Use Case

The applications of XCM are far reaching and can be transformative for the overall crypto, blockchain, and Web3 industry. However, understanding how XCM ultimately applies to the end users is not immediately intuitive and can be better expressed through a brief simulation.

Remote Calls ATLETA is connected to Ethereum. A user has an account on ATLETA and Ethereum. Assuming XCM is enabled and both chains trust the messages; the user can delegate his Ethereum account's call rights to his ATLETA address (making the ATLETA network address the owner of the account). Then, the user can initiate activities on his Ethereum account from the ATLETA account. A possible use case would be an emergency backstop for fund movement. The logic is pre-set such that, IF the Ethereum account attempts to execute any transaction directly (without having authorized signature from the ATLETA network account), then the account on ATLETA would administer a forced withdrawal and move all of the accounts assets to a different specified address.

---

* Initially, ATLETA will utilize XCM externally (via integrations with existing subtrate-based networks), move into an internal model (enabling native parachain communication), and ultimately, given the rapid pace of development taking place with XCM as well as alternative interoperability protocols (such as IBC), ATLETA anticipates implementing a more sophisticated hybrid solution in the future.