Cosmos has been gaining plenty of traction in the past few months — 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 — all for good reason.

The Cosmos stack compromising of Tendermint Core, Cosmos SDK, and 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 stack.

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

In this article, we will be focusing specifically on the Interchain Modules which extend the functionality of IBC.

P.S If you’re new to Cosmos, and looking for a primer article to understand Cosmos at a high level, take a look at our article here to get up to speed.

First, there was IBC…

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

All you need to know about IBC

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

A visual representation of IBC’s layers

Think of IBC as the TCP/IP for blockchains, as it is a universal interoperability protocol — consisting of 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 with each other 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.

A representation of the data flow in IBC/TAO

Connections: The connection is chain specific, and it is responsible for connecting light clients on two different chains. Before starting to relay packets, the IBC/TAO modules need to determine and authenticate *ClientState* to communicate with, this connection is done via a mechanism like the 3-way handshake of TCP.

Basically, think of the 3-way handshake like this:

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

Light clients: Light clients are a lightweight representation of a blockchain, and they are used to connect 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 are responsible for allowing transferring of data packets between different modules on the various chains.

Representation of relayers in the context of IBC

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 the sending and receiving of data in a reliable, ordered, and authenticated way, the application layer — built on top of the transport layer — is responsible for specifying 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 in terms of how new blockchain architectures are built.

Representation of IBC/APP in the context of IBC

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.

But despite the fact that IBC is now fleshed out and working seamlessly between chains — with 48 zones connected to one another and a month-to-month volume of about 450M — there is still a drawback with IBC.

All of the zones connected via IBC, as seen on mapofzones

Due to the nature of how IBC works (ie. 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.

Furthermore, if Cosmos were to fulfill its vision of becoming the Internet of Blockchains (which we know is more than likely… possible), then developing various Interchain Standards would take up 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.

In the roadmap by Cosmos, there are a few specific Interchain Modules that we will be looking at, mainly Interchain Accounts (v8 Rho), Interchain Security (v9 Lambda), and Interchain Queries (v10 Epsilon).

Interchain Accounts

Interchain Accounts allow a 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.

A typical IBC transaction, visualized.

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

Transactions with Interchain Accounts (IA)

Now, what if we could leverage the native blockchain’s module instead of having to create an ICS standard so that we can open up a CDP or stake?

An IBC transaction with Interchain Accounts, visualized.

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

A complete game-changer?

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

• It allows for IBC to be scalable due to its composability

Interchain Account transactions are not handled by IBC’s logic but 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 very quickly — 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 transaction, this means that supporting blockchain-specific modules would not require significant changes to the core blockchain application logic.

Interchain Security

Interchain Security — the Cosmos-specific category of Shared Security that uses IBC — allows for the provider chain (eg. 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.

A quick overview of a traditional validator set

Furthermore, since the chain’s security is tied to the market cap of the token that takes some time to increase its value, it 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 that is secured by the validator set of the provider chain.

A quick overview of Interchain Security

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

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

1. Are secured by the full validator set and the staked MCAP of ATOM (Around $2.5B at $12.72) of the Cosmos Hub from the get-go
2. Don’t have to go far and wide to search for their own validators.
3. Projects get the majority of the gas fees as compared to building on a typical smart contract platform such as Ethereum or Harmony

But it doesn’t only benefit the consumer chains only. The provider chain benefits as well because they are able to outsource core functionality, instead of having to dedicate resources to build extra functionality.

In the case of Cosmos Hub, they are planning to outsource the Hub’s liquid staking system to Quicksilver.

How the Consumer Chain works

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

An overview of the difference in Custom vs Contract Chains with IS

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 chains users has the same logic.

All of 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 that is secured by the provider chain.

1. It provides a standard chain binary so that teams don’t need to spend time working 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 types of 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. Because of the degree of customization, this allows developers to create a fully custom chain binary with full control as to 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 own token via inflationary rewards.
3. Because custom chains have their own 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 powerful as it is then able to 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 chains and provider chains, without a compromise in security and a compromise in lack of focus because they are looking for validators to secure their own app-chain.

Interchain Queries

Interchain Queries… well like the name states, allows chains to query other blockchains to retrieve data from other 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.

Now… what if we want to borrow assets on a MM blockchain A, using assets that are on blockchain B?

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

A simplified glance on how Interchain Queries work

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

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 we had a go at Interchain Accounts? This feature would then be used to 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 then relayed to blockchain A, and the MM contract allows Bob to borrow USDC.

Lastly, if both blockchains A and B were to be newer chains, 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.

The combination of the three Interchain Modules mentioned today

Here, we see the combination of all the Interchain modules, which brings about seamless interoperability between blockchains and dApps, that are able to 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 teams that are focusing on next-gen primitives.

Wrapping it all up & further reading

That wraps up this article about the upcoming Interchain modules. What we are seeing here is a set of upgrades that makes Cosmos 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).

Your Interoperability Solutions vs Cosmos

… and with Interchain, we are making all of the Lego blocks and sets compatible, thus allowing for much better, flexible, and insane use-cases, while still being secure due to the simplicity of 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.

In the upcoming articles (releasing soon), we will be going through some of the pioneers of the Interchain stack because it’s not worth building modules if no one is reallyyyy using them right?

So stay excited about that!

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

1. Introduction to Inter-Blockchain Communication
2. Introduction to Interchain
3. GitHub link to Interchain Standards
4. More reading into Interchain Accounts
5. More reading into the implementation of Interchain Security by Informal
6. More reading into Interchain Queries by P2P Validator

About Flagship

Flagship is an easy-to-use DeFi platform. We provide you access to early investment opportunities across emerging crypto sectors through our cross-chain ecosystem of decentralized funds and a network of experts.

• Join our Discord to be part of our active community and discover new assets and opportunities
• Check out our website and whitepaper here
• Get in touch with the team

We’d love to have you on board!