Understanding Cosmos IBC and how Interchain Modules will Drive its Scalability

The Cosmos ecosystem has been gaining plenty of traction in the past year — from dYdX announcing its decision to build its own blockchain that is based on the Cosmos SDK to VanEck (one of the world’s renowned ETFs) signaling that they are bullish on Cosmos in their latest article, and Syntropy, a project that is focused on decentralizing the internet, moving over to the Cosmos ecosystem from Polkadot— all for good reason.

The Cosmos ecosystem stack which compromises of the Cosmos Tendermint Core Consensus, Cosmos SDK, and Cosmos IBC, has greatly enhanced the developer experience in creating blockchains and makes the experience akin to creating a website through Wix — while still being competitive in terms of performance — where the website is a blockchain and Wix is the Cosmos ecosystem stack.

But of course, without the drag-and-drop (for now).

As the Interchain Security module is soon to come in February, we thought it’d be apt to revisit these Interchain modules with updated information on what you can expect out of all the various modules in 2023.

P.S If you’re new to the Cosmos ecosystem, and looking for a primer article to understand Cosmos and the Cosmos Hub at a high level, take a look at our articles, “Introduction to Cosmos”, and “Our 5 favorite blockchain projects built on Cosmos” to get up to speed.

First, there was IBC…

Before we get into the exciting world of Interchain Modules, first we need to understand Cosmos’ IBC, and its current drawbacks.

All you need to know about Cosmos IBC

Through the creation of Inter-Blockchain Communication (IBC), Cosmos solved one of the most pressing challenges in the entire blockchain industry, which was seamless communication between blockchains.

Think of IBC as the TCP/IP for blockchains, as it is a universal interoperability protocol — comprising a lower transport layer (IBC/TAO) and an upper application layer built on top of TAO (IBC/APP) — that allows two different blockchains to communicate with one another, and guarantees reliable, order, and authenticated communication.

Transport Layer (IBC/TAO)

When blockchains communicate via IBC, these messages are sent/transported within data packets, and the transport layer is responsible for transporting, authenticating, and ordering (TAO) these data packets.

The key components that make up the transport layer are connections, light clients, channels, and relayers.

Connections: The connection is chain-specific and connects light clients on two different chains. Before relaying packets, the IBC/TAO modules need to determine and authenticate ClientState to communicate with; this connection is made via a mechanism like the 3-way handshake of TCP.

Think of the 3-way handshake like this:

1. Blockchain A sends a packet saying, “I want to talk to you!”
2. Blockchain B then sends a packet back, saying, “Yeah, I got your packet; I would like to speak to you too!”
3. Blockchain A then receives the packet and sends back a confirmation, which is when they can start relaying information to each other.

Light clients: Light clients are a lightweight representation of a blockchain, and it is used for connecting to a full node to verify block headers (summary of the data contained within a block).

Two independent blockchains, A and B, interacting over IBC, have light clients of the counterparty chain.

Assuming that A wants to communicate a message “ABC” with blockchain B, it sends the header of the block in which that message exists, along with a commitment proof of that message to B.

Channels: Channels are module-specific and allow the transfer of data packets between different modules on the various chains.

Relayers: However, A and B do not send data packets between each other directly. If A wants to send “ABC” to blockchain B, it will instead store a hash of the data packet in its state machine, and relayers — which are off-chain processes — will constantly observe for such messages.

Once a relayer sees that A has committed a message for B in its state machine, it will pick it up and pass it to B.

One thing to note here is that because relayers are permissionless, they can be run by anyone.

Application Layer (IBC/APP)

While the transport layer (IBC/TAO) is only responsible for sending and receiving data in a reliable, ordered, and authenticated way, the application layer — built on top of the transport layer — specifies how data packets need to be interpreted.

Unlike other interoperability solutions, IBC separates its application layer from the transport layer and thus gives more flexibility regarding how new blockchain architectures are built.

One example of an IBC/APP protocol is ICS-20, which allows for cross-chain token transfer, and IBC/APP implementers don’t need to design or implement entire blockchain interoperability mechanisms.

But IBC isn’t that fast… yet

The simplicity and flexible design of IBC have allowed the Interchain Standards (ICS) to be significantly adopted across multiple blockchains in the Cosmos ecosystem.

But although IBC is now fleshed out and working seamlessly between chains — with 54 zones connected to one another and a month-to-month volume of about 700M (as of 28th January) — there is still a drawback with IBC.

