IOSG Ventures: Explain the status quo and future pattern of multi-chain ecology in detail
Original Author: Jiawei
Original editor: Olivia
Original source: IOSG Ventures
1. Primer

image description
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%: Realize the most basic cross-chain communication and inter-chain token movement;
20-50%: Users can provide liquidity for assets on different chains to maximize returns;
50-75%: Projects like Aave that enable users to deposit collateral on one chain while borrowing on another. That is, to realize inter-application communication of different chains;
75%: A single application deploys its different parts on multiple chains, so that each part runs on the most efficient chain. The backend packages of these different chains will communicate with each other to ensure the continuity of user experience;
100%: Ecosystem agnostic, providing interfaces to a wide range of Web3 ecosystems. Traditional developers can arbitrarily deploy applications supported by Web3 tools on the chain without complex blockchain programming - abstracting away all the complexity.The research and judgment of these stages basically determines how we should view today's multi-chain structure.In the abstract, I think Polkadot XCM / XCMP and Cosmos IBC, and Substrate and Cosmos SDK
, are already working on the fourth and fifth stages respectively.
Also as a multi-chain ecosystem, there have been many articles comparing the system design and technical architecture of Polkadot and Cosmos. As a minor supplement, this article will compare the respective cross-chain communication mechanisms XCMP / IBC and the development framework Substrate / Cosmos SDK from the perspective of light clients.
Finally, some personal thoughts are put forward as the conclusion.
2. Architecture
Before the text begins, let's quickly go through their architecture at a high-dimensional level.
2.1.Polkadot

Image source: https://coinmarketcap.com/alexandria/article/a-deep-dive-into-polkadot
https://polkadotters.medium.com/polkadot-architecture-6d150dd1253e
image description
The security of Polkadot parachains relies on the relay chain, which provides shared security and state consistency for parachains.
2.2.Cosmos

image description
Image source: https://v1.cosmos.network/introCosmos consists of two types of blockchains: Zones and Hubs. Zones are regular heterogeneous chains, and Hubs are used to connect these Zones.
Communication and messaging between Zones and Hubs relies 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 the Hub.
The Cosmos Hub is the first Hub in the entire network, marking the launch of the Cosmos network.
After having a basic understanding of the two cross-chain ecologies, let's look at their respective communication mechanisms in detail.
3.1.Polkadot XCM / XCMP
image description
Image source: https://w3f.github.io/parachain-implementers-guide/messaging.html
Polkadot uses UMP and DMP to transmit uplink and downlink messages between parachains and relay chains, and uses XCMP (Cross-Chain Message Passing) to transmit messages between parachains. XCMP is still under development, and the current cross-chain solution actually used is HRMP (Horizontal Relay-routed Message Passing).Therefore, HRMP, as a temporary transition solution, will be replaced by XCMP in the future.

image description
Image credit: According to https://www.youtube.com/watch?v=dyx-ePhuQRg, IOSG Ventures
The diagram above describes how XCMP works:
Two-way channels can be opened between parallel chains for receiving and sending messages respectively. For XCMP communication between parachain A and parachain B, firstly, the Collators on the respective chains need to add the message, destination and timestamp to their own output queue, and after the other party detects the message, it will add it to its own input queue , process the message and submit the block to Validators. Validators validate the message and then include the block on the relay chain. This is regarded as the completion of a cross-chain message delivery.
If we want to carry out further cross-consensus interoperability, we need a more general "language"-a high-level abstraction of the intent of these messages, providing a basic framework for datagrams communicated between consensus systems. At the same time, potential upgrades of smart contracts or blockchains need to be considered, so such a language must also be forward compatible and extensible.

Image source: https://medium.com/polkadot-network/xcm-the-cross-consensus-message-format-3b77b1373392
At the beginning of May this year, Polkadot officially launched XCM (Cross-consensus Messaging Format) in its v0. Ability to communicate between smart contracts, pallets, bridges, and even SPREE (Shared Protected Runtime Execution Enclaves). (Note: Pallet is equivalent to a series of specific-purpose, combinable modules and toolkits. For example, the purpose of EVM Pallet is to integrate Solidty-based contracts on the Substrate chain; the SPREE module is a trustless message module used to ensure How to execute the code after receiving the message)Need to pay attention to the difference between XCM and XCMP.
XCM is a "format" for mutual communication between consensus systems, and its utility is to express what the recipient of the message should do when he gets the message. XCMP is a "protocol" for messaging.
Essentially, the XCM message is a single or a series of instructions running on the non-Turing-complete virtual machine XCVM (Cross-Consensus Virtual Machine). In other words, the XCVM instruction set constitutes the entire content of the XCM message.Make the interoperability of the entire Polkadot network more unified at the protocol layer.
Image source: https://apps.moonbeam.network/moonbeam
Shortly after the launch of XCM, Moonbeam and Acala took the lead in announcing the launch of XCM-based two-way HRMP for cross-chain communication, realizing the free flow of native assets on the two chains.
For example, $ACA and $aUSD on Acala can be cross-chained to Moonbeam as XC-20 assets ($xcACA and $xcaUSD) to realize interconnection with the Ethereum ecosystem. Moonbeam's native token $GLMR can also be used as collateral on Acala to mint $aUSD or participate in staking.
3.2.Cosmos IBC
The opening of the XCM connection between the two major ecologies of Moonbeam and Acala is a milestone event, which symbolizes that the cross-chain landscape planned by Polkadot is slowly rolling out. As other parachains enable XCM-based cross-chain communication, we will see more similar use cases and inspire greater imagination.
From the bottom up, the Cosmos system is based on Tendermint Core, IBC and Cosmos SDK in turn, which are BFT consensus engine, cross-chain communication protocol and development framework.
image description
Image source: IOSG Ventures
The figure above describes the lifecycle of an IBC packet.
Image source: https://v1.cosmos.network/intro
Finality means that once a cryptocurrency transaction is completed, it cannot be changed or canceled arbitrarily. The above process describes the case of immediate finality. For a probabilistic finality blockchain such as Bitcoin, it is necessary to introduce Peg-Zone as a proxy chain (note: the current Peg-Zone between Cosmos and Ethereum is Gravity Bridge), and determine a finality threshold: for example, Assuming that a chain produces 100 new blocks after a certain transaction occurs, it is considered to have achieved (false) finality.

