Why IBC Everywhere is the Key to Cross-Chain DeFi

While it was once a highly debated topic, it is now quite clear that DeFi’s future is cross-chain. Countless projects and protocols have been created in recent years and months that are working towards this goal. Yet, it remains to be seen which cross-chain communication mechanism will reign superior.

At Composable, we believe the ideal solution for cross-chain communication is the Inter-Blockchain Communication (IBC) Protocol. IBC has many benefits that make it the best tech stack for interoperability, as we present in the following article. Ultimately, IBC is emerging as the gold standard of interoperability, and Composable aims to be at the helm of its expansion into all ecosystems. As a result, DeFi will be unified in a manner that best serves its users.

IBC Overview

The Inter-Blockchain Communication (IBC) Protocol enables communication between different blockchain ecosystems. A more technical description is that IBC is an end-to-end stateful protocol for reliable, ordered, and authenticated communication between blockchains. It enables bi-directional asynchronous communication between two blockchains.

The following summary of IBC’s architecture is taken from IBC’s documentation:

The transport layer (TAO) provides the necessary infrastructure to establish secure connections and authenticate data packets between chains. The application layer builds on top of the transport layer and defines exactly how data packets should be packaged and interpreted by the sending and receiving chains.

IBC provides a reliable, permissionless, and generic base layer (allowing for the secure relaying of data packets), while allowing for composability and modularity with separation of concerns by moving application designs (interpreting and acting upon the packet data) to a higher-level layer.

This separation is reflected in the categories:

• IBC/TAO comprises the Transport, Authentication, and Ordering of packets, i.e. the infrastructure layer.
• IBC/APP consists of the application handlers for the data packets being passed over the transport layer. These include but are not limited to fungible token transfers (ICS-20), NFT transfers (ICS-721), and interchain accounts (ICS-27).
• Application module: groups any application, middleware or smart contract that may wrap downsteam application handlers to provide enhanced functionality.

Note three crucial elements in the diagram:

• The chains depend on relayers to communicate. Relayers are the “physical” connection layer of IBC: off-chain processes responsible for relaying data between two chains running the IBC protocol by scanning the state of each chain, constructing appropriate datagrams, and executing them on the opposite chain as is allowed by the protocol.
• Many relayers can serve one or more channels to send messages between the chains.
• Each side of the connection uses the light client of the other chain to quickly verify incoming messages.

IBC Strengths & Benefits

Composable has chosen to use IBC as its cross-chain communication standard of choice because of IBC’s many strengths:

Trustlessness

As we have previously discussed in detail in our blog here, IBC offers an incredibly high degree of trustlessness. When a blockchain protocol is trustless (also referred to as having a decentralized trust architecture), it lacks assumptions/requirements that third-party actors must behave a certain way in order for the protocol to function properly. In other words, there are no middlemen that must be trusted to behave as expected. As a result, users only need to trust in publicly visible code when transferring over IBC.This lack of trust assumptions makes protocols like bridges less vulnerable to misbehavior and attack.

Specifically, IBC has native verification, which means that the verification of transactions and messages between blockchains is achieved through the built-in consensus mechanisms of the participating blockchains themselves, without requiring a separate, external layer of trust or verification. As a result, IBC doesn’t place any trust assumptions on third-party actors, meaning it is trustless/natively verified. To facilitate cross-chain communication, IBC instead uses light clients (also called light nodes), which are lightweight representations of a blockchain living in the state machine of another blockchain. Light clients are thus highly efficient in their information processing, in addition to their trustlessness.

Compared to other bridging mechanisms, IBC-based bridging is amongst the most trustless; IBC is superior to centralized, permissioned, and optimistic bridges and is comparable to ZK bridges, which are often considered the gold standard in trust-minimized bridging but are limited to connecting Ethereum and its layer 2s.

Security

In addition to trustlessness, a number of other factors provide IBC with augmented security. Indeed, IBC has not experienced a single hack since its creation around three years ago. For example, the IBC’s overlapping professional validator set delivers quorums that are far more secure than L2s with disjointed governance (as explained here).

Censorship Resistance

With IBC, there are no centralized entities that can censor transactions. If one relayer decides to not send a given packet, other relayers will step in to do so.