Due to how IBC works (i.e., IBC/TAO and IBC/APP), it takes up time for public discourse, alongside precious developer resources, for new Interchain Standards to come to fruition as new application-specific features would have to be built separately above the IBC/TAO layer.

If Cosmos were to fulfill its vision of becoming the Internet of Blockchains (which we know is more likely… possible), then developing various Interchain Standards would take a lot of time and resources.

Then, how do we go about compensating for speed in development?

Well, that brings us here.

Meet the upcoming Interchain upgrades from the Cosmos Hub  Roadmap 2.0 — and in the roadmap by Cosmos, there are a few specific Interchain Modules that we will look at, mainly Interchain Accounts (v8 Rho), Interchain Security (v9 Lambda), and Interchain Queries (v10 Epsilon).

Interchain Accounts (v8 Rho)

Interchain Accounts allows any cosmos ecosystem blockchain to securely control an account on another blockchain via IBC, thus saving a lot of time for developers.

Traditional IBC Transactions

Let’s take an instance of a typical IBC transaction from Blockchain A to Blockchain B, so that we can understand why Interchain Accounts are powerful and allow much more speed in terms of development.

While ICS has made things much easier for IBC/APP implementation, the current drawback is that if you wanted a CDP module or a token staking module, you would need to create a new ICS standard to have that module-specific feature on blockchain B.

Transactions with Interchain Accounts (IA)

What if we could leverage the native blockchain module instead of creating an ICS standard to open up a CDP or stake?

As seen above, the Interchain Account (ICS27) allows for relaying transactions from Blockchain A to Blockchain B (in the format of Blockchain B). Blockchain B’s internal logic will then handle the transaction.

A complete game-changer?

Thus, Interchain Accounts thoroughly changes the game for IBC, and positively, in a few ways:

• It allows for IBC to be scalable because of its composability

IBC’s logic does not handle Interchain Account transactions, but this is dealt with by the receivers’ internal logic, thus making Interchain Accounts feature-agnostic.

This means that IBC is now much more scalable as new features can be supported quickly on any cosmos ecosystem blockchain without having to create a new Interchain Standard — as long as Interchain Accounts are implemented in the Blockchain — and it is particularly groundbreaking in this industry as changes are made at almost light-speed every single day.

For example, in the picture above, if Blockchain B were to have another feature called “Loan” — and as long as IA is implemented — it can be immediately supported as an IBC transaction.

• Cross-Chain Security Risks are mitigated

IA transactions are only handled as an internal account-level transactions; this means that supporting blockchain-specific modules would not require significant changes to the core blockchain application logic.

Interchain Security (v9 Lambda)

Interchain Security — the Cosmos-specific category of Shared Security that uses IBC — allows the provider chain (e.g., Cosmos Hub) to produce blocks for a consumer chain.

Traditional Validator Set

In a typical blockchain scenario — or in this case, a new Cosmos chain — putting together a validator set that is both decentralized and with a valuable staking token has been a hurdle for many projects.

Take Blockchain XYZ below, for example. It is like the architecture of current blockchain ecosystems, where the blockchain itself puts together a validator set for the applications that run on XYZ.

Since XYZ chain’s security is tied to the token's market cap, which takes some time to increase its value, it then presents an inherent risk to the various dApps in the ecosystem and the chain itself (see above).

And then… there’s Interchain Security

With Interchain Security, developers can quickly launch a chain that runs their EVM, CosmWasm, or Cosmos SDK application and one secured by the provider chain's validator set.

In the case of blockchain ABC below, which is a provider of security to blockchains QQQ, WWW, and TTT, using Interchain Security, the latter chains’ security will now be dependent on chain ABC’s validator set — each with their set of application-specific dApps — instead of having to build up their validator sets.

As seen above, the structure is not that much different from a typical blockchain validator set.

These blockchains QQQ, WWW, and TTT can now focus on building and supporting the various dApps while knowing that they are secured from Blockchain ABC’s validator set and don’t need to go out sourcing for their validator sets.

So, for example — in the case of Cosmos Hub being a provider chain — any Cosmos chain looking to leverage on Interchain Security (or known as consumer chains) will benefit from the Hub’s validator set as they:

1. Are secured by the complete validator set and the staked MCAP of ATOM (Around $2.3B at $11.7 as of 19th January) of the Cosmos Hub from the get-go
2. They don’t have to go far and wide to search for their validators
3. Projects get most of the gas fees as compared to building on a typical smart contract platform such as Ethereum or Harmony

But it does not benefit only the consumer chains. The provider chain also benefits by outsourcing core functionality instead of dedicating resources to building extra functionality.

