Introduction to ibc-rs, the IBC Implementation in Rust

Ibc-rs is a Rust library that serves as a robust implementation of the Inter-Blockchain Communication Protocol (IBC). ibc-rs aims to extend the capabilities of IBC to a wider range of blockchains, regardless of their underlying consensus engine. Whether you're considering blockchains based on CometBFT, Near, or Solana, ibc-rs provides a versatile solution to integrate with IBC.

The key to this versatility lies in its design approach. It has taken great care to abstract away intricacies, ensuring that no details concerning transaction formats, the store, or other system-specific elements interfere with IBC's native functionality. As a result, ibc-rs provides interfaces, including the ValidationContext and ExecutionContext traits, empowering host chains to integrate based on their specific requirements.

This blog offers a brief overview of ibc-rs implementation and its latest status. If you'd like to refresh your general understanding of IBC, you can find more information on the official website or in the ibc-go documentation.

IBC Light Clients

The central concept in IBC is a light client. This is a fundamental building block that enables a chain to track the counterparty chain and verify proofs associated with that counterparty. Also called simply “IBC clients,” these are specified in standard ICS-02.

The IBC protocol permits various client types. Each light client corresponds to a type of a consensus algorithm. Notably, the Tendermint light client currently takes the spotlight, fully supported by ibc-rs. However, IBC's client abstraction extends far beyond Tendermint, and can accommodate light clients tailored for various consensus protocols. Additionally, it can support multisig protocols, where a consortium of trusted keys notifies IBC of updates to the counterparty chain. In fact, such a client already exists, referred to as the "solomachine" client in IBC terminology.

The ibc-rs library is designed to support a broad range of light clients by decoupling client implementations from the IBC core. This design approach allows individuals to develop new iterations of light clients as separate, self-contained crates. In practice, this flexibility has spurred the IBC developer community into action, leading to the creation of innovative solutions. For instance, Octopus Network has introduced a solomachine client, and Composable Finance has developed a Near light client, with ongoing efforts to align it with the latest ibc-rs iteration.

IBC Applications in ibc-rs

Applications are another cornerstone building block within IBC, serving as the designated realm for housing business logic. Among the array of applications available, the most prominent is the token transfer application, also known as ICS-20, which enables the movement of tokens across various chains. However, IBC's capabilities extend beyond token transfers, unlike conventional token bridging protocols. Applications provide considerable versatility, enabling the definition of diverse protocols, ranging from governing accounts on other chains (ICS-27) to executing atomic swaps (ICS-100).

Currently, ibc-rs provides out-of-the-box support exclusively for the token transfer application. However, similar to clients, ibc-rs is designed to allow users to build their own applications within separate crates that can be conveniently integrated into IBC core. The process is straightforward; developers must ensure that their application effectively implements the Module trait to initiate their journey.

Integrate IBC Core

For ibc-rs users, the first step toward integrating ibc-rs into their blockchain is to implement two essential traits called ValidationContext and ExecutionContext, which integrate the IBC core implementation primarily into their store.

The ValidationContext necessitates the implementation of methods crucial for performing various validations essential for core IBC operations. These validations are executed by invoking the validate() functions. For example, within this context, one method entails fetching a ClientState from the store, which is linked to a particular client identifier obtained from an incoming IBC message.

On the other hand, ExecutionContext offers a set of additional methods that ibc-rs relies upon to enact state alterations. These state transitions are applied by calling execute() functions.

Why separate validation from execution?

You may wonder why it is necessary to distinguish between the "validation" and "execution" of IBC datagrams. The purpose behind this separation is to facilitate a broader spectrum of potential chain architectures.

We can look at Namada as an example to understand the usefulness of this separation. In Namada, developers can define multiple validation steps for any given transaction, referred to as "validity predicates." If any of these validity predicates fail, the entire transaction is considered unsuccessful. Only when all validity predicates successfully pass is the transaction executed. In the context of IBC datagrams, IBC validation represents just one of the many validations developers might wish to consider. Since all validity predicates operate independently, they can be executed concurrently, resulting in a more efficient chain. Prior to separating validation from execution, ibc-rs could not support such an architecture.

Developers can also use ibc-rs without worrying about separation of validation from execution. To use ibc-rs in this way, all that's required is the implementation of ValidationContext and ExecutionContext, alongside the dispatch() function to handle IBC datagrams. This will perform validation, followed by execution.

Therefore, the division between validation and execution has expanded the realm of feasible architectures, all without imposing any drawbacks on those who don't necessitate such differentiation. Consequently, we believe it has led to the ibc-rs being a more robust and versatile library.

What Lies Ahead

Ibc-rs is built by the ibc-rs team at Informal Systems. We have ongoing enhancements in progress and a commitment to continuous improvement, especially as we are paving the way for the v1 release. We have a Road to V1 tracking issue with details about our current progress.

Also, about how the IBC core implementation interacts with various IBC applications, we are considering the incorporation of middleware. Like the middleware in ibc-go, this component would reside between the core IBC and applications, providing developers with the ability to fine-tune the functionality of a base application and particularly should facilitate the transmission of tokens to a destination chain via multiple intermediaries.

If your team believes that any additional features would be advantageous, please don't hesitate to get in touch with us and convey your interest! Most importantly, our development efforts are shaped by you. We are dedicated to tailoring ibc-rs to your specific needs. Should you find a missing feature or desire adjustments, please reach out to us. A convenient avenue for doing so is by opening an issue on Github. Additionally, the ibc-rs team is joining the regular IBC Core coordination calls, which all IBC users are also invited to. To do so, join the IBC Community group. We eagerly invite you to engage with us and share how we can be of assistance to you.