Merge branch 'main' into carlos/deps-bump-wasmvm-v2.0

.github/workflows/build-callbacks-simd-image-from-tag.yml

@@ -22,7 +22,7 @@ jobs:
             ref: "${{ env.GIT_TAG }}"
             fetch-depth: 0
          - name: Log in to the Container registry
-           uses: docker/login-action@343f7c4344506bcbf9b4de18042ae17996df046d
+           uses: docker/login-action@e92390c5fb421da1463c202d546fed0ec5c39f20
            with:
               registry: ${{ env.REGISTRY }}
               username: ${{ github.actor }}

.github/workflows/build-simd-image-from-tag.yml

@@ -26,7 +26,7 @@ jobs:
             ref: "${{ env.GIT_TAG }}"
             fetch-depth: 0
          - name: Log in to the Container registry
-           uses: docker/login-action@343f7c4344506bcbf9b4de18042ae17996df046d
+           uses: docker/login-action@e92390c5fb421da1463c202d546fed0ec5c39f20
            with:
               registry: ${{ env.REGISTRY }}
               username: ${{ github.actor }}

.github/workflows/build-wasm-simd-image-from-tag.yml

@@ -27,7 +27,7 @@ jobs:
          - name: Install dependencies
            run: make python-install-deps
          - name: Log in to the Container registry
-           uses: docker/login-action@343f7c4344506bcbf9b4de18042ae17996df046d
+           uses: docker/login-action@e92390c5fb421da1463c202d546fed0ec5c39f20
            with:
               registry: ${{ env.REGISTRY }}
               username: ${{ github.actor }}

.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@af5a7ed5ba88268d5278f7203fb52cd833f66d6e
+      uses: docker/build-push-action@2cdde995de11925a030ce8070c3d77a52ffcf1c0
       with:
         context: .
         tags: ${{ steps.meta.outputs.tags }}
@@ -39,14 +39,14 @@ jobs:
       run: |
         docker run --rm ${{ steps.meta.outputs.tags }}
     - name: Log in to the Container registry
-      uses: docker/login-action@343f7c4344506bcbf9b4de18042ae17996df046d
+      uses: docker/login-action@e92390c5fb421da1463c202d546fed0ec5c39f20
       with:
         registry: ${{ env.REGISTRY }}
         username: ${{ github.actor }}
         password: ${{ secrets.GITHUB_TOKEN }}
 
     - name: Push Docker image
-      uses: docker/build-push-action@af5a7ed5ba88268d5278f7203fb52cd833f66d6e
+      uses: docker/build-push-action@2cdde995de11925a030ce8070c3d77a52ffcf1c0
       with:
         context: .
         push: true

.github/workflows/e2e-compatibility-unreleased.yaml

@@ -22,7 +22,7 @@ jobs:
           ref: "${{ matrix.release-branch }}"
           fetch-depth: 0
       - name: Log in to the Container registry
-        uses: docker/login-action@343f7c4344506bcbf9b4de18042ae17996df046d
+        uses: docker/login-action@e92390c5fb421da1463c202d546fed0ec5c39f20
         with:
           registry: ${{ env.REGISTRY }}
           username: ${{ github.actor }}

.github/workflows/e2e-compatibility.yaml

@@ -56,7 +56,7 @@ jobs:
           fetch-depth: 0
       - name: Log in to the Container registry
         if: env.RELEASE_BRANCH == matrix.release-branch
-        uses: docker/login-action@343f7c4344506bcbf9b4de18042ae17996df046d
+        uses: docker/login-action@e92390c5fb421da1463c202d546fed0ec5c39f20
         with:
           registry: ${{ env.REGISTRY }}
           username: ${{ github.actor }}

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

@@ -112,7 +112,7 @@ jobs:
         if: ${{ inputs.build-and-push-docker-image }}
       - name: Log in to the Container registry
         if: ${{ inputs.build-and-push-docker-image }}
-        uses: docker/login-action@343f7c4344506bcbf9b4de18042ae17996df046d
+        uses: docker/login-action@e92390c5fb421da1463c202d546fed0ec5c39f20
         with:
           registry: ${{ env.REGISTRY }}
           username: ${{ github.actor }}
@@ -127,7 +127,7 @@ jobs:
 
       - name: Build and push Docker image
         if: ${{ inputs.build-and-push-docker-image }}
-        uses: docker/build-push-action@af5a7ed5ba88268d5278f7203fb52cd833f66d6e
+        uses: docker/build-push-action@2cdde995de11925a030ce8070c3d77a52ffcf1c0
         with:
           context: .
           push: true