How the Consumer Chain works

In the setting of Interchain Security, there are two types of consumer chains: Contract Chains and Custom Chains.

Similar to how one would install a .exe file where you get the option of an express installation vs. custom installation, the setup for consumer chain users has the same logic.

All the consumer chains — contract or custom — will require approval by a governance proposal on the provider chain.

Contract Chains: Similar to “express installation,” contract chains allow developers to quickly deploy a smart contract application secured by the provider chain.

1. It provides a standard chain binary, so teams don’t need to work on low-level code.
2. The gas fees in this scenario are set to the provider’s token, with 75% of it going to a DAO, which will support the development of the consumer’s project.

Custom Chains: Similar to “custom installation,” custom chains allow developers to customize the consumer chain at the Cosmos SDK level.

And since it is fully customizable, these chains need to be scrutinized more heavily by the validators of the providers by accepting these chains via governance, as the performance and security of the chains can not be as easily guaranteed, unlike Contract Chains.

1. The degree of customization allows developers to create a custom chain binary with complete control of how transactions are assembled or gas is metered.
2. The gas fees in this scenario are customizable and can be used to incentivize behaviors with their token via inflationary rewards.
3. Because custom chains have their token and are using Interchain Security, stakers of the provider’s chain will receive an ongoing airdrop from a portion of the fees on the consumer chain.

Aligning long-term goals

With Interchain Security, it makes Cosmos more potent as it can then align the long-term goals of provider chains by sharing its security, in return for a plethora of use cases, based on the provider’s goals.

This then allows for quick scaling for both the consumer and provider chains without compromising security and a compromise in lack of focus because they are looking for validators to secure their app-chain.

Drawbacks in the first version of Interchain Security

Due to the nature of core changes required, Interchain Security needs iterative changes to how Provider and Consumer Chains work, which will be developed gradually.

At launch, the first version of Interchain Security aims to provide a minimum viable set of functionality for chains before progressing to more complex and extended functionalities.

There are some drawbacks to the first version of Interchain Security, which are:

1. No free market mechanics for provider and consumer chains. Imagine that you have a security team, and you don’t get to pick who is protecting you — in this case, who validates your chain. In the first version of Interchain Security, the full validator set of provider chains needs to participate if Interchain Security is enabled.
2. It takes more time than you think to implement. Because the whole validator set requires participation, a governance process is necessary for every chain that wants to become a consumer to ensure readiness. This process in the first version will be a bit more lengthy.

Future versions of Interchain Security

These drawbacks will most likely fade out in future versions of Interchain Security.

In v2 of Interchain Security, the validators of the provider chains can opt-in to participate as a validator on the consumer chain instead of having the complete set of validators on the provider chain validate the consumer chain — meaning that there will be free market mechanics as it is up to consumer chains to advertise benefits, and up to the validators of the provider chains if they want to validate the said consumer chains.

In v3 of Interchain Security, which is still a stone’s throw away and subject to change, Consumer Chains can create their staking designs based on the set of validators provided by the Provider Chain and customize the set of validators and their voting power for Tendermint via ABCI. While this is technically possible, it is currently not considered for the first or second versions of Interchain Security; instead, it is considered for the third version — called Layered Security.

All in all, it’s up to the consumer chains to decide between the pros and cons of the different versions of Interchain Security and, ultimately, if they want to participate.

Interchain Queries

Interchain Queries… well, like the name states, allows chains to query other blockchains to retrieve data from different blockchains in the Interchain.

Bringing DeFi to the next level

Queries are a fundamental building block in DeFi applications as it allows the dApps to query the needed data accurately. For example, if you want to borrow on Blockchain A using some assets you have as collateral, it wouldn't be possible without queries.

What if we hope to borrow assets on MM blockchain A using assets that are on blockchain B?

This isn’t possible natively on blockchain A currently, as you would have to bridge your assets from B to A, then deposit your assets as collateral.

But with Interchain Queries, you can query states from other blockchains, as seen in the example above with Bob, thus removing the need for bridging assets, which poses security risks.

Why can’t the IBC protocol fix this?

Well, technically, it’s possible. However, while the IBC protocol enables the communication between chains, using it to query the state of blockchains in the Cosmos ecosystem by sending packet queries is costly and inefficient if you want to query something as simple as balances.

Furthermore, requests for information from one blockchain to another might disrupt if too many requests are made — and this is where Interchain Queries shines.

It enables on-chain applications to query the state of other chains seamlessly without involving the queried chain, requiring very little from the querying chain.

