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.
