Interoperability on Anoma

Anoma implements the inter-blockchain communication protocol (IBC) to communicate with other blockchains. By implementing IBC, Anoma gets closer to its goal of facilitating private payments using arbitrary assets regardless of how or by whom those assets were created.

  • Photo of Alex Flory Samartino
    Alex Flory Samartino
    · 9 min read

Abstract

Even though blockchains are decentralized and permissionless, most of them are siloed and cannot communicate with each other. Fortunately, various solutions have been proposed to solve this issue. Anoma chooses to implement the inter-blockchain communication protocol (IBC) due to its high flexibility. Via IBC, Anoma can communicate with other blockchains, enabling assets to be transferred from other blockchains to Anoma and vice versa.

Most decentralized and permissionless blockchains are siloed and cannot communicate with each other in a trustless and secure manner. This lack of interoperability between them confines the tokens and assets to a particular chain, thereby making them unable to move and be used elsewhere. Anoma aims to allow users to barter with arbitrary assets and to be as interoperable with as many chains as possible.

This article is an introduction to the inter-blockchain communication protocol (IBC), which is one of the components in Anoma’s architecture that enables Anoma to interoperate with any other blockchain that implements IBC, as well as future instances (e.g. geographically localized) between Anoma.

What is the inter-blockchain communication protocol (IBC)?

IBC is a general protocol for establishing and operating connections between heterogeneous ledgers, allowing them to communicate with each other. More precisely, IBC handles the authentication, transport, and ordering of opaque data packets relayed between modules on separate ledgers [1]. It is conceptually similar to the TCP/IP for the internet, and the IBC protocol resembles the TCP/IP model. For instance, it can also be divided into two layers: one layer defines how to authenticate, transport, and order packets of data and the other one is concerned with the application layer [2].

IBC is composed of multiple standards known as the inter-chain standard (ICS, for more details, please visit this repo). At the time of writing, there are 16 different ICSs distributed into various categories (namely Meta, Core, Client, Relayer, and App).

IBC specifies how packets of data are sent and accepted but presumes nothing about “what the data is” or “how it should be structured” [3]. For IBC, the payload data is opaque1. Note that even though IBC is agnostic to the payload data, it can still ensure the order of the committed data (i.e. packets are delivered in the order in which they were sent). By only standardizing the necessary elements needed for inter-blockchain communication, IBC can accommodate many heterogeneous blockchains (i.e. different architectures, consensus algorithms, programming languages, etc.) [3], [4]. IBC as a protocol is ecosystem and blockchain agnostic, and as such, the protocol has been implemented in many languages and ecosystems: for instance, in Golang in the Cosmos ecosystem, the implementation of IBC in Substrate on the Polkadot ecosystem, and the Anoma ecosystem, which also has an implementation of IBC in Rust.

1 portion of the transmitted data that actually holds the intended message [5].

How does IBC work?

Any blockchain can implement IBC as long as it meets certain specifications (fast finality, constant size state commitments, and succinct commitment proofs, see here for more details) [2]. IBC also assumes the existence of relayers to facilitate physical data transport between each pair of ledgers. A relayer is an off-ledger process that uses a network (e.g.like the internet) to physically connect two ledgers. The relayer will monitor each ledger and relay information between them by implementing a specific relayer algorithm. Anyone can run a relayer, with a chance of profiting from fees, depending on how each ledger is implemented [4]. As a relayer could try to modify IBC packets, each IBC packet is verified using a light client proof before reaching the module [4]. The module will then interpret the packet’s specific content and commit the data to the blockchain (e.g. token transfer). Assuming two ledgers fulfill these requirements, they can start communicating with each other using IBC.

Let us have a look at two different blockchains (i.e. blockchain A and blockchain B) that wish to communicate with each other. Assuming that both implement the IBC standard, the blockchains may communicate using IBC. Now that information can be exchanged, it needs to be processed (note that the data payload is opaque for IBC). The semantics of the data exchange will be dictated by the module on each ledger. The implementation of IBC means that the two chains will create a connection between them, allowing token transfers from one chain to the other.

Suppose that User A would like to send data (e.g. token transfer) to blockchain B (as illustrated in figure 1 below). In order to achieve that, User A submits a transaction to blockchain A. As soon as this data is committed, it triggers Module A. This committed data is then sent to blockchain B by a relayer. Before reaching Module B, a light client is used to verify the authenticity of this data. If valid, it reaches Module B, and is automatically committed to blockchain B. If deemed invalid, this data will be rejected. Notice that both modules can do state changes.

Figure 1
Fig. 1. Illustration of two blockchains communicating using IBC.

Multiple modules can exist on each chain independently. Each of these modules can use IBC to communicate with a module on another chain. Moreover, an IBC connection can allow different types of IBC packets to be sent, and all IBC packets are asynchronous (i.e. packets can be sent but committed to the other chain at a later time).

