Inter-Blockchain Communication (IBC) protocol is being developed to standardize data transfer between blockchains. If an individual blockchain is a planet, IBC is the space shuttle that takes information packets through a path that is designed to minimize the efforts of all stakeholders (network managers, block producers, blockchain developers, and end users) concerned. As the internet connects different categories of computers located in other parts of the World, IBC wishes to create a super highway through which reliable, ordered, and authenticated information can be safely carried from one blockchain to another without eavesdropping.

The Antelope IBC is built using smart contracts. dApp running on top of one Antelope IBC enabled blockchain (for example EOS blockchain) calls specific actions of IBC contract to communicate with other dApps running on completely different Antelope IBC enabled blockchain (for example UX Network). Being smart contracts, Antelope IBC is not only smooth to upgrade but also easy to audit. The Antelope IBC is trustless and has adopted a feature called instant finality.

The Block production in the Antelope blockchain follows quite a few well defined steps. Initially the block is just a proposal, not yet final, it can be replaced by another block if it fails to satisfy Byzantine Fault Tolerance. It becomes final and irreversible once it is approved by (⅔ + 1) active block producers. In the current scenario, the Antelope blockchain takes 180 seconds to declare a proposed block as final. This high block finality time is an impediment to dApp development on the Antelope IBC network. To overcome this bottleneck, the Antelope IBC has developed a new technology called Instant Finality. Once implemented, the proposed block will be declared final within a few seconds or even less, which will pave the way for development of simple to complex dApps on top of the Antelope IBC.

The Antelope IBC protocol promises to prove instantaneously that an event occurred in another Antelope IBC-enabled network. As figure 1 exhibits, the AntelopeIO IBC comprises two types of proofs viz. block proof and action proof. Block proof again can be divided into two parts viz. heavy proof and light proof.

A smart contract is instantiated when a blockchain implements AntelopeIO IBC protocol. Any kind of application (transfer of fungible token, transfer of non-fungible token, cross-chain account creation and maintenance, cross-chain query etc.) can be built on top of Antelope IBC. Once the smart contract is set, users use a single proof scheme or combination of multiple schemes to communicate over IBC.

Cosmos IBC is primarily divided into two layers viz. transport layer and application layer, as exhibited in figure 2.

Messages communicated over Cosmos IBC are encrypted within data packets which are ordered, authenticated and transported using a transport layer. The key components of the transport layer are exhibited in figure 3.
​

Light clients of Cosmos IBC do not store the entire history of all the messages present in a blockchain. Rather, they connect to a node and verify block headers. Different types of clients available are shown in figure 4.

Solo machines (phones, laptops, browsers etc.) can connect to IBC-enabled machines using Solo Machine Client.

State machines which are replicated using Tendermint consensus algorithm can interface with other replicated state machines or solo machines using Tendermint Client.

Wasm clients are dynamically upgradable clients.

GHOST-based Recursive Ancestor Deriving Prefix Agreement (GRANDPA) clients can be implemented by blockchains using GRANDPA finality gadget to communicate with other state machines or solo machines.

A relayer is an off-chain process which can retrieve the state of and post transactions to other ledgers communicating on IBC protocol. Relayer must be connected with a funded account on each chain. If you want to connect multiple chains, you have to use one relayer for each pair of chains.

Connection semantics is a protocol to establish safe connection between two chains having a light client of another chain.

Channel and Packet semantics provide a message delivery mechanism to the IBC protocol. Each channel is associated with a particular connection, and a connection may have any number of channels attached to it.

Allocation of ports between different types of modules is decided by the Port allocation algorithm. An IBC module can be allocated any number of ports.

State machine of a blockchain works as the manager of vector commitment. It has the ability and responsibility to add or remove items from the commitment.

Host State Machine Requirements define the minimal set of interfaces which must be implemented and properties which must be fulfilled by a state machine.

The IBC handler interface comprises methods to handle IBC clients, connections, channels and packet relay.

The routing module accepts external datagrams and calls into the IBC handler to deal with handshakes and packet relay.

Application layer describes packet encoding & processing semantics. Figure 5 exhibits different applications of IBC.

First and foremost application of IBC is fungible token transfer across chains. With this standard, users can transfer assets from one IBC enabled chain to another IBC enabled chain with no additional permissioning.

Interchain account is a cross-chain account management protocol, using which users of one IBC enabled chain can create and control accounts of other IBC enabled chains the same way as native systems do.

Interchain security is maintained using cross-chain validation. It enables a provider chain to offer security to multiple consumer chains.

General Relayer Incentivisation Mechanism is for handling fee payments on top of IBC.

IBC Middleware encompasses the interfaces and the state machine logic that a module must implement in order to function properly as middleware between core IBC and an underline application.

Cross chain query module encompasses the data structures and state machine logic that allows to perform cross chain query between IBC enabled chains.

Non-fungible Token transfer module comprises data structures, state machine handling logic and encoding processes for the transfer of non-fungible tokens from one IBC enabled chain to another IBC enabled chain.

Inter-Blockchain Communication which creates super highways between island blockchains is the next wave of blockchain development. There are many other cross-chain communication protocols (MAP, Layerzero, celer etc) beside the Antelope IBC and Cosmos IBC. In the future, the Antelope coalition will accept only those blockchains who have infrastructure to set up IBC.