@@ -159,7 +159,7 @@ jobs:
 
       - name: Log in to the Container registry
         if: ${{ inputs.build-and-push-docker-image-wasm }}
-        uses: docker/login-action@343f7c4344506bcbf9b4de18042ae17996df046d
+        uses: docker/login-action@e92390c5fb421da1463c202d546fed0ec5c39f20
         with:
           registry: ${{ env.REGISTRY }}
           username: ${{ github.actor }}
@@ -174,7 +174,7 @@ jobs:
 
       - name: Build and push Docker image
         if: ${{ inputs.build-and-push-docker-image-wasm }}
-        uses: docker/build-push-action@af5a7ed5ba88268d5278f7203fb52cd833f66d6e
+        uses: docker/build-push-action@2cdde995de11925a030ce8070c3d77a52ffcf1c0
         with:
           context: .
           push: true

.github/workflows/markdown-lint.yml

@@ -13,7 +13,7 @@ jobs:
     - uses: actions/checkout@v4
       with:
         fetch-depth: 0
-    - uses: tj-actions/changed-files@v42
+    - uses: tj-actions/changed-files@v43
       id: changed-files
       with:
         files: '**/*.md'

.github/workflows/release-wasm.yml

@@ -35,7 +35,7 @@ jobs:
       - name: Install dependencies
         run: make python-install-deps
       - name: Log in to the Container registry
-        uses: docker/login-action@343f7c4344506bcbf9b4de18042ae17996df046d
+        uses: docker/login-action@e92390c5fb421da1463c202d546fed0ec5c39f20
         with:
           registry: ${{ env.REGISTRY }}
           username: ${{ github.actor }}

.github/workflows/release.yml

@@ -39,7 +39,7 @@ jobs:
         uses: actions/checkout@v4
 
       - name: Log in to the Container registry
-        uses: docker/login-action@343f7c4344506bcbf9b4de18042ae17996df046d
+        uses: docker/login-action@e92390c5fb421da1463c202d546fed0ec5c39f20
         with:
           registry: ${{ env.REGISTRY }}
           username: ${{ github.actor }}
@@ -52,7 +52,7 @@ jobs:
           images: ${{ env.REGISTRY }}/cosmos/${{ env.IMAGE_NAME }}
 
       - name: Build and push Docker image
-        uses: docker/build-push-action@af5a7ed5ba88268d5278f7203fb52cd833f66d6e
+        uses: docker/build-push-action@2cdde995de11925a030ce8070c3d77a52ffcf1c0
         with:
           context: .
           push: true

CHANGELOG.md

@@ -40,6 +40,8 @@ Ref: https://keepachangelog.com/en/1.0.0/
 
 ### API Breaking
 
