Detailed Explanation of Cosmos Cross-Chain Communication Implementation Mechanism and Specific Products

Source: Interchain Blog

Original Title: 《Welcome to the IBC gang, let's talk》

Compiled by: Biscuit, Chain Catcher

The theme of the 2020 crypto story revolved around DeFi and composable financial systems, while the main narrative of 2021 was the rapid development of interoperability among various public chains. As early as 2016, the Cosmos white paper showcased foresight, allowing each public chain to embody its own value and enabling assets to move freely across chains, becoming a core part of the Cosmos white paper and its actual development.

Tendermint Core, the Inter-Blockchain Communication protocol (IBC), Cosmos SDK, and Cosmos Hub are all designed with cross-chain in mind: interoperability is the first principle. In a diverse ecosystem, IBC allows different public chains to find a common language, and the latest feature of IBC—cross-chain accounts—enables one chain to send messages to another while also receiving receipts.

Overview of IBC and Cross-Chain Communication

The security of cross-chain interoperability depends solely on its weakest link, and cross-chain solutions for communication between heterogeneous chains rely on decentralized third-party protocols.

The purpose of designing interoperability protocols is to verify the value transferred between two ecosystems. Trust in transaction security is delegated to validators on the protocol—trusting third-party validators and assets. Such designs are suitable for oracles or cross-chain bridges, but in all cross-chain scenarios, this interaction model is less secure.

The design of IBC is trustless. It first initiates network interaction (simulating TCP/IP connections) and then confirms between the two chains that wish to connect. To confirm transactions, the rules of Chain A are directly encoded in Chain B's IBC client, and state validation is performed against these rules. For example, in the Cosmos SDK, the ibc-go implementation uses the Tendermint light client, which can verify the state of the chain on the other end of the IBC transaction by validating the Merkle proof of the block, with the header associated with the transaction linked to the latest consensus state of the counterparty chain.

Chart from Aditya Sripal

This technology instantaneously verifies and transmits the data packets of relay operators, ensuring that IBC maintains high security and permissionless performance—any chain can configure IBC clients and relays, then connect to other networks. More importantly, any chain outside of Cosmos-SDK chains can connect through IBC and enter the Interchain (IBC ecosystem).

The IBC protocol consists of two distinct layers: the transport layer, which is responsible for transmission, authentication, ordering, establishing secure connections between chains, and validating data packets; and the application layer, which precisely defines who should package, send, and parse these packets.

When people talk about interoperability protocols, they usually refer to the transport layer, and IBC provides the most secure design for this layer. The immense potential of IBC lies not only in optimizing the transport layer but also in optimizing the application layer: a universal and trustless transport layer that supports diverse and innovative applications can deploy cross-chain synchronous transaction validation, oracle data, and more at this layer.

The challenge faced by the application layer is: how to transfer assets from Chain A to Chain B, and how do the chains understand what the assets are? The IBC application layer protocol standards and the IBC token module for transferring oracle data and cross-chain NFT transfers, completed in the second quarter of 2022, address this issue. Once assets have been transferred, what should be done next? IBC's answer is cross-chain accounts.

Cross-Chain Accounts and Composability Across Chains

Cross-chain accounts enable composability in cross-chain transactions, allowing chains not only to exchange data but also to write state. This means users do not have to choose various interfaces as assets migrate.

Composable systems decouple various components and then reassemble them into a module within a larger system. In a highly composable system, each component can innovate and optimize. Composability makes the whole greater than the sum of its parts. Enabling composability in IBC allows for the deployment of various innovative applications without upgrading the entire cross-chain system, making it more scalable. This is achieved by allowing the creation and optimization of lower-level components, which are then built into a shared infrastructure that is stateful and permissionless, generating value through information transfer and accessibility.

Cross-Chain Account Transactions

Cross-chain account transactions are the target blocks packaged in IBC transactions. How the receiver (Chain B) processes the transaction is determined by the receiver's own logic, allowing transaction code to be passed using cross-chain accounts regardless of the transaction type. Specific application chains can conveniently port their composable modules—business models can move from the original chain to one chain and then back across chains. This is achieved through a specific channel of a cross-chain account, and vice versa.

Cross-chain accounts can accept on-chain governance from both chains. These are encoded transaction messages, similar to Ethereum's delegate call encoding functions, instead of executing on the receiver (Chain B) by the sender (Chain A). Simply put, cross-chain account transactions can be understood as a letter in a box telling the receiver what to do next.

How Cross-Chain Accounts Enable Fast Cross-Chain Transactions