Image source: https://hub.mintscan.io/ecosystem
Currently, there are 39 chains and 78 validators in the Cosmos ecosystem, and the total value of pledged assets exceeds 3.1 billion US dollars. Some potential airdrop opportunities have become one of the driving forces to attract users into the Cosmos ecosystem. However, Terra's demise has obviously caused huge damage to the Cosmos ecology, and the total amount of locked positions in the ecology has shrunk significantly.
3.3. Light clients
We look at XCMP and IBC from a light client perspective.
During cross-chain communication, the relayer monitors the events on the source chain, generates a cryptographic proof of the event, and forwards the proof together with the block header to the smart contract (ie, the light client) on the target chain. The light client verifies a specific event and uses it as a credential to perform certain actions. The Polkadot XCMP and Cosmos IBC we discussed above both adopt the light client model.

Image source: https://near.org/zh/bridge/
In addition, NEAR's RainbowBridge is also a typical light client model. As smart contracts, the light client is deployed on Ethereum (stores NEAR block headers) and NEAR (stores Ethereum block headers). These block headers are regularly updated by the Relayer, and the update frequency depends on the trade-off in economic efficiency - the update of NEAR's block headers on Ethereum is set to 12 to 16 hours. Connector is responsible for handling the cross-chain logic of specific assets (such as ERC-20 tokens or NFT).
image description

Image source: IOSG Ventures
Image source: IOSG VenturesThrough the above combing of XCM / XCMP, IBC and RainbowBridge, we have a basic understanding of the light client model.
The advantage of the light client lies in security. By verifying certain information, the two chains can know what happened on the opponent chain without relying on the assumption of trust in the external verifier, so the security is basically equivalent to the chain itself.
In particular, the security of XCMP belongs to Shared Security and relies on the global security provided by the relay chain, because the verification of cross-chain messages is done by Validators, and then the Validators include the block containing the message into the relay chain.
The Interchain Security of Cosmos in the above table is a special kind of Shared Security, that is, multiple chains share the same validator set and produce blocks. Since some small chains have weak validators and are vulnerable to attack, Interchain Security is equivalent to helping them inherit the security of mature networks.
Communication using Cosmos IBC requires mutual trust between the two chains, while RainbowBridge requires mutual trust between NEAR and Ethereum, which is also the basic premise for validating block headers.The disadvantage of the light client is: the verification of these proofs has a high cost; in addition, it also involves connectivity issues, and it is necessary to deploy a light client for the communication between each two chains—
Of course, the native communication mechanism of Polkadot and Cosmos solves the connectivity problem within the ecosystem well.
As a summary, a brief comparison of XCMP/XCM, Cosmos IBC and NEAR RainbowBridge is made in the above table, and some of the data may directly involve the comparison between ecologies. (RainbowBridge only involves the cross-chain between NEAR and Ethereum, unlike the former two which belong to the cross-chain ecology, but as a kind of light client, we also put it here for comparison.)
Note: The above/below case projects are all IOSG Portfolio. The examples are for information 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 off-the-shelf software/hardware or toolkits that developers can use directly without spending time and effort re-implementing these functions.In terms of interoperability, both Substrate and the Cosmos SDK provide native support for the Polkadot and Cosmos ecosystems, respectively.
Image source: https://docs.substrate.io/v3/getting-started/architecture/
Both Polkadot and Kusama are developed based on Substrate. However, Substrate itself is a generalized development framework that supports seamless connection with Polkadot, which does not mean that all Substrates need to have a strong binding relationship with Polkadot.

