The XCVM is one of Composable’s fundamental solutions for cross-chain interoperability. By providing the infrastructure and necessary tooling to create cross-chain applications, Composable is ushering in a new era of innovation within the DeFi space. Through the unification of the Polkadot, Cosmos and EVM-based ecosystems, developers building on the XCVM will be able to architect applications with farther reach than ever before. As we have released the initial XCVM specification on GitHub, in this article we will provide an overview of the XCVM’s core architecture and features, along with specific use case examples.
What is the XCVM?
The XCVM can best be described as a stateful system which encompasses multiple chains. What this means is that the XCVM tracks the state of accounts across each of the blockchains it is connected to such as; our parachains, Ethereum, and Cosmos. Thus, all of the contracts we have written on these chains come together to form an asynchronous, cross-chain virtual machine. The XCVM is then capable of handling:
- Cross-chain identities and proxies
- Account state
- Bridging
Abstracting the complexity of dealing with such things away from developers will help reduce errors, and vulnerabilities, and ultimately lead to a safer and more intuitive user experience.
Additionally, the XCVM can be thought of as an application-level messaging protocol. In his talk at Unchained, our CTO, Karel Kubat provided a concise example of how this can be thought of in more traditional terms. The bridging infrastructure we have built on top of IBC and XCM is akin to the TCP.
“TCP stands for Transmission Control Protocol, a communications standard that enables application programs and computing devices to exchange messages over a network. It is designed to send packets across the internet and ensure the successful delivery of data and messages over networks.”
Similar to how TCP allows different computing devices to exchange messages over a network, our bridging infrastructure e.g Centauri allows for the trustless exchange of messages across various blockchains. With Centauri and Mosaic acting as an equivalent to TCP, the XCVM is then able to fulfill the role of HTTP, i.e to make requests in a predetermined language, that language being HTTP in Web2. In our case, that language is the XCVM instruction set, which will be covered in more detail later on.
Akin to how Web2 developers utilize HTTP to build web applications, Web3 developers can use the XCVM to build cross-chain decentralized applications (dApps). An example of what this will look like will be deconstructed in detail later in this article. But first a look at message handling and the XCVM instruction set.
Architecture
The XCVM refers to a set of on-chain contracts, as well as an interchain system of bridges and relayers. What this means is that the XCVM is capable of orchestrating communication between applications which live on different blockchains. The XCVM is able to accomplish this by acting as a generic interface which smart contracts can interact with.
The XCVM itself is composed of various components which vary depending on the chain. For example in Substrate the XCVM’s implementation may be done as a pallet, in Cosmos, it could be a Cosmos SDK module, or it could be a set of contracts on an EVM chain. These choices vary depending on gas optimizations, engineering standards and security practices. The general architecture of the XCVM remains the same, regardless of how its implementation may vary based on the chain/execution environment. This architecture is described below, followed by a flowchart which demonstrates a typical XCVM contract deployment:
Encoding
The XCVM is bridge agnostic, as long as the underlying bridging protocol is capable of transmitting bytes across chains. Different chains may choose to accept different encoding as the main entry point for contract calls. Chain-to-chain calls are always in a single encoding, protobuf, which is used within the transport.
Gateway
Gateway contracts are responsible for the whitelisting of bridges, and assets, and annotating the incoming program for use by the router and XCVM interpreter. This is done so that they are aware of what type of bridge was used (IBC, XCM, trusted) because this will have an effect on program functionality. In trusted bridges, message authenticity cannot be guaranteed, and thus the usage of trusted bridges is opt-in.
Router
Not to be confused with the routing layer. The router is responsible for keeping track of interpreter instances. For each smart contract within another ecosystem, we will have a separate XCVM interpreter instance. The router also keeps track of the addresses in use across these ecosystems, creating new addresses where necessary to allow the parent contract to manage positions and interact with other smart contracts transparently. Additionally, the router either instantiates or finds the previous instance of your VM, and finally transfers the funds to the interpreter.
Interpreter
The XCVM interpreter is a bytecode-like interpreter tailored to handle application logic. The XCVM program is a series of instructions that are executed in sequence.
A flowchart detailing the interaction between these modules can be seen below:
The XCVM instruction set
With the XCVM instruction set developers will be able to build applications that express a wide variety of logic using only 3 (soon to be 4) core instructions:
- Transfer — used for sending funds from the interpreter instance to another account on the same chain
- Call — used to call other smart contracts on the same chain
- Spawn — calls into the gateway to instantiate a new XCVM interpreter instance on another chain.
- Query — still under development, but will allow for contracts to check the state of account on different instances of the XCVM interpreter.
A lending example
Our CTO Karel provided an example of what is possible with these 3 instructions at the Unchained Conference where a user; deposits funds from one chain, takes out a loan on another chain, and receives their funds on the origin chain:
Additional tooling
In addition to the XCVM instruction set, Composable has developed additional tooling to support developers who seek to build upon our infrastructure.
Open Transport Protocol (OTP)
Open transport protocol (OTP) is our solution for bridge abstraction. OTP ensures that all bridges that are capable of sending messages or tokens across chains can be registered to our system. Thus allowing XCVM developers the ability to interact across more ecosystems. Although our primary focus remains on providing trustless infrastructure through the use of IBC and XCM, OTP opens the door for integrations with projects such as Wormhole for developers who wish to use their services.
CNS
CNS is our name service, but it provides higher functionality than the vanity addresses seen in DeFi today. CNS will allow XCVM users to share access to their accounts across different chains. This creates a seamless experience for cross-chain users and developers alike.
XCVM.js
Inspecting the state of accounts across chains is incredibly complicated. XCVM.js allows developers to inspect the state of all their interpreters across chains. Additionally, XCVM.js will allow developers to construct progress graphs to show users what is happening with their cross-chain transactions.
Conclusion
The creation of the XCVM has been a massive undertaking, but the potential unlocked by natively cross-chain applications will be well worth the effort. At Composable Finance we have been working tirelessly not only on the XCVM but also on providing the foundational infrastructure required by developers to create truly cross-chain applications. In this article, we provided deeper insight behind XCVM, however, if you would like to learn more our CTO Karel also gave a presentation on the architectural overview of the XCVM. Additionally, the XCVM specification can now be found on our GitHub. If you have any further questions or you are interested in building cross-chain applications with the XCVM be sure to contact us on Discord to learn more about our ongoing grants program.
For more information about Composable and how it is architecting the unified DeFi landscape of the future and composing DeFi for mass adoption, check out our socials:
Twitter | Telegram | Discord | Website | GitHub | LinkedIn | Youtube
XCVM Architectural Overview was originally published in Composable Finance on Medium, where people are continuing the conversation by highlighting and responding to this story.
