Multi-chain ecosystem: Our current stage and future landscape

Author: Jiawei, IOSG Ventures

1: Introduction

Image source: https://medium.com/composable-finance/the-philosophy-of-the-cross-chain-ecosystem-a-continuum-of-interoperability-33ed81350190

Composable Finance proposes five stages of development for cross-chain interoperability:

0-20%: Achieving the most basic cross-chain communication and inter-chain token movement;

20-50%: Users can provide liquidity for assets across different chains to maximize yields;

50-75%: Projects like Aave enable users to deposit collateral on one chain while borrowing on another, achieving communication between applications on different chains;

75%: A single application deploys its different parts across multiple chains, allowing each part to operate on the most efficient chain. The backends of these different chains will communicate with each other to ensure continuity of user experience;

100%: Ecosystem agnosticism, providing interfaces for a wide Web3 ecosystem. Traditional developers can deploy applications supported by Web3 tools on any chain without complex blockchain programming—abstracting away all complexities.

The assessment of these stages essentially determines how we should view today's multi-chain landscape. Abstractly, I believe that Polkadot XCM/XCMP and Cosmos IBC, as well as Substrate and Cosmos SDK, are already working on stages four and five respectively.

There have been many articles comparing the system design and technical architecture of Polkadot and Cosmos as multi-chain ecosystems. As a small supplement, this article will compare their cross-chain communication mechanisms XCMP/IBC and development frameworks Substrate/Cosmos SDK from the perspective of light clients.

Finally, some personal reflections are presented as a conclusion.

2: Architecture

As described in the Cosmos documentation: "Cosmos is not a product, but an ecosystem built on a set of modular, adaptable, and interchangeable tools." My understanding of Polkadot is similar.

Before diving into the main text, let's quickly review their architectures from a high-dimensional perspective.

2.1. Polkadot

Image source: https://coinmarketcap.com/alexandria/article/a-deep-dive-into-polkadot
https://polkadotters.medium.com/polkadot-architecture-6d150dd1253e

The relay chain is the core of Polkadot, with parachains being independent but uniformly connected to the relay chain to share its security. Collators collect transactions from parachains, generate state transition proofs, and submit them to the relay chain, where Validators verify these proofs and execute consensus to produce blocks on the relay chain. Nominators are responsible for selecting Validators and must stake DOT to protect the relay chain.

The security of Polkadot parachains relies on the relay chain, which provides shared security and state consistency for parachains.

2.2. Cosmos

Image source: https://v1.cosmos.network/intro

Cosmos consists of two types of blockchains: Zones and Hubs. Zones are regular heterogeneous chains, while Hubs are used to connect these Zones. Communication and messaging between Zones and Hubs rely on the IBC (Inter-blockchain Communication) protocol. When any Zone establishes an IBC connection with a Hub, it can communicate with other Zones connected to that Hub.

Cosmos Hub is the first Hub in the entire network, marking the launch of the Cosmos network.

3: Communication Mechanism

After gaining a basic understanding of the two cross-chain ecosystems, let's take a closer look at their communication mechanisms.

3.1. Polkadot XCM/XCMP

Image source: https://w3f.github.io/parachain-implementers-guide/messaging.html

Polkadot uses UMP and DMP for up and down messaging between parachains and the relay chain, and XCMP (Cross-Chain Message Passing) for messaging between parachains. XCMP is still under development, and the currently used cross-chain solution is HRMP (Horizontal Relay-routed Message Passing).

HRMP provides the same interface and functionality as XCMP but requires all messages to be stored in the relay chain's storage. This creates additional message load for the relay chain. In contrast, XCMP only stores the metadata hash associated with the message in the relay chain. Therefore, HRMP serves as a temporary transitional solution and will be replaced by XCMP in the future.

Image source: Based on https://www.youtube.com/watch?v=dyx-ePhuQRg, IOSG Ventures

The above image describes how XCMP works:

Parachains can open bi-directional channels for receiving and sending messages. For XCMP communication between parachain A and parachain B, the collators on each chain must first add the message, destination, and timestamp to their output queues. Once the other party detects the message, it adds it to its input queue, processes the message, and submits the block to Validators. Validators verify the message and then include the block containing that message on the relay chain. This is considered the completion of a cross-chain message transfer.

Between chains, or between different consensus systems, the message formats lack compatibility, each having its own messaging methods and standards.

If we want to achieve further cross-consensus interoperability, we need a more universal "language"—a high-level abstraction of the intent of these messages, providing a basic framework for communication between consensus systems. It must also consider potential upgrades to smart contracts or blockchains, so such a language must be forward-compatible and extensible.