Theoretically, similar transaction processes can be achieved by creating new IBC application standards. For example, if there is a new IBC standard related to liquidity pool functionalities, then each sender and receiver will be able to parse packets into corresponding message types and execute transactions through the IBC transport layer port.

However, the designed standards focus on the entire ecosystem, and the technical committee behind the IBC standards must consider the iteration and scalability of system design. Therefore, developing secure standards requires significant time and resources. The reality is that developing new IBC application layer standards for cross-chain ecosystems is not only extremely difficult but also easily deviates from the ultimate goal. Forcing application layer innovation to remain closely tied to the development of the core transport layer will lead to unnecessary delays in the application standards, hindering the creation of cross-chain value.

Charts from Josh Lee's blog

Expansion Section

Here are a few examples of actual products that are leading the development of cross-chain accounts and pioneering the future of cross-chain native products:

Cosmos Hub and Hub-as-Fund

Cosmos Hub has always been a very important part of the IBC ecosystem, not only funding the development of the entire Cosmos tech stack, including IBC, but also being the most secure validator. It serves as the foundation for the upcoming Hub Interchain Services products (such as Interchain Security). Now, new proposals are brewing: another valuable cross-chain service will be offered on the Hub. Using a binding mechanism, governance tokens will be sold at a discount to users providing governance-selected assets, and Cosmos Hub will provide an open order book that any trader can use.

The governance community sets asset listings and prices, and deploying these assets through cross-chain accounts will support collateralization, providing liquidity, or deploying assets in lending protocols. For example, Cosmos Hub could decide to purchase Osmosis OSMO/ATOM GAMM liquidity certificates at a price of 1.25 ATOM per share. When users fill this order, the module will use cross-chain accounts to stake these funds and return rewards to ATOM stakers.

This model of protocol-controlled value could have two significant impacts. First, it will more clearly link the value of ATOM with the value of the IBC network, which is built on the technology funded by it. As the most liquid trading pair, the value of ATOM will grow alongside the Interchain. This has always been the result of continuous airdrops from Interchain and strong liquidity provided by ATOM, and encoding Interchain into ATOM will be an exciting development, representing a new evolution of the ATOM valuation model. To complement this value growth, protocol-controlled liquidity will provide a price floor for ATOM, further enhancing its value.

Moreover, protocol-controlled value is just one way the Hub will use cross-chain accounts for the entire "Hub-as-Fund." This marks an important evolution in ATOM's role within the IBC ecosystem. As a large holder of ATOM, the Hub can more directly participate in various governance activities using the community pool treasury to reflect its status.

Sommelier Protocol and Liquidity

Sommelier Protocol provides optimized services for liquidity on Ethereum and Cosmos, using Sommelier to create and execute complex trading strategies to rebalance and manage portfolios without trusted intermediaries. These automated trades provide liquidity providers with a powerful tool to manage liquidity in the most efficient way.

Currently, Sommelier uses a non-custodial bi-directional bridge to provide liquidity to Ethereum and executes these trades using smart contracts deployed on Ethereum. A similar setup between Sommelier Protocol and Osmosis (the leading decentralized exchange in the IBC ecosystem) would require deploying the Sommelier Cellars module on Osmosis, which would necessitate a full-chain upgrade for each chain before it can be used for module development.

With the integration of cross-chain accounts, it becomes simple to send and receive Cellars information between cross-chain accounts on either side, then execute these messages to rebalance or reinvest, adjusting liquidity in the liquidity pool. The deployment and expansion of Cellars functionalities are permissionless and can significantly enhance efficiency.

Where is the Future Direction?

Interchain Accounts have now undergone a comprehensive review, and you can now find the official release candidate version on the repo! Without the contributions and support from Chainapsis (especially Tony Yun and Josh Lee's initial contributions to the specifications), Informal Systems, and Ethan Frey, it would not have been possible to launch this version so efficiently, and we extend our heartfelt thanks and appreciation to you.

In addition to refining the middleware modules within the IBC transaction module, we have now begun exploring a new cross-chain standard, which is now adopting a working group format to lay the technical foundation for cross-chain transactions. Cross-chain queries across the IBC ecosystem will enable users to verify the state from another chain and make changes without querying exposed RPC endpoints or running their own nodes. We welcome you to participate in discussions about this standard and other upcoming IBC standards and contribute to the growing IBC application-level modules.

This blog post only outlines a small part of the ongoing work within the IBC ecosystem, but we hope it at least gives readers a glimpse into the future of cross-chain. We hope it inspires: a rich and diverse full-chain ecosystem that has yet to be mapped out, which will form the landscape of cross-chain.