This article explores the main breakthrough innovation that the forthcoming Cosmos Network’s hub upgrade (Stargate) brings to the Cøsmos ecosystem and Distributed Ledger Technologies in general: The Inter-Blockchain Communication (IBC) protocol. The article also explains the function of bridges as they are going to be of paramount importance post-IBC on Cøsmos. Finally it points at suggestions and/or development of solutions that may add layers of value on top of IBC and that may lead to increased adoption, following the passing of the Stargate upgrade that will implement IBC.
The Stargate Upgrade
Note: Distributed Ledger, chain, and blockchain are used interchangeably throughout this document, in accordance with their colloquial usage.
Stargate is a set of upgrades that complete the original roadmap as envisioned and laid out in the Cøsmos Whitepaper. For the first time ever, Cøsmos blockchains will be able to connect with each other using the first standardised protocol for Inter-Blockchain Communication (IBC). In effect, the Stargate upgrade marks the implementation of IBC!!
Current Status of the upgrade: 97% complete
Primary Features of the Stargate Upgrade
Within a matter of weeks the Cosmos Hub’s governance mechanism will be invoked so that delegators and validators vote on the passing of the proposal of the largest Cosmos upgrade to this date. Here are the primary features of the forthcoming upgrade:
Inter-Blockchain Communication (IBC): The ability to exchange transactions of value and data across compatible chains;
Protobuf Migration: Accelerates front-end development and what is claimed to be a 10x to 100x better blockchain performance;
High Node Synchronisation Speeds: A new node can synchronise 200x faster, participating in consensus in a matter of minutes;
Chain Upgrade Module: Enables validators to upgrade the chain software asynchronously in a matter of minutes of the hour.
Tendermint’s light client security model allows full nodes to bootstrap themselves securely without waiting days to sync all past state.
The purpose of this article is to explore on the merits/functions of the IBC protocol and discuss it utility:
a. in relation to homogeneous chains (chains existing within the Cosmos ecosystem);
b. in relation to non-Tendermint based, heterogeneous blockchains.
At the end of the article we will attempt to draw a distinction between bridges and payment channels and point to resources suggesting methods and tools of wider adoption for IBC post-Stargate.
There are many articles and sources of information that are technically superior to the present one. The attempt here is to provide a synopsis and consolidation of the wealth of information that exists out there in relation to IBC and blockchain interoperability development on Cøsmos. At the footer of this article there are links to the material the author came across while researching for the present article.
Introduction to IBC
There are several blockchains that claim to be Sovereign, Decentralised, Scalable and Sustainable but only a one can claim that it will be able to do all of the above while solving the riddle of blockchain Interoperability. Cosmos Network is within arm’s reach of completing the vision of its original roadmap. The tool that will facilitate this vision is the Inter-Blockchain Communication Protocol (IBC).
In addition the upcoming release of IBC with the Stargate upgrade, will mark the completion of the three layers of the Cøsmos stack: Tendermint Core, Cosmos-SDK, and IBC.
The Inter-Blockchain Communication protocol (IBC) is a reliable & secure inter-module communication (interoperability) protocol that handles reliable transport, authentication, and ordering of data across different sovereign blockchains.
IBC can be used by any application which builds on top of reliable & secure inter-module communication. Example applications include cross-chain asset transfer, atomic swaps, multi-chain smart contracts (with or without mutually comprehensible VMs), and data & code sharding of various kinds.
This is why IBC has been called the TCP/IP for blockchains.
Josh Lee on a recent article provided a great explanation of how the IBC protocol works, that is worth sharing here:
It was the simplicity and flexibility of TCP/IP that allowed it to be the standard Internet communication protocol for nearly 50 years. It is used in computers, servers, mobile phones, and even small IoT devices, and has survived many improvements and iterations of the Internet.
Similar to the TCP/IP protocol, the unique aspect of IBC is that it separates the ‘application layer’ from the ‘transport and network layer’ (or TAO, transport, authorization, organization). This means that IBC defines how data is sent and acknowledged across blockchains, but it doesn’t define what that data is or how it should be structured. This sets IBC apart from other interoperability solutions which require a lot more standardization in the application layer. Adding additional requirements for standardization can add a layer of politics which decreases the diversity of blockchain architecture that can exist in the interoperable network.
IBC’s biggest strength is its simplicity.
What is IBC not?
IBC is not an application-layer protocol: it handles data transport, authentication, and reliability only.
IBC is not an atomic-swap protocol: arbitrary cross-chain data transfer and computation is supported.
IBC is not a token transfer protocol: token transfer is a possible application-layer use of the IBC protocol.
IBC is not a sharding protocol: there is no single state machine being split across chains, but rather a diverse set of different state machines on different chains which share some common interfaces.
IBC is not a layer-two scaling protocol: all chains implementing IBC exist on the same “layer”, although they may occupy different points in the network topology, and there is not necessarily a single root chain or single validator set.
IBC between homogeneous chains (chains existing within the Cosmos Ecosystem)
So how will a Cosmos blockchain connect with the other Tendermint-based blockchains? The Inter-Blockchain Communication (IBC) protocol, will link the Cosmos ecosystem together. It is important to note that the primary role of the Cosmos Hub will be to connect blockchains to one another.
As mentioned above, IBC will enable blockchains to exchange value (value that the tokens represent) and data with one another.
One question that may be asked is the following:
If two chains are sovereign → how can tokens from one be transferred to another?
Gavin Birch provides a good explanation on the mechanics of IBC protocol’s operation for asset transfers:
Chain A locks the tokens and relays proof to Chain B. Once verified, Chain B mints its own representative tokens (sort of like vouchers), which can later be destroyed to unlock the original tokens on Chain A. So the value that tokens represent can be transferred across chains, but the token itself cannot.
IBC & non-Tendermint/heterogeneous Blockchains
Can value and data be transferred between the Cosmos ecosystem and non-Tendermint blockchains (such as the Bitcoin network) with IBC?
IBC can directly enable value transfer between fast-finality chains (with deterministic finality). But e.g. Bitcoin is not a fast-finality chain, thus a special application-specific blockchain zone is required for such transfer to be effected.
According to Chjango Unchained Peg zones are our solution:
A peg zone is an account-based blockchain which bridges zones within Cosmos to external chains like Bitcoin or Ethereum. It acts as an adaptor zone — or a “finality gadget”, in Casper-speak — which translates finality for probabilistically finalized blockchains by imposing a “finality threshold” at some arbitrary number of blocks to achieve pseudo-finality. Generally, this “translator” zone design can be classified as a 2-way peg (2WP).
Gavin Birch again provides an explanation on the mechanics of IBC protocol’s operation for asset transfers between Tendermint and non-Tendermint chains:
Remember when Chain A proved to Chain B that it locked tokens? If that transaction is not reasonably permanent, Chain B could mint vouchers that back tokens that are not actually locked on Chain A. It’s important to have confidence that a block is permanent in order to have confidence that a change to an account balance is permanent. A Peg-Zone can set an assumed number of blocks (a finality threshold) in order to more securely enable a transfer the value of …. (e.g. BTC) to the Cosmos ecosystem.
Thus, a bridge works by minting tokens on Chain B when tokens are locked on Chain A. For example, with Peggy (Ethereum Bridge) (Chain A), you send an ERC-20 token (e.g. 1 Dai (stablecoin)) to a special Ethereum address, and specify which address on Cosmos (Chain B) should receive it. Your token is then locked on Ethereum. Peggy then mints the equivalent amount of the said token for you on the Cøsmos side. This is not exactly the same token as the token you locked on Ethereum, but can be considered the equivalent (e.g. 1 CosmosDAI or cDAI =1 Dai).
You can send the cDAI token around on Cøsmos and use it in decentralized applications there. cDAI can be sent back to an address on Ethereum by sending it to the Cøsmos side of the bridge. The cDAI is then burned, and the same amount of Dai on Ethereum (1 Dai in our example) is unlocked. Due to this ability to exchange the synthetic Dai (cDAI) for real Dai on Ethereum, they should trade at the same price and basically be equivalent.
Secret Network’s standalone Ethereum Bridge
Apart from Peggy, Secret Network (a Cosmos SDK/Tendermint chain) is also currently developing an Ethereum bridge. It is running on testnet and will be going live in December.
To illustrate how it works, here’s an example of what a user interaction with the bridge would look like:
- Alice sends 10 ETH to an Ethereum lock contract and provides her Secret Network address.
- Multisig committee watches this event and sends a mint request of 10 secretETH to the address Alice provided in step 1. The Secret Network then mints these wrapped tokens accordingly.
- Alice can now transact with secretETH on Secret Network and utilize her secretETH in the native Secret DeFi ecosystem.
- When she wishes to move back to Ethereum, Alice burns her secretETH and provides an ETH address to receive back her ETH.
- Multisig committee creates a TX on Ethereum that instructs the Ethereum Bridge smart contract to move ETH to Alice’s address in step 4.
This process can be replicated for any amount and for any ERC-20 token.
Blockchain Bridges are not Payment Channels
In order to understand what a payment channel is, let us assume that you want to transfer 1 Dai (a dollar-pegged stablecoin on Ethereum) to e.g. 1 cosmosUSD (cUSD)(an imaginary different dollar-pegged stablecoin on Cosmos). To do this with payment channels you first need a counter-party who wants to do the opposite trade. In practice this role would be played by a market-maker type of entity (e.g. AMM) who is getting a fee for providing the liquidity. This counter-party must have an amount of cUSD equivalent to the amount of Dai that you would like to trade/move. In this example, since they are both stablecoins, this will usually be almost the same number of tokens (i.e. close to 1:1).
For this to happen you will be required to lock up your Dai tokens in a hashlock on Ethereum which is set to release them to the counter-party once you reveal the pre-image of a certain hash. The counter-party will also have to hashlock their cUSD on Cøsmos, to be released to you using the same hash.
This example highlights one of the fundamental differences between these two methods of cross-chain value transfer. Notice that you were trading Dai for cUSD, unlike with the bridge example in the previous section whereby you traded a representation of the actual Dai token on Cøsmos. Of course, if Cøsmos does not have a native stablecoin, this whole process of using a payment channel is not possible. This is because payment channel swaps do not issue tokens, while bridges do.
Suggestions for wide IBC adoption post-Stargate
Interchain Accounts
For an important overview of IBC and the possibilities of reaching its full potential post-Stargate, please read the article of Josh Lee entitled:
Why Interchain Accounts Change Everything for Cosmos Interoperability
Josh makes a very intriguing and useful proposition of utilising Interchain Accounts that can — in effect — allow a blockchain to securely control an account on another blockchain using IBC. It works like this:
By implementing the above model many of the application-specific features (such as token transfers, token swaps, staking, etc) will not have to be built separately above the IBC TAO layer and as an application layer.
According to Josh:
Very simply put, interchain accounts allow a blockchain to securely control an account on another blockchain using IBC.
The aim is that rather than creating an application-level IBC for every modules’ features, interchain accounts would allow someone to leverage the capabilities of an account to access a blockchain’s application-specific features.
The two most important features of interchain accounts are as follows:
Deterministically create a new interchain account over IBC
Relay the transaction to the interchain account and submit it to the target blockchain.
AMM DEX Liquidity Module
The Liquidity Module (from an architectural perspective) is designed to allow continuous management of liquidity within the Tendermint proof of stake consensus environment. B-Harvest and Tendermint have been developing a fast finality DEX based on a scalable consensus mechanism toward allowing exchange of assets across blockchains. The roadmap includes:
IBC integration for interchain connections and exchanges between Cosmos zones
Interoperability with Ethereum based tokens using our two way peg technology
Onboarding Ethereum smart contract based systems utilising Ethermint.
IBC Use Cases
For an extensive overview of possible use cases of IBC please see:
https://github.com/cosmos/ics/blob/master/ibc/4_IBC_USECASES.mdSome of the use cases indicatively include:
Asset transfer (fungible tokens, non fungible tokens, vanilla & shielded payments)
Multichain Contracts (cross-chain contract calls, cross-chain fee payments, interchain collaterilisation)
Sharding (code migration, data migration)
Epilogue
IBC is not the end for Cøsmos development as can be drawn from the above analysis: It is the beginning. With the passing of the proposal for the Stargate upgrade, all we have is a complete, albeit basic set of tools with which we can build and create value within interoperable (not siloed anymore) blockchain environments. The possibilities are endless. Layers of value can be built on top of the IBC protocol. One may ambitiously claim that IBC marks the start of the second Era of the Blockchain Revolution, the Era of interconnected, interoperable blockchains within which Cøsmos is destined to have a central role.