Abstract v0.22: Simplifying The IBC Experience

IBC is extremely powerful, though this power remains largely unharnessed due to its complexity, asynchronicity, and lack of debugability. Abstract makes IBC (in CosmWasm) easy. How?

Introduction: The Pain of IBC Development
1. Abstract v0.22: Your IBC Hero
2. CosmWasm IBC vs. Abstract
3. Streamlined Experience for IBC Pros
4. Enhancing The Abstract Experience
Conclusion: Abstract — Making IBC a Breeze!

Introduction: The Pain of IBC Development

Back at Cosmoverse Istanbul 2023, I wore a T-shirt proclaiming Debugging IBC is such a PAIN!

This is me

And you can’t disagree with that. The lack of tooling, the various complicated handshakes and endpoints (Channel , Packet , Client , packet_receive…) are indeed challenging when developing simple IBC applications. Despite its strengths in security and decentralization, IBC presents significant difficulties due to insufficient tooling and abstraction, similar to forcing an app developer to manage TCP and HTTP protocols for every StackOverflow query they have.

Abstract v0.22: Your IBC Hero

As underlined in every written piece about Abstract:

Abstract builds tooling to streamline the on and off-chain CosmWasm developer experience in building Interchain applications

For over a year, the Interchain Abstract Accounts have provided users with a single account across the entire IBC ecosystem, enabling transactions across multiple blockchains without leaving their home-chain. This eliminates the need for bridging, managing gas tokens, and switching wallets, offering a seamless IBC experience within users’ comfort zones. The Abstract 0.22 release further simplifies sending and composing IBC messages without multiple transaction signatures.

Now, we also aim to simplify IBC for developers. This update introduces essential features and simplifications to facilitate creating IBC applications without delving into protocol specifics.

CosmWasm IBC vs. Abstract

CosmWasm smart contract all have the capability to send IBC messages. However, as a developer, regular IBC inside smart-contracts requires :

• Implementing 6 additional entry-points, 2 of which should never fail
• Creating and maintaining IBC channels, which is a huge Dev-Ops challenge on its own (and what smart-contract developer really likes Dev-Ops anyway ?)
• An extra mind-juggling effort to understand and remember all the IBC lingo.
• Learn more about all the necessary steps here

With Abstract and for simple IBC applications, you simply need to add 1 endpoint to receive packets. This allows for simpler and more composable applications thanks to simple implementation patterns and the diminished overhead.

Streamlined Experience to make you an IBC Pro

More advanced IBC applications will obviously need more tooling than a single IBC endpoints. Abstract also provides a simplified interface for experienced IBC developers to allow for a modular and inter-operable experience. Let’s dive in some code to illustrate the Abstract Interchain developer experience. If some of the single-chain endpoints are not familiar to you, check out the official documentation to learn more. The following sections present the difference between the single-chain and multi-chain experience inside Abstract smart-contracts.

Module to Module IBC

Abstract 0.22 introduces a feature to allow modules to communicate with one another seamlessly over IBC, without you as a dev having to worry about authentication, callback logic, channels, packets, clients, or anything related to IBC. It just works. How?

Diagram demonstrating Module to Module IBC

Sending Messages

Sending IBC messages is easy. You need to specify, the chain you want to communicate with, a receiver, the message and an eventual callback parameter. The structure looks like this :

// Single-chain experience
let msg = wasm_execute(contract_addr, msg, funds)?;
// IBC experience
let msg = app
      .ibc_client(deps.as_ref()) 
      .module_ibc_action(host_chain, target_module, exec_msg)?;

With this syntax, you see that it’s as easy to send a message as you would any CosmosMsg.

Receiving Messages

Abstract introduces an additional endpoint in its framework that can only be called by Abstract core contracts when another modules sends an IBC message. This endpoint looks like this:

// Single-chain experience
fn execute(deps: DepsMut, env: Env, info: MessageInfo, msg: ExecuteMsg)
// IBC experience
fn module_ibc(deps: DepsMut, env: Env, info: ModuleIbcInfo, msg: Binary) 

pub struct ModuleIbcInfo {
  pub source_chain: ChainName,
  pub source_module: ModuleInfo,
}

Similarly to receiving a message through the execute endpoint, you get the deps , env variables. The info variable in the IBC case contains information allowing to identify the original caller of the messages, just like the usual MessageInfo variable. It allows simplifying access-control for developers.

Action callbacks

In some cases, you want to be able to execute code depending on the execution result of an IBC message. You can specify the need for a callback in the original message using the callback_info field. Here is its structure:

pub struct CallbackInfo {
    /// Used to identify the callback that is sent (acts like the reply ID)
    pub id: String,
    /// Used to add information to the callback.
    /// This is usually used to provide information to the ibc callback function for context
    pub msg: Option<Binary>,
}

Similar to reply , you have an id which will be propagated back to the Abstract callback endpoint to identify which callback handler should be used. The additional msg field allows you to pass additional information to the callback (for example some context, the original message you sent…).

To receive the callback, you implement an additional endpoint :

// Single-chain experience
fn reply(deps: DepsMut, env: Env, reply: Reply);
// IBC experience
fn ibc_callback(deps: DepsMut, env: Env, msg: IbcResponseMsg);

pub struct IbcResponseMsg {
    /// The ID chosen by the caller in the `callback_info.id`
    pub id: String,
    /// The msg sent with the callback request.
    /// This is usually used to provide information to the ibc callback function for context
    pub msg: Option<Binary>,
    /// The execution or query result (because YES you can also query remote chains !)
    pub result: CallbackResult,
}

Callbacks are secure because they can only be received on the module that dispatched them. This ensures security of execution and makes sure that all the IBC interactions are secure !

Enhancing The Abstract Experience

In addition to onboarding every dev to the Interchain, Abstract has simplified the developer experience throughout its framework. Here is a non-exhaustive list of the additional changes that were brought to the framework in the last month:

- Multiple API changes were made (interface macro, re-exports…) in order to making the library more accessible to all developers, new or experienced.
- We made the namespace claiming process permissioned on Mainnet to avoid namespace pollution, squatting and impersonation.
- We tested and iterated on the Abstract client library to smooth the on-boarding of all kinds of developers. We added numerous features and simplified the API (Name Service builder, IBC helpers, apps, accounts retrievers…)
- We added an Authz API to facilitate the use of this complicated module inside Abstract Apps

Conclusion: Abstract — Making IBC a Breeze!

Abstract v0.22 comes with wonderful new IBC features that Abstract everything complicated about cross-chain communication :

• No more Dev-Ops for IBC interactions (say bye to channels, relayers,…)
• The execution flow is exactly the same as the CosmWasmsubmessage-reply flow, developers don’t need to learn more things to use IBC !

To learn more about it, check out:

• The v0.22 Changelog
• Our official documentation
• The Abstract IBC documentation
• Our Discord channel for support, we want to help you !
• Our Twitter for more announcements
• Our YouTube channel for workshops and tutorials!

Be Abstract. Think Interchain.