Composable Finance: Emerging as the first cross-chain smart contracting L1
Over the last year or two, “interoperability” has grown from just being loosely thrown around as a buzzword in DeFi to a burgeoning reality. Composable Finance and other projects focused on facilitating interoperability have successfully facilitated various bridging and communication functions between different blockchain networks, striving to make these linkages as efficient and effective as possible. Now, we see interoperability in DeFi realized as the ability for a transaction on a smart contract on one blockchain to trigger a response on another smart contract on another blockchain.
Interoperability has always been a major focus at Composable Finance, but we have also always dreamt even bigger. We envision a seamlessly interconnected, limitlessly customizable, LEGO-like DeFi industry, wherein value and user experience are optimized, and complications and frustrations are minimized. In other words, we have been dreaming of (and more importantly, working towards) the next level of interoperability in the space: composability.
At its most basic definition, composability describes the ability to combine a range of different hand-selected building blocks into something new. At Composable, we further argue that composability entails a situation wherein the whole is greater than the sum of its parts; in other words, the combination of these tools offers a superior functionality above what the individual tools alone offer. If this is made possible in DeFi, then the result of composability is new and unparalleled innovation and opportunity. For composability to truly occur, all of the individual parts must be able to combine so smoothly that delineations are undetectable. Further, developers building composable infrastructure should be able to do so without obstacles, instead of being able to select from whichever components in whichever ecosystems they choose, building to their precise vision and objectives. The experience must be similarly barrier-free for users, as well.
Composable’s Cross-Chain Virtual Machine (XCVM) is the primary piece of technology that will finally allow for true composability across multiple ecosystems within DeFi, facilitated by its natively cross-chain smart contracts. In the current DeFi landscape, the most common virtual machines in existence now (such as the Ethereum Virtual Machine or EVM) are designed to exist and execute transactions on only 1 chain, however, the Composable XCVM is different from anything deployed through the XCVM will be natively cross-chain. To understand how this works and why it is important, we must explore the current level of interoperability provided by Composable Finance and others.
Current Interoperability Solutions are Retroactive
I conceptualize current options for interoperability in DeFi as the glue with which projects use to allow for the different instances of their application on the other chains or layers wherein they are deployed to communicate with themselves. To begin with, previously disjointed blockchains and applications are now stuck together in selected locations through trusted relayers, as is the case in LayerZero. Its relayers pass messages between chains, while the oracles verify the correctness of the messages; together they allow smart contracts on different applications and chains that are already deployed on these chains to communicate with each other.
This is an incredibly important step toward the growth and expansion of the DeFi industry, yet it is not interoperable at full capacity. The limitation here is that interoperability is being applied retroactively, not proactively.
Smart contracts and the projects they belong to must still be deployed natively onto one chain and then must use an intermediate platform to access a bridge to smart contracts on other chains. This is relatively effective for moving funds between protocols on different chains and managing different instances of protocols deployed on different chains. However, the major problem is that this still forces DeFi developers to choose the blockchain with which they must natively deploy their applications to assume their interoperability features. The XCVM framework significantly differs from these solutions as it acts as the orchestration layer that developers can leverage and build their application in one place rather than being constrained to choose a single chain to build on.
The XCVM Vision for Composability
In this section, I address the current state of cross-layer interoperability in DeFi and contrast this with the XCVM solution. I further outline the various features of the XCVM that will allow it to be so much more successful at achieving composability, including its use of CosmWasm and IBC. Finally, I provide a diagrammatic comparison between the XCVM and existing cross-layer solutions, as well as a summary of the advantages of the XCVM.
The Problem in Current Cross-Layer Solutions
Solutions like Layer Zero rely on relayers and oracles to broadcast and check events between applications on different chains. On the other hand, the XCVM creates an environment where smart contracts on different chains can interoperate in a trustless way with finality proofs via the Centauri bridging infrastructure.
Unlike existing iterations of blockchain virtual machines, the XCVM does not force applications and smart contracts to be deployed onto one particular chain. Instead, the XCVM provides a novel opportunity for applications to be natively cross-chain. The goal is to facilitate a top-down approach to interoperability and composability instead of connecting different pre-existing pieces together.
During the pre XCVM era, developers who wished to create an interoperable application needed to consider the various chains they wanted their applications to operate between and narrow down their choice to just one as their native chain. Then, they must deploy their project to work with that specific chain’s virtual machine (for instance, the EVM for a project built on Ethereum). An additional burden to developers is finding an interoperability solution that works with Ethereum and the other chains they wish their applications to communicate with, integrate that solution, and use it any time there’s a need to bridge to other applications that are not on Ethereum. Further, suppose they want to deploy that project on additional chains. In that case, DeFi developers must completely recreate their projects and then link them with their existing ones — possibly many times over, depending on the number of instances they desire to create.
The XCVM Solution
In contrast, the XCVM is positioned as an interoperable smart contract environment where we envision developers building decentralized applications that can natively operate across chains. Thus, projects can capitalize upon the advantages of several chains at once while cutting out the additional steps of needing to create multiple instances on multiple chains or focusing and relying on various bridges.
IBC Integration
The Inter-Blockchain Communication Protocol (IBC) currently allows for the trustless passing of arbitrary data in opaque packets between Cosmos SDK chains. Crucially, it achieves trustlessness through light clients and finality proofs, rather than relying on the conventional relayer and mint structure. Composable is working on expanding IBC’s functionality to connect chains in other ecosystems such as NEAR (or any other ecosystems that support light clients) by integrating light clients that track the finality in these ecosystems on IBC. This becomes the transport layer for the Composable XCVM.
As a result, we are effectively helping the IBC become what the Cosmos ecosystem imagined itself to be: an internet of blockchains. Facilitating inter-ecosystem communication has always been the vision for Cosmos and has seen some initial progress via creating the IBC and Cosmos’s multi-chain contracts. Yet, absolute interconnection of the space, with Cosmos as the hub, has not been achieved. Composable’s integration of the IBC and CosmWasm into the XCVM will allow for many new integrations between different ecosystems and Cosmos, helping to expand the capacity of Cosmos.
Writing CosmWasm Smart Contracts
To add even more benefits to the XCVM, Composable has decided to build this technology with the CosmWasm framework, meaning this is the framework upon which developers will be able to build cross-chain native applications. This framework combines the benefits of the WebAssembly (Wasm) smart contract engine, the Cosmos SDK, and Cosmos’s Inter-Blockchain Communication Protocol (IBC). Another feature of CosmWasm is that it allows for multi-chain contracts: one dApp, one contract, but multiple chains. Any chain using the Cosmos SDK can easily integrate the CosmWasm module, which is built to maintain low overhead on systems demand. CosmWasm allows for composition across multiple chains and migration to other chains, with built-in, permissioned, pre-contract migration functionality.
CosmWasm was focused on interoperability from the offset, designed to be compatible with the IBC and concentrated on building a smart contracting environment for an ecosystem with multiple connected chains. CosmWasm has proven to be a well-tested framework that is ready to serve as the underlying development framework for the XCVM as it facilitates native communication and smart contracting across multiple ecosystems, especially beyond ecosystems that Composable is already integrated with.
Decentralised applications leveraging the XCVM will be written in CosmWasm.
Smart contracts within the CosmWasm framework function in a different way to convetional smart contracts. CosmWasm smart contracts can send a side message through an IBC transfer message to the other chain. Overall the basic contract endpoints for message sending can be broken down into the following: reflect messages to handler and wraps/send native or non-native tokens to be executed in chain B. Then, an authentication check ensures the channel between two chains is connected and constructs a packet to the Composable Parachain/IBC enabled chain underlying the CosmWasm. Finally, an IBC message is executed and sent to the other contract.
Systems Architecture
The following diagram is from LayerZero, depicting how their protocol, similarly to others currently in the space, accomplishes cross-layer operations. To have a transaction on Chain A cause a response on Chain B, the transaction must first be passed to an off-chain relayer through LayerZero. As previously described, this is not true, native cross-chain communication.
The subsequent diagram depicts the Composable Finance XCVM. In contrast to LayerZero and other existing solutions, the XCVM enables the creation of natively cross-chain smart contracts:
XCVM Example
A unique example for the XCVM can be seen in the diagram below, where a user intends to withdraw their loan on a chain different to the one deposited: firstly, a user deposits their LP token into a lending protocol on chain A. During this contract instantiation, the message binds to an IBC port and sends IBC opaque packets to the satellite contract on chain B. As a result, the user now has the ability to withdraw a loan on chain B.
XCVM Roadmap
Turning our vision for the XCVM into reality involves a few core points in our roadmap. The Composable SDK, in its current and early iteration, is an early set of tools to interact with XCVM subsets.
The Composable SDK
We have built the Composable Software Development Kit (SDK) largely fulfilling the core purpose of solutions like LayerZero and other similar protocols: linking various applications and chains together. Our SDK taps into Mosaic that we built from the ground up, which allows for function calling across several notable chains within the EVM and Substrate ecosystems. As the XCVM continues to develop, we plan to integrate additional features into the Composable SDK that enables direct interaction with core segments of the XCVM.
Currently, the Composable SDK is still an early iteration that taps into the XCVM. In the future, the Composable SDK will serve to provide endpoints that tap into the XCVM and its specific isolated components. Although our SDK has been a critical interim solution to the issue of interoperability, it, however, needs further expansion in capabilities to achieve true composability Hence, we are keen on improving its current state through the creation of XCVM features.
The XCVM and Its Features
Ultimately, the XCVM forms an alliance between XCM and the IBC protocol by acting as the smart contracting layer to orchestrate IBC and XCM messages. CosmWasm will be placed on top of an ink! pallet to allow for smart contracts to be written and the XCVM will utilise the IBC as the transport layer to send data and packet formats across contracts on different chains. Furthermore, we are using XCM inspired messages to allow for packet passing.
Moreso, by building light clients that report finality of other networks to IBC, we can connect other ecosystems outside of Cosmos, such as Near, Zksync, Starkware and many other ecosystems that have enabled light client technology and finality proofs. Within the XCVM, we will build libraries to call, borrow, and perform other vital functions for smart contract writers who use CosmWasm to specify DeFi lego functions.
The Routing Layer would comprise Indexers and Solvers who synergise to compute the best possible route across multiple ecosystems and continuously query contracts from a library of DeFi Application Binary Interfaces (ABIs). The Routing Layer determines where specific functions should be executed, which dApps need to interact, and more specifically, which satellite contracts to interact with.
We are also exploring the possibility of this becoming a rollup based environment on a substrate based chain which would be the first of its kind. For example, a contract being deployed on the spree module of the XCVM but then executing the transaction in a zk-rollup based execution environment.
Conclusion
Given the current state of interoperability in DeFi, smart contracts are limited to a singular deployment location, cannot interact with each other, and lack a top layer for orchestration. As a result, cross-layer and cross-chain solutions are incredibly limited to a framework where one event triggers another on another chain.
While this is certainly a step in the right direction and a useful interim solution, this still does not truly solve developers’ needs for building cross-chain applications. Yes, it solves the problem associated with having multiple applications deployed simultaneously and having them talk to each other. However, this does not allow the deployment of an application natively cross-chain.
To provide a top-down solution to interoperability and not just simply glueing pre-existing applications together, Composable has created its XCVM. Composable envisions the XCVM as the top-level orchestration layer for deploying protocols that can communicate across multiple chains natively. As a result, these applications can be not just interoperable but also composable; developers can use the XCVM to compose protocols across various existing chains to allow for maximal customization and effectiveness.
— — —
If you are a developer with a project you think fits our ecosystem and goals, and you would like to participate in our interactive testing landscape at Composable Labs, reach out to me on Telegram at @brainjar.
