Releases · cosmos/ibc-go

05 Apr 12:01

v4.6.0

5480cf7

v4.6.0

This release includes a fix for the ASA-2024-007 security advisory. Credits to Maxwell Dulin (@mdulin2) at Asymmetric Research for the discovery and disclosure via our bug bounty program.

Please note that this release, as indicated in our release versioning policy, is state machine breaking and requires a coordinated upgrade.

Please see the v4.6.0 changelog for the full set of changes included in this release.

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.45.16 and ibc-go v4.6.0, please follow:

Contributors

mdulin2

Assets 11

14 Mar 14:29

crodriguezvega

v8.1.1

a4ef536

v8.1.1

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 only adds the proto files for the 08-wasm module, so that this release can be imported in ibc-proto-rs. See #5988 for more details.

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.1, please follow:

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.
The migration from ibc-go v1 to v2.
The migration from ibc-go v2 to v3.
The migration from ibc-go v3 to v4.
The migration from ibc-go v4 to v5.
The migration from ibc-go v5 to v6.
The migration from ibc-go v6 to v7.
The migration from ibc-go v7 to v7.1.
The migration from ibc-go v7.2 to v7.3.
The migration from ibc-go v7 to v8.
The migration from ibc-go v8 to v8.1.

Assets 11

31 Jan 08:51

crodriguezvega

v8.1.0

7e01c91

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:

Migration 🦆

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

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.
The migration from ibc-go v1 to v2.
The migration from ibc-go v2 to v3.
The migration from ibc-go v3 to v4.
The migration from ibc-go v4 to v5.
The migration from ibc-go v5 to v6.
The migration from ibc-go v6 to v7.
The migration from ibc-go v7 to v7.1.
The migration from ibc-go v7.2 to v7.3.
The migration from ibc-go v7 to v8.
The migration from ibc-go v8 to v8.1.

Contributors

mmsqe, ThanhNhann, and 6 other contributors

Assets 11

31 Jan 08:34

crodriguezvega

v8.0.1

73d28ab

v8.0.1

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.

We present here a summary of the most relevant changes, please see the v8.0.1 changelog for the full set of 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.

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

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.
The migration from ibc-go v1 to v2.
The migration from ibc-go v2 to v3.
The migration from ibc-go v3 to v4.
The migration from ibc-go v4 to v5.
The migration from ibc-go v5 to v6.
The migration from ibc-go v6 to v7.
The migration from ibc-go v7 to v7.1.
The migration from ibc-go v7.2 to v7.3.
The migration from ibc-go v7 to v8.

Assets 11

31 Jan 08:32

crodriguezvega

v7.3.2

747eb6f

v7.3.2

UPDATES

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

We present here a summary of the most relevant changes, please see the v7.3.2 changelog for the full set of changes included in this release.

dependencies

Cosmos SDK has been bumped to v0.47.8.
CometBFT has been bumped to v0.37.4.

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.

Special thanks to our external contributors in this release: @emidev98

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

Contributors

emidev98

Assets 11

31 Jan 08:29

crodriguezvega

v7.2.3

d94d690

v7.2.3

UPDATES

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

We present here a summary of the most relevant changes, please see the v7.2.3 changelog for the full set of changes included in this release.

dependencies

Cosmos SDK has been bumped to v0.47.8.
CometBFT has been bumped to v0.37.4.

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.

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

Assets 11

18 Dec 09:00

crodriguezvega

modules/light-clients/08-wasm/v0.1.0+ibc-go-v8.0-wasmvm-v1.5

57fcdb9

modules/light-clients/08-wasm/v0.1.0+ibc-go-v8.0-wasmvm-v1.5

This is the first release (compatible with ibc-go v8.0) of the anticipated 🥁🎺 08-wasm light client proxy module 🌈🤩
Read the blog post by @adiraviraj announcing the release, for more information.

What is the 08-wasm module?

The 08-wasm client module comprises a Wasm VM capable of hosting light client bytecode, offering the flexibility to write new light clients in any language that compiles to Wasm (Rust, C/C++, JS, Go, etc.). With a consistent interface aligned with ICS 02, this module serves as a proxy light client, facilitating interaction with the actual light client contracts deployed as Wasm bytecode. To learn more about what it means to be a proxu light client, please read this section of the documentation.

Why do we need it?

The expansion of IBC into new blockchain ecosystems necessitates adding support for new light clients. Light clients for non-Cosmos ecosystem chains are, in many cases, implemented in Rust, and thus there are probably libraries used in their light client implementations for which there is no equivalent in Go. This makes the development of a light client in Go very difficult, but relatively simple to do it in Rust. Therefore, writing a CosmWasm smart contract in Rust that implements the light client algorithm becomes a lower effort. However, The light client can actually be implemented in any language that compiles to Wasm and implements the interfaces of a CosmWasm contract. Even though in theory other languages could be used, in practice (at least for the time being) the most suitable language to use would be Rust, since there is already good support for it for developing CosmWasm smart contracts.

