Inter Blockchain Communication (IBC) or cross-chain transactions is a technology that renders blockchains interoperable without any intermediaries by making it possible to move tokens and information between them. EOSIO has been designed as a software for multiple chains and in order to make them interoperable, Daniel Larimer designed an IBC standard. The IBC itself is a wide field that can see different implementations but all of them have a common goal which is of the main interest to the end user – the transfer of tokens. EOSIO, however, permits for arbitrary cross-chain communication and does not require tokens only be transferred but more the messaging and communication at the protocol level.

The use cases of Inter Blockchain Communication

From a level application standpoint the use cases of chain interoperability range from finance to identity verification to oracles or to anything that is deemed blockchain worthy.

An application will find a easier adoption of its token if it can be transferred at a protocol level rather than exchanged on a central exchange. Acceptance of payments in one token for some dApp services on another chain in a purely decentralized manner is one of best use cases.

Another practical example could be the transfer of one NFT asset like a virtual reality game object to a game on another game on a different chain without never losing the ownership over it.

IBC in EOSIO plays also an important role in horizontal scaling. Scaling via IBC and side chains gives EOSIO an unlimited scaling potential as well as solves the issue of expensive network resources by offering cheap RAM, CPU and bandwidth and permits for higher transactions speed.

Interchain operability is a feature that enhances the EOSIO ecosystem by giving an opportunity to communicate seamlessly between various blockchains using just a single account.

IBC improves also innovation by permitting for other chains to exists. The security of a chain is directly proportional to the number of users it has this is why it is important to connect it via IBC and give it the possibility to thrive even with a small userbase.

Different chains have many features that wouldn’t be possible to implement on a single chain this is where interoperability is essential.

The possibility to transfer arbitrary messages, any kind of data structure or data that can be transferred, opens the door for many use cases that were not possible before. For example, an IoT device can feed its data to an oracle chain which verifies its integrity and transfers that data to an insurance DApp to pay out and settle an insurance claim.

This will also allow applications which don’t make use of tokens to benefit from the advantages of blockchains.

The most known use case of IBC is a decentralized exchange (DEX). A DEX based on interchain communication is totally decentralised and is probably the most resistant to deliberate manipulation or censorship. For this to be true, there is a need for a security model in which block producers cannot censor transactions.

Asset encumbrance can benefit greatly from IBC. Liens, collateral in financial derivatives, bankruptcy clawbacks, court orders and various use cases involving security deposits are all dependent on interchain operability. It’s the ability to lock up an asset on one chain and unlock it if a certain condition on another chain is met and this is why communication between them is needed.

The payout of dividends on chain X to a holder of an asset whose ownership is registered on chain Y by checking if this user is registered as a stakeholder on that chain is also dependent on the IBC.

Other than the tranasfer of assets, IBC solves the problem of scalability of other blockchains. Bitcoin and ethereum must shorten their transaction times if they are to compete with traditional services like Visa or PayPal. With 1667 transactions operated by Visa, Ethereum and Bitcoin managing just less than 20 transactions per second is something that is an impediment to the mass adoption. Despite the efforts put into solving scalability issue like SegWit, Lightning Network, Raiden they don’t provide the final solution. Interchain communication on EOSIO will make it possible for Ethereum, Bitcoin and other blockchains to scale efficiently.

How IBC works

There are different implementations of IBC. Chain interoperability could be done via sidechains/relays, centralized or multisig notary schemes or via hash locking.

Although a sidechain is described as a blockchain that validates data from other blockchains, this nomenclature in IBC is quite confusing because it implies a subservience of one chain to the other. A pegged chain is also misleading because it describes a property of individual asset on top of blockchain rather than being it property of that blockchain itself. This is why chain X and chain Y or chain A and chain B seem like a better nomenclature.

IBC via notaries

The use of notary mechanisms, a trusted entity or set of entities that is trusted as a group, is the simplest way to facilitate cross chain operations but it relies on trusted intermediaries to provide information about one chain to another. A federated pegged sidechain like Liquid, a BTC backed sidechain created by Blockstream, relies on the honesty of the federation as part of the trust model. BFT algorithm, however, ensures that  there’s no trust in a single notary but only in two thirds of the group.

IBC via relays

Relays implementation in interchain operability is a more trustless system and it uses light client verification.

