NewsFlash Articles Data Fundraising BlockBeats Pro

Buidler DAO: Understanding IBC—Cosmos Cross-chain Communication Protocol in One Article

Read this article in 52 Minutes

IBC has achieved more than 43 million cross-chain transfers in more than 48 active chains and has more than three million users.

Original Source: Buidler DAO

TL;DR

- IBC not only solves the blockchain interoperability problem, but also enables arbitrary data transfer across blockchains in a trust-minimized, secure, scalable and universal manner. "Arbitrary data" includes cross-chain assets and cross-chain information, such as the transfer of tokens and NFT assets. You can also manage accounts on another chain while using one blockchain, and query information from other chains ,etc.

- The unique feature of the IBC protocol is that it adopts a layered design, the transport layer and the application layer for the entire workflow. The transport layer (TAO: transport layer) provides the necessary infrastructure to establish secure connections and verify data packets between blockchains. The application layer (application layer) is built on top of the transport layer, which defines how data packets should be packaged by the sending chain and unpacked by the receiving chain.

- The security of IBC is based on the IBC light client and does not require additional trusted third parties . Using a light client based on the source chain also means that its security is basically consistent with the underlying security assumptions of its blockchain.

- The core "light client" that realizes the trust minimization of IBC, for small teams Said it was a lot of development work. Cross-chain security will allow other blockchains to “rent” security from the Cosmos Hub without having to build and maintain validators for their own chains.

- Although IBC originates from Cosmos, it can also be used on other chains (not based on Cosmos SD build), or even a completely different consensus than Tendermint. It's just that this requires chain-based consensus types and blockchain frameworks to develop different components required for IBC.

- IBC visualization tool: MapOfZones more intuitively shows chain-to-chain interconnection channels; Mintscan More detailed information about the relayer is displayed; IOBScan can search through the transaction hash more conveniently.

Introduction

The Internet has facilitated different types of The simplicity and flexibility of TCP/IP make it a standard Internet communication protocol for computers, servers, mobile phones, and even small Internet of Things devices. Cosmos is known as the "Blockchain Internet", and IBC is the "TCP/IP" protocol in the Blockchain Internet. It provides a permissionless way to relay data packets between blockchains, enabling blockchains to communicate with each other.

In the 18 months since its launch, IBC has become the standard for secure, interoperable, cross-chain communication. As of now, IBC has achieved more than 43 millioncross-chain transfers in more than 48 active chains, with more than three million users.

With the development of multi-chain ecology, IBC not only supports the Cosmos ecological block Chain cross-chain communication is also interconnecting with other blockchain ecosystems, such as Composable Finance is bringing IBC to Polkadot & NEAR, Electron is using zkProof to bring IBC to Ethereum and so on.

This article will explain the IBC cross-chain communication protocol in detail, including working principles, key applications, Visualization tools and security discussions.

What is IBC?

IBC (Inter-Blockchain Communication) is a general interoperability protocol that supports two different blockchains to communicate with each other, and No need to trust anyone in the middle. IBC can be used not only for blockchains developed based on the Cosmos SDK, but also for other blockchains, such as Ethereum, Polkadot, etc.

The infrastructure of the Cosmos ecosystem mainly has seven teams contributing to its development, among which the IBC protocol The specification is led by the Interchain GmbH team. This specification describes the data structures and interfaces required for IBC-enabled chains, including IBC core protocols and IBC-based applications, and is integrated into a set of inter-chain standards (ICS).

What problem does IBC solve ?

In one sentence, IBC solves the problem of "cross-chain communication". The Internet allows information to flow easily around the world. Likewise, information betweendifferent blockchains also requires free access across multiple platforms. When a user wants to use the stable currency of blockchain A, the liquidity pool (LP) of decentralized exchange (DEX) of blockchain B generates income. This requires interoperability between chains to achieve.

IBC not only solves interoperability problems, but also trust-minimized, secure, scalable It realizes arbitrary data transmission across blockchains in a universal way. "Arbitrary data" includes cross-chain assets and cross-chain information, such as the transfer of tokens and NFT assets. You can also manage accounts on another chain while using one blockchain, and query information from other chains ,etc.

How does IBC work?

The unique feature of the IBC protocol is that it uses a layered design, the transport layer and the application layer to achieve the entire workflow. The transport layer (TAO: transport layer) provides the necessary infrastructure to establish a secure connection and verify data packets between blockchains. The application layer (application layer) is built on top of the transport layer, which defines how data packets should be packaged by the sending chain and unpacked by the receiving chain.