Image source: https://v1.cosmos.network/intro
Different from smart contracts, the Cosmos SDK proposes the concept of Application-specific Blockchains (that is, blockchains customized for a single application), and encapsulates the underlying BFT consensus engine Tendermint Core and the network layer. With the help of ABCI (Application Blockchain Interface) realizes the connection with the application layer.
In addition to the Cosmos SDK, there are some extension tools as supplements, such as the JavaScript-based DeFi component Agoric, the Wasm-based smart contract module CosmWasm, and the Cosmos SDK-based EVM implementation Ethermint.
(PS: Some subjective opinions: When writing this article, the author asked some questions in the Discord developer channels of Polkadot and Cosmos. When Cosmos asks questions, there is a dedicated developer community Mod to establish a sub-area to answer questions one-on-one , is a better experience)

image description
Image source: https://medium.com/electric-capital/electric-capital-developer-report-2021-f37874efea6dAccording to a report by Electric Capital, the number of Web3 developers has grown significantly since 2017, and by the end of 2021, more than 18,000 developers will be active in the Web3 field. However, it is still a minority compared to traditional developers.
From the perspective of industry development, it is necessary to further lower the threshold for on-chain application development and provide good developer services.
image description

Image source: IOSG Ventures
Image source: IOSG Ventures
Also, we did a simple comparison of Substrate and the Cosmos SDK.
5. Thinking and conclusionI partially agree with the "fat app" argument (and the protocol doesn't necessarily need to be "thin").In terms of engineering, different chains have different trade-offs, and they have proposed unique technical solutions for different goals, but the ultimate goal of such infrastructure is relatively consistent-serving applications.
We don't want to build castles in the air, aside from the academic spirit of applying empty talk technology. Looking back at the narratives of 2018 and 19, there are frequent "Ethereum killers" and "millions of TPS". Do users care about these? Maybe don't care. Therefore, there should be some small and beautiful applications and applications with high user acceptance, which should be run on the chain first. (One app that I think fits this description is the NFT Marketplace aggregator gem.xyz, which has a clean interface and features that are good enough for many users.)Ethereum is designed such that the applications and protocols built on it are constrained from each other and inevitably compete for the underlying resources. The rise of multi-chain ecology has shared the pressure of Ethereum to a certain extent, but it is actually eroding its leading position. At the same time, from the perspective of a bear market, Ethereum's return to relatively reasonable Gas fees and transaction speeds has also weakened the motivation for capital outflows.In the short term, whether each chain can produce a "money-making effect" is the main attraction for attracting user inflows (such as DeFi Kingdoms and STEPN). In the medium and long term, user flow is inseparable from the overall quality of each chain ecology.
End users will use their funds to vote, so that the competitive relationship between the chains will be relatively balanced.Composability and interoperability inspire new narratives, but the risks involved cannot be ignored. Two years ago, we only built Lego on Ethereum. In the extreme market on March 12, the layered nesting of protocols and the exhausted liquidity caused systemic risks.
Under the multi-chain structure in the past year, we have more anchors, cross-chain bridges, and more complex protocols, but we have not yet experienced such a severe test. The disintegration of the Terra Empire may only be a harbinger. Moreover, the current market is in a mid-to-long-term downward trend, and we need to tread on eggshells and proactively estimate and judge risks.It needs to be admitted that the current multi-chain ecology is still a bit "puffy". Some seemingly prosperous ecology, in the final analysis, is just a set of protocols and a set of codes to reopen the game on another chain.Whether the ecology is prosperous or not depends not only on the number of projects, but also on the comprehensive evaluation of the activity of users and the continuity of funds.
In addition, asset cross-chain is still the main use case of cross-chain. We can expect or foresee some other application scenarios in the future. Some interesting use cases may be: we need to evaluate the activity trajectory of multiple chains when doing DID; we can mortgage NFT assets of multiple chains when doing NFT loans; even assist arbitrage decisions based on asset activity changes in multiple chains; and so on.The cross-chain infrastructure is already on the way, but to really ignite the multi-chain ecology requires a large-scale incremental user, which is just a game aimed at stock users.With this in mind, it is crucial to provide user-friendly on-ramps such as multi-chain wallets.

Image source: https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8
How should we look forward to the future multi-chain pattern? In the picture above (as of September 2021), we have seen that the cross-chain ecology is becoming prosperous. Although the decline is inevitable in the bear market, objectively speaking, the cross-chain infrastructure is relatively complete. (Nevertheless, hackers' attacks on the vulnerabilities of cross-chain facilities are still emerging one after another. Be optimistic, but you should also be cautious.)It is reasonable to guess that the narrative of the next big cycle is a multi-chain ecology built around high-quality applications on each chain.
Remarks like "building a public chain to meet all needs" may become history. After all, we really don't need to do everything on one chain. Expect more application chains to emerge in the future.
Original link
https://thenewstack.io/web3-developer-ecosystem/
https://www.parity.io/blog/what-is-a-light-client/
https://substrate.io/https://wiki.polkadot.network/docs/https://v1.cosmos.network/intro
https://github.com/paritytech/xcm-format
https://aurora.dev/blog/2021-how-the-rainbow-bridge-works


