IBC. Interoperability, interchain communication, and appchains. Whether you’re newer to the crypto scene or a multi-cycle battle-hardened degen, you’ve most likely come across these terms. If you use crypto protocols regularly, then you know firsthand that crypto is a digital universe containing a seemingly infinite array of dispersed networks and applications. How do these terms relate?
The nearest galaxy to ours, Andromeda, is over 2.5 million light years away. Even if you managed to travel 2.7 million times the speed of F1's top speed record, it would still take you 2.5 million years to arrive at Andromeda. Our universe, as crowded and bright as it may seem on a clear night, is unfathomably isolating.
Much like our own universe, the cryptoverse has a major isolation problem as well.
A Multichain World In Need of Unification
While we can browse the web2 world seamlessly from one application to the next, the web3 world enjoys no such conveniences by default. This fragmentation poses significant challenges to users and web3 applications.
Prior to 2019, a token, contract, or component of chain data could not realistically translate from one blockchain to another at scale. Sure, you could utilize hacky, slow, and difficult to use P2P exchanges of native assets like atomic swaps. But where’s the fun in that?
To further illustrate the problem, suppose a user yield farms on protocol A and dutifully earns separate airdrops across isolated blockchains B, C, and D. What if they wanted to regularly collect all their newly earned tokens and bring them all together into protocol A, which happens to be home to the safest lending protocol?
A straightforward solution to this is to build a bridge. The concept works as follows: the user deposits their tokens from chain A into a bridge smart contract on chain A. Once the tokens are securely deposited, a corresponding smart contract on chain B issues a ‘wrapped’ version of those tokens to the user’s wallet address on chain B. In this way, the user effectively bridges their funds from one chain to another. Wormhole, Ronin, Nomad, BNB, Harmony, Hop, and many other bridge protocols have formed around this idea.
For more complex use cases, suppose a developer wants to build a protocol that tracks wrapped collateral positions, token prices, or wallet activity on one chain to initiate arbitrage or liquidation strategies on another chain. The protocol must securely validate this data without experiencing downtime or data manipulation. If the data is not accurately and timely transmitted across chains, the developer will face significant challenges.
These challenges restrict the flow of users, tokens, liquidity, talent, app-specific utility, oracle data, and mindshare between blockchain protocols. Web3 cannot succeed with such fragmentation.
Problems with Bridges
Bridges are a commonly used vessel to mitigate these challenges by bringing data and tokens from one chain to another. However, they often rely on a small centralized group of operators. These operators observe deposits and withdrawals from the bridge on chain A, and then report that information to chain B. As long as there exists an honest majority of operators, or the basic fulfillment of some cryptographic logic, then all of the deposits and withdrawals can be successfully transferred from A and notated for chain B. Problem solved. Sounds great right?
Unfortunately, this is not so great. Blockchains are heterogeneous. The combination of trust assumptions, lack of standards around finality guarantees from one chain to another, and complexity of the logic in many of the bridges mentioned earlier has resulted in gargantuan failures. Over $1 Billion in value has been exploited from bridges over recent years which typically results in significant token depegs, and leaves shockwaves across DeFi ecosystems. Any DeFi protocol relying on tokens or data spawned from these bridges is at risk of collapse depending on how large its exposure to the corrupted assets was.
The diagram above illustrates several potential attack vectors to traditional bridges. Suppose Blockchain A is a “fast finality” rollup, and Blockchain B is a much higher finality time backed by more than 100 times the economic security of Blockchain network A. Blockchain A may also be subject to frequent block reorganizations, which can be a messy situation to deal with. They are common on chains like Ethereum and Polygon to name a couple, and can definitely pose risk to the operation of bridges.
Combine this with the fact that the bridge itself acts like a bank vault, storing vast quantities of tokens as IOUs to users transferring in and out between chains A and B. Every contract that stores significant value becomes an even larger target, attracting the constant attention of attackers worldwide.. All this risk and it could still take up to 30 minutes (depending on the chains being bridged) for your tokens to finally arrive out the other end.
IBC is a Cosmic Bridge and Universal Translator
On March 29th 2021, the inaugural IBC connection was created.
The Inter-Blockchain Communication Protocol (“IBC”), is described as the “internet of blockchains”, and the “gold standard” for blockchain interoperability. It is akin to surfing the web but for crypto. Launched in 2021, the protocol provides standards for blockchains to communicate end-to-end, and transfer data amongst each other. Each of these inter-chain standards (“ICS”) follows a predefined specification.
While the Cosmos network ($ATOM) is often confused with IBC, it is important to note that the two concepts are distinct. Cosmos is a network, and a platform for deploying parallel blockchains, or “appchains”. It provides the infrastructure, via the Cosmos SDK, for easily creating and connecting these independent blockchains.
Critically, IBC standards can be adopted and used by any blockchain — regardless if it is a part of the Cosmos network or not.
Often chains built with the Cosmos SDK have IBC in mind by default, as the core thesis of the Cosmos platform itself is to facilitate interoperability between different blockchains. Axelar is a unique protocol as it utilizes both IBC and traditional bridging for protocols without native IBC, in order to connect more chains to its network.
IBC Technical Components
Let’s briefly dive under the hood. The protocol operates on a modular architecture, with a focus on adaptability, security and decentralization. It can easily be integrated into new blockchains. As of this writing, over 100 networks have integrated with IBC.
There are two primary layers to IBC:
I. Core Transport Layer
This layer of IBC handles the secure transport, authentication, and ordered delivery of data packets between blockchains. It is conceptually similar to how TCP/IP operates on the internet. The layer has four components:
- Channels: Act as a conduit to connect a module/application on the source chain to a module on the destination chain. Data packets between the source and destination chains are sent over these channel abstractions. Channels can be ordered or unordered, depending on whether packet ordering needs to be enforced
- Light Clients: Lightweight representations of a destination blockchain that live within the state machine of the source blockchain. They track the consensus state of the counterparty chain by verifying block headers and Merkle proofs, enabling cross-chain verification without requiring a full node
- Connections: Link the light clients of two different blockchains together. They establish an authenticated channel over which the light clients can communicate and pass messages/packets.
- Relayers: The backbone of IBC. Permissionless off-chain processes that ferry data packets from one blockchain to another. They scan chain states, build transactions based on these states, and submit the transactions to the involved chains. Relayer operators play a crucial role for IBC. In fact, relayers as of June 2024, will be eligible to receive fees for their work.
II. Application Layer
The Application Layer interprets the data packets received from the Transport Layer, enabling user interactions, smart contract executions, and defining how data is packaged and interpreted by the sending and receiving chains. It is through this layer that end users transact with the interchain. The key components are summarized below:
- Token Transfers: Facilitates the seamless transfer of tokens between different chains. For example, transferring assets like ATOM or other tokens across IBC-enabled chains.
- Cross-Chain Smart Contracts: Enables the execution of smart contracts that can interact with contracts on other blockchains, expanding the capabilities of dApps.
- Interchain Accounts: Allows one blockchain to control an account on another blockchain, streamlining complex interactions and automating cross-chain processes.
- Oracles: Integrates with oracles, or blockchain data providers, to provide reliable information from external sources across different blockchains. Critical for any dApps that rely on real-world data.
- Custom Modules: Developers can create custom modules to support unique use cases and business logic, leveraging the modularity of IBC to extend its capabilities.
Security of IBC
Wrapping all of these components together is the robust security of IBC. The underlying security of IBC is permissionless, and relies on the Interchain Security provided by the Cosmos hub. 180 validators secure over $2.5B in assets today via this security mechanism.
Additionally, there is a fault isolation mechanism that exists to prevent a malfunctioning or malicious blockchain from impacting others in the IBC network. Here are the key principles of this mechanism:
- Consensus Divergence Handling: If the full nodes running the consensus algorithm diverge from the light client, or if the ledger’s state machine incorrectly implements the escrow & voucher logic, the divergence gets marked as misbehavior. This can lead to freezing the client, and isolating the fault to prevent it from affecting other chains.
- Asset Recovery Limitations: Containment logic can be implemented on the interface boundary by tracking the incoming and outgoing supply of each asset. This ensures that no ledger is allowed to redeem vouchers for more tokens than it had initially escrowed, preventing supply inflation of source assets.
- Channel-Based Accounting: Certain channels can be treated as accounts, where a module on the other end of a channel cannot spend more than it has received. This further isolates any potential faults to the specific channel or account.
- Byzantine Fault Tolerance: IBC is designed to handle Byzantine faults, where a portion of the network may behave maliciously or unpredictably. The protocol can automatically detect, mitigate, and contain the potential damage of such faults without requiring the use of additional trusted parties or global coordination.
In Conclusion
IBC enables the rich landscape of blockchains to communicate with each other with minimal sacrifices to trust, security, and scale. Given how likely a multichain future is, today I am paying close attention to blockchains built with inter-communication in mind. Some day we will be able to say with certainty that the crypto universe is foundationally connected. With enough luck and grit, that day will come soon.
Thanks for reading and see you next time!
~Dan