An easy-to-follow analogy: How IBC works Similar to mail delivery system. When you send someone a letter through the postal service, the postal service deposits the envelope containing the letter in the recipient's mailbox. The recipient then opens the envelope and reads your letter. IBC's transport layer can be thought of as a postal service. The postal service doesn't care what the contents of the letter are. It just performs the action of picking up the envelope from point A and sending it to point B. The envelope itself can be seen as an IBC packet sent from one chain to another. On this envelope, you write the address of the recipient, which is equivalent to the IBC packet containing the sender and recipient information. Finally, the recipient (application) receives the letter (packet) and opens it to read its contents.

Transport Layer

Messages that need to cross-chain are packaged in packets and transmitted Layers are responsible for transmitting, validating, and ordering these packets. At the transport layer, it doesn't care what is in the data packet, nor does it care how the receiving chain decodes the data packet. From the perspective of the transport layer, the information in the packet is just random bytes.

The key components of the transport layer are light clients, relays, connections and channels.

Light Client

Responsible for verifying message proofs in packets. A light client is a lightweight alternative to running a full node. Unlike a full node,it does not store all block data nor execute transactions. Instead, they only validate block headers. The IBC light client is actually a validation algorithm in one blockchain that tracks state changes (timestamp, root hash, next validator set hash) in another blockchain, which saves space and improve the efficiency of processing consensus state updates.

That is to say, two independent areas that use IBC interaction Block chains A and B have light clients of each other's counterparty chains. For example, there is a light client of chain B on chain A. When chain A wants to communicate a certain message X with chain B, it will send the data packet containing the block header and message proof of the block of message X to chain B. . Chain B then uses the received packet to cryptographically verify that chain A executed message X. vice versa.

The IBC security model is based on light clients rather than chains. In other words, the IBC protocol does not care about the information of the chain, as long as the IBC light client maintains a valid consensus update and can verify the Merkle proof. This is similar to IP address and DNS, where IP address is the clientID of the IBC and DNS is the chainID.

Repeater

In IBC, blockchains do not directly transmit messages to each other through the network, but rely on relays for communication. Relays are off-chain processes responsible for monitoring the status of each chain running the IBC protocol and relaying updated packets to counterparty chains. As in the example in the previous paragraph, when A sends message X to B, A will submit or store the hash value of the packet containing message X in its state machine. When relayers see that A has submitted a message X in the state machine that they intend to send to B, they just need to pick up this message X and pass it on to B.

The repeater is responsible for sending data packets back and forth and cannot modify the data package, and does not perform any validation on the data package, so it does not need to be trusted. Repeaters are also used when establishing connections and channel handshakes. When the chain at one end of the connection attempts to fork or other malicious behavior, the relayer can also submit misconduct as evidence.

There is a flaw in relying on repeater communication: imagine if every Running repeaters between blockchains would be very complex and wasteful of resources. So the Cosmos Hub was born for this purpose, as a hub for transferring data between blockchains. Only need to run a repeater between the blockchain and the Cosmos Hub, this blockchain can transfer data to and from other blockchains that are already connected to the Cosmos Hub.

Currently, the operation mode of off-chain repeaters is feasible in the short term, but in the long run unsustainable. In this regard, IBC proposed an on-chain relay incentive method in the cross-chain standard ICS-29, including three different methods, fee middleware, fee subsidies, and budget modules. The purpose is to provide a sustainable income model for relayers.

Note: Since this article mainly describes the working principle of the IBC protocol, if you want to know more about For the content of the repeater, you can read the related articles of the repeater in the reference materials at the end of the article.

Connection

Responsible for connecting light clients on two different chains, and verifying whether the clients of their respective counterparties are correct through the four-way handshake. The simple understanding is that before the light client verifies the data packet, the connection must first verify the identity of the "light client" verifier. All the operations of these four handshakes are triggered by the repeater, and before each handshake updates the connection status, the status of each other's light clients on the two chains will be updated to ensure that their consensus status is up to date. An overview of the process is as follows:

Handshake 1 – OpenInit, from This handshake initiated by chain A updates its connection state to INIT

Handshake 2 – OpenTry , chain B verifies the identity of chain A based on the information of chain A in its light client (the last snapshot of the algorithm and consensus state, including the root hash of the latest height and the next validator hash). At the same time, it also verifies whether the counterparty Chain A has the identity information of Chain B. After both verifications are passed, the handshake is initiated from chain B to update its connection status to TRY.

