Merge branch 'main' into damian/rename-migrations-ica

.github/compatibility-test-matrices/release-v5.0.x.json

@@ -0,0 +1,12 @@
+{
+  "include": [
+    {
+      "chain-binary": "simd",
+      "chain-a-tag": "release-v5.0.x",
+      "chain-b-tag": "release-v5.0.x",
+      "chain-image": "ghcr.io/cosmos/ibc-go-simd",
+      "entrypoint": "TestTransferTestSuite",
+      "test": "TestReceiveEnabledParam"
+    }
+  ]
+}

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

@@ -11,15 +11,15 @@ env:
    REGISTRY: ghcr.io
    ORG: cosmos
    IMAGE_NAME: ibc-go-simd
-   VERSION: "${{ inputs.tag }}"
+   GIT_TAG: "${{ inputs.tag }}"
 
 jobs:
    build-image-at-tag:
       runs-on: ubuntu-latest
       steps:
          - uses: actions/checkout@v3
            with:
-            ref: "${{ env.VERSION }}"
+            ref: "${{ env.GIT_TAG }}"
             fetch-depth: 0
          - name: Log in to the Container registry
            uses: docker/login-action@49ed152c8eca782a232dede0303416e8f356c37b
@@ -31,5 +31,7 @@ jobs:
            run: curl https://raw.githubusercontent.com/cosmos/ibc-go/main/Dockerfile -o Dockerfile
          - name: Build image
            run: |
-            docker build . -t "${REGISTRY}/${ORG}/${IMAGE_NAME}:${VERSION}"
-            docker push "${REGISTRY}/${ORG}/${IMAGE_NAME}:${VERSION}"
+            # remove any `/` characters from the docker tag and replace them with a -
+            docker_tag="$(echo $GIT_TAG | sed 's/\//-/')"
+            docker build . -t "${REGISTRY}/${ORG}/${IMAGE_NAME}:${docker_tag}"
+            docker push "${REGISTRY}/${ORG}/${IMAGE_NAME}:${docker_tag}"

.github/workflows/e2e-compatibility.yaml

@@ -0,0 +1,88 @@
+name: Compatibility E2E
+on:
+  workflow_dispatch:
+    release-branch:
+      description: 'Release branch to test'
+      required: true
+      type: choice
+      options:
+        - release/v5.0.x
+
+env:
+  REGISTRY: ghcr.io
+  ORG: cosmos
+  IMAGE_NAME: ibc-go-simd
+  RELEASE_BRANCH: '${{ inputs.release-branch }}'
+
+jobs:
+  determine-docker-tag:
+    runs-on: ubuntu-latest
+    outputs:
+      docker-tag: ${{ steps.set-docker-tag.outputs.docker-tag }}
+    steps:
+      - run: |
+          docker_tag="$(echo $RELEASE_BRANCH | sed 's/\//-/')"
+          echo $docker_tag
+          echo "::set-output name=docker-tag::$docker_tag"
+        id: set-docker-tag
+
+  build-release-image:
+    runs-on: ubuntu-latest
+    needs: determine-docker-tag
+    steps:
+      - uses: actions/checkout@v3
+        with:
+          ref: "${{ env.RELEASE_BRANCH }}"
+          fetch-depth: 0
+      - name: Log in to the Container registry
+        uses: docker/login-action@49ed152c8eca782a232dede0303416e8f356c37b
+        with:
+          registry: ${{ env.REGISTRY }}
+          username: ${{ github.actor }}
+          password: ${{ secrets.GITHUB_TOKEN }}
+      - name: Fetch latest Dockerfile
+        run: curl https://raw.githubusercontent.com/cosmos/ibc-go/main/Dockerfile -o Dockerfile
+      - name: Build image
+        run: |
+          docker build . -t "${REGISTRY}/${ORG}/${IMAGE_NAME}:${{ needs.determine-docker-tag.outputs.docker-tag }}"
+          docker push "${REGISTRY}/${ORG}/${IMAGE_NAME}:${{ needs.determine-docker-tag.outputs.docker-tag }}"
+
+  load-test-matrix:
+    outputs:
+      test-matrix: ${{ steps.set-test-matrix.outputs.test-matrix }}
+    needs: determine-docker-tag
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - run: |
+          # use jq -c to put the full json contents on a single line. This is required when using the json body
+          # to create the matrix in the following job.
+          test_matrix="$(cat .github/compatibility-test-matrices/${{ needs.determine-docker-tag.outputs.docker-tag }}.json | jq -c)"
+          echo $test_matrix
+          echo "::set-output name=test-matrix::$test_matrix"
+        id: set-test-matrix
+
+  e2e-tests:
+    runs-on: ubuntu-latest
+    needs:
+      - load-test-matrix
+      - build-release-image
+    strategy:
+      fail-fast: false
+      matrix: ${{ fromJSON(needs.load-test-matrix.outputs.test-matrix) }}
+    steps:
+      - uses: actions/checkout@v3
+      - uses: actions/setup-go@v3
+        with:
+          go-version: 1.18
+      - name: Run e2e Test
+        run: |
+          cd e2e
+          make e2e-test entrypoint=${{ matrix.entrypoint }} test=${{ matrix.test }}
+        env:
+          # each test has its own set of variables to specify which images are used.
+          CHAIN_IMAGE: "${{ matrix.chain-image }}"
+          CHAIN_A_TAG: "${{ matrix.chain-a-tag }}"
+          CHAIN_B_TAG: "${{ matrix.chain-b-tag }}"
+          CHAIN_BINARY: "${{ matrix.chain-binary }}"
+          RLY_TAG: "v2.0.0"

