diff --git a/architecture/adr-list/adr-005-genesis-parameters.md b/architecture/adr-list/adr-005-genesis-parameters.md index fdf9f34..5632bb5 100644 --- a/architecture/adr-list/adr-005-genesis-parameters.md +++ b/architecture/adr-list/adr-005-genesis-parameters.md @@ -22,7 +22,7 @@ Genesis consists of Tendermint consensus engine parameters and Cosmos app-specif ## Tendermint consensus parameters -Tendermint requires [genesis parameters](https://docs.cometbft.com/v0.34/core/using-cometbft#genesis) to be defined for basic consensus conditions on any Cosmos network. +Tendermint requires [genesis parameters](https://docs.cometbft.com/v0.38/core/using-cometbft#genesis) to be defined for basic consensus conditions on any Cosmos network. ### Block parameters @@ -185,4 +185,4 @@ The parameters above were agreed separate the cheqd mainnet and testnet paramete ## References * [List of Cosmos modules](https://docs.cosmos.network/main/modules) -* [Tendermint genesis parameters](https://docs.cometbft.com/v0.34/core/using-cometbft#genesis) +* [Tendermint genesis parameters](https://docs.cometbft.com/v0.38/core/using-cometbft#genesis) diff --git a/docs/build-and-networks/docker-build.md b/docs/build-and-networks/docker-build.md index a286270..c811293 100644 --- a/docs/build-and-networks/docker-build.md +++ b/docs/build-and-networks/docker-build.md @@ -13,7 +13,7 @@ These advanced instructions are intended for developers who want to build their 1. Docker Engine v20.10.x and above (use `docker -v` to check) 2. Docker Compose v2.3.x and above (use `docker compose version` to check) -Our Docker Compose files [use Compose v2 syntax](https://docs.docker.com/compose/compose-v2/). The primary difference in usage is that Docker Compose's new implementation uses `docker compose` commands (with a space), rather than the legacy `docker-compose` although they are supposed to be drop-in replacements for each other. +Our Docker Compose files [use Compose v2 syntax](https://docs.docker.com/reference/compose-file/). The primary difference in usage is that Docker Compose's new implementation uses `docker compose` commands (with a space), rather than the legacy `docker-compose` although they are supposed to be drop-in replacements for each other. ### Special guidance for Mac OS running on Apple silicon (M-series chips) diff --git a/docs/setup-and-configure/docker.md b/docs/setup-and-configure/docker.md index 9cdccd1..0152b80 100644 --- a/docs/setup-and-configure/docker.md +++ b/docs/setup-and-configure/docker.md @@ -15,7 +15,7 @@ Docker-based installations are useful when running non-validator (observer) node 1. Docker Engine v20.10.x and above (use `docker -v` to check) 2. Docker Compose v2.3.x and above (use `docker compose version` to check) -Our Docker Compose files [use Compose v2 syntax](https://docs.docker.com/compose/compose-v2/). The primary difference in usage is that Docker Compose's new implementation uses `docker compose` commands (with a space), rather than the legacy `docker-compose` although they are supposed to be drop-in replacements for each other. +Our Docker Compose files [use Compose v2 syntax](https://docs.docker.com/reference/compose-file/). The primary difference in usage is that Docker Compose's new implementation uses `docker compose` commands (with a space), rather than the legacy `docker-compose` although they are supposed to be drop-in replacements for each other. ### Special guidance for Mac OS running on Apple silicon (M-series chips) diff --git a/docs/setup-and-configure/requirements.md b/docs/setup-and-configure/requirements.md index 87f4ba0..dca0641 100644 --- a/docs/setup-and-configure/requirements.md +++ b/docs/setup-and-configure/requirements.md @@ -12,7 +12,7 @@ For most nodes, the RAM/vCPU requirements are relatively static and do not chang It is recommended to **mount disk storage for blockchain data as an expandable volume/partition separate from your root partition**. This allows you mount the node data/configuration path on `/home` (for example) and increase the storage if necessary *independent* of the root `/` partition since hosting providers typically force an increase in CPU/RAM specifications to grow the root partition. -Extended information on [recommended hardware requirements is available in Tendermint documentation](https://docs.cometbft.com/main/explanation/core/running-in-production#hardware). The figures below have been updated from the default Tendermint recommendations to account for current cheqd network chain size, real-world usage accounting for requests nodes need to handle, etc. +Extended information on [recommended hardware requirements is available in Tendermint documentation](https://docs.cometbft.com/v0.38/core/running-in-production#hardware). The figures below have been updated from the default Tendermint recommendations to account for current cheqd network chain size, real-world usage accounting for requests nodes need to handle, etc. ### Recommended hardware specifications @@ -60,13 +60,13 @@ The P2P port is used for peer-to-peer communication between nodes. This port is * Outbound TCP connections must be allowed on *all* ports to *any* IP address range. * The default P2P port can be changed in `$HOME/.cheqdnode/config/config.toml`. -Further details on [how P2P settings work is defined in Tendermint documentation](https://docs.cometbft.com/main/explanation/core/running-in-production#p2p). +Further details on [how P2P settings work is defined in Tendermint documentation](https://docs.cometbft.com/v0.38/core/running-in-production#p2p). ### RPC port The RPC port is intended to be used by client applications as well as the cheqd-node CLI. Your RPC port **must** be active and available on localhost to be able to use the CLI. It is up to a node operator whether they want to expose the RPC port to public internet. -The [RPC endpoints for a node](https://docs.cometbft.com/main/explanation/core/rpc) provide REST, JSONRPC over HTTP, and JSONRPC over WebSockets. These API endpoints can provide useful information for node operators, such as healthchecks, network information, validator information etc. +The [RPC endpoints for a node](https://docs.cometbft.com/v0.38/core/rpc) provide REST, JSONRPC over HTTP, and JSONRPC over WebSockets. These API endpoints can provide useful information for node operators, such as healthchecks, network information, validator information etc. * By default, the RPC port is set to `26657` * Inbound and outbound TCP connections should be allowed from destinations desired by the node operator. The default is to allow this from any IPv4 address range. @@ -82,7 +82,7 @@ In addition to the P2P/RPC ports above, you need to allow the following ports in ### Sentry nodes (optional) -Tendermint allows more complex setups in production, where the ingress/egress to a validator node is [proxied behind a "sentry" node](https://docs.cometbft.com/main/explanation/core/validators). +Tendermint allows more complex setups in production, where the ingress/egress to a validator node is [proxied behind a "sentry" node](https://docs.cometbft.com/v0.38/core/validators). While this setup is not compulsory, node operators with higher stakes or a need to have more robust network security may consider setting up a sentry-validator node architecture. @@ -94,5 +94,5 @@ If you're not running a validator node, or if you want more advanced control on ## Further information -* Tendermint documentation has [best practices for running a Cosmos node in production](https://docs.cometbft.com/main/explanation/core/running-in-production). +* Tendermint documentation has [best practices for running a Cosmos node in production](https://docs.cometbft.com/v0.38/core/running-in-production). * [Сosmovisor could be used for automatic upgrades](https://docs.cosmos.network/main/tooling/cosmovisor); however in our testing so far this method has not been reliable and is therefore currently not recommended. diff --git a/docs/setup-and-configure/set-up-state-sync.md b/docs/setup-and-configure/set-up-state-sync.md index 0100169..725a8e3 100644 --- a/docs/setup-and-configure/set-up-state-sync.md +++ b/docs/setup-and-configure/set-up-state-sync.md @@ -36,7 +36,7 @@ After that, you need to provide **RPC endpoints** that expose and serve state sy After that, you need to add the `trust_height` - this is usually $CURRENT_BLOCK_HEIGHT - 2000 blocks (which is the interval at we generate new snapshots on our RPC nodes). Finally, you need to add the block ID hash, as `trust_hash` parameter. This can be fetched via RPC, like this - `https://rpc.cheqd.net/block?height=20748000`. You will find block hash under `.result.block_id.hash`. -Reference: [CometBFT State Sync docs](https://docs.cometbft.com/v0.34/core/state-sync) +Reference: [CometBFT State Sync docs](https://docs.cometbft.com/v0.38/core/state-sync) You can also use this simple bash script to update your node configuration: diff --git a/docs/validator-guide/README.md b/docs/validator-guide/README.md index 5b4c657..1804d6c 100644 --- a/docs/validator-guide/README.md +++ b/docs/validator-guide/README.md @@ -65,13 +65,25 @@ P.S. in case of using Ledger Nano device it would be helpful to use [this instru You can decide how many tokens you would like to stake from your account balance. For instance, you may want to leave a portion of the balance for paying transaction fees (now and in the future). - To promote to validation, submit a `create-validator` transaction to the network: + To promote to validation, first prepare a json file with all the validator information named `validator.json`: - ```bash - cheqd-noded tx staking create-validator --amount --from --chain-id --min-self-delegation --gas auto --gas-adjustment --gas-prices --pubkey --commission-max-change-rate --commission-max-rate --commission-rate - ``` +```bash +{ + "pubkey": {"@type":"/cosmos.crypto.ed25519.PubKey","key":"4anVUO8WhmRMqG1t4z6VxqmqZL3V7q6HqucjwZePiUw="}, + "amount": "1000000000ncheq", + "moniker": "mainnet-validator-name", + "identity": "optional identity signature (ex. UPort or Keybase)", + "website": "validator's (optional) website", + "security": "validator's (optional) security contact email", + "details": "validator's (optional) details", + "commission-rate": "0.1", + "commission-max-rate": "0.2", + "commission-max-change-rate": "0.01", + "min-self-delegation": "1" +} +``` - Parameters required in the transaction above are: + Parameters required in the json file above are: * **`amount`**: Amount of tokens to stake. You should stake at least 1 CHEQ (= 1,000,000,000ncheq) to successfully complete a staking transaction. * **`from`**: Key alias of the node operator account that makes the initial stake @@ -80,21 +92,17 @@ P.S. in case of using Ledger Nano device it would be helpful to use [this instru * **`commission-rate`**: Validator's commission rate. The minimum is set to `0.05`. * **`commission-max-rate`**: Validator's maximum commission rate, expressed as a number with up to two decimal points. The value for this cannot be changed later. * **`commission-max-change-rate`**: Maximum rate of change of a validator's commission rate per day, expressed as a number with up to two decimal points. The value for this cannot be changed later. - * **`chain-id`**: Unique identifier for the chain. - * For cheqd's current mainnet, this is `cheqd-mainnet-1` - * For cheqd's current testnet, this is `cheqd-testnet-6` - * **`gas`**: Maximum gas to use for *this specific* transaction. Using `auto` uses Cosmos's auto-calculation mechanism, but can also be specified manually as an integer value. - * **gas-adjustment** (optional): If you're using `auto` gas calculation, this parameter multiplies the auto-calculated amount by the specified factor, e.g., `1.4`. This is recommended so that it leaves enough margin of error to add a bit more gas to the transaction and ensure it successfully goes through. - * **`gas-prices`**: Maximum gas price set by the validator. Default value is `5000ncheq`. -Please note the parameters below are just an “**example**”. +Please note the parameters mentioned are just an “**example**”. When setting parameters such as the commission rate, a good benchmark is to consider the [commission rates set by validators on existing networks such as Cosmos ATOM chain](https://www.mintscan.io/cosmos/validators). You will see the commission they set, the max rate they set, and the rate of change. Please use this as a guide when thinking of your own commission configurations. This is important to get right, because the `commission-max-rate` and `commission-max-change-rate` cannot be changed after they are initially set. +Submit the `create-validator` transaction to the chain: + ```bash - cheqd-noded tx staking create-validator --amount 1000000000ncheq --from key-alias-name --moniker mainnet-validator-name --chain-id cheqd-mainnet-1 --min-self-delegation="1" --gas auto --gas-adjustment 1.4 --gas-prices="5000ncheq" --pubkey '{"@type":"/cosmos.crypto.ed25519.PubKey","key":"4anVUO8WhmRMqG1t4z6VxqmqZL3V7q6HqucjwZePiUw="}' --commission-max-change-rate 0.01 --commission-max-rate 0.2 --commission-rate 0.05 --node https://rpc.cheqd.net:443 +cheqd-noded tx staking create-validator path/to/validator.json --from key-alias-name --gas auto --gas-adjustment 1.4 --gas-prices="5000ncheq" --node https://rpc.cheqd.net:443 ``` 1. **Check that your validator node is bonded** diff --git a/docs/validator-guide/cpu-memory.md b/docs/validator-guide/cpu-memory.md index ea00958..9f83438 100644 --- a/docs/validator-guide/cpu-memory.md +++ b/docs/validator-guide/cpu-memory.md @@ -4,7 +4,7 @@ Blockchain applications (especially when running validator nodes) are a-typical from "traditional" web server applications because their performance characteristics tend to be different in the way specified below: -1. **Tend to be more disk I/O heavy**: Traditional web apps will typically offload data storage to persistent stores such as a database. In case of a blockchain/validator node, the database *is* on the machine itself, rather than offloaded to separate machine with a standalone engine. Many blockchains use [LevelDB](https://github.com/google/leveldb) for their local data copies. (In Cosmos SDK apps, such as cheqd, this is the [Golang implementation of LevelDB](https://github.com/syndtr/goleveldb), but can also be [C-implementation of LevelDB](https://docs.cometbft.com/main/tutorials/install), [RocksDB](https://rocksdb.org/), etc.) The net result is the same as if you were trying to run a database engine on a machine: the system needs to have fast read/write performance characteristics. +1. **Tend to be more disk I/O heavy**: Traditional web apps will typically offload data storage to persistent stores such as a database. In case of a blockchain/validator node, the database *is* on the machine itself, rather than offloaded to separate machine with a standalone engine. Many blockchains use [LevelDB](https://github.com/google/leveldb) for their local data copies. (In Cosmos SDK apps, such as cheqd, this is the [Golang implementation of LevelDB](https://github.com/syndtr/goleveldb), but can also be [C-implementation of LevelDB](https://docs.cometbft.com/v0.38/guides/install#compile-with-cleveldb-support), [RocksDB](https://rocksdb.org/), etc.) The net result is the same as if you were trying to run a database engine on a machine: the system needs to have fast read/write performance characteristics. 2. **Validator nodes cannot *easily* be auto-scaled**: Many traditional applications can be *horizontally* (i.e., add more machines) or *vertically* (i.e., make current machine beefier) scaled. While this is *possible* for validator nodes, it must be done with extreme caution to ensure there aren't two instances of the same validator active simultaneously. This can be perceived by network consensus as a sign of compromised validator keys and lead to the [node being jailed for double-signing blocks](unjail.md). These concerns are less relevant for non-validating nodes, since they have a greater tolerance for missed blocks and *can* be scaled horizontally/vertically. 3. **Docker/Kubernetes setups are not recommended for validators** (unless you *really* know what you're doing): Primarily due to the double-signing risk, it's (../setup-and-configure/docker.md) unless you have a strong DevOps practice. The other reason is related to the first point, i.e., a Docker setup adds an abstraction layer between the actual underlying file-storage vs the Docker volume engine. Depending on the Docker (or similar abstraction) storage drivers used, you may need to [tune the storage/volume engine options](https://docs.docker.com/storage/storagedriver/select-storage-driver/) for optimal performance. @@ -54,7 +54,7 @@ If you don't have a monitoring application installed, you could use the built-in Unfortunately, this only provides the **real-time** usage, rather than historical usage over time. Historical usage typically requires an external application, which many cloud providers provide, or through 3rd party monitoring tools such as [Datadog](https://www.datadoghq.com/), etc. -[Tendermint / Cosmos SDK also provides a Prometheus metrics interface](https://docs.cometbft.com/v0.34/core/metrics), in case you already have a Prometheus instance you can use or comfortable with using the software. This can allow alerting based on actual metrics emitted by the node, rather than just top-level system metrics which are a blunt instrument / don't go into detail. +[Tendermint / Cosmos SDK also provides a Prometheus metrics interface](https://docs.cometbft.com/v0.38/core/metrics), in case you already have a Prometheus instance you can use or comfortable with using the software. This can allow alerting based on actual metrics emitted by the node, rather than just top-level system metrics which are a blunt instrument / don't go into detail. ## Troubleshooting system clock synchronisation issues diff --git a/docs/validator-guide/faq.md b/docs/validator-guide/faq.md index 1532ea6..d74124a 100644 --- a/docs/validator-guide/faq.md +++ b/docs/validator-guide/faq.md @@ -108,7 +108,7 @@ We have also [built a tool](https://github.com/cheqd/validator-status) internall Please join the channel 'mainnet-alerts' on the cheqd community slack. -In addition to that, [Cosmos/Tendermint also provide a Prometheus metrics interface](https://docs.cometbft.com/v0.34/core/metrics) (for those who already use it for monitoring/want to set one up) that has metrics for monitoring node status (and a lot more). +In addition to that, [Cosmos/Tendermint also provide a Prometheus metrics interface](https://docs.cometbft.com/v0.38/core/metrics) (for those who already use it for monitoring/want to set one up) that has metrics for monitoring node status (and a lot more). ## **Are there any other ways to optimise?**