Merge branch 'main' into bundle-flushcomplete

.github/workflows/docker.yml

@@ -28,7 +28,7 @@ jobs:
         images: ${{ env.REGISTRY }}/cosmos/${{ env.IMAGE_NAME }}
 
     - name: Build Docker image
-      uses: docker/build-push-action@15560696de535e4014efeff63c48f16952e52dd1
+      uses: docker/build-push-action@1a162644f9a7e87d8f4b053101d1d9a712edc18c
       with:
         context: .
         tags: ${{ steps.meta.outputs.tags }}
@@ -46,7 +46,7 @@ jobs:
         password: ${{ secrets.GITHUB_TOKEN }}
 
     - name: Push Docker image
-      uses: docker/build-push-action@15560696de535e4014efeff63c48f16952e52dd1
+      uses: docker/build-push-action@1a162644f9a7e87d8f4b053101d1d9a712edc18c
       with:
         context: .
         push: true

.github/workflows/e2e-fork.yml

@@ -9,6 +9,11 @@ on:
       - '**.md'
       - 'LICENSE'
 
+# cancel workflows if a new one is triggered on the same branch.
+concurrency:
+  group: ${{ github.ref }}
+  cancel-in-progress: ${{ github.ref != 'refs/heads/main' }}
+
 jobs:
   # dynamically build a matrix of test/test suite pairs to run
   build-test-matrix:

.github/workflows/e2e-test-workflow-call.yml

@@ -127,7 +127,7 @@ jobs:
 
       - name: Build and push Docker image
         if: ${{ inputs.build-and-push-docker-image }}
-        uses: docker/build-push-action@15560696de535e4014efeff63c48f16952e52dd1
+        uses: docker/build-push-action@1a162644f9a7e87d8f4b053101d1d9a712edc18c
         with:
           context: .
           push: true
@@ -174,7 +174,7 @@ jobs:
 
       - name: Build and push Docker image
         if: ${{ inputs.build-and-push-docker-image-wasm }}
-        uses: docker/build-push-action@15560696de535e4014efeff63c48f16952e52dd1
+        uses: docker/build-push-action@1a162644f9a7e87d8f4b053101d1d9a712edc18c
         with:
           context: .
           push: true

.github/workflows/e2e-wasm.yaml

@@ -17,6 +17,11 @@ on:
       # trigger workflow if PR is marked ready for review.
       - ready_for_review
 
+# cancel workflows if a new one is triggered on the same branch.
+concurrency:
+  group: ${{ github.ref }}
+  cancel-in-progress: ${{ github.ref != 'refs/heads/main' }}
+
 jobs:
   # determine-image-tag will either output the PR number e.g. pr-1234 or the string main.
   # this will be used to tag the images that are built during the workflow.

.github/workflows/e2e.yaml

@@ -16,6 +16,10 @@ on:
       - 'docs/**'
       - '**.md'
       - 'LICENSE'
+# cancel workflows if a new one is triggered on the same branch.
+concurrency:
+  group: ${{ github.ref }}
+  cancel-in-progress: ${{ github.ref != 'refs/heads/main' }}
 
 jobs:
   # determine-image-tag will either output the PR number e.g. pr-1234 or the string main.

.github/workflows/release.yml

@@ -52,7 +52,7 @@ jobs:
           images: ${{ env.REGISTRY }}/cosmos/${{ env.IMAGE_NAME }}
 
       - name: Build and push Docker image
-        uses: docker/build-push-action@15560696de535e4014efeff63c48f16952e52dd1
+        uses: docker/build-push-action@1a162644f9a7e87d8f4b053101d1d9a712edc18c
         with:
           context: .
           push: true

CHANGELOG.md