Handshake 3 – OpenAck, chain A verifies the identity of chain B in its light client, At the same time, verify whether chain B has the correct identity information of chain A. After all verifications are passed, this handshake initiated from chain A updates its connection status to OPEN.

Handshake 4 – OpenConfirm, Chain B confirms both self-identification and counterparty identification Success, update its connection status from TRY to OPEN Handshake ends, successfully establishes IBC connection

From the description of the above four-way handshake, we can see that the chain A and chain B have light clients of their opponent chains. During the process of establishing a connection, they each verify the opponent information of their own chain and their own information of the opponent chain to prevent malicious impersonation and verify that they are each other.

Channel (channel)

The communication between applications in IBC is carried out through channels, which are on these different chains A pipe for transferring packets between application modules. A connection can have any number of associated channels. However, each channel is only associated with a connection ID (ConnectionID), which is used to identify the light client, and a port ID (PortID), which is used to identify the application connecting to the channel.

Application modules on the chain are responsible for how packet data is decoded and processed. The data packets transmitted by the channel can be ordered (ORDERED) and processed by the receiving module in the order they are sent; they can also be unordered (UNORDERED) and processed in the order they arrive. It should be emphasized that in most applications the order in which packets are sent does not matter, so packets can be sent in any order and received in any order. This is especially important for token transfers. Because if a packet times out, they can no longer be received in-order, and the in-order channel is closed. Moreover, for the communication between blockchains, most of the time it is asynchronous, and it is difficult to guarantee that it receives data packets in the order they were sent.

Similar to how a connection is established, a channel is also established through a four-way handshake, each of which is initiated by a repeater. The handshake process for establishing a channel is as follows:

Handshake 1 – ChanOpenInit, set chain A to INIT state . During this process, the application may customize a series of checks through the callback, such as whether the port is correct, whether the channel is in the expected order, whether the version of the application is consistent, and so on.

Handshake 2 – ChanOpenTry, if chain B verifies that the state of chain A is INIT, it will Chain B is set to TRY state.

Handshake 3 – ChanOpenAck, if chain A verifies that the state of chain B is TRY, it will Chain A is set to OPEN state.

Handshake 4 – ChanOpenConfirm, Chain B If the verification chain A status is OPEN, it will Chain B is set to OPEN state.

When the channel status of chain A and chain B are both OPEN, the channel is established success. In every handshake, the application version consistency needs to be checked. Because the data packet is parsed by the application, if the application version is different, it may cause the parsing of the data packet to fail.

Note that although the handshake process is similar, the connection (Connection) connects two blocks chain. A channel connects two modules.

Transmission process of data packets

In the above content, respectively Introduces the key components of the transport layer, how light clients, relays, connections, and channels all work. So, how is a data packet to be transmitted across chains?

As shown above As shown, there are two examples of packet flows, the first is a successful packet flow, and the second is a flow in case of a timeout. The details are as follows:

APP A in chain A calls sendPacket to send to APP B in chain B A data packet, the core IBC a of chain A submits the data packet to update its status, the repeater monitors this data packet and sends a message to the core IBC b of chain B. During this process, core IBC a and core IBC b will perform various verifications, verify that the data packet is indeed sent by chain A, whether the order of the data packets is correct, whether the message proof of the data packets is valid, and so on. If the core IBC authentication succeeds, the packet reaches APP B. After APP B receives the data packet from the core IBC, it will unpack it according to the expected structure, and then execute the corresponding application logic. After the data packet is processed, a receipt will also be given to chain A.

In the packet structure of the IBC protocol, the timeout timestamp (TimeoutTimestamp) and Timeout block height (TimeoutHeight), if the data packet arrives at chain B timed out, the data packet will not be processed. However, chain A will roll back the state of the data packet if it has not received the receipt after the data packet sent expires. For example, the application of token transfer will cancel the custody of locked tokens and so on.

Application Layer

The application layer is where the end user interacts. It is a variety of applications built on top of the transport layer and is responsible for processing packets from transport layer channels. Currently, the most widely used IBC applications are cross-chain token transfers and cross-chain accounts.

Cross-chain Token Transfer

