v8.1.0

UPDATES

• 5th April 2024: This release is NOT recommended since it is impacted by the ASA-2024-007 security advisory. Please use version >= 8.2.0.

---

This release main additions are:

Channel upgradability

Currently, once a channel is opened and the channel handshake is complete, you cannot change or renegotiate the semantics of that channel. This means that if you wanted to make a change to a channel affecting the semantics on both channel ends, you would need to open a new channel, meaning all previous state in the prior channel would be lost. This is particularly important for channels using the ICS 20 (fungible token transfer) application module because tokens are not fungible between channels.

With channel upgradability it is now possible to upgrade existing IBC channels to leverage new features that require a new packet data structure or adding a middleware at both channel ends. Some examples of what it will be possible:

• Add fee middleware on existing channels to incentivize IBC relayers.
• Adopt ICS-20 v2 (planned for later this year).
• Migrate from ordered Interchain Accounts (ICA) channels to unordered ones.
• Change connection hops, provided the application stack allows it.
• Prune stale acknowledgements and packet receipts to reduce disk overhead.

Channel upgradability introduces two new channel states: FLUSHING and FLUSHCOMPLETE. Application developers should consider these new states when implementing application logic that relies on the channel state:

• When a channel end moves from OPEN to FLUSHING (or FLUSHCOMPLETE after all packets are flushed on the channel end), sending new packets will not be allowed. This is needed, so that no new packets are sent and all existing in-flight packets complete their lifecycle with the pre-upgrade channel parameters. Once the channel reopens, sending will be possible again and packets will be processed under the new channel parameters.
• When a channel end is in FLUSHING, packets can be received and acknowledged; when a channel end is in FLUSHCOMPLETE, packets can only be received (when a channel end is in FLUSHCOMPLETE, all packets sent from that channel end should have completed their lifecycle).

For more information, please read the documentation and this blog post. If you want to adopt the fee middleware, please read this section of the documentation or follow this tutorial.

This feature has a been truly a tour de force for the IBC team at Interchain. Work started almost 2 years ago, with the writing of the first version of the upgrades spec, and we have been steadily working on it (while switching regularly to other priorities). We finally merged the feature branch just before the end of 2023 and in January we have been doing our due diligence to make sure the feature is secure. The feature is audited as well by Atredis Partners and we will share the audit report in due time.

Support for unordered channels in ICA

Currently, ICA only allows ordered channels, which causes the channel to close if a timeout occurs, forcing the user to reopen it. This release adds support for opening new ICA channels using unordered ordering, as well as upgrading existing ICA channels to use ordered ordering via channel ugpradability.

Highlights 🌟

Please see the v8.1.0 changelog for the full set of changes included in this release. We present here a summary of other relevant changes included in this release:

dependencies

• Cosmos SDK has been bumped to v0.50.3.
• CometBFT has been bumped to v0.38.2.

core

• The emission of events on erroneous IBC application callbacks was removed due to the huckleberry security advisory. Since then, many users have been unable to debug their IBC applications effectively causing a considerable uptick in support requests across many chains. In this release we are introducing re-enabling emission of events on erroneous IBC application callbacks by appending the prefix ibccallbackerror- to all event type and attribute keys.

apps/transfer

• A new field allowed_packet_data has been added to the Allocation type used for authz support of IBC transfers. This field is a list of MsgTransfer's memo packet data keys that are allowed to send the packet. If this list is empty, then only an empty memo is allowed. If this list includes a single element equal to "*", then all keys in the JSON-encoded memo field will be allowed. See the documentation for more information.

apps/27-interchain-accounts

• The maximum allowed length for the memo field of InterchainAccountPacketData has been increased to 32768.

Contributors ❤️

Special thanks to all external contributors that pushed code for this release:

• @chandiniv1
• @expertdicer
• @GNaD13
• @hieuvubk
• @mmsqe
• @ThanhNhann
• @sontrinh16
• @vishal-kanna

Migration 🦆

To learn more about ibc-go versioning, please read our RELEASES.md.

IMPORTANT: Please read the migration guides for any versions of ibc-go that you might be going through when upgrading to this version. For example: if you upgrade from the IBC module contained in the Cosmos SDK 0.42.0 to SDK v0.50.3 and ibc-go v8.1.0, please follow:

1. The migration from SDK 0.41.x or 0.42.x to the IBC module in the ibc-go repository based on the SDK v0.44.x.
2. The migration from ibc-go v1 to v2.
3. The migration from ibc-go v2 to v3.
4. The migration from ibc-go v3 to v4.
5. The migration from ibc-go v4 to v5.
6. The migration from ibc-go v5 to v6.
7. The migration from ibc-go v6 to v7.
8. The migration from ibc-go v7 to v7.1.
9. The migration from ibc-go v7.2 to v7.3.
10. The migration from ibc-go v7 to v8.
11. The migration from ibc-go v8 to v8.1.