Why Interchain Accounts Change Everything for Cosmos Interoperability
and why interchain accounts might be the catalyst that drives IBC adoption on Cosmos
There is no doubt that IBC is one of the most exciting developments in the blockchain space right now. IBC opens up the possibility where sovereignty and interoperability can coexist to unleash the power of many application-specific blockchains working together.
The release of IBC will finalize the completion of the three holy grails of the Cosmos stack: Tendermint Core, Cosmos-SDK, and IBC. So the next logical question is, what will it take to drive IBC adoption across the Cosmos ecosystem once IBC is live?
This blogpost explores a high-level overview of what IBC is, the obstacles it must overcome to achieve adoption, and how interchain accounts can help in the early stages of IBC.
A Brief Overview of the IBC Protocol
IBC is a fundamental blockchain interoperability protocol that handles reliable transport, authentication, and ordering of data across blockchains.
Think of it as the TCP/IP for blockchains.
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.
Similarly, IBC was purposefully designed to standardize only the fundamental aspects that are required for cross-chain data transfer to accommodate a wide variety of blockchain architecture.
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.
The Obstacles of IBC Adoption
While this flexible and fairly simple design of IBC has significant advantages in allowing the Interchain Standards (ICS) to be adopted across a wide variety of blockchains, it also means that many of the application-specific features (such as token transfers, token swaps, staking, etc) have to be built separately above the IBC TAO layer and as an application layer.
One disadvantage to this can be that even when IBC is ready, there may not be many features one can use beyond token transfers across blockchains.
“So why can’t you just create new interchain standards for each of these applications?”, you ask.
Well, you can. And that should be the way it’s done, eventually.
I say eventually because the problem is that creating a new application layer standard takes time, resources, and public discourse.
If hundreds of applications and features are developed within the Cosmos ecosystem in the next few years, each of those features will likely need to go through the process of implementation and standardization. Considering the speed of growth that the Cosmos ecosystem has seen in the past year, creating application-layer standards for all of these features will bring significant overhead in terms of development resources.
So how do we solve this?
I believe that Interchain Accounts is one key feature that will help unlock the potential of interconnected blockchains without significantly increasing development resources.
What is Interchain Accounts?
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.
Specification of interchain accounts is outlined in Interchain Standards #27. It was initially proposed as an idea in August of 2019 and after months of public discussion, feedback, and revision — it was merged as an official interchain standard in December of 2019.
What Problems Does Interchain Accounts Solve?
Composability between Cosmos Zones without Reducing Zone Sovereignty
So let’s go back to the point made earlier: Creating new standards and implementations for each application-feature on IBC will take time.
What this means is that for there to be implementations of application-specific transactions on IBC (examples could be something like opening a CDP, doing DEX trades, interchain DAOs, etc), there will need to be a time and resources spent in implementing these features on the application layer of IBC.
This could be an issue where IBC itself may be production-ready, but very little application-level features outside of interchain token transfers are available. This can delay the time it takes for IBC to be adopted within the Cosmos ecosystem.
Interchain accounts help solve this issue by allowing one blockchain to access the application-features of another blockchain (such as stake, vote, swap tokens, etc) through what an ‘account’ can do. This provides a simple way of creating application composability, similar to how smart contracts interact with each other on the EVM, by leveraging IBC. Because the fundamental architecture of ‘sovereign, interoperable blockchains’ remains, the composability that interchain accounts introduce doesn’t take away the benefits of application-specific blockchains.
This is crucial in building a network effect of applications in the Cosmos ecosystem by being able to cross-interact with one another from the early stages of IBC adoption.
Provide a Simple & Scalable Path for Early IBC Adoption
An interchain accounts transaction is simply a non-IBC blockchain transaction of the target blockchain packaged inside an IBC transaction. The interchain accounts transaction leaves how the non-IBC transaction is handled to the internal logic of the target blockchain. Interchain accounts itself is feature-agnostic, in the sense that interchain accounts don’t care what the transaction that it contains is trying to do.
This provides a far more scalable solution in the short-term for fast-changing blockchain ecosystems like Cosmos, where potential architectural changes in the target blockchain can be frequent and new features can be added to the blockchain. As long as interchain accounts are implemented, new features on the blockchain can be immediately supported as IBC transactions.
This allows interchain accounts to act as a stepping stone for early stages of application interoperability for projects to test what type of integrations are possible before committing resources to create a standardized IBC application implementation.
Mitigate Security Risks
One design principle that interchain accounts were built upon was that application interoperability shouldn’t require significant changes to the core blockchain application logic.
For example, if someone wanted to implement an IBC application that enables one blockchain to access the staking module of another blockchain (in the scenario that this person was trying to create some type of liquid staking protocol), this may require changes to the staking module of the target blockchain.
Changing a core module such as bank, stake, or gov should be done conservatively with an extensive security analysis to ensure that the modification will not result in new attack vectors or vulnerabilities.
Because interchain accounts application transactions are handled as an internal account-level transaction, it doesn’t require any modification to application modules (such as x/bank or x/gov) to accommodate IBC transactions. As long as the internal architecture of how an account’s transactions are handled is sound and secure, adding IBC functionality will not introduce new potential vulnerabilities.
A Practical Approach to Cosmos Application Interoperability
Interchain accounts aim to provide a scalable path to IBC adoption in the early stages of IBC rolling out into production. As most features that could benefit from IBC are features that the average account can already do (such stake, opening a CDP position, token swaps), interchain accounts simplify the process of building interchain applications with little to no downside.
By turning applications on Cosmos blockchains into lego blocks, applications such as the following can be built easily:
- Interchain staking
- Argent-like interchain wallets
- Cross-chain token swaps
- Multichain DAOs
If the modularity of the Cosmos-SDK is what led innovators to build on Cosmos, it is the composability of IBC applications that will finally allow them to unleash their true potential.
What’s Next?
Chainapsis will be leading the Cosmos-SDK implementation of Interchain Accounts (ICS27) for the Cosmos-SDK through the support of the Interchain Foundation.
We welcome any questions or feedback. Feel free to join us at the channel on the Cosmos Community Discord or drop by at the Telegram discussion group. Also, you can drop by at the GitHub repository to raise an issue or to contribute.
