Releases: cosmos/ibc-go
v9.0.1
We present here a summary of the most relevant changes, please see the v9.0.1 changelog for more details.
Testing
- #7430 Update the block proposer in test chains for each block.
Bug Fixes
- (core/03-connection) #7397 Skip the genesis validation connectionID for localhost client.
v8.5.2
v9.0.0
This release main additions are:
ICS20 v2
ICS20 v2 introduces two key features:
Multi-token transfers with a single packet
A new field tokens has been added to MsgTransfer and it can hold up to 100 tokens. The existing token field has been marked deprecated and will be removed in a future release.
Native packet forwarding and unwinding
Forwarding enables transferring tokens to a final destination through a set of intermediary chains, specified by the source port/channel identifiers. Native tokens or IBC vouchers on any chain can be forwarded through intermediary chains to reach their final destination. The multi-hop transfer route is specified in the new hops field in MsgTransfer as source port ID/channel ID pairs.
With unwinding it is possible to automatically return IBC vouchers back to their origin chain. For example, if a token was sent from A (origin) to C through B, unwinding means returning it from C back to A through B over the same channels they were initially sent over, so that the tokens recover their original denomination on chain A. Unwinding can be used by simply setting the new unwind boolean in MsgTransfer to true (multiple tokens can be unwound together if the all share the same denomination trace path, i.e. the set of destination port/channel identifiers where tokens have been received).
For more information, please read the transfer application documentation and the v9.0.0 launch blog post. To use the features of ICS20 v2, chains must upgrade the transfer channel version from ics20-1 to ics20-2 using channel upgradability. Please read the channel upgrades section of the documentation or follow this tutorial (it upgrades a channel to wire up fee middleware, but a similar process needs to be followed to upgrade a channel version). Please follow also the ICS20 v2 section of the migration documentation.
Protobuf encoding of packet data
ICS20 v2 introduces a new packet data type FungibleTokenPacketDataV2 that contains the forwarding information. If the transfer channel version is ics20-2 then the type FungibleTokenPacketDataV2 will be used to construct the packet data and it will be encoded using Protobuf (instead of JSON, which is used to encode packet data of type FungibleTokenPacketData when the channel version is ics20-1).
ICS20 v2 has been audited by Atredis Partners and the report is available here.
02-client routing refactor
We have refactored the routing at the 02-client layer by decoupling it from the encoding structures used by light clients (i.e. the implementation of the ClientState interface). The different light client implementations of the ClientState interface are not used anymore to route requests to the right light client at the 02-client layer. Instead, a light client module is registered for every light client type (tendermint, solomachine, etc.) and 02-client routes the requests to the right light client module based on the client ID. Light client developers must implement the newly introduced LightClientModule interface and are encouraged to move the logic implemented in the functions of their light client's implementation of the ClientState interface to the equivalent function in the LightClientModule interface. Please refer to the migration docs to see the equivalence between ClientState interface functions that have been removed and the functions in the LightClientModule interface, and check the light client developer guide for more information.
For more details about the features introduced in this release, please read the v9.0.0 announcement blog post.
Contributors ❤️
Special thanks to all external contributors that pushed code, improved documentation, testing or CI since our last major release:
- @vishal-kanna
- @chandiniv1
- @NisTun
- @healthyyyoung
- @hakuno2000
- @TropicalDog17
- @cratiu222
- @neitdung
- @lichdu29
- @lfgtwo
- @winniehere
- @lido333
- @jgscr
- @tiendn
- @Taztingo
- @trungnt1811
- @tianyeyouyou
- @tuantran1702
- @jjjike2021
- @MukulKolpe
- @GNaD13
- @argentpapa
- @tcpdumppy
- @BabyHalimao
- @suiyuan1314
- @polymaer
- @kien6034
- @ma68584703
- @icarus012832
- @hoank101
- @seay404
- @goofylfg
- @hoank101
- @careworry
- @akaladarshi
- @hoangdv2429
- @AtomicInnovation321
- @GNaD13
- @AdventureSeeker987
- @omahs
- @tungle-notional
- @zoereco
- @expertdicer
- @levisyin
- @keienWang
- @natebeauregard
- @phamminh0811
- @Halimao
- @sontrinh16
- @Frierened
- @vuittont60
- @bodhi-crypo
- @joaolago1113
- @yihuang
- @nnsW3
- @anhductn2001
- @sontrinh16
- @lukema95
- @ukema95
- @Ursulafe
- @0xstepit
- @mattverse
- @tbruyelle
- @shuoer86
- @muku314115
- @trinitys7
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.9 and ibc-go v9.0.0, 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.
- The migration from ibc-go v8 to v9.
Contributors
Assets 2
v8.5.1
This release fixes a panic that occurred during instantiation of the interchain accounts host keeper when populating the list of all module safe queries and port definitions were not found. The solution implemented is to use the cosmos/gogoproto registry instead of including the entire merged global files registry. Please check the v8.5.1 changelog for more details. Big thanks to @damiannolan for resolving this issue!
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.9 and ibc-go v8.5.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.
Contributors
Assets 11
v8.5.0
We present here a summary of the most relevant changes, please see the v8.5.0 changelog for more details. Please note that this release, as indicated in our release versioning policy, is state machine breaking and requires a coordinated upgrade.
dependencies
core/03-connection
- We have removed from the connection handshake the verification step that guaranteed that the client state and consensus state stored by the light client on the counterparty is a correct representation of the chain and its consensus state. Please check cosmos/ibc#1121 for more details and rationale.
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.9 and ibc-go v8.5.0, 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.
v7.8.0
We present here a summary of the most relevant changes, please see the v7.8.0 changelog for more details. Please note that this release, as indicated in our release versioning policy, is state machine breaking and requires a coordinated upgrade.
core/03-connection
- We have removed from the connection handshake the verification step that guaranteed that the client state and consensus state stored by the light client on the counterparty is a correct representation of the chain and its consensus state. Please check cosmos/ibc#1121 for more details and rationale.
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.47.13 and ibc-go v7.8.0, 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.
modules/light-clients/08-wasm/v0.4.1+ibc-go-v8.4-wasmvm-v2.0
This release amends the release of 08-wasm v0.4.0 with ibc-go v8.3 to bump the version of ibc-go to v8.4 as v8.3 was redacted. No additional commits have been made.
In order to use this release, please follow the steps to import git commit ccd4dc2.
modules/light-clients/08-wasm/v0.3.1+ibc-go-v7.4-wasmvm-v1.5
This release amends the release of 08-wasm v0.3.0 with ibc-go v7.3 to bump the version of ibc-go to v7.4 as v7.3 was redacted. No additional commits have been made.
In order to use this release, please follow the steps to import git commit 13c071f.
v8.4.0
We present here a summary of the most relevant changes, please see the v8.4.0 changelog for more details. Please note that this release, as indicated in our release versioning policy, is state machine breaking and requires a coordinated upgrade.
core/04-channel
- An extra check has been added to the
ChannelUpgradeConfirmhandler to make sure that the upgrades are compatible and thus prevent that an upgrade completes with channel ends in incompatible state. We have retracted v8.2.x and v8.3.x and all chains planning to use channel upgradability are strongly recommended to upgrade to this version. Thank you very much to @siburu and @bluele for responsibly reporting this bug through our bug bounty program.
apps/transfer
- If the
Amountof theTokenfield inMsgTransferis set to the maximum value for a 256-bit unsigned integer (i.e. 2^256 - 1), then the whole balance of the corresponding denomination will be transferred. The helper functionUnboundedSpendLimitin thetypespackage of thetransfermodule provides the sentinel value that can be used.
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.7 and ibc-go v8.4.0, 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.
Contributors
Assets 11
v7.7.0
We present here a summary of the most relevant changes, please see the v7.7.0 changelog for more details. Please note that this release, as indicated in our release versioning policy, is state machine breaking and requires a coordinated upgrade.
dependencies
- Cosmos SDK has been bumped to v0.47.13.
apps/transfer
- If the
Amountof theTokenfield inMsgTransferis set to the maximum value for a 256-bit unsigned integer (i.e. 2^256 - 1), then the whole balance of the corresponding denomination will be transferred. The helper functionUnboundedSpendLimitin thetypespackage of thetransfermodule provides the sentinel value that can be used.
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.47.13 and ibc-go v7.7.0, 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.