At the moment of this release there are two contracts available: one for Tendermint and one GRANDPA (which is being used in production in Composable Finance's Centauri bridge). And there are others in development (e.g. for Near).

How can I use it?

First the 08-wasm module needs to be integrated in the chain. For more details about how to integrate the module in your own chain, please read this section of the documentation. Then, adding a new light client to a chain is just as simple as submitting a governance proposal with the message that stores the byte code of the light client contract. No coordinated upgrade is needed. When the governance proposal passes and the message is executed, the contract is ready to be instantiated upon receiving a relayer-submitted MsgCreateClient. The process of creating a Wasm light client is the same as with a regular light client implemented in Go. Please read this section of the documentation, for more information.

Our e2e tests used the GRANDPA contract at this hash of Composable Finance's composable-ibc repository. To build the bytecode for the contract we have followed these steps:

# set up environment
rustup toolchain install nightly
rustup target add wasm32-unknown-unknown
rustup +nightly target add wasm32-unknown-unknown
cargo install wasm-opt --locked

# build and optimise contract
cd light-clients/ics10-grandpa-cw
RUSTFLAGS='-C link-arg=-s' cargo build -p ics10-grandpa-cw --target=wasm32-unknown-unknown --release --lib
wasm-opt -Os ../../target/wasm32-unknown-unknown/release/ics10_grandpa_cw.wasm -o ics10_grandpa_cw.wasm

# gzip
gzip ics10_grandpa_cw.wasm

Who developed this breakthrough innovation?

Lets go down the memory lane and talk about the history of this module... In 2021 the Chorus One team submitted the ICS 08 spec with a design that was implemented also by them, but never got merged in ibc-go. Then at the end of 2022 Composable Finance took over the initial ICS 08 spec written by Chorus One and updated it with a new design. Composable Finance teamed up with Strangelove, who re-booted the implementation based on the new design. Then in July 2023, Strangelove opened the PR to upstream the module to ibc-go. Strangelove and the IBC team at Interchain GmbH had already started collaborating on the upstreaming process at the beginning of 2023, and after the PR was merged the IBC team continued improving the module based on their own feedback and an audit by Ethan Frey and Confio GmbH. And that's how we got here!

Shout-outs are passionately given to:

From Composable: @blasrodri and @vmarkushin, for coming up with the new design and writing the GRANDPA contract that enables direct connection to the Polkadot ecosystem.
From Strangelove: @jackzampolin (for taking up the challenge of re-booting the implementation of the module) and @misko9 (for implementing the module, for his support along the upstreaming process and for always being there to help us and answer our questions).
@ethanfrey, for auditing the implementation and providing increadibly useful feedback.
From Confio: @webmaster128 (for taking to the finish line the audit started by Ethan Frey) and @alpe (for answering many Wasm-related questions we had in this journey).

And last, but not least, to each and everyone in the IBC team at Interchain GmbH: @adiraviraj @AdityaSripal @colin-axner @charleenfei @chatton @damiannolan @DimitrisJim @sangier @srdtrk @womensrights @zadkiel88. Everyone moved mountains and poured blood, sweat and tears to elevate this module to the team's high quality standards of product, engineering and marketing.

Contributors ❤️

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

Contributors

alpe, vmarkushin, and 26 other contributors

Assets 2

18 Dec 09:00

crodriguezvega

modules/light-clients/08-wasm/v0.1.0+ibc-go-v7.3-wasmvm-v1.5

b306e7a

modules/light-clients/08-wasm/v0.1.0+ibc-go-v7.3-wasmvm-v1.5

This is the first release (compatible with ibc-go v7.3) of the anticipated 🥁🎺 08-wasm light client proxy module 🌈🤩
Read the blog post by @adiraviraj announcing the release, for more information.

What is the 08-wasm module?

Why do we need it?

How can I use it?

Our e2e tests used the GRANDPA contract at this hash of Composable Finance's composable-ibc repository. To build the bytecode for the contract we have followed these steps:

# set up environment
rustup toolchain install nightly
rustup target add wasm32-unknown-unknown
rustup +nightly target add wasm32-unknown-unknown
cargo install wasm-opt --locked

# build and optimise contract
cd light-clients/ics10-grandpa-cw
RUSTFLAGS='-C link-arg=-s' cargo build -p ics10-grandpa-cw --target=wasm32-unknown-unknown --release --lib
wasm-opt -Os ../../target/wasm32-unknown-unknown/release/ics10_grandpa_cw.wasm -o ics10_grandpa_cw.wasm

# gzip
gzip ics10_grandpa_cw.wasm

Who developed this breakthrough innovation?

Shout-outs are passionately given to:

From Composable: @blasrodri and @vmarkushin, for coming up with the new design and writing the GRANDPA contract that enables direct connection to the Polkadot ecosystem.
From Strangelove: @jackzampolin (for taking up the challenge of re-booting the implementation of the module) and @misko9 (for implementing the module, for his support along the upstreaming process and for always being there to help us and answer our questions).
@ethanfrey, for auditing the implementation and providing increadibly useful feedback.
From Confio: @webmaster128 (for taking to the finish line the audit started by Ethan Frey) and @alpe (for answering many Wasm-related questions we had in this journey).

Contributors ❤️

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

Contributors

alpe, vmarkushin, and 26 other contributors

Assets 2

15 Nov 09:37

crodriguezvega

modules/apps/callbacks/v0.2.0+ibc-go-v8.0

342c00b

modules/apps/callbacks/v0.2.0+ibc-go-v8.0

This release bumps ibc-go to v8.0.0 and introduces two fixes:

The event that is emitted when the callback cannot be executed due to a panic or an out of gas error indicates now that an error occurred.
The packet is not be sent unless the IBCSendPacketCallback returns nil explicitly (see this issue for more information).

Please also note that this release requires a coordinated upgrade.

Assets 2

10 Nov 08:13

crodriguezvega

v8.0.0

2551dea

v8.0.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:

Cosmos SDK v0.50 upgrade

We have upgraded to Cosmos SDK v0.50.1 and CometBFT v0.38.

Migration of gov proposals from v1beta1 to v1

Governance proposals based on Cosmos SDK version v1beta1 of the x/gov module have been migrated to v1 messages. The proposal ClientUpdateProposal has been deprecated and MsgRecoverClient should be used instead. Likewise, the proposal UpgradeProposal has been deprecated and MsgIBCSoftwareUpgrade should be used instead. Both proposals will be removed in the next major release.

MsgRecoverClient and MsgIBCSoftwareUpgrade will only be allowed to be executed if the signer is the authority designated at the time of instantiating the IBC keeper. So please make sure that the correct authority is provided to the IBC keeper.

Migration of params to be self managed

Params of all modules are now self-managed. Each module has a corresponding MsgUpdateParams message with a field of type Params that can be specified in full to update the module's params.

Legacy params subspaces must still be initialised in app.go in order to successfully migrate from x/params to the new self-contained approach. See this code sample for more information.

For new chains which do not rely on migration of parameters from x/params, an expected interface has been added for each module. This allows chain developers to provide nil as the legacySubspace argument to NewKeeper functions.

Highlights 🌟

Please see the v8.0.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.1.
CometBFT has been bumped to v0.38.

apps/transfer

Length validation has been added to the Receiver and Memo fields of MsgTransfer.

We are now using Cosmos SDK x/bank's Metadata to store metadata for IBC vouchers when they are minted for the first time. Cosmos SDK v0.50 introduces the boolean field resolve_denom to QueryAllBalancesRequest and the flag resolve-denom in the query bank balances CLI command. When specified in the balances query, and if there exists metadata for the IBC vouchers in the balance of the account, the denomination displayed for IBC vouchers will not be the regular denomination of the form ibc/<hash>, but a human-readable denomination with full prefix trace path and the token denomination on the source chain.

For example, when using the query bank balances CLI command before the resolve-denom flag was available, the denomination for IBC vouchers displayed like this:

> simd query bank balances cosmos14wajutn6hcph9u8zl6j9c4l5cduwpqwmu3g7nt \
  --node http://localhost:27010
balances:
- amount: "100"
  denom: ibc/27A6394C3F9FF9C9DCF5DFFADF9BB5FE9A37C7E92B006199894CF1824DF9AC7C
- amount: "100000000"
  denom: samoleans
- amount: "99998941"
  denom: stake
pagination:
  next_key: ""
  total: "3"

But from ibc-go v8.0.0, when using the resolve-denom flag, the denomination for IBC vouchers will be displayed like this:

> simd query bank balances cosmos14wajutn6hcph9u8zl6j9c4l5cduwpqwmu3g7nt --resolve-denom \
  --node http://localhost:27010
balances:
- amount: "100"
  denom: transfer/channel-0/samoleans
- amount: "100000000"
  denom: samoleans
- amount: "99998941"
  denom: stake
pagination:
  next_key: ""
  total: "3"

Note that the denomination for the IBC voucher displays now as transfer/channel-0/samoleans.

We have also implemented an automatic migration handler to set the denomination metadata for the IBC denominations of all vouchers minted by the transfer module. Therefore, the human-readable denomination will be available for all previously minted IBC vouchers.

apps/27-interchain-accounts

An encoding parameter has been added to SerializeCosmosTx and DeserializeCosmosTx to specify the encoding format of the messages. Currently supported values are proto3 and proto3json.
Length validation has been added to the Owner field of MsgRegisterInterchainAccount and the Owner field of MsgSendTx.