Users can send tokens across chains that support IBC, following Inter-Chain Standard 20 (ICS-20). ICS-20 (Interchain Standards -20) specifies the structure of packets and how the receiving chain decodes them. By hosting the token on the source chain, the proof of custody and token metadata are relayed to the target chain, and the proof of custody is verified by a light client stored on the target chain. If verified, a certificate is generated for the token on the target chain and a confirmation is sent back to the source chain. There is also a situation where the tokens are transferred from the target chain back to the source chain, first the target chain destroys the tokens, and then the source chain releases the tokens in custody.

Cross-chain account

Follow ICS-27, a cross-chain account management protocol based on IBC. At the same time, ICS-27-enabled chains can programmatically create accounts on the opposite chain, and send data packets through IBC to control these accounts, without having to use private key signatures. Cross-chain accounts allow blockchains not only to exchange data, but also to write state. A cross-chain account contains all the functions of a normal account (i.e. pledge, send, vote), and it is managed by a separate chain, the controller chain, through IBC. Accounts on the control chain have full control over accounts on the main chain (host chain).

Further explain why cross-chain accounts can achieve all functions of ordinary accounts without key signature ? To put it simply, the IBC data packet with "programming instructions" is sent to the main chain through the control chain to programmatically control the accounts in the main chain.

Another feature of the cross-chain account is that it improves the experience of cross-chain interaction, it allows users to Stay on the same interface without realizing cross-chain interaction.

In addition to the above-mentioned cross-chain token transfer and cross-chain account, IBC also has:

- Interchain Security: was proposed and upgraded at the Cosmos 2.0 Conference. It enables blockchains to rent security from another chain (such as Cosmos Hub), without the need to build their own validator nodes, and only need to pay a small rental fee.

- Fee Middleware: Follows ICS-29 for Incentivize packet relayers.

- Cross-chain NFT transmission:ICS-721, is a An application layer protocol that allows cross-chain NFT interoperability between IBC-connected blockchains (including homogeneous chains and heterogeneous chains).

How safe is IBC?

Among the seven main development teams in the Cosmos ecosystem, the Informal Systems Team is mainly responsible for security reviews. The IBC protocol specification, protocol review, and model-based testing are all done by this team. IBC security is designed around two main principles:

Chain of Trust (Consensus) Instead of a bridge (third party)

Validation of packets in IBC is done by light clients. Therefore, the security of IBC depends on the security of light clients. That is to say, using IBC to interact between chains does not require additional trusted third parties, which is also called "trust minimization". Using a light client based on the source chain also means that its security is basically consistent with the underlying security assumptions of its blockchain.

Fault Isolation Mechanism

It is possible to limit any damage done when these links are affected by malicious behavior.

In Tendermint, fast finality of chains is required (i.e. Transactions are packaged quickly and cannot be reversed or changed), which is also a prerequisite for IBC, so in principle, forks should not occur. If there is malicious behavior on one chain in the cross-chain communication using IBC, the relayer can submit a proof of misbehavior, and the light client on the other chain will be frozen. After the attack has been neutralized, the light client can be unfrozen through a governance proposal, thereby recovering the funds.

As we all know, the Terra chain stablecoin Luna is almost zero, in this crisis, although the ecological Some blockchains have been affected, but most of them are affected by the economic model, and the use of the IBC protocol in terms of security has also withstood the test.

Compared with cross-chain bridges, IBC's trust minimization makes it more secure. But it also has its flaws. The core "light client" that realizes IBC's trust-minimization is a daunting development task for small teams. In the Cosmos2.0 white paper, it is mentioned that "cross-chain security" may solve this problem. Cross-chain security will allow other blockchains to "rent" security from the Cosmos Hub instead of having to build and maintain validators for their own chains. It can be understood that the Cosmos Hub is a supplier chain, and other application chains are consumer chains. The supplier chain generates blocks for the consumer chain, and the consumer chain issues block rewards to the supplier chain and its verifiers . For small teams, the use of cross-chain security can reduce the excessive technical burden in the early stage, and at the same time ensure the security of their blockchain.

How can IBC leverage other non-Cosmos chains?

Although IBC is derived from Cosmos, it can also be used in other chains (not based on Cosmos SDK build), or even a completely different consensus from Tendermint But this requires chain-based consensus type and blockchain framework to develop different components required by IBC, such as:

1. Implementation of the IBC transport layer The implementation of the light client on the chain is used to track the counterparty chain to be connected. (The realization of the light client of the counterparty chain under the technical framework of this chain)

2. The implementation of the light client based on the chain consensus type will be used on the counterparty chain.

As mentioned earlier, developing these components is not a simple matter. With the support of the Interchain Foundation (ICF), there are several development teams using IBC for Bitcoin, Ethereum, Polkadot, etc.