How does interoperability work on Anoma?

By implementing IBC, Anoma’s users will be able to transfer assets from other sovereign blockchains to Anoma and vice versa. This will allow other blockchain users to transfer their assets to Anoma, and benefit from Anoma’s different features (such as the multi-asset shielded pool).

A simple fungible token transfer

Users could transfer tokens from a sovereign blockchain to Anoma to benefit from Anoma’s features (see the multi-asset shielded pool). For instance, one user could transfer Ether to Anoma by using an Anoma-Ethereum bridge. This user will obtain a wrapped Ether on Anoma denoted aETH that can be used on Anoma. Once the user wants to convert it back, they can simply use the Anoma-Ethereum bridge to get back their Ether. This user could also transfer it to another blockchain (provided that this other blockchain can communicate with Anoma). Many bridges will exist, enabling numerous possible assets to be sent to and from Anoma. Note that bridges are permissionless and trustless (i.e. can be used by anyone).

Connecting to Legacy Chains

Note that IBC would not work with chains that cannot adopt deterministic finality. In these cases, specific bridges should be built, for example between Ethereum and Anoma, or with one chain that has the purpose to bridge to all legacy chains.

A non-fungible token transfer

Note that IBC also enables the transfer of non-fungible tokens (NFTs). For instance, a user could transfer a CryptoKitty or a CryptoPunk from Ethereum to Anoma. It will work similarly to the example above. The difference is that Anoma mints a new NFT voucher to represent the original NFT on Anoma and only this token can then be exchanged back for the original NFT. For instance, let us assume that User A moves his CryptoKitty from Ethereum to Anoma in order to exchange it. User B buys this CryptoKitty from User A. As User B wants to breed this new CryptoKitty with another one of his CryptoKitty on Ethereum, they can move this CryptoKitty back to Ethereum.

Routing of assets

Let us assume that you move one part of your XAN (Anoma’s native token) to blockchain B and another part to blockchain C. A few days later, you want to move your XAN tokens from blockchain B and C to blockchain D. The issue is that your XAN tokens can not be treated equally on blockchain D, as their security will depend on the route taken. For instance, the security of the tokens coming from blockchain B (in figure 2 below, bXAN) will rely on the security of blockchain B, while the ones coming from blockchain C will depend on the security of blockchain C (see figure 2 below).

Figure 2
Fig. 2 Illustration of a transfer of XAN (Anoma’s native token) from the Anoma blockchain to blockchain B and C. If those tokens are then transferred to blockchain D, they should not be treated equally by blockchain D as their security model depends on the route taken.

Thus, in order for the tokens to be treated equally and to not have to rely on the security of another chain, you should move them back to Anoma and then to blockchain D.

If tokens are sent to Anoma from a different route, they will be treated differently by Anoma. For instance, if you send some blockchain D native tokens to Anoma from blockchain B and some from blockchain C, they will be considered distinct by Anoma, as their security model is different.

Fractal upgrades and fractal instances

The Anoma protocol enables any user to create a new version of Anoma (learn more about fractal upgrades and fractal instances in this post). Those different instances of the Anoma protocol will all run in parallel and communicate with each other using IBC. This is also how upgrades happen on Anoma. A new version of the Anoma protocol will run in parallel to all the other versions. Users will select the canonical version by voting and reaching a threshold of two thirds of the votes.

Research on future versions of IBC: Heterogeneous Paxos

The simple token transfer example mentioned above could be improved using heterogeneous Paxos (i.e. an extension of Byzantine Paxos used to achieve consensus, learn more by reading this article). By implementing heterogeneous Paxos, multiple blockchains can coordinate their processes to have a joint consensus round between them. This will result in specific cross-chain transactions becoming atomic. In other words, the state transitions on different blockchains are atomic with each other whenever a cross-chain transaction takes place. Note that regular transactions still happen on individual chains. Heterogeneous Paxos is an improved version of a multiphase commit.

Conclusion

Anoma implements IBC to communicate with other blockchains. By enabling this interoperability, other sovereign blockchains users can transfer tokens (fungible and non-fungible) to and from Anoma and benefit from Anoma’s features (such as the multi-asset shielded pool). Thanks to IBC, Anoma gets closer to its goal of facilitating private payments and bartering using arbitrary assets, regardless of how or by whom those assets were created.

Bibliography

[1] The Interblockchain Communication Protocol: An Overview

[2] The Interblockchain Communication Protocol, IBC Specification Team, 22nd October 2020, 1.0.0-rc5

[3] Why Interchain Accounts Change Everything for Cosmos Interoperability

[4] IBC protocol FAQ

[5] Wikipedia, payload (computing)