+* (core/02-client, light-clients) [\#5806](https://github.com/cosmos/ibc-go/pull/5806) Decouple light client routing from their encoding structure.
+
 ### State Machine Breaking
 
 ### Improvements

README.md

@@ -94,6 +94,7 @@ The following audits have been performed on the `ibc-go` source code:
 
 - [ICS27 Interchain Accounts](https://github.com/cosmos/ibc-go/blob/main/docs/audits/27-interchain-accounts/Trail%20of%20Bits%20audit%20-%20Final%20Report.pdf) by Trail of Bits.
 - [ICS08 Wasm Clients](https://github.com/cosmos/ibc-go/blob/main/docs/audits/08-wasm/Ethan%20Frey%20-%20Wasm%20Client%20Review.pdf) by Ethan Frey/Confio.
+- [ICS04 Channel upgradability](https://github.com/cosmos/ibc-go/blob/main/docs/audits/04-channel-upgrades/Atredis%20Partners%20-%20Interchain%20Foundation%20IBC-Go%20Channel%20Upgrade%20Feature%20Assessment%20-%20Report%20v1.1.pdf) by Atredis Partners.
 
 ## Quick Navigation
 

docs/docs/01-ibc/05-upgrades/02-developer-guide.md

@@ -11,4 +11,4 @@ slug: /ibc/upgrades/developer-guide
 Learn how to implement upgrade functionality for your custom IBC client.
 :::
 
-Please see the section [Handling upgrades](../../03-light-clients/01-developer-guide/05-upgrades.md) from the light client developer guide for more information.
+Please see the section [Handling upgrades](../../03-light-clients/01-developer-guide/06-upgrades.md) from the light client developer guide for more information.

docs/docs/03-light-clients/01-developer-guide/01-overview.md

@@ -27,6 +27,7 @@ The following aims to provide a high level IBC light client module developer gui
 
 A light client module developer should be concerned with three main interfaces:
 
+- [`LightClientModule`](#lightclientmodule) a module which manages many light client instances of a certain type. 
 - [`ClientState`](#clientstate) encapsulates the light client implementation and its semantics.
 - [`ConsensusState`](#consensusstate) tracks consensus data used for verification of client updates, misbehaviour detection and proof verification of counterparty state.
 - [`ClientMessage`](#clientmessage) used for submitting block headers for client updates and submission of misbehaviour evidence using conflicting headers.
@@ -35,6 +36,21 @@ Throughout this guide the `07-tendermint` light client module may be referred to
 
 ## Concepts and vocabulary
 
+### `LightClientModule`
+
+`LightClientModule` is an interface defined by core IBC which allows for modular light client implementations. All light client implementations *must* implement the [`LightClientModule` interface](https://github.com/cosmos/ibc-go/blob/501a8462345da099144efe91d495bfcfa18d760d/modules/core/exported/client.go#L51) so that core IBC may redirect calls to the light client module. 
+
+For example a light client module may need to:
+
+- create clients
+- update clients
+- recover and upgrade clients
+- verify membership and non-membership
+
+The methods which make up this interface are detailed at a more granular level in the [`LightClientModule` section of this guide](02-light-client-module.md).
+
+Please refer to the `07-tendermint`'s [`LightClientModule` definition](https://github.com/cosmos/ibc-go/blob/501a8462345da099144efe91d495bfcfa18d760d/modules/light-clients/07-tendermint/light_client_module.go#L17) for more information. 
+
 ### `ClientState`
 
 `ClientState` is a term used to define the data structure which encapsulates opaque light client state. The `ClientState` contains all the information needed to verify a `ClientMessage` and perform membership and non-membership proof verification of counterparty state. This includes properties that refer to the remote state machine, the light client type and the specific light client instance.
@@ -47,7 +63,7 @@ For example:
 - Constraints used for client upgrades.
 
 The `ClientState` type maintained within the light client module *must* implement the [`ClientState`](https://github.com/cosmos/ibc-go/tree/02-client-refactor-beta1/modules/core/exported/client.go#L36) interface defined in `core/modules/exported/client.go`.
-The methods which make up this interface are detailed at a more granular level in the [ClientState section of this guide](02-client-state.md).
+The methods which make up this interface are detailed at a more granular level in the [`ClientState` section of this guide](03-client-state.md).
 
 Please refer to the `07-tendermint` light client module's [`ClientState` definition](https://github.com/cosmos/ibc-go/tree/02-client-refactor-beta1/proto/ibc/lightclients/tendermint/v1/tendermint.proto#L18) containing information such as chain ID, status, latest height, unbonding period and proof specifications.
 
@@ -58,7 +74,7 @@ Please refer to the `07-tendermint` light client module's [`ClientState` definit
 For example, the `ConsensusState` of the `07-tendermint` light client module defines a trusted root which is used by the `ClientState` to perform verification of membership and non-membership commitment proofs, as well as the next validator set hash used for verifying headers can be trusted in client updates.
 
 The `ConsensusState` type maintained within the light client module *must* implement the [`ConsensusState`](https://github.com/cosmos/ibc-go/tree/02-client-refactor-beta1/modules/core/exported/client.go#L134) interface defined in `modules/core/exported/client.go`.
-The methods which make up this interface are detailed at a more granular level in the [`ConsensusState` section of this guide](03-consensus-state.md).
+The methods which make up this interface are detailed at a more granular level in the [`ConsensusState` section of this guide](04-consensus-state.md).
 
 ### `Height`
 
@@ -76,4 +92,4 @@ The following are considered as valid update scenarios:
 - A batch of block headers which when verified inserts `N` `ConsensusState` instances for `N` unique heights.
 - Evidence of misbehaviour provided by two conflicting block headers.
 
-Learn more in the [Handling update and misbehaviour](04-updates-and-misbehaviour.md) section.
+Learn more in the [Handling update and misbehaviour](05-updates-and-misbehaviour.md) section.

docs/docs/03-light-clients/01-developer-guide/02-client-state.md → docs/docs/03-light-clients/01-developer-guide/02-light-client-module.md

@@ -1,28 +1,12 @@
 ---
-title: Client State interface
-sidebar_label: Client State interface
+title: Light Client Module interface
+sidebar_label: Light Client Module interface
 sidebar_position: 2
-slug: /ibc/light-clients/client-state
+slug: /ibc/light-clients/light-client-module
 ---
 
 
-# Implementing the `ClientState` interface
-
-Learn how to implement the [`ClientState`](https://github.com/cosmos/ibc-go/blob/v7.0.0/modules/core/exported/client.go#L36) interface. This list of methods described here does not include all methods of the interface. Some methods are explained in detail in the relevant sections of the guide.
-
-## `ClientType` method
-
-`ClientType` should return a unique string identifier of the light client. This will be used when generating a client identifier.
-The format is created as follows: `ClientType-{N}` where `{N}` is the unique global nonce associated with a specific client.
-
-## `GetLatestHeight` method
-
-`GetLatestHeight` should return the latest block height that the client state represents.
-
-## `Validate` method
-
-`Validate` should validate every client state field and should return an error if any value is invalid. The light client
-implementer is in charge of determining which checks are required. See the [Tendermint light client implementation](https://github.com/cosmos/ibc-go/blob/v7.0.0/modules/light-clients/07-tendermint/client_state.go#L111) as a reference.
+# Implementing the `LightClientModule` interface
 
 ## `Status` method
 
@@ -37,9 +21,9 @@ All possible `Status` types can be found [here](https://github.com/cosmos/ibc-go
 
 This field is returned in the response of the gRPC [`ibc.core.client.v1.Query/ClientStatus`](https://github.com/cosmos/ibc-go/blob/v7.0.0/modules/core/02-client/types/query.pb.go#L665) endpoint.
 
-## `GetTimestampAtHeight` method
+## `TimestampAtHeight` method
 
-`GetTimestampAtHeight` must return the timestamp for the consensus state associated with the provided height.
+`TimestampAtHeight` must return the timestamp for the consensus state associated with the provided height.
 This value is used to facilitate timeouts by checking the packet timeout timestamp against the returned value.
 
 ## `Initialize` method
@@ -52,12 +36,12 @@ Clients may also store any necessary client-specific metadata.
 ## `VerifyMembership` method
 
 `VerifyMembership` must verify the existence of a value at a given commitment path at the specified height. For more information about membership proofs
-see the [Existence and non-existence proofs section](06-proofs.md).
+see the [Existence and non-existence proofs section](07-proofs.md).
 
 ## `VerifyNonMembership` method
 
 `VerifyNonMembership` must verify the absence of a value at a given commitment path at a specified height. For more information about non-membership proofs
-see the [Existence and non-existence proofs section](06-proofs.md).
+see the [Existence and non-existence proofs section](07-proofs.md).
 
 ## `VerifyClientMessage` method
 

docs/docs/03-light-clients/01-developer-guide/03-client-state.md

@@ -0,0 +1,21 @@
+---
+title: Client State interface
+sidebar_label: Client State interface
+sidebar_position: 3
+slug: /ibc/light-clients/client-state
+---
+
+
+# Implementing the `ClientState` interface
+
+Learn how to implement the [`ClientState`](https://github.com/cosmos/ibc-go/blob/v7.0.0/modules/core/exported/client.go#L36) interface.
+
+## `ClientType` method
+
+`ClientType` should return a unique string identifier of the light client. This will be used when generating a client identifier.
+The format is created as follows: `{client-type}-{N}` where `{N}` is the unique global nonce associated with a specific client (e.g `07-tendermint-0`).
+
+## `Validate` method
+
+`Validate` should validate every client state field and should return an error if any value is invalid. The light client
+implementer is in charge of determining which checks are required. See the [Tendermint light client implementation](https://github.com/cosmos/ibc-go/blob/v7.0.0/modules/light-clients/07-tendermint/client_state.go#L111) as a reference.

docs/docs/03-light-clients/01-developer-guide/03-consensus-state.md → docs/docs/03-light-clients/01-developer-guide/04-consensus-state.md

@@ -1,7 +1,7 @@
 ---
 title: Consensus State interface
 sidebar_label: Consensus State interface
-sidebar_position: 3
+sidebar_position: 4
 slug: /ibc/light-clients/consensus-state
 ---
 
@@ -16,13 +16,11 @@ The below [`ConsensusState`](https://github.com/cosmos/ibc-go/blob/v7.0.0/module
 
 ## `ClientType` method
 
-This is the type of client consensus. It should be the same as the `ClientType` return value for the [corresponding `ClientState` implementation](02-client-state.md).
+This is the type of client consensus. It should be the same as the `ClientType` return value for the [corresponding `ClientState` implementation](03-client-state.md).
 
 ## `GetTimestamp` method
 
-*Deprecated*: soon to be removed from interface
-
-`GetTimestamp` should return the timestamp (in nanoseconds) of the consensus state snapshot.
+`GetTimestamp` should return the timestamp (in nanoseconds) of the consensus state snapshot. This function has been deprecated and will be removed in a future release.
 
 ## `ValidateBasic` method
 

docs/docs/03-light-clients/01-developer-guide/04-updates-and-misbehaviour.md → docs/docs/03-light-clients/01-developer-guide/05-updates-and-misbehaviour.md

@@ -1,14 +1,14 @@
 ---
 title: Handling Updates and Misbehaviour
 sidebar_label: Handling Updates and Misbehaviour
-sidebar_position: 4
+sidebar_position: 5
 slug: /ibc/light-clients/updates-and-misbehaviour
 ---
 
 
 # Handling `ClientMessage`s: updates and misbehaviour
 
-As mentioned before in the documentation about [implementing the `ConsensusState` interface](03-consensus-state.md), [`ClientMessage`](https://github.com/cosmos/ibc-go/blob/v7.0.0/modules/core/exported/client.go#L147) is an interface used to update an IBC client. This update may be performed by:
+As mentioned before in the documentation about [implementing the `ConsensusState` interface](04-consensus-state.md), [`ClientMessage`](https://github.com/cosmos/ibc-go/blob/v7.0.0/modules/core/exported/client.go#L147) is an interface used to update an IBC client. This update may be performed by:
 
 - a single header
 - a batch of headers
@@ -30,7 +30,7 @@ type ClientMessage interface {
 }
 ```
 
-The `ClientMessage` will be passed to the client to be used in [`UpdateClient`](https://github.com/cosmos/ibc-go/blob/v7.0.0/modules/core/02-client/keeper/client.go#L48), which retrieves the `ClientState` by client ID (available in `MsgUpdateClient`). This `ClientState` implements the [`ClientState` interface](02-client-state.md) for its specific consenus type (e.g. Tendermint).
+The `ClientMessage` will be passed to the client to be used in [`UpdateClient`](https://github.com/cosmos/ibc-go/blob/v7.0.0/modules/core/02-client/keeper/client.go#L48), which retrieves the `ClientState` by client ID (available in `MsgUpdateClient`). This `ClientState` implements the [`ClientState` interface](03-client-state.md) for its specific consenus type (e.g. Tendermint).
 
 `UpdateClient` will then handle a number of cases including misbehaviour and/or updating the consensus state, utilizing the specific methods defined in the relevant `ClientState`.
 

docs/docs/03-light-clients/01-developer-guide/05-upgrades.md → docs/docs/03-light-clients/01-developer-guide/06-upgrades.md

@@ -1,7 +1,7 @@
 ---
 title: Handling Upgrades
 sidebar_label: Handling Upgrades
-sidebar_position: 5
+sidebar_position: 6
 slug: /ibc/light-clients/upgrades
 ---
 

docs/docs/03-light-clients/01-developer-guide/06-proofs.md → docs/docs/03-light-clients/01-developer-guide/07-proofs.md

@@ -1,7 +1,7 @@
 ---
 title: Existence/Non-Existence Proofs
 sidebar_label: Existence/Non-Existence Proofs
-sidebar_position: 6
+sidebar_position: 7
 slug: /ibc/light-clients/proofs
 ---
 

docs/docs/03-light-clients/01-developer-guide/07-proposals.md → docs/docs/03-light-clients/01-developer-guide/08-proposals.md

@@ -1,7 +1,7 @@
 ---
 title: Handling Proposals
 sidebar_label: Handling Proposals
-sidebar_position: 7
+sidebar_position: 8
 slug: /ibc/light-clients/proposals
 ---
 

docs/docs/03-light-clients/01-developer-guide/08-setup.md → docs/docs/03-light-clients/01-developer-guide/09-setup.md

@@ -1,7 +1,7 @@
 ---
 title: Setup
 sidebar_label: Setup
-sidebar_position: 8
+sidebar_position: 9
 slug: /ibc/light-clients/setup
 ---
 

docs/docs/03-light-clients/04-wasm/03-integration.md

@@ -353,7 +353,7 @@ func CreateWasmUpgradeHandler(
 }
 ```
 
-Or alternatively the parameter can be updated via a governance proposal (see at the bottom of section [`Creating clients`](../01-developer-guide/08-setup.md#creating-clients) for an example of how to do this).
+Or alternatively the parameter can be updated via a governance proposal (see at the bottom of section [`Creating clients`](../01-developer-guide/09-setup.md#creating-clients) for an example of how to do this).
 
 ## Adding the module to the store