Everything You Need to Know About IBC Channels: FAQs (Part 2)
Channels are a crucial component of the Inter Blockchain Communication (IBC) protocol by enabling application to application communication. For developers implementing IBC for their apps, it is useful to have a strong understanding of channels since it is the layer of abstraction that they will interface with the most.
In Part 1 of this two part series of blog posts, we discussed the fundamentals of IBC channels and their importance for application developers. In this second part, we address common questions and misconceptions about channels.
FAQs
What are the reasons as to why a channel would close?
A channel can close due to any of the following 3 reasons:
- Due to a packet timeout on an ordered channel.
- Due to a 66% takeover by malicious validators on a chain.
- Due to a light client attack where the compromised chain can fool the counterparty into thinking that it has closed its end of the channel
How are channels closed?
A channel closes when a module calls chanCloseInit to close their end of the channel. Subsequently, chanCloseConfirm is called by the counterparty module to close their channel end.
If a packet is received out of order on an ordered channel, does the channel automatically close?
No, it does not. The packet is merely rejected by core IBC till a relayer submits the expected packet with the correct sequence (see ‘Types of channels’ section on part 1 for more information).
Does each module (transfer, interchain accounts, interchain queries, etc.) have its own channel?
Yes, it does. Each module such as transfer/interchain accounts/interchain queries binds to a port and then opens a channel using that port.
Are channels ordered in the case of interchain accounts?
Yes, currently all channels using interchain accounts are ordered channels. Hence if a packet times out, the channel closes and a new channel needs to be negotiated. Doing so avoids any unnecessary errors. For example, a user sends 2 ICA txs, packet #3 to transfer tokens and packet #4 to stake those tokens. If the channels were unordered there could be a scenario where #4 is delivered before #3, causing an error.
Can a chain have multiple channels for the same transfer module?
Although there is no reason for a chain to have multiple channels for the transfer module, it is possible to do so. But creating two or more channels for transfer is redundant and provides no benefits (unless they are two different versions). It also causes the same token sent over two different channels to be non-fungible. See section on ‘token fungibility’ in part 1 to understand why this is the case.
Can a channel be connected to multiple channels?
As of today, all channels are 1 to 1 mappings. This means that channel-141 on the Cosmos Hub will only be connected to channel-0 on Osmosis and no other.
Can a chain have two or more channels with the same channel ID?
No, this is not possible. On a given chain, all channels have a unique channel ID. The ID is incremented every time a new channel is opened on a chain.
Is a channel handshake needed every time an IBC packet is sent?
No, a channel handshake is only required to either open or close a channel. Once a channel has been opened, packets can flow through it freely.
Is it possible to upgrade a module from v1 to v2 while maintaining the same channel?
Currently this is not possible in ibc-go. Upgrading a module or adding a new feature/middleware to both sides of a channel requires either a network-wide upgrade or a new channel must be negotiated. But with the launch of channel upgradability later this year, channels can leverage new features and modules can upgrade while maintaining the existing channel.
Is it possible to limit the amount of tokens flowing in/out of a channel?
Yes, with the use of a rate limiting middleware. See here for the spec, and implementations of the rate limiter in Go and for CosmWasm contracts in a Go wrapper.
Is it possible to limit certain token denoms from flowing into a chain?
Yes, see this merged PR on how to add an IBC middleware that essentially acts as a firewall for certain denoms from being transferred into an IBC-connected blockchain.
How are channels reopened?
Once a channel is closed, the same channel with the same channel ID cannot be reopened.
Reusing channel IDs are prevented in order to avoid replay of packets. Every packet is uniquely identified by its port ID, channel ID, and sequence. When a new channel opens, the packet sequence is reset to zero. Therefore, using the same port ID and channel ID can cause packets that were processed earlier to be replayed again.
If a light client expires or gets frozen, is it possible to maintain the existing channels while reviving the client?
Yes, a frozen or expired light client can be revived with a successful governance proposal. If the proposal passes then the client is revived and all existing channels built upon that client are reopened. You can refer to our documentation for more information on how to revive a client.
What is a port?
A port is a logical construct that enforces object capabilities. Ports ensure that the only module that can open a channel on a particular port, is the module that is bound to that port. When a module binds to a port, it is issued a capability which the module must then claim.
Ports designate namespace for the modules, such as ‘transfer’ for ICS-20 token transfers, or ‘icacontroller’ for the ICA controller submodule.
Does having multiple channels increase the throughput of the chain?
No, it does not for ibc-go because tendermint processes transactions sequentially. Having one channel or multiple channels between two chains will yield the same throughput.
Who sets the timeout parameters?
The module sending the packet.
Can timeouts be set to zero?
Either the timeout timestamp or the timeout height can be set to zero but not both.
Do relayers need to pay fees for sending a packet that timed out?
Yes they do. A relayer needs to perform computation that involves spending gas, even if the packet times out on the receiving chain.
Do acknowledgements have timeouts?
No, they do not. There needs to be at least one message that can be submitted async. Otherwise it causes a circular problem where if timeouts existed for acknowledgements, then the message proving that the acknowledgment timed out could itself timeout, and so on — causing an endless loop.
Where can I view all the existing IBC channels and their respective IDs?
You can view it here on mintscan or on the chain registry.
Conclusion
If you have any remaining questions after reading the FAQs, feel free to reach out to us on the developer or support channels on our Discord. And if you’re a chain developer, application developer, or light client developer interested in using IBC, you’ll find all the information you need on our developer portal or in our ibc-go documentation.
About the Author:
Adi Ravi Raj works at Interchain GmbH and is the Protocol Analyst for the IBC team.
Thank you to Susannah Evans, Thomas Dekeyser and Carlos Rodriguez for reviewing drafts of this post.
