Interchain Abstract Accounts

The cosmos is going interchain. The arrival of Inter-Blockchain Communication (IBC) launched us into a new paradigm in application development. New use-cases and solutions to existing UX problems are now possible. As the interchain application platform, Abstract attempts to make IBC accessible to developers and users alike. In this section we’ll delve into interchain application development, what makes it so hard and how Abstract can help you create your first #Interchain application.

What is The Interchain?

The interchain, sometimes called the internet of blockchains, is the concept of a network of blockchains that can communicate with each other. This is made possible by the Inter-Blockchain Communication (IBC) protocol, which is a standard for communication between blockchains. IBC is a protocol that allows for the transfer of arbitrary data between blockchains. This means that users can send data (like tokens) from one blockchain to another without third-party trust assumptions. This is a huge step forward for the blockchain industry, as it allows for the creation of a network of blockchains that can independently communicate with each other.

Building on The Interchain

Developers quickly started developing applications with IBC after its release. But they quickly ran into a major problem. IBC is not developer friendly. It’s a low-level protocol that requires extensive knowledge about its inner workings. These problems were quickly recognized by the CosmWasm community. In response DAO-DAO built Polytone, an Interchain Account (ICA) solution for CosmWasm smart-contracts. This was a great step forward for interchain CosmWasm development, but it introduced its own complexities and knowledge requirements.

As a response, Abstract has created its own ICA solution called Interchain Abstract Account (ICAA). The goal of ICAA is multifold. First, it aims to make IBC accessible to developers by removing any knowledge requirements about the underlying technology. Using IBC is as simple as enabling it on an Abstract Account and interacting with it through our SDK. Second, it aims to make IBC a backend technology, unbeknown to users. Users should not have to know about IBC. They should only have to know about the application they are using.

Interchain Abstract Accounts (ICAA)

An Interchain Abstract Account is an Abstract Account that is owned by another Abstract Account which is located on a different chain. This relationship is showcased in the diagram below.

flowchart LR
    subgraph Juno
        direction BT
        Account
    end

    subgraph Osmosis
        direction BT
        Account -- Polytone --> ICAAOsmo[ICAA]
    end
direction TB
Owner[fa:fa-user Owner] ==> Account

When a user creates an Abstract Account they do so locally on whichever chain they prefer. In this scenario the user opted to create his account on the Juno network.

After account creation the user (or his application) opted to create an ICAA on Osmosis. The ICAA creation is handled by the Account Factory in a similar way to regular account creation. After successfully creating the ICAA, the user (and his/her applications) can interact with the ICAA as if it were a regular account. Applications can send tokens to the ICAA, execute smart-contract calls, request queries and more. With the help of Polytone, the ICAA returns the result of these actions to the application.

ICAAs can be chained together, creating a network of accounts that can interact with each other. This allows for the creation of complex applications that span multiple chains. The diagram below showcases this relationship.

flowchart LR
    subgraph Juno
        direction BT
        Account([Account])
    end

    subgraph Osmosis
        direction LR
        Account --> ICAAOsmo([ICAA])
        ICAAOsmo2([ICAA 2])
    end

    subgraph Terra
        direction RL
        Account --> ICAATerra([ICAA])
    end

    subgraph Archway
        direction RL
        ICAATerra --> ICAAArch([ICAA])
        ICAAArch --> ICAAOsmo2
    end
    Owner[fa:fa-user Owner] ==> Account

Each of these accounts has a unique AccountId defined by the account’s origin chain and the path over which it was created. This allows the account’s owner to decide how messages should be routed.

flowchart LR
    subgraph Juno
        direction BT
        Account([local:1])
    end

    subgraph Osmosis
        direction LR
        Account --> ICAAOsmo([juno:1])
        ICAAOsmo2([juno>terra>archway:1])
    end

    subgraph Terra
        direction RL
        Account --> ICAATerra([juno:1])
    end

    subgraph Archway
        direction RL
        ICAATerra --> ICAAArch([juno>terra:1])
        ICAAArch --> ICAAOsmo2
    end
direction TB
Owner[fa:fa-user Owner] ==> Account

Interchain Applications

We’re now able to easily create interchain applications. I.e. a single smart-contract that we can deploy to multiple blockchains that uses IBC to communicate about its state. Any chain-specific logic can be handled by the application’s dependencies, like the dex or staking adapter.