.github/workflows/link-check.yml

@@ -1,10 +1,10 @@
 name: Check Markdown links
-on: [push, pull_request]
+on: pull_request
 jobs:
   markdown-link-check:
     runs-on: ubuntu-latest
     steps:
     - uses: actions/checkout@v3
     - uses: gaurav-nelson/github-action-markdown-link-check@v1
       with:
-        config-file: '.github/workflows/link-check-config.json'
+        config-file: '.github/workflows/link-check-config.json'

CHANGELOG.md

@@ -97,7 +97,9 @@ Ref: https://keepachangelog.com/en/1.0.0/
 * (apps/27-interchain-accounts) [\#2157](https://github.com/cosmos/ibc-go/pull/2157) Adding `IsMiddlewareEnabled` functionality to enforce calls to ICS27 msg server to *not* route to the underlying application.
 * (apps/27-interchain-accounts) [\#2177](https://github.com/cosmos/ibc-go/pull/2177) Adding `IsMiddlewareEnabled` flag to interchain accounts `ActiveChannel` genesis type.
 * (apps/27-interchain-accounts) [\#2140](https://github.com/cosmos/ibc-go/pull/2140) Adding migration handler to ICS27 `controller` submodule to assert ownership of channel capabilities and set middleware enabled flag for existing channels. The ICS27 module consensus version has been bumped from 1 to 2.
-* (apps/27-interchain-accounts) [\#2290](https://github.com/cosmos/ibc-go/pull/2290) Changed `DefaultParams` function in `host` submodule to allow all messages by default. Defined a constant named `AllowAllHostMsgs` for `host` module to keep wildcard "*" string which allows all messages.     
+* (apps/27-interchain-accounts) [\#2290](https://github.com/cosmos/ibc-go/pull/2290) Changed `DefaultParams` function in `host` submodule to allow all messages by default. Defined a constant named `AllowAllHostMsgs` for `host` module to keep wildcard "*" string which allows all messages.
+* (apps/27-interchain-accounts) [\#2248](https://github.com/cosmos/ibc-go/pull/2248) Adding call to underlying app in `OnChanCloseConfirm` callback of the controller submodule and adding relevant unit tests.
+* (apps/27-interchain-accounts) [\#2251](https://github.com/cosmos/ibc-go/pull/2251) Adding `msgServer` struct to controller submodule that embeds the `Keeper` struct.    
 
 ### Features
 

docs/apps/interchain-accounts/parameters.md

@@ -26,7 +26,7 @@ The `ControllerEnabled` parameter controls a chains ability to service ICS-27 co
 | Key                    | Type     | Default Value |
 |------------------------|----------|---------------|
 | `HostEnabled`          | bool     | `true`        |
-| `AllowMessages`        | []string | `[]`          |
+| `AllowMessages`        | []string | `["*"]`       |
 
 #### HostEnabled
 
@@ -55,4 +55,4 @@ There is also a special wildcard `"*"` message type which allows any type of mes
     "host_enabled": true,
     "allow_messages": ["*"]
 }
-```
+```

docs/ibc/proposals.md

@@ -4,51 +4,55 @@ order: 5
 
 # Governance Proposals
 
-In uncommon situations, a highly valued client may become frozen due to uncontrollable 
+In uncommon situations, a highly valued client may become frozen due to uncontrollable
 circumstances. A highly valued client might have hundreds of channels being actively used.
 Some of those channels might have a significant amount of locked tokens used for ICS 20.
 
 If the one third of the validator set of the chain the client represents decides to collude,
 they can sign off on two valid but conflicting headers each signed by the other one third
 of the honest validator set. The light client can now be updated with two valid, but conflicting
 headers at the same height. The light client cannot know which header is trustworthy and therefore
-evidence of such misbehaviour is likely to be submitted resulting in a frozen light client. 
+evidence of such misbehaviour is likely to be submitted resulting in a frozen light client.
 
 Frozen light clients cannot be updated under any circumstance except via a governance proposal.
-Since a quorum of validators can sign arbitrary state roots which may not be valid executions 
+Since a quorum of validators can sign arbitrary state roots which may not be valid executions
 of the state machine, a governance proposal has been added to ease the complexity of unfreezing
 or updating clients which have become "stuck". Without this mechanism, validator sets would need
-to construct a state root to unfreeze the client. Unfreezing clients, re-enables all of the channels 
-built upon that client. This may result in recovery of otherwise lost funds. 
+to construct a state root to unfreeze the client. Unfreezing clients, re-enables all of the channels
+built upon that client. This may result in recovery of otherwise lost funds.
 
-Tendermint light clients may become expired if the trusting period has passed since their 
+Tendermint light clients may become expired if the trusting period has passed since their
 last update. This may occur if relayers stop submitting headers to update the clients.
 
-An unplanned upgrade by the counterparty chain may also result in expired clients. If the counterparty 
-chain undergoes an unplanned upgrade, there may be no commitment to that upgrade signed by the validator 
-set before the chain-id changes. In this situation, the validator set of the last valid update for the 
-light client is never expected to produce another valid header since the chain-id has changed, which will 
-ultimately lead the on-chain light client to become expired.  
+An unplanned upgrade by the counterparty chain may also result in expired clients. If the counterparty
+chain undergoes an unplanned upgrade, there may be no commitment to that upgrade signed by the validator
+set before the chain-id changes. In this situation, the validator set of the last valid update for the
+light client is never expected to produce another valid header since the chain-id has changed, which will
+ultimately lead the on-chain light client to become expired.
 
 In the case that a highly valued light client is frozen, expired, or rendered non-updateable, a
-governance proposal may be submitted to update this client, known as the subject client. The 
+governance proposal may be submitted to update this client, known as the subject client. The
 proposal includes the client identifier for the subject and the client identifier for a substitute
-client. Light client implementations may implement custom updating logic, but in most cases, 
+client. Light client implementations may implement custom updating logic, but in most cases,
 the subject will be updated to the latest consensus state of the substitute client, if the proposal passes.
-The substitute client is used as a "stand in" while the subject is on trial. It is best practice to create 
-a substitute client *after* the subject has become frozen to avoid the substitute from also becoming frozen. 
-An active substitute client allows headers to be submitted during the voting period to prevent accidental expiry 
-once the proposal passes. 
+The substitute client is used as a "stand in" while the subject is on trial. It is best practice to create
+a substitute client _after_ the subject has become frozen to avoid the substitute from also becoming frozen.
+An active substitute client allows headers to be submitted during the voting period to prevent accidental expiry
+once the proposal passes.
 
-*note* two of these parameters: `AllowUpdateAfterExpiry` and `AllowUpdateAfterMisbehavior` have been deprecated, and will both be set to `false` upon upgrades even if they were previously set to `true`. These parameters will no longer play a role in restricting a client upgrade. Please see ADR026 for more details.
+_note_ two of these parameters: `AllowUpdateAfterExpiry` and `AllowUpdateAfterMisbehavior` have been deprecated, and will both be set to `false` upon upgrades even if they were previously set to `true`. These parameters will no longer play a role in restricting a client upgrade. Please see ADR026 for more details.
 
 # How to recover an expired client with a governance proposal
 
 See also the relevant documentation: [ADR-026, IBC client recovery mechanisms](../architecture/adr-026-ibc-client-recovery-mechanisms.md)
 
-### Preconditions 
+> **Who is this information for?**
+> Although technically anyone can submit the governance proposal to recover an expired client, often it will be **relayer operators** (at least coordinating the submission).
+
+### Preconditions
+
 - The chain is updated with ibc-go >= v1.1.0.
-- The client identifier of an active client for the same counterparty chain.
+- There exists an active client (with a known client identifier) for the same counterparty chain as the expired client.
 - The governance deposit.
 
 ## Steps
@@ -72,18 +76,53 @@ The client is attached to the expected Akash `chain-id`. Note that although the
 
 ### Step 2
 
-If the chain has been updated to ibc-go >= v1.1.0, anyone can submit the governance proposal to recover the client by executing this via cli:
+If the chain has been updated to ibc-go >= v1.1.0, anyone can submit the governance proposal to recover the client by executing this via CLI.
 
-```
-<binary> tx gov submit-proposal update-client <expired-client-id> <active-client-id>
-```
+> Note that the Cosmos SDK has updated how governance proposals are submitted in SDK v0.46, now requiring to pass a .json proposal file
+
+- From SDK v0.46.x onwards
+
+  ```
+  <binary> tx gov submit-proposal [path-to-proposal-json]
+  ```
+
+  where `proposal.json` contains:
+
+  ```json
+  {
+    "messages": [
+      {
+        "@type": "/ibc.core.client.v1.ClientUpdateProposal",
+        "title": "title_string",
+        "description": "description_string",
+        "subject_client_id": "expired_client_id_string",
+        "substitute_client_id": "active_client_id_string"
+      }
+    ],
+    "metadata": "<metadata>",
+    "deposit": "10stake"
+  }
+  ```
+
+  Alternatively there's a legacy command (that is no longer recommended though):
+
+  ```
+  <binary> tx gov submit-legacy-proposal update-client <expired-client-id> <active-client-id>
+  ```
+
+- Until SDK v0.45.x
+  ```
+  <binary> tx gov submit-proposal update-client <expired-client-id> <active-client-id>
+  ```
+
+The `<expired-client-id>` identifier is the proposed client to be updated. This client must be either frozen or expired.
 
-The `<active-client-id>` should be a client identifier on the same chain as the expired or frozen client. This client identifier should connect to the same chain as the expired or frozen client. This means: use the active client that is currently being used to relay packets between the two chains as the replacement client.
+The `<active-client-id>` represents a substitute client. It carries all the state for the client which may be updated. It must have identical client and chain parameters to the client which may be updated (except for latest height, frozen height, and chain ID). It should be continually updated during the voting period.
 
-After this, it is just a question of who funds the governance deposit and if the chain in question votes yes.
+After this, all that remains is deciding who funds the governance deposit and ensuring the governance proposal passes. If it does, the client on trial will be updated to the latest state of the substitute.
 
-## Important considerations 
+## Important considerations
 
 Please note that from v1.0.0 of ibc-go it will not be allowed for transactions to go to expired clients anymore, so please update to at least this version to prevent similar issues in the future.
 
-Please also note that if the client on the other end of the transaction is also expired, that client will also need to update. This process updates only one client.
+Please also note that if the client on the other end of the transaction is also expired, that client will also need to update. This process updates only one client.

go.mod

@@ -1,6 +1,6 @@
 go 1.18
 
-module github.com/cosmos/ibc-go/v5
+module github.com/cosmos/ibc-go/v6
 
 replace github.com/gogo/protobuf => github.com/regen-network/protobuf v1.3.3-alpha.regen.1
 
@@ -9,7 +9,7 @@ require (
 	github.com/armon/go-metrics v0.4.1
 	github.com/confio/ics23/go v0.7.0
 	github.com/cosmos/cosmos-sdk v0.46.1
-	github.com/gogo/protobuf v1.3.2
+	github.com/gogo/protobuf v1.3.3
 	github.com/golang/protobuf v1.5.2
 	github.com/gorilla/mux v1.8.0
 	github.com/grpc-ecosystem/grpc-gateway v1.16.0

modules/apps/27-interchain-accounts/client/cli/cli.go

@@ -3,8 +3,8 @@ package cli
 import (
 	"github.com/spf13/cobra"
 
-	controllercli "github.com/cosmos/ibc-go/v5/modules/apps/27-interchain-accounts/controller/client/cli"
-	hostcli "github.com/cosmos/ibc-go/v5/modules/apps/27-interchain-accounts/host/client/cli"
+	controllercli "github.com/cosmos/ibc-go/v6/modules/apps/27-interchain-accounts/controller/client/cli"
+	hostcli "github.com/cosmos/ibc-go/v6/modules/apps/27-interchain-accounts/host/client/cli"
 )
 
 // GetQueryCmd returns the query commands for the interchain-accounts submodule

modules/apps/27-interchain-accounts/controller/client/cli/query.go

@@ -8,7 +8,7 @@ import (
 	"github.com/cosmos/cosmos-sdk/version"
 	"github.com/spf13/cobra"
 
-	"github.com/cosmos/ibc-go/v5/modules/apps/27-interchain-accounts/controller/types"
+	"github.com/cosmos/ibc-go/v6/modules/apps/27-interchain-accounts/controller/types"
 )
 
 // GetCmdQueryInterchainAccount returns the command handler for the controller submodule parameter querying.

modules/apps/27-interchain-accounts/controller/client/cli/tx.go

@@ -11,9 +11,9 @@ import (
 	"github.com/cosmos/cosmos-sdk/codec"
 	"github.com/spf13/cobra"
 
-	"github.com/cosmos/ibc-go/v5/modules/apps/27-interchain-accounts/controller/types"
-	icatypes "github.com/cosmos/ibc-go/v5/modules/apps/27-interchain-accounts/types"
-	clienttypes "github.com/cosmos/ibc-go/v5/modules/core/02-client/types"
+	"github.com/cosmos/ibc-go/v6/modules/apps/27-interchain-accounts/controller/types"
+	icatypes "github.com/cosmos/ibc-go/v6/modules/apps/27-interchain-accounts/types"
+	clienttypes "github.com/cosmos/ibc-go/v6/modules/core/02-client/types"
 )
 
 const (

modules/apps/27-interchain-accounts/controller/ibc_middleware.go

@@ -5,13 +5,13 @@ import (
 	sdkerrors "github.com/cosmos/cosmos-sdk/types/errors"
 	capabilitytypes "github.com/cosmos/cosmos-sdk/x/capability/types"
 
-	"github.com/cosmos/ibc-go/v5/modules/apps/27-interchain-accounts/controller/keeper"
-	"github.com/cosmos/ibc-go/v5/modules/apps/27-interchain-accounts/controller/types"
-	icatypes "github.com/cosmos/ibc-go/v5/modules/apps/27-interchain-accounts/types"
-	channeltypes "github.com/cosmos/ibc-go/v5/modules/core/04-channel/types"
-	porttypes "github.com/cosmos/ibc-go/v5/modules/core/05-port/types"
-	host "github.com/cosmos/ibc-go/v5/modules/core/24-host"
-	ibcexported "github.com/cosmos/ibc-go/v5/modules/core/exported"
+	"github.com/cosmos/ibc-go/v6/modules/apps/27-interchain-accounts/controller/keeper"
+	"github.com/cosmos/ibc-go/v6/modules/apps/27-interchain-accounts/controller/types"
+	icatypes "github.com/cosmos/ibc-go/v6/modules/apps/27-interchain-accounts/types"
+	channeltypes "github.com/cosmos/ibc-go/v6/modules/core/04-channel/types"
+	porttypes "github.com/cosmos/ibc-go/v6/modules/core/05-port/types"
+	host "github.com/cosmos/ibc-go/v6/modules/core/24-host"
+	ibcexported "github.com/cosmos/ibc-go/v6/modules/core/exported"
 )
 
 var _ porttypes.Middleware = &IBCMiddleware{}