Image source: https://medium.com/polkadot-network/xcm-the-cross-consensus-message-format-3b77b1373392

In early May of this year, Polkadot officially enabled XCM (Cross-consensus Messaging Format) in its v0.9.19, where the meaning of cross-consensus indicates that this communication format can be used not only in UMP, DMP, and XCMP between Polkadot chains but also for communication between smart contracts, Pallets, bridges, and even SPREE (Shared Protected Runtime Execution Enclaves). (Note: Pallet refers to a series of specific-purpose, composable modules and toolkits, such as the EVM Pallet, which is used to integrate Solidity-based contracts on Substrate chains; the SPREE module is a trustless messaging module used to ensure how code is executed after receiving a message.)

It is important to note the difference between XCM and XCMP. XCM is a "format" for communication between consensus systems, and its utility lies in expressing what the recipient of the message should do upon receiving it. In contrast, XCMP is a "protocol" for message passing.

Essentially, XCM messages are a single or series of instructions running on a non-Turing complete virtual machine, XCVM (Cross-Consensus Virtual Machine); in other words, the instruction set of XCVM constitutes the entirety of XCM messages.
By proposing XCM and XCMP, Polkadot essentially provides native, generic support for communication between parachains, allowing them to communicate directly without relying on specialized cross-chain bridges, thus making the interoperability of the entire Polkadot network more unified at the protocol level.

Image source: https://apps.moonbeam.network/moonbeam

Shortly after the activation of XCM, Moonbeam and Acala were the first to announce the use of XCM-based bi-directional HRMP for cross-chain communication, enabling the free flow of native assets across the two chains.

For example, $ACA and $aUSD on Acala can be cross-chained to Moonbeam as XC-20 assets ($xcACA and $xcaUSD) to achieve interoperability with the Ethereum ecosystem. Moonbeam's native token $GLMR can also be used as collateral on Acala to mint $aUSD or participate in staking.

The connection between the two ecosystems of Moonbeam and Acala through XCM is a milestone event, symbolizing that the cross-chain vision envisioned by Polkadot is gradually unfolding. As other parachains enable XCM-based cross-chain communication, we will see more similar use cases and inspire greater imagination.

3.2. Cosmos IBC

From the bottom up, the Cosmos system is based on Tendermint Core, IBC, and Cosmos SDK, which are respectively the BFT consensus engine, cross-chain communication protocol, and development framework.

The IBC as a cross-chain communication protocol was officially implemented during the Cosmos Stargate upgrade last March, with its semantics and design principles established by the inter-chain standard ICS (Inter-chain Standard).

Analogous to the layered system of the internet communication protocol TCP/IP, IBC can be decomposed into a transport layer and an application layer. The transport layer provides the necessary infrastructure to establish secure connections and verify data packets between chains; the application layer precisely defines how these packets should be packaged by the sender and how they should be interpreted by the receiver.

Image source: IOSG Ventures

The above image describes the lifecycle of IBC packets.

Image source: https://v1.cosmos.network/intro

IBC employs a "lock-mint" asset cross-chain model. As shown in the above image, if Zone A wants to transfer assets to Zone B, it needs to lock the tokens and send proof to Zone B. Upon verification, Zone B mints an equivalent amount of tokens on its own chain. During this process, the asset does not actually transfer; instead, it is locked in Zone A while an equivalent asset is re-minted in Zone B.

Finality refers to the fact that once a cryptocurrency transaction is completed, it cannot be arbitrarily changed or canceled. The above process describes the case of immediate finality. For probabilistic finality blockchains like Bitcoin, a Peg-Zone needs to be introduced as a proxy chain (Note: Currently, the Peg-Zone between Cosmos and Ethereum is Gravity Bridge), and a finality threshold must be established: for example, if a certain chain produces 100 new blocks after a transaction occurs, it is considered to have achieved (pseudo) finality.

Image source: https://hub.mintscan.io/ecosystem

Currently, the Cosmos ecosystem includes 39 chains and 78 validators, with a total staked asset value exceeding 3.1 billion USD. Some potential airdrop opportunities have become one of the driving forces attracting users to the Cosmos ecosystem. However, the collapse of Terra has evidently caused significant damage to the Cosmos ecosystem, severely shrinking the total locked value.

3.3. Light Clients

Let's look at XCMP and IBC from the perspective of light clients.

Light clients (or light nodes) were originally a term used to distinguish from full nodes, applied to Bitcoin's Simplified Payment Verification (SPV). More broadly, smart contracts can also be considered light clients. Such light clients often do not interact directly with the chain but rely on full nodes as intermediaries to request certain information from full nodes, such as sending transactions, verifying account balances, and requesting block headers.