The protocol lock up state on one chain and spawns it on another. You can watch proofs of this lock up (the lock up is really just holding it in a “smart contract” designed to coordinate IBC) through light clients, so you could have the target chain act as a light client of the original chain (the one we lock up on).

A BTCRelay smart contract implemented on Ethereum stores Bitcoin block headers. BTCRelay uses these block headers to build a mini-version of the Bitcoin blockchain: a method used by Bitcoin SPV light wallets. A proof for the validity of each header amounts to checking it resides on the longest chain of submitted headers. It’s a one way communication but it shows the functionality.

To understand how this works we need to know that a blockchain is made of blocks and block headers where block header is a compact piece of information that “represents” the block (and possibly state data) in some cryptographically authenticated way, most likely using Merkle trees.

Light clients process account balances from Merkle Tree Proofs. In other words, chain A receives messages from chain B by following chain B’s block headers and processing action proofs. Each action proof has one or more sequence numbers which chain A uses to make sure there are no gaps in processing. The IBC in EOSIO has been designed in this way that a light client can derive the balance of a single account by processing all sequenced actions for that account without having to process the actions for other accounts. This is because a chain in EOSIO generates a Merkle tree over sequenced actions instead of generating a Merkle tree over state (account balances).

“Ibc is one chain talking to another. That is here today like dialup modems between two world computers. What people want is the elastic scaling of aws for blockchain. That will take 10 years which is 2x as fast as it took to go from p2p modems to aws”

Daniel Larimer

Relays implementations on EOSIO

The developers working on the EOSIO software created many different implementations of IBC working with relays:

Kyber’s project, Waterloo, created fully decentralized way to implement an EOS light client as an Ethereum smart contract, and an Ethereum light client as an EOS smart contract. This relay bridge allows tokens exchange between EOS and Ethereum by deploying, locking, minting and burning contracts in a deterministic way on each blockchain. Waterloo project is possible because of the unique EOS blockchain property like low computation costs on EOS network, a light client that needs to maintain a set of BPs as well as light SmartPool verification algorithm to verify Ethereum proof of work hash function.

EOS block producer, shEOS, proposed a teleportation protocol for Ethereum ERC-20 and EOS-21 tokens exchange although this method doesn’t follow the IBC design as described by Daniel Larimer. The EOS-21 Protocol involves three dimensions. The first one is the source chain, Ethereum that involves a Blackhole contract for ERC-20 tokens absorption and which receives account information for the destination chain (EOS). The second dimension is an oracle which runs off-chain to validate ETH transactions and authorizes the EOS tokens distribution. Finally, there is the destination chain, EOS. The ERC-20 tokens become non-fungible and the EOS tokens are teleported to their destination on the EOS chain.

Relays work well on chains that have rapid finality, but where chains are too slow like in Ethereum or Bitcoin example, the approach is problematic. One needs to incur to deposits on a third chain with very fast block times to overcome the issue. This could be exactly what Daniel Larimer thinks when he talks about his new algorithm to decentralize Bitcoin.

Recent work made by developers working on an EOSIO chain BOSCore lowers the finality to 0.3s which makes IBC much faster. BOS developers goal is to optimize EOSIO enabling BTC, ETH, EOS or other certificate assets to be traded and transferred on the BOS Network.

Hash locking

Cross chain hash locking leverages hash-time lock contracts (HTLC) to facilitate p2p atomic swaps without any intermediary. These cross chain atomic operations require the blockchains to know much less about each other. Hash-locking  triggers an action on two blockchains simultaneously in an atomic manner i.e., with both actions or none of them happening.

Hash locking, however, is not ideal for asset portability or cross chain oracle use case because it requires a passive (read) operation where hash-locking needs active participation from both sides. Asset portability is also not possible (without an exchange as intermediary) because hash-locking preserves the assets at both chains.

Wanchain uses “Locked Account” scheme instead of hashed time lock contracts.  This scheme creates an account which is being locked while the two transfers are happening. It manages that by splitting up the private key of the account and distributing it to multiple nodes in the Wanchain.  The nodes can only jointly make transfer from the locked accounts and make sure that the transactions are atomic.

IBC implementation on EOSIO

Earlier I spoke with information technologist and consultant, John Chamberlain about IBC. In 2017 John became a Digigenz founding partner, focusing on community and next generation blockchains, primarily EOSIO and most recently has partnered with BOSCore teams developing the BOSCore project. This is what he had to say about BOS IBC.

