#303 Upgrade Cosmos-SDK to v0.47.8

- Update docs and helper scripts
- Revert Ansible CI changes

Signed-off-by: Abdulbois <abdulbois.tursunov@dsr-corporation.com>
Signed-off-by: Abdulbois <abdulbois123@gmail.com>

Author: Abdulbois

README-DEV.md

@@ -153,10 +153,12 @@ 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: 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`.
 - 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 +168,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 +196,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,6 +222,13 @@ Re-generate cosmos base openapi (service API from cosmos exposed in DCL) using [
 ./scripts/cosmos-swagger-gen.sh tx
 ```
 
+## 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.
+
+Also don't forget to update the link to the CometBFT RPC in [Swagger UI](docs/index.html).
+
 ## Other
 
 For more details, please have a look at [Cosmos SDK tutorial](https://tutorials.cosmos.network/).

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/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/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.
+- Refer to [this doc](./docs/cometbtf-rpc.md) to see how to [subscribe](./docs/cometbtf-rpc.md#subscribe) to a CometBFT WebSocket based events and/or [query](./docs/cometbtf-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)

app/encoding.go

@@ -9,7 +9,7 @@ import (
 	"github.com/cosmos/cosmos-sdk/x/auth/tx"
 )
 
-// makeEncodingConfig creates an EncodingConfig for an amino based test configuration.
+// makeEncodingConfig creates an EncodingConfig for an amino based configuration.
 func makeEncodingConfig() params.EncodingConfig {
 	amino := codec.NewLegacyAmino()
 	interfaceRegistry := types.NewInterfaceRegistry()
@@ -24,7 +24,7 @@ func makeEncodingConfig() params.EncodingConfig {
 	}
 }
 
-// MakeEncodingConfig creates an EncodingConfig for testing
+// MakeEncodingConfig creates an EncodingConfig
 func MakeEncodingConfig() params.EncodingConfig {
 	encodingConfig := makeEncodingConfig()
 	std.RegisterLegacyAminoCodec(encodingConfig.Amino)

deployment/ansible/roles/bootstrap/defaults/main.yml

@@ -12,3 +12,5 @@
 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 # See the License for the specific language governing permissions and
 # limitations under the License.
+
+

deployment/ansible/roles/bootstrap/molecule/default/tests/test_default.py

@@ -33,6 +33,6 @@ def test_service(host):
         "User=cosmovisor",
         "Group=dcl",
         'Environment="DAEMON_HOME=/var/lib/dcl/.dcl" "DAEMON_NAME=dcld"',
-        "ExecStart=/usr/bin/cosmovisor run start",
+        "ExecStart=/usr/bin/cosmovisor start",
     ]:
         assert prop in svc.content_string

deployment/ansible/roles/configure/defaults/main.yml

@@ -28,6 +28,6 @@ client:
   # <host>:<port> to Tendermint RPC interface for this chain
   node: "tcp://localhost:26657"
   # Transaction broadcasting mode (sync|async|block)
-  broadcast-mode: sync
+  broadcast-mode: block
 config: {}
 app: {}

deployment/cosmovisor.service

@@ -11,7 +11,7 @@ User=ubuntu
 Environment="DAEMON_HOME=/var/lib/ubuntu/.dcl" 
 Environment="DAEMON_NAME=dcld"
 Environment="DAEMON_ALLOW_DOWNLOAD_BINARIES=true"
-ExecStart=/usr/bin/cosmovisor run start
+ExecStart=/usr/bin/cosmovisor start
 
 [Install]
 WantedBy=multi-user.target

docs/tendermint-rpc.md docs/cometbtf-rpc.md

@@ -47,7 +47,8 @@ Here is the list of supported settings:
 - `chain-id <chain id>` - unique chain ID of the network you are going to connect to
 - `output <type>` - Output format (text/json)
 - `node <node-ip>` - Address `<host>:<port>` of the node to connect.
-- `broadcast-mode <mode>` - Write transaction broadcast mode to use (one of: `sync`, `async`, `block`. `block` is default).
+- `broadcast-mode <mode>` - Write transaction broadcast mode to use (one of: `sync`, `async`. `sync` is default). 
+  - Note: In `sync` broadcast mode, to get the actual result of transaction(`dcld tx ..`) one more query call with `txHash` must be executed(`dcld query tx=txHash`)
 
 In order to connect the CLI to a DC Ledger Network (Chain), the following parameters should be used:
 
@@ -336,5 +337,5 @@ Node will be jailed and removed from the active validator set in the following c
 
 Note that jailed node will not be removed from the main index to track validator nodes.
 So it is not possible to create a new node with the same `validator address`.
-In order to unjail the node and return it to the active tendermint validator set the sufficient number of Trustee's approvals is needed
+In order to unjail the node and return it to the active cometbft validator set the sufficient number of Trustee's approvals is needed
 (see authorization rules).

docs/how-to.md

@@ -2,14 +2,14 @@
 
 Light Client Proxy can be used if there are no trusted Full Nodes (Validator or Observers) a client can connect to.
 
-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.
 
 See the following links for details about a Light Client:
 
-- <https://docs.tendermint.com/v0.34/tendermint-core/light-client.html>
+- <https://docs.cometbft.com/main/explanation/core/light-client>
 
 ## Running Light Client Proxy - Short
 
@@ -21,7 +21,7 @@ dcld config node tcp://<light-client-proxy-host>:8888
 
 ## Running Light Client Proxy - Detailed
 
-See <https://docs.tendermint.com/v0.34/tendermint-core/light-client.html> for details
+See <https://docs.cometbft.com/main/explanation/core/light-client> for details
 
 ### 1. Choose Semi-trusted or Non-trusted Nodes for Connection
 
@@ -36,7 +36,7 @@ dcld light <chain-id> -p tcp://<primary-host>:26657 -w tcp://<witness1-host>:266
 
 Light Client Proxy is started at port `8888` by default. It can be changed with `--laddr` argument.
 
-Light Client Proxy will write some information (about headers) to disk. Default location is `~/.tendermint-light`.
+Light Client Proxy will write some information (about headers) to disk. Default location is `~/.cometbft-light`.
 It can be changed with `--dir` argument.
 
 Light Client needs initial height and hash it trusts. If no `--height` and `--hash` arguments provided,

docs/running-light-client-proxy.md

@@ -7,7 +7,7 @@
 - `Private Sentry` - Full Node to connect other (external) Validator Nodes ([Sentry Node Architecture](https://forum.cosmos.network/t/sentry-node-architecture-overview/454))
 - `Public Sentry` - Full Node to connect other (external) Full Nodes
 - `Observer` - Full Node for serving gRPC / REST / RPC clients
-- `Seed` - Full Node for sharing IP addresses of `Public Sentry` Nodes ([Seed Node](https://docs.tendermint.com/))
+- `Seed` - Full Node for sharing IP addresses of `Public Sentry` Nodes ([Seed Node](https://docs.cometbft.com/))
 
 ## DCL network architecture overview