Welcome to the IBC gang, let’s talk
If the crypto narrative of 2020 was around DeFi and the deconstruction of financial systems to composable primitives, 2021 saw the growth of interoperability– the interaction of these primitives across the growing diversity of crypto ecosystems– as a major component of the narrative. However, this world of sovereign interchain ecosystems with their own values and assets was already a prescient and integral part of the original 2016 Cosmos whitepaper, and continues to be a core part of the Cosmos thesis and stack. Tendermint Core, the Inter-Blockchain Communication Protocol (IBC), the Cosmos SDK, and the Cosmos Hub itself have all been designed on this vision of an interchain future: one built around interoperability as a first principle. In a world of various, diverse ecosystems, IBC enables chains to find a common language, and the latest IBC feature — Interchain Accounts — enables a chain to send a message to another chain, and as well enables the receiver chain to understand how to execute the received message.
A brief overview of IBC and cross-chain communication
The security of cross chain interoperability is only as strong as its weakest (or in this case, its most trusted) link, and cross-chain solutions which allow for communication between heterogeneous chains (ie: chains that are not already connected together through something like a Beacon or Relay chain) can be loosely classified into protocols which depend on third party roots of trust external to the two chains (trust-based*), and protocols that don’t (trust-minimized*).
The design and value proposition of a trust-based* interoperability protocol is simple: its only purpose is to verify transactions being passed back and forth between two ecosystems. Trust in the security of the transaction is delegated to validators on the protocol infrastructure — you trust the validators, you trust the asset. Variations on this design apply which delegate the root of trust to slashable oracles or a bridge validator set, but in all cases the security model of trust-based interoperability protocols take into account an additional security assumption of a third party other than the two chains involved in the initial transaction.
The design of IBC, on the other hand, is trustless. A handshake (modeled off of the TCP/IP handshake) is first initiated and then confirmed between two chains which want to connect. In order to confirm the transaction, validity rules of one chain are directly encoded in the IBC client on the other chain, and state verification is performed against these rules. For example, the ibc-go implementation– which is offered out of the box in Cosmos SDK– uses the Tendermint light client, which can verify the state of the chain on the other side of the IBC transaction by validating a Merkle proof of the block headers associated with the transaction against the latest consensus state of the counterparty chain.
This state validation technique, along with a live network of relayer operators passing the packets back and forth, ensures that IBC remains highly secure and permissionless — any chain can spin up an IBC client and relayer and connect to other self-sovereign Interchain networks. Equally important is that this design also enables any chain ecosystem outside of Cosmos-SDK based chains to connect through IBC, and into the Interchain (IBC ecosystem).
The IBC protocol consists of two distinct layers: the transport layer (or ‘TAO’ for transport, authentication, ordering) which provides the necessary infrastructure to establish secure connections and authenticate data packets between chains, and the application layer, which defines exactly how these data packets should be packaged and interpreted by the sending and receiving chains.
When people talk about interoperability protocols, they are generally referring to the transport layer, and IBC offers the highest security design for this layer. However, the great promise of IBC is the possibility of optimisation not only on transport layer, but also on the layers above it: a powerful and secure, but ultimately generic and permissionless transport layer that supports any number of diverse and innovative applications, from asset transfers and oracle data provision to decentralized identities and cross-chain, synchronous transaction validation to be built on top of it.
The question for the application layer until now has been: how can I transfer my asset from chain A to chain B, and how will these chains understand what the asset is? IBC application layer protocol standards and modules address this question through IBC token transfers, oracle data, and the upcoming Interchain NFT transfer and IBC queries standards slated for finalization in Q2 2022. Interchain Accounts is a protocol level answer to the next question: what can we do, now that the asset has been transferred?
Interchain Accounts and Interchain Composability
As a next step in the evolution of cross-chain interoperability, Interchain Accounts enable native composability in cross-chain transactions, which will allow for chains to not only exchange data, but write state — instead of requiring an end user to move across various interfaces as an asset moves.
A composable system is one where its various components can be decoupled, reshuffled, and reintegrated as building blocks in larger systems. In a highly composable setup, innovation and optimization can happen not only on the highest level, but on every single component. Composability is what enables the whole to be greater than the sum of its parts. Enabling composability in IBC allows innovation in distinct applications to be deployed without needing to upgrade the entire Interchain, providing a more scalable innovation model that preserves compatibility. This is made possible by allowing lower level primitives to be created, optimized and then built into shared infrastructures which are both stateful (value through information) and permissionless (value through accessibility).
Interchain Account Transactions
An Interchain Account transaction is a non-IBC blockchain transaction of the target blockchain packaged inside an IBC transaction. How the transaction is then handled by the receiver chain is left up to the logic on the receiver chain, which allows the Interchain Account to be used for passing over the encoded transaction, no matter what the transaction type is. This allows transactions from application-specific chains to become their own composable primitives — and business models to move from being native to the scope of one chain, to being native on the Interchain. This is supported by enabling one chain to open an Interchain Accounts specific channel on another chain that it is already connected to, and vice versa. On-chain governance from both chains would then whitelist messages which can be accepted by the Interchain Account on each side. These messages are encoded transactions, similar to Ethereum delegatecall encoded functions, which can then be executed on the receiver chain, on behalf of the sender chain. Very simply put, an Interchain Account transaction can be thought of as “a letter inside of an envelope inside of a box”, which contains instructions on what task should be submitted to the receiving blockchain.
How Interchain Accounts will enable chains to move quickly and get shit done
A remark here might be that a similar transaction flow could theoretically be achieved by creating a new IBC application standard. For example, if there would be a new IBC standard for liquidity pool related functionality, then each sender and receiver chain would be able to correctly parse the packets being passed through the relevant IBC transport layer port to their corresponding message types, and perform the transaction execution accordingly.
However, well-designed standards take the long view of an ecosystem and the technical committee behind IBC standards must consider both current iterations of system design as well as their potential iterations over time. Therefore, the development of highly secure standards which can remain relevant over the long term requires considerable time and resources. The reality is that scaling the development of new IBC application layer standards at the same speed as the Interchain ecosystem would not only be extremely difficult but would also be arguably detrimental to the quality of the resulting standards. Forcing application layer innovation to remain tightly coupled with the development of the core transport layer would result in unnecessary delays to application standards and stymy value creation for the larger Interchain. Interchain Accounts enable a world in which robust and secure standards can continue to develop, while still preserving a non-blocking path for chain developers to iterate on their products.
The Trailblazers
In the section below, we want to highlight the work of several entities who be among the first to take Interchain Accounts forward and pioneer the future of Interchain native products:
The Cosmos Hub and Hub-as-Fund
The Cosmos Hub has been a hugely important part of the IBC ecosystem. Not only has it funded the development of the entire Cosmos tech stack, including IBC, but it is also home to the most secure validator set, which will be the basis for upcoming Hub Interchain Services products such as Interchain Security. Now, there is a new proposal in the works for a mechanism which will provide another valuable Interchain Service on the Hub. Using a bonding mechanism where governance tokens are sold at a discount to users who provide a governance selected asset, the Cosmos Hub could operate an open order book that can be filled by any counterparty.
Setting the asset list and prices would be determined by governance, and the deployment of these assets via Interchain Accounts would enable staking, providing liquidity, or deploying assets in lending protocols. For example, the Cosmos Hub could decide to buy Osmosis OSMO/ATOM GAMM shares at a price of 1.25 atom per share. As users fill this order, the module would use Interchain Accounts to stake these funds and collect rewards back to staking ATOM holders via distribution.
There are two important implications which could result from this model of protocol controlled value. The first is to couple more explicitly the value of ATOM with the value of the IBC network which has been built with the technology it has funded. As the most liquid trading pair, ATOM value would grow along with the Interchain — this has been until now a benevolent side effect of Interchain airdrops and the strong liquidity of the ATOM, but an explicit encoding of Interchain utility into the ATOM would be an exciting new evolution in models of ATOM valuation. To complement this growth in value, the protocol controlled liquidity would provide a kind of price floor for ATOM, further increasing the viability of ATOM as an asset class.
Furthermore, using the Cosmos Hub for protocol controlled value is just one way that the Hub can utilize Interchain Accounts for an entire class of “Hub-as-Fund” activities — an important evolution in the role of ATOM in the IBC ecosystem. A more immediate way for the Hub to leverage its position as a large ATOM holder in the middle of the Interchain would be to utilize the Community Pool treasury in various governance controlled activities. As the owner of an Interchain Account on various other chains, the Cosmos Hub Community Pool would be able to participate in more complex actions from staking to creating leveraged positions for ATOM as a powerful and native player in the Interchain.
Sommelier Protocol and Osmosis
Sommelier Protocol services liquidity providers on Ethereum and Cosmos, who use Sommelier to create and execute complicated transactions to rebalance and manage portfolios without needing a trusted intermediary. These automated transactions ultimately give liquidity providers a powerful tool to manage liquidity in the most efficient way. Currently, Sommelier sends liquidity to and from Ethereum using a non-custodial bi-directional bridge, and uses smart contracts deployed on Ethereum to execute these transactions. A similar setup between Sommelier Protocol and Osmosis, a leading decentralized exchange in the IBC ecosystem, would necessitate the deployment of a Sommelier Cellars module on Osmosis (and on every counterparty chain), which would require a full chain upgrade for each participating chain and upgrades thereafter for any module developments. With the integration of Interchain Accounts, Cellars messages can simply be sent to and from Interchain Accounts on either side, which will then be executed to rebalance or reinvest liquidity in Osmosis pools. The deployment and scaling of Cellars functionality will become permissionless, as well as gaining a huge order of efficiency.
What’s next?
Interchain Accounts is now fully audited, and you can now find the official release candidate as well on the repo! The culmination of this release would not have been possible without input and support from Chainapsis (especially Tony Yun and Josh Lee for the initial implementation and contributions to the spec), Informal Systems, and Ethan Frey and we extend our fullest thanks and appreciation to you.
In addition to wrapping up our ongoing work on a middleware module which can add fees to any IBC transaction module, we have now begun work on a new Interchain Standard, which is now in Working Group format and which will lay the technical groundwork for cross-chain querying across the IBC ecosystem, which will present a way for the end user to verify the result of a state changing action from another chain, without having to query an exposed RPC endpoint or run a node of the chain themselves. We welcome you to participate in the discussion on this and other upcoming IBC standards, as well as contribute to the growing body of IBC application level modules.
This blogpost is just a fraction of the ongoing work in the IBC ecosystem, but we hope that it will give you at least a small glimpse of what this Interchain future will look like. We hope it will inspire what is next — a rich and diverse landscape of yet-to-be mapped out products which will comprise the Interchain.
Many thanks to reviewers: Kevin Denham,
Josh Lee, Zaki Manian, Catdotfish, Billy Rennekamp, Alan Traegar, Jack Zampolin
— — —
About the Author: Charlie Fei is the product owner for IBC at Interchain GmbH she tweets from: Charly Fei
If you’re a chain developer looking to build your custom IBC light client, and have any questions, comments or feedback on the above, feel free to reach out to us here.