In cross-chain communication, relayers monitor events on the source chain and generate cryptographic proofs of those events, forwarding the proofs along with the block headers to the smart contract (i.e., light client) on the target chain. The light client verifies a specific event and uses that as evidence to execute certain actions. Both Polkadot XCMP and Cosmos IBC discussed above adopt the light client model.

Image source: https://near.org/zh/bridge/

Additionally, NEAR's RainbowBridge is also a typical light client model. The light client, as a smart contract, is deployed on both Ethereum (storing NEAR's block headers) and NEAR (storing Ethereum's block headers). These block headers are regularly updated by Relayers, with the update frequency depending on the economic efficiency trade-off—updating NEAR's block headers on Ethereum is set to 12 to 16 hours. The Connector is responsible for handling the cross-chain logic of specific assets (such as ERC-20 tokens or NFTs).

The speed and cost of RainbowBridge primarily depend on Ethereum. Sending assets from Ethereum to NEAR takes about 6 minutes (20 blocks). Sending assets back from NEAR to Ethereum currently takes up to 16 hours (due to the time cost of Ethereum's finality).

3.4. Summary

Image source: IOSG Ventures

Through the above analysis of XCM/XCMP, IBC, and RainbowBridge, we have a basic understanding of the light client model. The advantage of light clients lies in security; by verifying certain information, two chains can know what happens on the counterpart chain without relying on trust assumptions about external validators, thus the security is essentially equivalent to that of the chain itself.

Specifically, the security of XCMP belongs to Shared Security, relying on the global security provided by the relay chain, as the validation of cross-chain messages is completed by Validators, who then include the blocks containing those messages on the relay chain.

In the table above, Cosmos's Interchain Security is a special type of Shared Security, where multiple chains share the same validator set and produce blocks. Since some smaller chains have weaker validators and are more susceptible to attacks, Interchain Security effectively helps them inherit the security of a mature network.

Using Cosmos IBC for communication requires mutual trust between the two chains, while RainbowBridge requires mutual trust between NEAR and Ethereum, which is also a fundamental prerequisite for the validity verification of block headers.

The downside of light clients is that verifying these proofs comes at a significant cost; additionally, there are connectivity issues, as light clients need to be deployed for communication between every two chains—of course, the native communication mechanisms of Polkadot and Cosmos effectively address the connectivity issues within the ecosystem.

In summary, the table provides a brief comparison of XCMP/XCM, Cosmos IBC, and NEAR RainbowBridge, with some data potentially directly related to inter-ecosystem comparisons. (RainbowBridge only involves cross-chain communication between NEAR and Ethereum, unlike the first two which belong to cross-chain ecosystems, but as a type of light client, we include it here for comparison.)
Note: The above/below case projects are all part of the IOSG Portfolio, and examples are for informational exchange only and do not constitute investment advice. Please DYOR for personal investment decisions!

4: Development Framework

"Out of the box" refers to a series of ready-made software/hardware or toolkits that developers can use directly without spending time and effort to re-implement these functions.

Substrate and Cosmos SDK are such frameworks: they encapsulate underlying logic, provide some pre-built modules, and allow flexible, customizable module combinations for building blockchains and applications. In terms of interoperability, both Substrate and Cosmos SDK provide native support for the Polkadot and Cosmos ecosystems, respectively.

Image source: https://docs.substrate.io/v3/getting-started/architecture/

Substrate offers three development methods: Substrate Node provides pre-configured node settings, requiring only an additional JSON file for one-click chain building; Substrate FRAME offers a series of modules and components (i.e., the aforementioned Pallets), and developers can also write Pallets and combine them freely; Substrate Core is more high-dimensional and abstract, allowing developers to design runtimes from scratch (Note: The runtime is essentially a state transition function, a core concept in Substrate representing the state storage of the chain and how the state will be changed). The development difficulty and technical flexibility of these three methods increase incrementally.

Both Polkadot and Kusama are developed based on Substrate. However, Substrate itself is a generalized development framework that supports seamless connection with Polkadot, and does not imply that all Substrate projects need to have a strong binding relationship with Polkadot.

Image source: https://v1.cosmos.network/intro

In contrast to smart contracts, Cosmos SDK introduces the concept of application-specific blockchains (blockchains customized for individual applications) and encapsulates the underlying BFT consensus engine Tendermint Core and network layer, using ABCI (Application Blockchain Interface) to connect with the application layer.

In addition to Cosmos SDK, there are also some extended tools as supplements, such as the JavaScript-based DeFi component Agoric, the Wasm-based smart contract module CosmWasm, and the EVM implementation Ethermint based on Cosmos SDK.
Overall, the functions and tools provided by the development frameworks are largely similar, with subtle differences in design philosophies, which will not be elaborated on here.
(P.S: Some subjective views: While writing this article, the author raised some questions in the Polkadot and Cosmos Discord developer channels. In Cosmos, a dedicated developer community Mod established a sub-channel to answer questions one-on-one, which was a good experience.)

Image source: https://medium.com/electric-capital/electric-capital-developer-report-2021-f37874efea6d

According to Electric Capital's report, since 2017, the number of Web3 developers has seen significant growth, with over 18,000 developers active in the Web3 space by the end of 2021. However, compared to traditional developers, they still represent a minority. From the perspective of industry development, it is necessary to further lower the barriers to on-chain application development and improve developer services.
A thriving ecosystem will attract more quality developers to join, as both Substrate and Cosmos SDK emphasize the convenience of integrating into their respective ecosystems. In fact, the choice of development framework is closely tied to the choice of the subsequent ecosystem.

4.1. Summary

Image source: IOSG Ventures

Similarly, we have provided a brief comparison of Substrate and Cosmos SDK.

5: Thoughts and Conclusion

I partially agree with the argument for "fat applications" (and protocols do not necessarily need to be "thin"). In engineering, different chains have their own trade-offs, proposing unique technical solutions for different goals, but the ultimate goal of such infrastructure is relatively consistent—serving applications. We are not trying to build castles in the air; discussing technology without applications is mere academic posturing. Looking back at the narratives of 2018 and 2019, terms like "Ethereum killer" and "million TPS"—do users care about these? Perhaps not. Therefore, there should be some small and beautiful applications, applications with high user acceptance, that can run on-chain first. (I believe one such application is the NFT Marketplace aggregator gem.xyz, which has a clean interface and good functionality, which is sufficient for many users.)

Ethereum's design causes applications and protocols built on it to be mutually constrained and inevitably compete for underlying resources. The rise of multi-chain ecosystems has alleviated some of Ethereum's pressure, but it has also been eroding its leading position. Meanwhile, from the perspective of a bear market, Ethereum's return to relatively reasonable gas fees and transaction speeds has weakened the motivation for capital outflow. In the short term, whether each chain can generate a "profit effect" is the main attraction for users to flow in (e.g., DeFi Kingdoms and STEPN). In the medium to long term, user flow is closely tied to the overall quality of each chain's ecosystem. Ultimately, users will vote with their funds, leading to a relatively balanced competitive relationship between chains.

Composability and interoperability have sparked new narratives, but the inherent risks cannot be ignored. Two years ago, we were only building Legos on Ethereum; during the extreme market conditions on March 12, the layered nesting of protocols and depleted liquidity triggered systemic risks. In the past year under the multi-chain landscape, we have seen more anchors, cross-chain bridges, and more complex protocols, but we have yet to experience such severe tests. The collapse of the Terra empire may just be a precursor. Moreover, the current market is in a medium to long-term downward trend, and we need to tread carefully, proactively estimating and assessing risks.

It must be acknowledged that the current multi-chain ecosystem is still somewhat "bloated"; some seemingly prosperous ecosystems are, at the end of the day, merely a set of protocols and code reopening a gambling game on another chain. The prosperity of an ecosystem should not be judged solely by the number of projects but should comprehensively evaluate user activity and the sustainability of funds. Furthermore, asset cross-chain remains the primary use case for cross-chain today. In the future, we can expect or foresee some other application scenarios. Some interesting use cases might include: evaluating multi-chain activity trajectories when doing DID; using multi-chain NFT assets as collateral for NFT lending; or even assisting arbitrage decisions based on changes in multi-chain asset activity; and so on.

Cross-chain infrastructure is already on the verge of being launched, but truly igniting the multi-chain ecosystem requires a large influx of new users; merely targeting existing users and the movement of funds between chains will not bring exponential growth. Considering this, providing user-friendly entry points (such as multi-chain wallets) is crucial.

Image source: https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8

How should we look forward to the future multi-chain landscape? In the above image (as of September 2021), we have already seen the cross-chain ecosystem becoming prosperous; although it inevitably shows signs of decline in a bear market, objectively speaking, the cross-chain infrastructure has become relatively complete. (Nevertheless, attacks by hackers on vulnerabilities in cross-chain facilities continue to emerge, so while we remain optimistic, we should also be cautious.)

A reasonable guess is that the narrative of the next big cycle will be built around high-quality applications on various chains within a multi-chain ecosystem. Statements like "building a public chain to meet all needs" may become history, as we indeed do not need to do everything on one chain. We look forward to more application-specific chains emerging in the future.

At present, we are still in the early stages of the multi-chain landscape.