Merge pull request #536 from zigbee-alliance/#303-Upgrade-Cosmos-SDK

#303 Upgrade Cosmos SDK

.github/.wordlist.txt

@@ -83,4 +83,9 @@ li
 md
 pdf
 ul
-WebSocket
+WebSocket
+cometbft
+CometBFT
+CometBFT's
+distributedcoplianceledger
+zigbeealliance

.github/actions/setup-molecule/action.yml

@@ -24,7 +24,7 @@ runs:
   steps:
     - uses: actions/setup-python@v3
       with:
-        python-version: '3.x'
+        python-version: '3.10'
     - name: install dependencies
       shell: bash
       run: pip install -r deployment/test-requirements.txt

.github/workflows/on-demand_molecule.yml

@@ -18,13 +18,13 @@ name: Check All Molecule tests
 on:
   push:
     branches:
-      - master
+      - dev
     paths:
       - deployment/test-requirements.txt
       - deployment/ansible/roles/**
   pull_request:
     branches:
-      - master
+      - dev
     paths:
       - deployment/test-requirements.txt
       - deployment/ansible/roles/**

.github/workflows/release.yml

@@ -129,9 +129,9 @@ jobs:
     runs-on: ${{ matrix.os }}
     steps:
       - name: Set up Go 1.x
-        uses: actions/setup-go@v3
+        uses: actions/setup-go@v4
         with:
-          go-version: ^1.16
+          go-version: ^1.20
 
       - name: Check out code into the Go module directory
         uses: actions/checkout@v2

.github/workflows/verify.yml

@@ -56,8 +56,8 @@ jobs:
     if: needs.changes.outputs.workflows == 'true'
     name: Run actionlint tool to verify lint issues in GitHub actions
     runs-on: ubuntu-latest
-    needs:
-      - changes
+#    needs:
+#      - changes
     steps:
       - uses: actions/checkout@master
       - uses: reviewdog/action-actionlint@v1
@@ -85,9 +85,9 @@ jobs:
     needs:
       - lint
     steps:
-      - uses: actions/setup-go@v3
+      - uses: actions/setup-go@v4
         with:
-          go-version: ^1.17
+          go-version: ^1.20
       - uses: actions/checkout@v3
       - uses: actions/cache@v3
         if: ${{ !env.ACT }}
@@ -111,9 +111,9 @@ jobs:
     needs:
       - changes
     steps:
-      - uses: actions/setup-go@v3
+      - uses: actions/setup-go@v4
         with:
-          go-version: ^1.17
+          go-version: ^1.20
       - uses: actions/checkout@v3
       - uses: actions/cache@v3
         with:
@@ -134,13 +134,13 @@ jobs:
       - changes
     steps:
       - uses: actions/checkout@v3
-      - uses: actions/setup-go@v3
+      - uses: actions/setup-go@v4
         with:
-          go-version: 1.17
+          go-version: 1.21
       - name: golangci-lint
-        uses: golangci/golangci-lint-action@v3.6.0
+        uses: golangci/golangci-lint-action@v3
         with:
-          version: v1.46.0
+          version: v1.55
           args: --timeout 5m0s
   check:
     if: always()

.golangci.yml

@@ -50,3 +50,34 @@ linters:
     - nonamedreturns
     - exhaustruct
     - gofumpt
+    - depguard
+    - deadcode
+    - godot
+    - inamedparam
+    - goconst
+    - nosnakecase
+    - perfsprint
+    - unparam
+    - revive
+
+issues:
+  exclude-rules:
+    - path: _test\.go$
+      linters:
+        - goconst
+        - stylecheck
+        - testifylint
+        - nosnakecase
+        - perfsprint
+        - dupword
+        - testifylint
+    - path: helpers\.go$
+      linters:
+        - goconst
+        - stylecheck
+        - testifylint
+        - nosnakecase
+        - perfsprint
+        - dupword
+        - testifylint
+

Dockerfile

@@ -22,7 +22,7 @@
 FROM ubuntu:20.04 AS builder
 
 ARG GO_VERSION
-ENV GO_VERSION=1.19.4
+ENV GO_VERSION=1.20
 
 RUN apt-get update --fix-missing
 RUN apt-get install -y wget git gcc
@@ -36,7 +36,7 @@ ENV GOPATH /go
 ENV PATH $GOPATH/bin:/usr/local/go/bin:$PATH
 RUN mkdir -p "$GOPATH/src" "$GOPATH/bin" && chmod -R 777 "$GOPATH"
 
-RUN go install github.com/cosmos/cosmos-sdk/cosmovisor/cmd/cosmovisor@v1.0.0
+RUN go install github.com/cosmos/cosmos-sdk/cosmovisor/cmd/cosmovisor@v1.3.0
 
 ############################
 # STEP 2 build node image

Dockerfile-build

@@ -20,7 +20,7 @@
 FROM ubuntu:20.04 AS builder
 
 ARG GO_VERSION
-ENV GO_VERSION=1.19.4
+ENV GO_VERSION=1.20
 
 RUN apt-get update
 RUN apt-get install -y wget git gcc make

README-DEV.md

@@ -153,10 +153,16 @@ Please take into account the following when sending a PR:
 
 ## How To Add a new Module or Transaction
 
-- Use [starport](https://github.com/tendermint/starport) command to scaffold the module.
-  Consider using a docker container built from the provided [Dockerfile](scripts/Dockerfile) to have a predictable version of starport. See [README.md](scripts/README.md).
+- Use [ignite v0.27.1](https://github.com/ignite/cli) command to scaffold the module.
+  Consider using a docker container built from the provided [Dockerfile](scripts/Dockerfile) to have a predictable version of ignite. See [README.md](scripts/README.md).
 - Have a look at the scripts and commands used for generation of existing modules, messages and CRUD operations and do it in a similar way
   (for example [PKI module commands](scripts/starport/upgrade-0.44/07.pki_types.sh)).
+  - 
+    **Note**:
+    1. On previous scaffolding of modules `starport` cli used instead of `ignite`. 
+               While generating new module, command structure will the same except it must start with `ignite`.
+    2. After execution of command `ignite scaffold ...` generated `.proto` files will be added into `proto/distributedcoplianceledger/{module}/{proto}`
+    . So make sure to put contents of generated proto files into related folders inside `proto/zigbeealliance/..` folder.
 - If a new transaction with a new data in state (key-value) and new queries needs to be created, then both message and CRUD commands need to be executed.
 - If just a message to update existing state values need to be created, then a message command is enough.  
 - Adjust the generated code
@@ -166,19 +172,18 @@ Please take into account the following when sending a PR:
   - add `(cosmos_proto.scalar) = "cosmos.AddressString"` annotation for all fields with address/account type (such as `signer` or `owner`).
   - fix types if needed in `proto/<module>/<entity>.proto` files
     - Note1: `unit64` will be returned as string if the output is a JSON format. So, it's better to use `uint64` only when it's really `uint64`.
-    - Note2: for `uint16` type: use `int32` during starport scaffolding, and add custom validation (annotations above) to check the lower and upper bounds.
-    - Note3: for `uint32` type: use `int32` during starport scaffolding, then replace it by `uint32` in .proto files, re-generate the code and fix compilation errors.
-  - build proto (for example `starport chain build`). Fix compilation errors if any.
+    - Note2: for `uint16` type: use `int32` during ignite scaffolding, and add custom validation (annotations above) to check the lower and upper bounds.
+    - Note3: for `uint32` type: use `int32` during ignite scaffolding, then replace it by `uint32` in .proto files, re-generate the code and fix compilation errors.
+  - build proto (for example `ignite chain build`). Fix compilation errors if any.
   - generate openapi docs from proto using (`scripts/dcl-swagger-gen.sh`). It's recommended to run from container built from [Dockerfile](scripts/Dockerfile)
 
   - **Note1**: colons (`:`) are part of subject-id in PKI module, but colons are not allowed in gRPC REST URLs by default.
     `allow_colon_final_segments=true` should be used as a workaround.
     So, make sure that `runtime.AssumeColonVerbOpt(false)` in `/x/pki/types/query.pb.gw.go`.
     It's usually sufficient to revert the generated changes in `/x/pki/types/query.pb.gw.go`.
-  - **Note2**: move `compliance_info.pb.go` and `compliance_history_item.pb.go` to `types/compliance` and adjust the import in other places accordingly.
     It may be easier just to revert changes in all  `*.pb.go` files not affected by your changes in `.proto`
-  - **Note3**: `starport chain build` needs to be called only if you made manual changes in `.proto` files.
-    There is no need to call `starport chain build` again once all errors and adjustments above are done. It's sufficient just to build the project via usual ways (such as `make build`)  
+  - **Note3**: `ignite chain build` needs to be called only if you made manual changes in `.proto` files.
+    There is no need to call `ignite chain build` again once all errors and adjustments above are done. It's sufficient just to build the project via usual ways (such as `make build`)  
 - Add static validation for new messages:
   - Call `validator.Validate(msg)` in `ValidateBasic` methods for all generated messages
   - Add additional checks to `ValidateBasic` that do not depend on the state (key-value) and order of transactions
@@ -195,19 +200,19 @@ Please take into account the following when sending a PR:
 
 ## How To Make Changes in Data Model for Existing Modules
 
-- Use [starport](https://github.com/tendermint/starport) command to scaffold the module.
-  Consider using the provided [Dockerfile](scripts/Dockerfile) to have a predictable version of starport. See [README.md](scripts/README.md).
+- Use [ignite](https://github.com/ignite/cli) command to scaffold the module.
+  Consider using the provided [Dockerfile](scripts/Dockerfile) to have a predictable version of ignite. See [README.md](scripts/README.md).
 - **Never change `.pb` files manually**. Do the changes in `.proto` files.
-- Every time `.proto` files change, re-generate the code (for example `starport chain build`) and fix compilation errors if any.
+- Every time `.proto` files change, re-generate the code (for example `ignite chain build`) and fix compilation errors if any.
 - Update openapi docs from proto using (`scripts/dcl-swagger-gen.sh`). It's recommended to run from container built from [Dockerfile](scripts/Dockerfile).
 - **Note1**: colons (`:`) are part of subject-id in PKI module, but colons are not allowed in gRPC REST URLs by default.
   `allow_colon_final_segments=true` should be used as a workaround.
   So, make sure that `runtime.AssumeColonVerbOpt(false)` in `/x/pki/types/query.pb.gw.go`.
   It's usually sufficient to revert the generated changes in `/x/pki/types/query.pb.gw.go`.
 - **Note2**: move `compliance_info.pb.go` and `compliance_history_item.pb.go` to `types/compliance` and adjust the import in other places accordingly.
   It may be easier just to revert changes in all  `*.pb.go` files not affected by your changes in `.proto`
-- **Note3**: `starport chain build` needs to be called only if you made manual changes in `.proto` files.
-  There is no need to call `starport chain build` again once all errors and adjustments above are done. It's sufficient just to build the project via usual ways (such as `make build`)
+- **Note3**: `ignite chain build` needs to be called only if you made manual changes in `.proto` files.
+  There is no need to call `ignite chain build` again once all errors and adjustments above are done. It's sufficient just to build the project via usual ways (such as `make build`)
 
 
 ## Update Cosmos-sdk Version
@@ -221,14 +226,12 @@ Re-generate cosmos base openapi (service API from cosmos exposed in DCL) using [
 ./scripts/cosmos-swagger-gen.sh tx
 ```
 
-## Update Tendermint Version
-
-Please note, that we depend on the Tendermint fork <https://github.com/zigbee-alliance/tendermint/releases/tag/v0.34.140>
-due to hotfixes for <https://github.com/tendermint/tendermint/issues/7640> and <https://github.com/tendermint/tendermint/issues/7641>
+## Update CometBFT Version
+Please note, that we depend on the CometBFT fork https://github.com/zigbee-alliance/cometbft/releases/tag/v0.37.5
+due to hotfixes for https://github.com/tendermint/tendermint/issues/7640 and https://github.com/tendermint/tendermint/issues/7641
 required for Light Client Proxy.
-Now that fixes are merged to Tendermint master, so check if we still need to depend on the fork.
 
-Also don't forget to update the link to the Tendermint RPC in [Swagger UI](docs/index.html).
+Also don't forget to update the link to the CometBFT RPC in [Swagger UI](docs/index.html).
 
 ## Other
 

README.md

@@ -18,7 +18,7 @@ DC Ledger is a public permissioned Ledger which can be used for two main use cas
 
 More information about use cases can be found in [DC Ledger Overview](./docs/design/DCL-Overview.pdf) and [Use Case Diagrams](docs/use_cases).
 
-DC Ledger is based on [Tendermint](https://tendermint.com/) and [Cosmos SDK](https://cosmos.network/sdk).
+DC Ledger is based on [CometBFT](https://cometbft.com/) and [Cosmos SDK](https://cosmos.network/sdk).
 
 DC Ledger is a public permissioned ledger in the following sense:
 
@@ -40,7 +40,7 @@ In order to send write transactions to the ledger you need:
 
 ### Pool of Nodes
 
-- A network of Tendermint-based validator nodes (Validators and Observers) maintaining the ledger.
+- A network of CometBFT-based validator nodes (Validators and Observers) maintaining the ledger.
 - Every validator node (`dcld` binary) runs DC Ledger application code (based on Cosmos SDK) implementing the use cases.
 - See the proposed deployment in [deployment](docs/deployment.png) and [deployment-detailed](docs/deployment-detailed.png).
 - See recommended design for DCL MainNet deployment on AWS in [aws deployment](./docs/deployment-design-aws.md)
@@ -54,7 +54,7 @@ In order to send write transactions to the ledger you need:
     - **Private Sentry Node:** a full node to connect other Validator or Sentry nodes only; should not be accessed by clients.
     - **Public Sentry Node:** a full node to connect other external full nodes (possibly observer nodes).
   - **Observer Node (ON):** a full node that doesn't participate in consensus. Should be used to receive read/write requests from the clients.
-- **Light Client Proxy Node**: doesn't contain a full replication of data. Can be used as a proxy to untrusted Full nodes for single-value query requests sent via CLI or Tendermint RPC.
+- **Light Client Proxy Node**: doesn't contain a full replication of data. Can be used as a proxy to untrusted Full nodes for single-value query requests sent via CLI or CometBFT RPC.
   It will verify all state proofs automatically.
 - **Seed Node**: provides a list of peers which a node can connect to.
 
@@ -64,7 +64,7 @@ See
 - [Deployment-detailed](docs/deployment-detailed.png).
 - [Deployment Recommendations](https://github.com/zigbee-alliance/distributed-compliance-ledger/wiki/DCL-MainNet-Deployment)
 - [Deployment Recommendations for AWS](./docs/deployment-design-aws.md)
-- <https://docs.tendermint.com/v0.34/tendermint-core/validators.html>
+- <https://docs.cometbft.com/v0.37/core/validators>
 - [Run Light Client Proxy](docs/running-light-client-proxy.md)
 
 ### Clients
@@ -79,7 +79,7 @@ A Light Client Proxy can be connected to multiple nodes and will verify the stat
 - [CLI](#cli)  
 - [REST](#rest)
 - [gRPC](#grpc)
-- [Tendermint RPC and Light Client](#tendermint-rpc-and-light-client)
+- [CometBFT RPC and Light Client](#cometbft-rpc-and-light-client)
 
 **Please note, that multi-value queries don't have state proofs support and should be sent to trusted nodes only.**
 
@@ -126,7 +126,7 @@ See [Run local pool](README-DEV.md#run-local-pool) section in [README-DEV.md](RE
 
 Should be used if there are no trusted Observer or Validator nodes to connect.
 
-It can be a proxy for CLI or direct requests from code done via Tendermint RPC.
+It can be a proxy for CLI or direct requests from code done via CometBFT RPC.
 
 Please note, that CLI can use a Light Client proxy only for single-value query requests.
 A Full Node (Validator or Observer) should be used for multi-value query requests and write requests.
@@ -139,7 +139,7 @@ See [Run Light Client Proxy](docs/running-light-client-proxy.md) for details how
 
 - **There are no state proofs in REST, so REST queries should be sent to trusted Validator or Observer nodes only.**
 - OpenAPI specification: <https://zigbee-alliance.github.io/distributed-compliance-ledger/>.
-- Any running node exposes a REST API at port `1317`. See <https://docs.cosmos.network/v0.45/core/grpc_rest.html>.
+- Any running node exposes a REST API at port `1317`. See <https://docs.cosmos.network/v0.47/learn/advanced/grpc_rest>.
 - See [transactions](docs/transactions.md) for a full list of endpoints.
 - REST HTTP(S) queries can be directly used for read requests.
   See [How to read from the Ledger](docs/transactions.md#how-to-read-from-the-ledger).
@@ -150,23 +150,23 @@ See [Run Light Client Proxy](docs/running-light-client-proxy.md) for details how
 ### gRPC
 
 - **There are no state proofs in gRPC, so gRPC queries should be sent to trusted Validator or Observer nodes only.**
-- Any running node exposes a REST API at port `9090`. See <https://docs.cosmos.network/v0.45/core/grpc_rest.html>.
+- Any running node exposes a REST API at port `9090`. See <https://docs.cosmos.network/v0.47/learn/advanced/grpc_rest>.
 - A client code can be generated for all popular languages from the proto files [proto](proto), see <https://grpc.io/docs/languages/>.
 - The generated client code can be used for read and write requests, i.e. generation and signing of transactions
   See [How to read from the Ledger](docs/transactions.md#how-to-read-from-the-ledger) and [How to write to the Ledger](docs/transactions.md#how-to-write-to-the-ledger) for details.
 
-### Tendermint RPC and Light Client
+### CometBFT RPC and Light Client
 
-- Tendermint RPC is exposed by every running node  at port `26657`. See <https://docs.cosmos.network/v0.45/core/grpc_rest.html#tendermint-rpc>.
-- Tendermint RPC supports state proofs. Tendermint's Light Client library can be used to verify the state proofs.
+- CometBFT RPC is exposed by every running node  at port `26657`. See <https://docs.cosmos.network/v0.47/learn/advanced/grpc_rest#cometbft-rpc>.
+- CometBFT RPC supports state proofs. CometBFT's Light Client library can be used to verify the state proofs.
     So, if Light Client API is used, then it's possible to communicate with non-trusted nodes.
 - Please note, that multi-value queries don't have state proofs support and should be sent to trusted nodes only.
 - There are currently no DC Ledger specific API libraries for various platforms and languages,
 but they may be provided in the future.
 - The following libraries can be used as light clients:
-  - [Golang Light Client implementation](https://pkg.go.dev/github.com/tendermint/tendermint/lite2)
-  - [Rust Light Client implementation](https://docs.rs/tendermint-light-client/0.23.3/tendermint_light_client/)
-- Refer to [this doc](./docs/tendermint-rpc.md) to see how to [subscribe](./docs/tendermint-rpc.md#subscribe) to a Tendermint WebSocket based events and/or [query](./docs/tendermint-rpc.md#querying-application-components) an application components.
+  - [Golang Light Client implementation](https://pkg.go.dev/github.com/cometbft/cometbft/light)
+  - [Rust Light Client implementation](https://docs.rs/cometbft-light-client/0.1.0-alpha.2/cometbft_light_client/)
+- Refer to [this doc](./docs/cometbft-rpc.md) to see how to [subscribe](./docs/cometbft-rpc.md#subscribe) to a CometBFT WebSocket based events and/or [query](./docs/cometbft-rpc.md#querying-application-components) an application components.
 
 
 ### Instructions
@@ -227,5 +227,5 @@ the following instructions from [how-to.md](docs/how-to.md) can be used for ever
 - [Running Node](docs/running-node.md)
 - [Pool Upgrade](docs/pool-upgrade.md)
 - [Pool Upgrade How To Guide](docs/pool-upgrade-how-to.md)
-- [Tendermint](https://tendermint.com/)
+- [CometBFT](https://cometbft.com/)
 - [Cosmos SDK](https://cosmos.network/sdk)