Bridging Over the IBC
Summary
Composable proposes that SUAVE uses the Inter-Blockchain Communication (IBC) Protocol as its native bridge. The IBC is a trust-minimized interoperability protocol that Composable is working to connect to all chains. The IBC is compatible with 100+ Cosmos SDK chains, Ethereum (in testnet), Solana (in testnet), Polkadot, and Kusama, with more connections planned in the future. Using the IBC, SUAVE could have a mechanism for trust-minimized, scalable, and decentralized bridging.
Proposed Solution: The IBC
The Inter-Blockchain Communication (IBC) Protocol is a protocol for trust-minimized communication between different blockchain networks/ecosystems. This trust-minimization is a core advantage of the IBC protocol, and a large reason why we selected the IBC as a cornerstone of Composable’s efforts to connect ecosystems, as we explain below.
The following summary of IBC is taken from IBC’s documentation.
The following diagram shows how IBC works at a high level:
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.
Decentralization
By using IBC, SUAVE can implement a decentralized bridge.
Most bridges and connections between blockchains are built in a centralized manner and rely on trusted architecture. This is a massive security risk for users’ assets as can be seen from the numerous hacks and exploits over the past few years. A trusted bridge is a connection between blockchain networks that relies on a third party to facilitate asset transfers between these networks. This third party is tasked with upholding bridge security and reliability. Users must therefore trust this entity to properly handle their transactions.
In contrast, a trust-minimized architecture like one using IBC is based on light client bridging and connecting two blockchain networks without any trusted third party intermediaries. Users can transfer assets between the two networks without needing to trust a third party, instead only needing to trust in code, which is made publicly available to and auditable by all. However, existing trustless bridging solutions are generally not extensible across ecosystems or often sacrifice speed or UX in the bridging process. For more information on the advantages of trustless connections and the current limitations of trusted bridges, check out our blog on this topic.
IBC is designed to be trust-minimized for several key reasons:
- It relies on light clients that interact to keep each other updated on the states of counterparty chains.
- It can update chain states through the transmission of finality proofs and other types of verifiable transactions and packets.
A more technical explanation of why we chose to expand IBC is that it is an end-to-end stateful protocol for reliable, ordered, and authenticated communication between blockchains. It enables bi-directional asynchronous communication between two blockchains within a relatively short time window: an average of less than one minute per IBC message, as reported by Kim, Essaid, and Ju, 2022. Thus, IBC is our mechanism of choice for facilitating cross-chain communication in a trust-minimized manner, and we believe that it is similarly optimally suited as SUAVE’s bridge.
Security
If SUAVE adopts an IBC bridge, security will be augmented by the trust-minimized nature of IBC. As the IBC website states the protocol’s “…light client-based interoperability removes the need for a trusted third party in cross-chain interactions, securing tens of billions in annual value transfer without a single exploit since launch.”
Light clients serve as a lightweight, trustless mechanism for verifying the state of connected blockchains. They 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.
Chain Scalability
If SUAVE uses the IBC, its bridge will be quite scalable, given that the reach of the IBC is quite wide and rapidly expanding. IBC originated as the standard messaging protocol for Cosmos. Composable has expanded the IBC from this initial deployment; IBC thus connects all 100+ IBC-enabled Cosmos SDK chains, ~80 Polkadot and Kusama parachains, Ethereum (in testnet), and Solana (coming soon), with more connections planned for the future. Our eventual goal is to connect all major chains over IBC.
User Experience
The IBC supports an improved user experience for cross-chain transactions. In fact, user (and developer) experience are one of IBC’s top priorities (source).
For one thing, the IBC is highly performant; It enables bi-directional asynchronous communication between two blockchains within a relatively short time window (an average of less than one minute per IBC message) (Kim et al., 2022).
Moreover, IBC is compatible with a wide array of transactions, serving a user’s many needs. These transactions include the transfer of both fungible and non-fungible tokens, generic message passing, cross-chain contract calls, cross-chain fee payments, and interchain collateralization, all executed in a trust-minimized environment.
Similarly, the IBC offers a very mature and expansive solution for developers. Using IBC, it is possible to build extremely sophisticated distributed programs, with autonomous execution over untrusted domains. Thus, performant and manifold solutions can be developed with the IBC, serving whatever needs a user may have.
IBC also enables cross-chain bridging to be:
-
One-stop: users can bring any asset from any chain, swap natively, and instantly earn yield
-
Flexible: users can maximize the potential of their assets with any number of DeFi processes such as lending, staking, restaking, liquidity provisioning, vault participation, lockdrops, NFT borrowing, limit orders, and perpetual swaps
-
Optimized: users get best-price execution with dark pools and cross-chain MEV subsidies
-
Simplified: users experience a seamless, intuitive interface
These benefits in user experience can be delivered to SUAVE bridge users if IBC is leveraged in the bridge design.
Conclusion
IBC is a battle-tested protocol that has been gaining rapid adoption. Its use in a SUAVE bridge will likely bring cross-chain composability, and a truly trust-minimized mode of communication with other chains.