Permissionlessness

The decision for a protocol or chain to connect to IBC or not sits at the individual blockchain level. This process is not governed by any centralized entity that must grant a protocol permission to connect.

Speed

IBC cross-chain communication can occur within a relatively short time window: an average of less than one minute per IBC message (Kim, Essaid, and Ju, 2022). This speed is in part driven by IBC’s asynchronous communication.

Cost

IBC keeps user fees low; each chain is able to set its own IBC fee structure, but given the efficient nature of IBC, these are generally very low or entirely free.

Interoperability

IBC is natively interoperable with the Cosmos hub and all of the approximately 110 Cosmos SDK chains; it was truly designed with interoperability in mind. This provided an excellent starting point for expanding it into a solution for interconnecting all major blockchain ecosystems.

Technological Hurdles

Despite the benefits of the IBC, there are a number of hurdles to connecting this protocol to other chains. Composable has successfully been able to overcome these challenges, becoming the first team to successfully bring IBC to other networks.

Originally, the IBC Protocol was tailored for native connections within the Interchain Ecosystem, specifically including Cosmos SDK chains and the Cosmos Hub. Extending this to include more networks required significant development effort.

In fact, Polkadot IBC (DOT IBC), Kusama IBC (KSM IBC), Ethereum IBC (ETH IBC), and Solana IBC (SOL IBC) all required customization, which ranged from implementation of light clients to achieving state proof (finality). As a result of these customizations, IBC connections have been established that do not rely on any centralized intermediary and uphold the IBC values of censorship resistance and native security. Composable is working to continue to expand these connections to all major blockchains, leveraging its innovations below in addition to any other necessary developments:

Light Clients

For all of our IBC connections (including Polkadot, Kusama, Ethereum, and soon Solana), we needed to create light clients on each chain, as well as their corollaries in the Interchain. Light clients are essential components of the IBC protocol as they facilitate secure and efficient cross-chain interactions without the necessity of fully synchronizing and managing the complete history of every connected blockchain.

Establishing light clients on Ethereum was particularly challenging, given that Ethereum lacked light client implementations when we began our development. Now, Ethereum has limited light client options, but developing our own enabled us to create the most tailored solution.

Zero Knowledge Circuit

Another novel component of our Ethereum IBC connection is a zero-knowledge (ZK) circuit, which is a program that outputs a proof when given a set of inputs. This proof can then be easily verified to ensure each computational step that was run inside the circuit was done so correctly.

Hyperspace Relayer

Relayers send information across blockchains connected by IBC. Hyperspace is a custom relayer implementation that allows transferring arbitrary packets on non-Cosmos blockchains using the IBC protocol. In the future, we anticipate that other relayer solutions will add support for cross-ecosystem message passing through IBC. However, as of now, Hyperspace is the only relayer implementation that has this functionality. This makes it a critical component of our IBC connections.

Guest Blockchain

Because of the requirements of the IBC protocol, Solana and a number of other chains like TRON and NEAR were previously incompatible with IBC. For example, Solana lacks state proofs (as detailed here). Composable has collaborated with the INESC-ID Distributed Systems Group at the University of Lisbon to develop a mechanism for making Solana and other IBC-incompatible chains capable of connecting to IBC for the first time. We are initially deploying this mechanism for Solana, with plans for expansion to other networks in the future.

The TL;DR of this innovation is a guest blockchain that runs on top of Solana, providing all of the features needed to make Solana IBC-compatible. Validators on the guest blockchain receive messages about transactions on Solana, using this information to create blocks on the guest blockchain that reflect these Solana transactions.

Thus, the guest blockchain essentially serves as a replication of the Solana blockchain, but unlike Solana, it is able to interoperate along IBC and the Picasso Network. In this manner, the guest blockchain is a sort of layer 2 (L2) of the Solana network.

Key Takeaways

IBC is truly the end game for bridging: it is trustless, secure, censorship-resistant, permissionless, fast, and interoperable. Because of these strengths, the IBC is growing in popularity and utility: IBC has seen over $30 billion in annual value transfer, with over 30 million individual token transfers annually. At Composable, we are working to drive IBC everywhere, helping IBC and its manifold benefits to be rightfully established as the standard of cross-chain interoperability.