A deeper understanding of Interchain Accounts
In this blog, you will learn about the background of Interchain Accounts, how it works and what are its implications on the Cosmos Ecosystem.
Interchain Accounts — High Level Overview.
In a multi-chain universe like Cosmos, there are multiple chains connected to each other via Inter Blockchain Communication or IBC.
Historically, the chains connected by Interchain Accounts IBC pass the tokens over an ICS20 IBC token transfer exchange.
Interchain Accounts open up a completely new avenue of use cases based on generalized message execution across chains.
Interchain Accounts — Working.
In traditional IBC transactions, your “tokens” would be the assets that would be passed from one chain to the other IBC-enabled chain. However, with Interchain Accounts, instead of assets being transferred, a list of directions is passed from the controller chain to the host chain. In this case, a controller chain is a chain that registers and controls an interchain account on the host chain and a host chain is a chain where the interchain account is registered.
Let us take an example of 2 chains — Cosmos Hub & Osmosis. In this example, we have Cosmos Hub as controller chain and Osmosis as the host chain. If someone wants to send their ATOM over to Osmosis, they would have to put it in a Liquidity Pool or swap it. This tx would be considered as an IBC tx where you would transfer your assets from Cosmos Hub to Osmosis. Some of these steps have to be completed manually.
However, these manual steps can be automated with ICA. With Interchain Accounts, you can enable a flow that looks something like this — Hub will open an Interchain Account on Osmosis and the user can submit a transaction. This tx would basically trigger the IBC token transfer and when the token is successfully transferred, it will trigger an action message like — swap or deposit in Liquidity Pool.
This is use case is only the tip of the iceberg of what can be achieved with Interchain Accounts. As you can already notice, Interchain Accounts can open up many new complex use cases and further promote cross-chain transfers.
All of these complicated operations are being performed in the background while abstracting it from the user who has to just submit a simple transaction.
Working of Host Chain & Controller Chain
The controller chain first opens an account on the host chain. Something to note here is that Interchain Accounts and User Accounts are different from each other. The controller chain opens a channel and this channel is responsible for passing the tx from the controller chain to the host chain to be executed.
Let’s say a user wants to submit an individual message to swap over the controller’s Interchain Accounts channel on the host. The user doesn’t have to open his own Interchain Accounts on the host. Rather, the user would have to just use the controller to host the channel.
Interchain Accounts —Technical Understanding.
From an end-user perspective, it is a simple ‘transfer message.’ However, under the hood, an Interchain Account transaction is a non-IBC blockchain transaction of the target blockchain packaged inside an IBC transaction. How the transaction is then handled by the receiver chain is left up to the logic on the receiver chain, which allows the Interchain Account to be used for passing over the encoded transaction, no matter what the transaction type is. This allows transactions from application-specific chains to become their own composable primitives — and business models to move from being native to the scope of one chain to being native on the Interchain. This is supported by enabling one chain to open an Interchain Accounts-specific channel on another chain that it is already connected to and vice versa.
On-chain governance from both chains would then whitelist messages which can be accepted by the Interchain Account on each side. These messages are encoded transactions, similar to Ethereum delegate call encoded functions, which can then be executed on the receiver chain, on behalf of the sender chain. Very simply put, an Interchain Account transaction can be thought of as “a letter inside of an envelope inside of a box”, which contains instructions on what task should be submitted to the receiving blockchain.
Interchain Accounts — Steps for Communication
- The Controller chain transfers tokens over to the Host chain.
- The tokens are successfully registered on the Host chain.
- The message is sent to the Host chain on the Interchain Accounts channel to swap the tokens.
- The message executes on the Host chain’s side.
- The user gets a successful acknowledgment message.
How are Interchain Accounts different from Web2 services?
Interchain Accounts — How it differs from web2 services.
Authz allows you to have access control on tx within the same chain whereas Interchain Accounts allows a cross-chain workflow.
Right now chains have to implement all the features and services they want on their own chain or make users manually do the workflow. When compared to web2 you can observe that a lot of this is accomplished by exposing service endpoints and by pinging these endpoints to query an API or simply performing some action.
However, in a cross-chain workflow, there isn’t really a way to expose such endpoints on a chain that can be used by other chains.
The most effective way to do something like that on an interchain workflow is through Interchain Accounts.
Interchain Accounts — Security Model
Interchain Accounts is built on top of the IBC transport layer that provides a ‘light client security guarantee’ as opposed to a ‘bridging guarantee.’ The major difference between the two is that, in a ‘bridging guarantee’ to send a message, you will have to trust that the messenger will not sniff and manipulate the message. However, in ‘light client security guarantee,’ the same exact copy of the state of the chain is maintained on both chains. So if there is a tx that happens on 1 chain, it will reflect on the other chain which can be verified.
Since Interchain Accounts is built on top of this ‘light client security guarantee,’ you can almost be certain that this security feature will be inherited by Interchain Accounts. This is a very powerful feature that actually lets you know the state of your counterparty, and the next step is to actually give them directions on what to do or how to do it.
Interchain Accounts — Integration Complexity
The IBC module of ICA can be easily integrated into a chain. What is more technically challenging is finding the relayers to provide the relaying infrastructure for the chain.
This has been solved to a certain extent as many validators now relay as it’s a good value proposition for them to get delegations.
One important thing to note here is even though relayers play an integral part in the interchain transactions, they are not ‘trusted.’ Which basically means that they have no way of actually changing the message. They are just literally responsible for carrying the message back and forth between chains.
Interchain Accounts — Implications on composability
It is really difficult to think about composable cross-chain workflows without something like Interchain Accounts because without Interchain Accounts you either rely on the user to complete all of these cross-chain workflows themselves or you rely on all of the chains you want to do business with to have coordinated upgrades and implement your kind of business model. This kind of dependency slows down the overall development of the use cases built for interchain.
Interchain Accounts — Challenges
One of the challenges currently presented by Interchain Accounts is scalability. Due to the nature of how Interchain Accounts works, every chain needs to maintain a copy of all the other chain’s states which can become resource intensive and increase overhead.
There are some solutions being worked on such as decentralized relaying networks and pruning old states that can potentially mitigate this issue.
Another challenge is the lack of adoption and usage of Interchain Accounts by chains, as it requires coordination and collaboration between chains which can be difficult to achieve. However, with increasing interest in interoperability solutions, more and more projects are starting to explore using Interchain Accounts in their workflows.
Another challenge is finding reliable relayers. This is still something that needs to be addressed as delegators may not always choose to delegate their stake to relayers, so it’s important to incentivize them in the right way.
Conclusion
Overall, Interchain Accounts is still a relatively a new feature and there are definitely challenges that need to be addressed as more use cases are built on top of it. However, it has already shown its potential for enabling cross-chain workflows and paving the way for more composability in the blockchain space.
This is an exciting time for blockchain technology as we continue to push the boundaries and explore new use cases. Interchain Accounts are just one piece of the puzzle, and it will be interesting to see how they evolve and progress in the future.
Thank you for reading. Cheers!