Combination of modules, Cambrian explosion of use cases

Of course, just queries alone won’t allow Bob to borrow USDC since Interchain queries are purely queries.

We need to bring it all together.

Remember Interchain Accounts? This feature would lock the JUNO in the MM contract on blockchain B.

The querier then asks if the JUNO has been locked and if yes, this information is relayed to blockchain A, and the MM contract allows Bob to borrow USDC.

Last, suppose both blockchains A and B were to be newer chains. In that case, they can just focus on building their chains by leveraging Interchain Security instead of spending time to make their staking tokens valuable so that they can secure their chains.

Here, we see the combination of all the Interchain modules, which brings about seamless interoperability between blockchains and dApps, that can adapt quickly to the markets without compromising security.

And at the end of the day, we are left with: (1) Bob, who is happy since he doesn’t need to be confused about bridging left and right, and (2) Secured blockchains with focused teams on next-gen primitives.

How are other projects leveraging the various Interchain Modules?

Of course, the above scenario is a hypothetical situation that I deem possible and will most likely see in the future.

In the Cosmos ecosystem, however, some projects are already leveraging on the various Interchain Modules and are the trailblazers in fully integrating these specific modules into their applications for multiple use cases, such as liquid staking, vault management, and more.

Stride Zone (Live)

Stride is a liquid staking protocol that allows users to bond tokens and receive liquid tokens in return.

Stride stakes the tokens on four different host chains: Osmosis, Hub, Juno, and Stargaze, with more incoming, and was the first chain to use Interchain Accounts and Interchain Queries to be used in a real-world setting — but how are they using it exactly?

Interchain Account (ICA): Stride batches multiple liquid stake deposits on their chain & stakes them on the respective host chain every 6 hours using ICA. Redemptions (which are not shown above) are also initiated using ICA.

Interchain Query (ICQ): ICQ is used to query the 'Withdraw ICA' on a host chain every 6 hours to determine the interest rate and reinvest it with an ICA transaction. Stride also uses ICQ to query for validator slashing events.

Quasar Finance (Not live)

Quasar’s Public testnet will launch in February, with the mainnet shortly after.

Quasar is a DeFi appchain that allows users to use customizable strategies to manage digital assets across multiple blockchains.

It also provides Liquidity Providers with access to actively managed strategies through collective decision-making and “dynamic vaults,” where the vaults allow LPs to efficiently crowdsource and deploy capital in a permissionless, transparent, and self-governed way.

Interchain accounts (ICA) allow Quasar vaults to execute actions remotely on other chains.

Interchain queries (ICQ) allow values and balances to be read cross-chain.

Neutron (Not live)

Neutron is on testnet right now and will likely go live mainnet during March 2023.

Neutron is a Permissionless CosmWasm Platform that will be secured by the Cosmos Hub from the get-go, alongside a few other chains.

Where does the Interchain Module come in?

These Interchain modules are native within Neutron, meaning that Neutron provides a way for smart contracts to use the latest Interchain technology with little effort. In addition, they’ve created some blueprints (developers, you should look at this) on what you can do with Interchain Modules.

One example would be Bob wanting to borrow from one chain using his collateral from another, but this time, it’s just simple swapping from various chains.

As you can see, the architecture provided by Neutron can easily be deployed, since developing within Neutron doesn’t require external connections.

Wrapping it all up & further reading

That wraps up this article about the upcoming Interchain modules. We are seeing a set of upgrades that makes the Cosmos ecosystem a powerful player in the interoperability sector.

If you were to compare this with Legos, first, we created the Lego blocks (Smart Contracts & Tendermint), toyed around with packaging Lego Sets (Cosmos SDK), then created Lego Socket Joints (IBC).

… and with Interchain, we are making all the Lego blocks and sets compatible within the Cosmos ecosystem, thus allowing for much better, flexible, and insane use cases while still being secure because of the simplicity of Cosmos' IBC technology.

Further Reading

With that, let me leave you with some links for further reading, as most of the concepts here have been simplified, and if you are a nerd (like me), then you’d want to know what’s under the hood.

P.S Credits to Neutron and Stride for fact-checking and helping me out with the draft.

1. Introduction to Interchain
2. GitHub link to Interchain Standards
3. More reading into Interchain Accounts
4. More reading into implementing Interchain Security by Informal
5. More reading into Interchain Queries by P2P Validator

About Flagship

Curious about what we do? Be a part of the Flagship community that's revolutionizing the economy with the wisdom of our captains!