What are the application chains that use IBC?

Since Cosmos launched the blockchain inter-chain communication protocol (IBC) in April 2021, the Cosmos blockchain Internet is developing rapidly. According to the data on IOBScan, up to now, there are 53 application blockchains connected through IBC, 48 active chains, and 9.2 million IBC transactions have occurred. The successful implementation of IBC attracts more users to Cosmos, which benefits the entire ecosystem.

In-depth understanding of the application chain using IBC, you can master The initiative to invest in the Cosmos ecosystem in the future. The following is a brief introduction to the Cosmos ecological projects that use IBC. The data comes from "Cosmos Ecosystem - Q3 2022 Quarterly Report".

Osmosis – Top DEX on Cosmos

Link: https://osmosis.zone ///a>

With a TVL of $209 million, Osmosis ranks in the Cosmos ecosystem second. Osmosis always provides a high-liquidity flow pool, which is the first choice for the Cosmos ecosystem.

Osmosis is consistently number one in IBC statistics and in the third quarter, The 30-day IBC volume is growing every month. In September, Osmosis’s IBC totaled $468.73 million and currently has 46 peers and 174 channels. Additionally, Osmosis has 62,027 IBC monthly active users, accounting for 45.4% of the overall MAU.

Kava – Cosmos' first DeFi platform

Link: https://www .kava.io/

Kava Network is a Layer1 blockchain, its The proposed "co-chain" architecture can support the cross-chain flow of Ethereum EVM and Cosmos. It is committed to providing product applications and developers with a permanent financial service infrastructure without threshold. At the same time, the Kava DApp created by its team It is the first DeFi platform on Cosmos, similar to MakerDAO, providing cross-chain decentralized financial services for mainstream digital asset mortgage loans and stable coins.

Currently, Kava's TVL is $291.2 million, ranking first in the Cosmos ecosystem, surpassing Near Protocol. In addition, both SushiSwap and Curve have announced their deployment to Kava.

Secret – Cosmos Ecological privacy chain

Link: https://scrt.network/

Secret network is The first customizable privacy blockchain. Users can choose what to share, with whom, and how. This protects users and enables developers to build a better Web3.

Secret is currently using CosmWasm version 0.10, and will upgrade to CosmWasm version 1.0 with the Shockwave Delta mainnet upgrade. With CosmWasm1.0, Secret smart contracts can run on multiple chains with the help of the IBC protocol.

Juno Network – Cosmos Ecological cross-chain smart contract platform

Link: https://www.junonetwork.io/

Juno is developed by the official Cosmos team, an interoperable smart contract network that can deploy DApps. Unlike the Ethereum EVM which uses Solidity smart contracts, Juno-based smart contracts use CosmWasm.

Many people complain about Juno, if you want to do DAPP, you can go to Ethereum, why come to Juno? In fact, Juno may be more of a practical product used by the Cosmos official team for ecological development, just like before Osmosis, the Cosmos official team developed Gravity DEX, which was shut down after being overtaken by Osmosis latecomers. And because the development of Cosmos SDK modules is relatively easy to use, you can also enjoy the help of the Cosmos ecosystem by choosing Juno to build DApps. Many small DApp products have an advantage in choosing Juno.

Cosmos ecology is a blockchain Internet, and IBC is responsible for "cross-chain communication", which is similar to "TCP/IP" in Web2 Internet. Osmosis (DEX), KAVA (DEFI), Secret (privacy), Juno (smart contract DApp), are all independent blockchains. Their development directions are different, but they all use IBC to strengthen each other. The interoperability and composability of the ecology make the users in the ecology continuously increase and benefit from each other.

IBC Visualizer ;

Recommend three IBC network visualization tools, you can view the chain (hub&zone), connection, channel, transaction information in the IBC network, Can also help with repeater selection.

MapOfZones

Cosmos web browser. You can intuitively see the connection relationship between the various chains under the Cosmos ecological network and the current activity information, including: IBC transfer times, IBC transaction volume, success rate, transaction volume, transaction volume, etc.

As shown above, MapOfZones can also show chains and A list of connections between chains. You can also see channel information between the selected chain and other chains.

Mintscan

also Cosmos web browser . The feature of Mintscan is that in addition to the relationship between the basic Cosmos ecological network chains and the display of IBC information, you can also see connections, send/receive transactions, relayer transaction history, and relayer transaction volume on the detailed page The information of the repeater is very detailed.