In 2021, 0rigin, the team behind UX network, announced an industry-leading IBC (inter-blockchain communication) protocol built on top of the Antelope-based UX Network blockchain. After joining the Antelope coalition in 2021 and winning an RFP (request for proposal) for implementing Instant Finality for Antelope blockchains, the 0rigin team offered to open-source their IBC solution so that all Antelope chains could leverage the technology.
What is IBC?
IBC protocols can be described as a mechanism that is used to link one blockchain to another and handle authentication and data transfer processes across different chains. Using a real-world example, IBC can be compared with the global economic system, where its interconnected blockchains act as countries, and its cross-chain authentication acts as global trading policies and cargo ships between countries. This allows blockchain networks to trade with each other based on their resources and area of expertise in the same fashion that countries trade with each other across the globe to compound their GDP growth. This amplifies network effects accelerating adoption exponentially.
Several noteworthy IBC solutions have been developed in the past to allow inter-blockchain communication. These consist of oracle based bridges, Cosmos Network, and Polkadot Parachains. It should be mentioned that the list of noteworthy IBC solutions mentioned is not exhaustive and there are other solutions that have been developed as well.
A blockchain bridge joins two different blockchain networks or applications, just like physical bridges do. A blockchain bridge, often known as a “cross-chain bridge,” can operate in a variety of ways. Bridges are commonly a network of nodes that listen for messages to be relayed between chains. These relay networks require their own consensus mechanisms and are essentially oracle networks. The introduction of an intermediate network introduces additional latency and overall complexity and also increases the attack surface available to bad actors.
The Cosmos network (also known as the internet of blockchains), stands as a popular solution for interconnected apps and solutions. Through their native IBC and Peg-Zones which bridge from Cosmos to probabilistic finality chains (note that all “proof of work” chains only have probabilistic finality), Cosmos enables blockchains to exchange assets while allowing each blockchain to choose their own consensus algorithm, virtual machine implementation or programming language. In Cosmos both sides use a known state to ensure the integrity of the IBC transfers, avoiding the need for trusted relayers. As explored further in this article, both Antelope and Cosmos IBC solutions use similar concepts to achieve trustless IBC.
Polkadot is an interoperable blockchain that can connect multiple blockchains, enabling them to communicate with each other. Parachains are heterogeneous blockchains that are connected to Polkadot. They are interoperable with the Polkadot Network and other Parachains. An individual layer-one blockchain called a parachain, also known as a parallelizable chain operates in the Polkadot and Kusama multichain networks, among others. A Relay Chain, Polkadot’s primary chain that controls the entire system, provides security that Parachains attach to.
Antelope’s IBC Protocol
The Antelope IBC protocol is a trustless and permissionless inter-blockchain communication protocol, where there is no need for an extra security layer, additional confirmation from third parties, or dependence on oracles, state channels, and off-chain computations.
Antelope’s IBC implementation allows for faster and more secure inter-chain communication due to its innovative smart contract-based on-chain implementation with minimal-friction bidirectional interchain action proof generation and validation, which we will explain in the following sections. More detailed and specific information related to the technical details, solution architecture, and smart contract technical documentation(bridge contract and wraplock/wraptocken contract) will be available through Antelope’s IBC dedicated webpage, which will be deployed in the near future.
The IBC protocol’s architecture allows any client or server process the ability to collect and package the required data for a compact proof of an action executed on a blockchain, and submit it to a smart contract for verification and homologation to a target chain. This process leverages the bridge contracts and wraplock / wraptoken contracts to facilitate safe communication and asset storage/creation between chains.
The bridge contract allows a user to prove blocks and actions using either a heavy proof or a light proof scheme. At a high-level heavy proofs are used to maintain the state between the two sides of an IBC channel and light proofs are used by Dapps to transfer data between chains. After contract initialization and a valid heavy proof submission, the state of the source chain is now saved to the target chain, and it becomes possible to prove actions that occurred prior to the saved state with light proofs.
Wraplock / Wraptoken contracts
Wraplock and wraptoken contracts are responsible for facilitating interchain token transfers. Through the wraplock Contract, the user can lock native tokens on chain A, and the wraptoken contract provides the ability for the tokens to be issued as wrapped tokens on chain B. To facilitate transfers of both wrapped and native tokens in both directions, the wraplock and wraptoken contracts need to be deployed on both chains, and to facilitate transfers across multiple chains, the contracts need to be deployed to multiple accounts.
The obvious use case example for IBC is moving NFTs or tokens from chain A to chain B. For example, if you own an NFT on the WAX chain that you would like to sell on another chain, such as EOS, you have an opportunity to wrap your tokens on WAX, send them across to EOS, and trade. This opens up a variety of doors for Defi such as cross chain pools, lending and standardization of stablecoins. Additionally, token transfers can be utilized in games – for example, a game on WAX might incorporate mining rewards based on wrapped NFTs from another chain, allowing both ecosystems to take part in the game economics.
The concept of ‘’elastic sidechains’’ plays an important role in terms of amplifying IBC’s importance. All chains have resource limitations and at some point will reach capacity and have to either increase resources (i.e. scale vertically by upgrading hardware to faster CPU, more RAM, or higher network bandwidth) or change the resource model and make transactions more expensive for users and hope for developers and users to therefore utilize less resources. IBC gives application developers the option to leverage resources of a side chain and move certain actions to those chains, splitting resource load and allowing for horizontal scalability.
Using a real world example, imagine a fighting game that is resource intensive on the number of transactions needed to battle and save the game state. With IBC, developers can allocate low-importance level transactions to the side-chain(s) and report the final result of each round / battle / important event information to the main chain e.g. – transactions relating to different abilities, such as punches, kicks, and using spells could be processed on a side-chain, and as soon as the final game has resulted, the aggregation of those transactions (e.g. points and rewards) will be allocated to the main chain.
All blockchains have their focus areas, with different levels of liquidity considering their background and characteristics. IBC will facilitate the pooling of all connected chains’ liquidity and amplify the network effect which compounds growth and the types of applications that can be built. For example, EOS being a highly liquid chain can have wrapped tokens generated on UX Network, therefore bridging liquidity from EOS to UX allowing higher volume flow through DeFi and NFT marketplaces on UX. This now allows developers that like the UX stack to tap into these larger pools of liquidity and design products around that level of volume.
EOS has just executed an MSIG to create the necessary accounts for the EOS IBC and the first-ever IBC wrap token transfer between EOS and the UX Network has been successfully completed. Before the launch occurs across all chains, several contracts need to be deployed to the respective chains, such as the wrap token and wrap lock (where each chain has 3 such pairs -6 in total) and the main eosio.ibc contract that maps all respective chains wrap and lock token contracts. This rollout is expected to take place over the coming months until all chains have deployed the required contracts needed.