“Efficient inter blockchain communication is key to scalability and protocol evolution. One token can easily migrate from one generation chain to the next as we learn how to scale. Current and future generations can run side by side,” — Dan Larimer.

In the age of cutting-edge technologies, brand-new definitions, features of vague and confusing nature appear frequently. In this vein, speaking of the EOS community, there are too many ambiguous definitions and interpretations of inter blockchain communication (IBC). The vast confusion around IBC definition spanning throughout the entire EOS community inspired us to look deeply into the IBC phenomenon, and we hope that the result of our research will, at last, clear what IBC is… and what it isn’t.

Today’s agenda is live use cases of general IBC solution in the crypto community.

Existing IBC

In the nutshell, IBC refers to the ability to communicate between two or more independent blockchains. Disambiguating the word “communicate” in this context is not simple and this is exactly where the difficulties in interpreting the IBC nature lies. For instance, while transferring coins from one chain to the other might seem like the simplest and most obvious thing to do, yet for most protocols doing so (at least for now) is impossible. Hence, we need to go a level deeper and think about e.g. messages. Indeed, if one can send information about actions from one chain to another in a deterministic and irreversible manner, we can speak of smart contract structures that by combining, locking, issuing and burning coins allow for the creation of assets proxying coins from one chain to the other. In this context, IBC enables the cross-chain interoperability. Obvious use cases could be acceptance of payments in one coin for the, say, dApp services on another chain in a purely decentralized manner.

There are existing projects, plugins, and protocols pioneering the field of cross-chain communication. For example, BancorX and Waterloo are two decentralized bridges which swap your ETH tokens to EOS.

BancorX offers a token exchange via its native BNT token. At first, your Ethereum tokens will be swapped to BNT and then exchanged to EOS.

Kyber’s project, Waterloo, proposes a relay bridge where block headers of the first blockchain are constantly being submitted to a smart contract in the second blockchain by implementing a light client logic to verify the headers’ validity and vice-versa. This bridge allows tokens exchange between EOS and Ethereum by deploying, locking, minting and burning contracts on each blockchain.

Pursuing an IBC solution, EOS block producer, shEOS, proposed an EOS-21 protocol for Ethereum ERC-20 and EOS-21 tokens exchange as well. Sending tokens from one network to another is going to involve three dimensions. The first one is the source chain, Ethereum. Then goes an oracle which runs off-chain to validate ETH transactions and authorizes the EOS tokens distribution. Finally, there is the destination chain, EOS.

An EOS sister chain, BOS CORE, also offers an open-source IBC solution by swapping BOS CORE native tokens with the EOS mainnet coin and vice-versa.

There are also Komodo, Polkadot, Thorchain, atomic swaps, etc — all these projects represent cross-chain communication as it is.

In the EOS universe, however, IBC enables, among other things, horizontal scaling. How could this be? Let’s figure out.

Back to Side Chains

In the preceding article, we’ve figured out that IBC is the technology that, when implemented, will enable the so-called side chains that are in turn essential for horizontal scaling. To remind, side chain is a separate blockchain which is (i) run by the same block producers, and (ii) stakes the same base token for resource procurement as the mainnet. Side chain offers horizontal scaling thereby improving the life of every agent comprising the EOS ecosystem by offering low RAM, CPU and bandwidth price. In words of EOS mastermind, Dan Larimer, “scaling via IBC will give us an unlimited scaling potential”.

To get it straight: why do we need side chains? To get cheaper RAM for dApp implementation. How can we gain a lower price of RAM? By enabling horizontal scaling via IBC and side chains. We know, that side chains together with IBC solution will deliver higher transaction speed and a possibility to easily transfer tokens and data between the mainnet and side chains. The set of BPs on the mainnet will also serve side chains by verifying transactions, distributing the resources and maintaining the tokenomics of EOS. As a result, dApp developers will likely choose a side chain to deploy an application.

The EOS base token plays an important role in IBC formation, so next time we observe inter blockchain communication phenomenon from this point of view.

What do you think about an IBC in the EOS context? Let us know in the comment section below.