chore(deps): bump github.com/cosmos/ibc-go/v8 from 8.0.0 to 8.1.1

[dependabot]

Bumps github.com/cosmos/ibc-go/v8 from 8.0.0 to 8.1.1.

Release notes

Sourced from github.com/cosmos/ibc-go/v8's releases.

v8.1.1

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:

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.

v8.1.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 (TODO: add link when merged).

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 🌟

... (truncated)

Changelog

Sourced from github.com/cosmos/ibc-go/v8's changelog.

v8.1.1 - 2024-03-14

Improvements

• (proto) #5988 Add wasm proto files.

v8.1.0 - 2024-01-31

Dependencies

• #5663 Bump Cosmos SDK to v0.50.3 and CometBFT to v0.38.2.

State Machine Breaking

• (apps/27-interchain-accounts) #5442 Increase the maximum allowed length for the memo field of InterchainAccountPacketData.

Improvements

• (core/02-client) #5429 Add wildcard "*" to allow all clients in AllowedClients param.
• (core) #5541 Enable emission of events on erroneous IBC application callbacks by appending a prefix to all event type and attribute keys.

Features

• (core/04-channel) #1613 Channel upgradability.
• (apps/transfer) #5280 Add list of allowed packet data keys to Allocation of TransferAuthorization.
• (apps/27-interchain-accounts) #5633 Allow setting new and upgrading existing ICA (ordered) channels to use unordered ordering.

Bug Fixes

• (apps/27-interchain-accounts) #5343 Add check if controller is enabled in sendTx before sending packet to host.
• (apps/29-fee) #5441 Allow setting the relayer address as payee.

Commits

• a4ef536 update changelog before v8.1.1 release
• aa39fab add wasm protos to release/v8.1.x (#5988)
• 7e01c91 update changelog before v8.1.0 release
• 95b89bb imp: add defensive check on WriteErrorReceipt in addition to more in-line doc...
• 990ca9e fix: Write ErrorReceipt for previous upgrade on Reinitialization (#5732) (#5743)
• bc63fa5 ICS4: fix off by one error in non-crossing-hello case (#5722) (#5739)
• 1718cbe chore: refactor UpgradeError to use built in errors functions (#5704) (#5715)
• 64897d9 imp: modify error string to reflect actual behaviour in receive packet defens...
• e750262 test: add additional test for iterator on fee mw migration (#5667) (#5690)
• 1f7a5fb chore: remove OnChanUpgradeRestore callbacks and discard state changes on a...
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.