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.
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.
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).
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
Share this article
PreviousExplore Further:
(and Perfectly Boiled Eggs)
20 September 2022
This blog post is intended to give a primer on the concept of arithmetic circuits that is gaining a lot of attention lately with the rise in the popularity of zero-knowledge proofs. We will take a look at what arithmetic circuits are, what they are used for, what tools are there for working with them, including the tools we develop here at Anoma, and what we can do with the circuits using these tools.
31 May 2022
The future of coordination relies heavily on the successful verification of information — and zero-knowledge proofs have a significant role to play here. This article explores what zero-knowledge proofs are, how they work, and why they are so important to privacy-preserving technology.
18 March 2022
Anoma incorporates many different concepts, components, and mechanisms in its protocol. Learn about Anoma’s architecture on a high level and understand how it all works together to deliver an innovative universal coordination mechanism.