@@ -40,7 +40,7 @@ Ref: https://keepachangelog.com/en/1.0.0/
 
 * [\#6193](https://github.com/cosmos/ibc-go/pull/6193) Bump Cosmos SDK to v0.50.7.
 * [\#6193](https://github.com/cosmos/ibc-go/pull/6193) Bump `cosmossdk.io/store` to v1.1.0.
-* [\#6720](https://github.com/cosmos/ibc-go/pull/6720) Bump CometBFT to v0.38.8.
+* [\#6737](https://github.com/cosmos/ibc-go/pull/6737) Bump CometBFT to v0.38.9.
 * [\#6380](https://github.com/cosmos/ibc-go/pull/6380) Bump go to v1.22.
 
 ### API Breaking
@@ -59,7 +59,9 @@ Ref: https://keepachangelog.com/en/1.0.0/
 * (apps/transfer) [\#6440](https://github.com/cosmos/ibc-go/pull/6440) Remove `GetPrefixedDenom`.
 * (apps/transfer) [\#6508](https://github.com/cosmos/ibc-go/pull/6508) Remove the `DenomTrace` type.
 * (apps/27-interchain-accounts) [\#6598](https://github.com/cosmos/ibc-go/pull/6598) Mark the `requests` repeated field of `MsgModuleQuerySafe` non-nullable.
+* (23-commmitment) [\#6644](https://github.com/cosmos/ibc-go/pull/6644) Introduce commitment/v2 `MerklePath` to include `repeated bytes` in favour of `repeated string`. This supports using merkle path keys which include non UTF-8 encoded runes.
 * (23-commmitment) [\#6633](https://github.com/cosmos/ibc-go/pull/6633) MerklePath has been changed to use `repeated bytes` in favour of `repeated strings`.
+* (apps/27-interchain-accounts) [\#6749](https://github.com/cosmos/ibc-go/pull/6749) The ICA controller `NewIBCMiddleware` constructor function sets by default the auth module to nil.
 
 ### State Machine Breaking
 

docs/architecture/adr-009-v6-ics27-msgserver.md

@@ -12,13 +12,13 @@ Accepted, implemented in v6 of ibc-go
 
 ICS 27 (Interchain Accounts) brought a cross-chain account management protocol built upon IBC.
 It enabled chains to programmatically create accounts on behalf of counterparty chains which may enable a variety of authentication methods for this interchain account.
-The initial release of ICS 27 focused on enabling authentication schemes which may not require signing with a private key, such as via on-chain mechanisms like governance.
+The initial release of ICS 27 focused on enabling authentication schemes that may not require signing with a private key, such as via on-chain mechanisms like governance.
 
 Following the initial release of ICS 27 it became evident that:
 
 - a default authentication module would enable more usage of ICS 27
 - generic authentication modules should be capable of authenticating an interchain account registration
-- application logic which wraps ICS 27 packet sends do not need to be associated with the authentication logic
+- application logic which wraps ICS 27 packet sends does not need to be associated with the authentication logic
 
 ## Decision
 

docs/architecture/adr-015-ibc-packet-receiver.md

@@ -10,7 +10,7 @@
 
 In ICS 26, the routing module is defined as a layer above each application module
 which verifies and routes messages to the destination modules. It is possible to
-implement it as a separate module, however, we already have functionality to route
+implement it as a separate module, however, we already have the functionality to route
 messages upon the destination identifiers in the baseapp. This ADR suggests
 to utilize existing `baseapp.router` to route packets to application modules.
 

docs/architecture/adr-026-ibc-client-recovery-mechanisms.md

@@ -18,7 +18,7 @@
 
 ### Summary
 
-At launch, IBC will be a novel protocol, without an experienced user-base. At the protocol layer, it is not possible to distinguish between client expiry or misbehaviour due to genuine faults (Byzantine behavior) and client expiry or misbehaviour due to user mistakes (failing to update a client, or accidentally double-signing). In the base IBC protocol and ICS 20 fungible token transfer implementation, if a client can no longer be updated, funds in that channel will be permanently locked and can no longer be transferred. To the degree that it is safe to do so, it would be preferable to provide users with a recovery mechanism which can be utilised in these exceptional cases.
+At launch, IBC will be a novel protocol, without an experienced user-base. At the protocol layer, it is not possible to distinguish between client expiry or misbehaviour due to genuine faults (Byzantine behaviour) and client expiry or misbehaviour due to user mistakes (failing to update a client, or accidentally double-signing). In the base IBC protocol and ICS 20 fungible token transfer implementation, if a client can no longer be updated, funds in that channel will be permanently locked and can no longer be transferred. To the degree that it is safe to do so, it would be preferable to provide users with a recovery mechanism which can be utilised in these exceptional cases.
 
 ### Exceptional cases
 

docs/architecture/adr-027-ibc-wasm.md

@@ -29,7 +29,7 @@ client is part of its codebase), re-build chains' binaries, pass a governance pr
 
 Another problem stemming from the above process is that if a chain wants to upgrade its own consensus, it will 
 need to convince every chain or hub connected to it to upgrade its light client in order to stay connected. Due 
-to the time consuming process required to upgrade a light client, a chain with lots of connections needs to be 
+to the time-consuming process required to upgrade a light client, a chain with lots of connections needs to be 
 disconnected for quite some time after upgrading its consensus, which can be very expensive in terms of time and effort.
 
 We are proposing simplifying this workflow by integrating a Wasm light client module that makes adding support for

docs/architecture/adr.template.md

@@ -12,7 +12,7 @@
 
 ## Context
 
-> This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high level idea behind the solution.
+> This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high-level idea behind the solution.
 
 ## Decision
 

docs/docs/02-apps/02-interchain-accounts/04-integration.md

@@ -104,7 +104,7 @@ app.ICAAuthKeeper = icaauthkeeper.NewKeeper(appCodec, keys[icaauthtypes.StoreKey
 icaAuthModule := icaauth.NewAppModule(appCodec, app.ICAAuthKeeper)
 
 // Create controller IBC application stack and host IBC module as desired
-icaControllerStack := icacontroller.NewIBCMiddleware(nil, app.ICAControllerKeeper)
+icaControllerStack := icacontroller.NewIBCMiddleware(app.ICAControllerKeeper)
 icaHostIBCModule := icahost.NewIBCModule(app.ICAHostKeeper)
 
 // Register host and authentication routes
@@ -194,7 +194,7 @@ icaModule := ica.NewAppModule(&app.ICAControllerKeeper, nil)
 ...
 
 // Create controller IBC application stack
-icaControllerStack := icacontroller.NewIBCMiddleware(nil, app.ICAControllerKeeper)
+icaControllerStack := icacontroller.NewIBCMiddleware(app.ICAControllerKeeper)
 
 // Register controller route
 ibcRouter.AddRoute(icacontrollertypes.SubModuleName, icaControllerStack)

docs/docs/02-apps/02-interchain-accounts/10-legacy/02-integration.md

@@ -110,7 +110,7 @@ icaAuthModule := icaauth.NewAppModule(appCodec, app.ICAAuthKeeper)
 icaAuthIBCModule := icaauth.NewIBCModule(app.ICAAuthKeeper)
 
 // Create controller IBC application stack and host IBC module as desired
-icaControllerStack := icacontroller.NewIBCMiddleware(icaAuthIBCModule, app.ICAControllerKeeper)
+icaControllerStack := icacontroller.NewIBCMiddlewareWithAuth(icaAuthIBCModule, app.ICAControllerKeeper)
 icaHostIBCModule := icahost.NewIBCModule(app.ICAHostKeeper)
 
 // Register host and authentication routes
@@ -192,7 +192,7 @@ icaAuthModule := icaauth.NewAppModule(appCodec, app.ICAAuthKeeper)
 icaAuthIBCModule := icaauth.NewIBCModule(app.ICAAuthKeeper)
 
 // Create controller IBC application stack
-icaControllerStack := icacontroller.NewIBCMiddleware(icaAuthIBCModule, app.ICAControllerKeeper)
+icaControllerStack := icacontroller.NewIBCMiddlewareWithAuth(icaAuthIBCModule, app.ICAControllerKeeper)
 
 // Register controller and authentication routes
 ibcRouter.

docs/docs/03-light-clients/02-localhost/01-overview.md

@@ -14,33 +14,43 @@ slug: /ibc/light-clients/localhost/overview
 Learn about the 09-localhost light client module.
 :::
 
-The 09-localhost light client module implements a localhost loopback client with the ability to send and receive IBC packets to and from the same state machine.
+The 09-localhost light client module implements a stateless localhost loopback client with the ability to send and
+receive IBC packets to and from the same state machine.
 
 ### Context
 
-In a multichain environment, application developers will be used to developing cross-chain applications through IBC. From their point of view, whether or not they are interacting with multiple modules on the same chain or on different chains should not matter. The localhost client module enables a unified interface to interact with different applications on a single chain, using the familiar IBC application layer semantics.
+In a multichain environment, application developers will be used to developing cross-chain applications through IBC.
+From their point of view, whether or not they are interacting with multiple modules on the same chain or on different
+chains should not matter. The localhost client module enables a unified interface to interact with different
+applications on a single chain, using the familiar IBC application layer semantics.
 
 ### Implementation
 
-There exists a [single sentinel `ClientState`](03-client-state.md) instance with the client identifier `09-localhost`.
+There exists a localhost light client module which can be invoked with the client identifier `09-localhost`. The light
+client is stateless, so the `ClientState` is constructed on demand when required.
 
-To supplement this, a [sentinel `ConnectionEnd` is stored in core IBC](04-connection.md) state with the connection identifier `connection-localhost`. This enables IBC applications to create channels directly on top of the sentinel connection which leverage the 09-localhost loopback functionality.
+To supplement this, a [sentinel `ConnectionEnd` is stored in core IBC](04-connection.md) state with the connection
+identifier `connection-localhost`. This enables IBC applications to create channels directly on top of the sentinel
+connection which leverage the 09-localhost loopback functionality.
 
-[State verification](05-state-verification.md) for channel state in handshakes or processing packets is reduced in complexity, the `09-localhost` client can simply compare bytes stored under the standardized key paths.
+[State verification](05-state-verification.md) for channel state in handshakes or processing packets is reduced in
+complexity, the `09-localhost` client can simply compare bytes stored under the standardized key paths.
 
 ### Localhost vs *regular* client
 
-The localhost client aims to provide a unified approach to interacting with applications on a single chain, as the IBC application layer provides for cross-chain interactions. To achieve this unified interface though, there are a number of differences under the hood compared to a 'regular' IBC client (excluding `06-solomachine` and `09-localhost` itself).
+The localhost client aims to provide a unified approach to interacting with applications on a single chain, as the IBC
+application layer provides for cross-chain interactions. To achieve this unified interface though, there are a number of
+differences under the hood compared to a 'regular' IBC client (excluding `06-solomachine` and `09-localhost` itself).
 
 The table below lists some important differences:
 
-|                                              | Regular client | Localhost |
-| -------------------------------------------- | --------------------------------------------------------------------------- | --------- |
-| Number of clients                            | Many instances of a client *type* corresponding to different counterparties | A single sentinel client with the client identifier `09-localhost`|
-| Client creation                              | Relayer (permissionless) | `ClientState` is instantiated in the `InitGenesis` handler of the 02-client submodule in core IBC |
-| Client updates                               | Relayer submits headers using `MsgUpdateClient` | Latest height is updated periodically through the ABCI [`BeginBlock`](https://docs.cosmos.network/v0.47/building-modules/beginblock-endblock) interface of the 02-client submodule in core IBC |
-| Number of connections                        | Many connections, 1 (or more) per client | A single sentinel connection with the connection identifier `connection-localhost` |
-| Connection creation                          | Connection handshake, provided underlying client | Sentinel `ConnectionEnd` is created and set in store in the `InitGenesis` handler of the 03-connection submodule in core IBC |
-| Counterparty                                 | Underlying client, representing another chain | Client with identifier `09-localhost` in same chain |
-| `VerifyMembership` and `VerifyNonMembership` | Performs proof verification using consensus state roots | Performs state verification using key-value lookups in the core IBC store |
-| Integration | Expected to register codec types using the `AppModuleBasic` interface | Registers codec types within the core IBC module |
+|                                              | Regular client                                                              | Localhost                                                                                                                    |
+|----------------------------------------------|-----------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------|
+| Number of clients                            | Many instances of a client *type* corresponding to different counterparties | A single sentinel client with the client identifier `09-localhost`                                                           |
+| Client creation                              | Relayer (permissionless)                                                    | Implicitly made available by the 02-client submodule in core IBC                                                             |
+| Client updates                               | Relayer submits headers using `MsgUpdateClient`                             | No client updates are required as the localhost implementation is stateless                                                  |
+| Number of connections                        | Many connections, 1 (or more) per client                                    | A single sentinel connection with the connection identifier `connection-localhost`                                           |
+| Connection creation                          | Connection handshake, provided underlying client                            | Sentinel `ConnectionEnd` is created and set in store in the `InitGenesis` handler of the 03-connection submodule in core IBC |
+| Counterparty                                 | Underlying client, representing another chain                               | Client with identifier `09-localhost` in same chain                                                                          |
+| `VerifyMembership` and `VerifyNonMembership` | Performs proof verification using consensus state roots                     | Performs state verification using key-value lookups in the core IBC store                                                    |
+| `ClientState` storage                        | `ClientState` stored and directly provable with `VerifyMembership`          | Stateless, so `ClientState` is not provable directly with `VerifyMembership`                                                 |