“BOS IBC is the first IBC implementation deployed on EOS, it conforms not only to the standard outlined by Dan Larimer last year but also to design standards outlined in papers by Satoshi and Vitalik.

One of the things about BOS IBC, that not many realize is that it’s both pegged assets and decentralised IBC based on a system of optimized merkle proofs and SPV technology.

The pegged assets part works with BTC and ETH based chains while the Merkle Proofs and SPV technology allows seamless transference between EOSIO based chains.

It’s also worth mentioning that EOS takes around 3 minute to reach consensus finality which can slow down certain dApp functions. For example IBC can take up-to 6 minutes due to 3 minute finality and BOSCore is working on improvements that could see finality reached in 0.5 – 3 Seconds”

BOSCore has been the first chain on EOSIO to develop IBC with SPV (Simple Payment Verification). SPV has been described first in the Bitcoin white paper and it serves to verify that a transaction exists in a blockchain. SPV client  called also lightweight client is nothing else than a lightweight chain composed of block headers.

BOSIBC is based on Dan Larimer’s white paper that outlines Inter-Blockchain Communication via Merkle Proofs with EOSIO.

BOSIBC utilises a type of light client on-chain smart contract dApp that can be utilised in a decentralized wallet, that calls the bosibc.io contract account which interacts with the ibc.chain contract. This means that it’s easier for it to gain public trust, because the contract data is globally consistent and can not be tampered with.

BOSCore developer Simon said about IBC on BOSCore:

“This IBC system contains two contracts, the ibc.chain contract is the SPV client, and this SPV client can be used as a service to verify peer chain transactions, and the ibc.token contract can be seen as a Dapp by the ibc.chain contract, so BOS IBC is not only a pegged token IBC, pegged token IBC is just a DApp based on ibc.chain contract, (in other words, we can say BOS IBC composed of decentralized IBC and a peg token application).”

Running lightweight client in contract in EOSIO with real time synchronization of all block headers with the blockchain would be too expensive in terms of CPU resources consumption.

While Bitcoin produces 4Mb of block headers per year and Ethereum much more, to achieve real-time full synchronisation of an EOSIO chain would require 0.35% of the whole chain. If EOSIO is to grow in multiple sidechains that need to communicate each with its own light client that means that the consumption of CPU to maintain all these light clients is not a viable solution. This is why the concept of “section” that records a batch of continuous block headers has been introduced in ibc.chain contract. Section records the first block number (first) and the last block number (last) of the block header, block headers are stored in chaindb. When the block is considered irreversible it can be used to verify cross-chain transactions.

Conclusions

Chain interoperability or IBC is needed to link blockchains with different features and functions by exchanging assets and messages. Connecting all blockchains together is an arduous task because many blockchain systems don’t speak the same language. Once we achieve fully functional IBC with multi-token transfers it will be possible to see multi-token wallet systems. This will allow users to rely on a single wallet to store and transfer all their tokens across various blockchains which will make blockchain adoption much faster and easier.

References:

EOS.IO Technical White Paper v2

https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md#inter-blockchain-communication

Inter-blockchain Communication via Merkle Proofs with EOS.IO

https://steemit.com/eos/@dan/inter-blockchain-communication-via-merkle-proofs-with-eos-io

Waterloo — a Decentralized Practical Bridge between EOS and Ethereum

https://blog.kyber.network/waterloo-a-decentralized-practical-bridge-between-eos-and-ethereum-1c230ac65524

Chain Interoperability – Squarespace

https://static1.squarespace.com/static/…/t/…/Chain+Interoperability.pdf

Design and Development of a Blockchain Interoperability API

http://www.merlin.uzh.ch/contributionDocument/download/11596

Blockchain Interoperability – The Importance of Cross Chain Technology

https://101blockchains.com/blockchain-interoperability/

Enabling Blockchain Innovations with Pegged Sidechains

https://blockstream.com/sidechains.pdf

Comparison of Inter-Blockchain Communication Technologies

http://troubles.md/posts/comparison-of-inter-blockchain-communication-technologies/

Dan Larimer chats about BOS IBC

https://medium.com/@blocksiam/dan-larimer-chats-about-bos-ibc-1b3fa4ecf584

View this content's WordProof Blockchain Certificate