diff --git a/.github/linters/mlc_config.json b/.github/linters/mlc_config.json index 2f311d3..57dd725 100644 --- a/.github/linters/mlc_config.json +++ b/.github/linters/mlc_config.json @@ -1,5 +1,5 @@ { - "aliveStatusCodes": [0, 200, 202, 206, 403, 501, 999], + "aliveStatusCodes": [0, 200, 202, 206, 403, 429, 501, 999], "replacementPatterns": [ { "pattern": "\" %}", diff --git a/SUMMARY.md b/SUMMARY.md index 6b0da71..7c02c9d 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -9,6 +9,7 @@ * [(Alternative) Install with Docker](docs/setup-and-configure/docker.md) * [Configure cheqd node](docs/setup-and-configure/configure-cheqd-node.md) * [Configure cosmovisor](docs/setup-and-configure/cosmovisor-configuration.md) + * [Configure State Sync](docs/setup-and-configure/set-up-state-sync.md) * [Command Line usage](docs/cheqd-cli/README.md) * [Manage keys](docs/cheqd-cli/cheqd-cli-key-management.md) * [Manage accounts](docs/cheqd-cli/cheqd-cli-accounts.md) diff --git a/docs/setup-and-configure/README.md b/docs/setup-and-configure/README.md index 3d4d28b..885bf06 100644 --- a/docs/setup-and-configure/README.md +++ b/docs/setup-and-configure/README.md @@ -16,7 +16,7 @@ Alternatively, if you want to manage network upgrades manually, you can also opt > > This document specifies the CPU/RAM requirements, firewall ports, and operating system requirements for running cheqd-node. -The interactive installer is written in **Python 3** and is designed to work on **Ubuntu Linux 20.04 LTS** systems. The script has been written to work pre-installed Python 3.x libraries generally available on Ubuntu 20.04. +The interactive installer is written in **Python 3** and is designed to work on **Ubuntu Linux 24.04 LTS** systems. The script has been written to work pre-installed Python 3.x libraries generally available on Ubuntu 24.04. ### Software installed by installer @@ -81,13 +81,13 @@ All the questions specify the default answer/value for that question in square ( Binary release version to install, automatically fetched from Github. The first release displayed in the list will always be the latest stable version. Other versions displayed below it are pre-release/beta versions. ```text -Latest stable cheqd-noded release version is Name: v1.3.0 +Latest stable cheqd-noded release version is Name: v4.1.4 List of cheqd-noded releases: -1. v1.3.0 -2. v1.4.0-develop.1 -3. v1.3.1-develop.1 -4. v1.3.0-develop.3 -5. v1.3.0-develop.2 +1. v4.1.4 +2. v4.1.4-develop.1 +3. v4.1.3 +4. v4.1.3-develop.1 +5. v4.1.2 Choose list option number above to select version of cheqd-node to install [default: 1]: ``` @@ -112,6 +112,7 @@ The next few questions are used to configure Cosmovisor-related options. Read [a 1. `Install cheqd-noded using Cosmovisor? (yes/no) [default: yes]`: Use Cosmovisor to run node 2. `Do you want Cosmovisor to automatically download binaries for scheduled upgrades? (yes/no) [default: yes]`: By default, Cosmovisor will attempt to automatically download new binaries that have passed [software upgrade proposals voted on the network](../upgrades/README.md). You can choose to do this manually if you want more control. 3. `Do you want Cosmovisor to automatically restart after an upgrade? (yes/no) [default: yes]`: By default, Cosmovisor will automatically restart the node after an [upgrade height](../upgrades/README.md) is reached and an upgrade carried out. +4. `Do you want to overwrite existing configuration (or create a new one) for cosmovisor, with the values you provided? (yes/no) [default: yes]`: By default, Cosmovisor will create `config.toml` file under `/home/cheqd/.cheqdnode/cosmovisor`, with values you provided previously. However, the environment variables set in `systemd` file will take precedence over this file, unless you modify the file and pass `--config` flag to cosmovisor. You can also choose `no` to installing with Cosmovisor on the first question, in which case a standalone binary installation is carried out. @@ -131,7 +132,18 @@ See more details about `app.toml` and `config.toml` configuration parameters on 7. `Specify log level (trace|debug|info|warn|error|fatal|panic) [default: error]:`: The default log level of `error` is generally recommended for normal operation. You may temporarily need to change to more verbose logging levels if trying to diagnose issues if the node isn't behaving correctly. 8. `Specify log format (json|plain) [default: json]:`: JSON log format allows parsing log files more easily if there's an issue with your node, hence it's set as the default. -#### 6. Choose whether to restore from snapshot +#### 6. Choose whether to init from State Sync + +In case you don't need full (or significant) blockchain history, you can start your initialize your node via State Sync: + +> [INFO]: State sync rapidly bootstraps a node without downloading full snapshot and uses less storage. You can still choose snapshot (slower, much larger storage) if you decline state sync. + +`Initialize chain via State Sync? (yes/no) [default: yes]:` +This will massively reduce your node operational costs, as required disk space in this case is less than 10GB. +Installer will update `config.toml` file with RPC endpoints to fetch state sync snapshots from, trusted height and trusted block hash. +It will also enable state sync, so after starting the `cheqd-cosmovisor service`, the node will start discovering snapshots, restoring them and start catching up with the network. + +If you skip this step, you will be asked if you want to proceed with state DB snapshot restoration. When setting up a new node, you typically need to download all past blocks on the network, including any upgrades that were done along the way with the specific binary releases those upgrades went through. diff --git a/docs/setup-and-configure/requirements.md b/docs/setup-and-configure/requirements.md index 00a3969..87f4ba0 100644 --- a/docs/setup-and-configure/requirements.md +++ b/docs/setup-and-configure/requirements.md @@ -18,7 +18,14 @@ Extended information on [recommended hardware requirements is available in Tende * 4-8 GB RAM (2 GB RAM minimum) * x64 2.0 GHz 2-4 vCPU or equivalent (x64 1.4 GHz 1 vCPU or equivalent minimum) -* 650 GB SSD (500 GB minimum) + +#### Storage requirements + +Storage requirements may vary, depending on your specific needs: + +* If you need more historic data and you plan to initialize your node by using state DB snapshot, you will need at least 625 GB of SSD storage. +* If you don't need specific historic data, you can use state sync to initialize your node. In this case, your node will start with less than 1GB of disk space consume, but it will keep to grow with time. It's recommended to provide at least 10GB of SSD. +* In case you need full chain history and you want to run an archive node, you will need 2.7 TB of disk storage. For obtaining full chain history snapshot, reach out to our team on Discord. > ⚠️ **Storage requirements for the blockchain grows with time**. Therefore, these minimum storage figures are expected to increase over time. Read our validator guide for "pruning" settings to optimise storage consumed. diff --git a/docs/setup-and-configure/set-up-state-sync.md b/docs/setup-and-configure/set-up-state-sync.md new file mode 100644 index 0000000..0100169 --- /dev/null +++ b/docs/setup-and-configure/set-up-state-sync.md @@ -0,0 +1,66 @@ +# Configure State Sync + +State Sync allows node operators to initialize their nodes quickly with much less storage consumed. +This is really useful in case you don't need full (or significant) chain history and it significantly reduces costs. For comparison, our state DB snapshots published on snapshots.cheqd.net, typically have around 600GB of data, while after State Sync initialization, node consumes only around 540 MB of data. + +## Modifying config.toml file + +In order to enable State Sync, you need to update the Comet BFT configuration file, like this: + +```toml +####################################################### +### State Sync Configuration Options ### +####################################################### +[statesync] +# State sync rapidly bootstraps a new node by discovering, fetching, and restoring a state machine +# snapshot from peers instead of fetching and replaying historical blocks. Requires some peers in +# the network to take and serve state machine snapshots. State sync is not attempted if the node +# has any local state (LastBlockHeight > 0). The node will have a truncated block history, +# starting from the height of the snapshot. +enable = true + +# RPC servers (comma-separated) for light client verification of the synced state machine and +# retrieval of state data for node bootstrapping. Also needs a trusted height and corresponding +# header hash obtained from a trusted source, and a period during which validators can be trusted. +# +# For Cosmos SDK-based chains, trust_period should usually be about 2/3 of the unbonding time (~2 +# weeks) during which they can be financially punished (slashed) for misbehavior. +rpc_servers = "https://eu-rpc.cheqd.net:443,https://ap-rpc.cheqd.net:443" +trust_height = 20748000 +trust_hash = "BD43534FB20E7C163917BC1A501349C68656A9C24EE48C92BB82FFEE687EEE14" +trust_period = "168h0m0s" +``` + +As you can see, first you need to **enable** the State Sync module. +After that, you need to provide **RPC endpoints** that expose and serve state sync snapshots. You can use our public RPC endpoints, as we generate and serve state sync snapshots from them. +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) + +You can also use this simple bash script to update your node configuration: + +```bash +#!/bin/bash +set -euo pipefail + +# set environment variables +export RPC1=https://eu-rpc.cheqd.net:443 # use https://eu-rpc.cheqd.network:443 for testnet +export RPC2=https://ap-rpc.cheqd.net:443 # use https://ap-rpc.cheqd.network:443 for testnet + +INTERVAL=2000 +CONFIG=/home/cheqd/.cheqdnode/config/config.toml + +# GET TRUST HASH AND TRUST HEIGHT +LATEST_HEIGHT=$(curl -s "$RPC1/block" | jq -r .result.block.header.height) +BLOCK_HEIGHT=$((LATEST_HEIGHT-INTERVAL)) +TRUST_HASH=$(curl -s "$RPC1/block?height=$BLOCK_HEIGHT" | jq -r .result.block_id.hash) + +# UPDATE [statesync] block in config.toml (in-place, no backup) +sed -i -E '/^\[statesync\]/,/^\[/{s/^enable\s*=.*/enable = true/}' "$CONFIG" +sed -i -E "/^\[statesync\]/,/^\[/{s|^rpc_servers\s*=.*$|rpc_servers = \"${RPC1},${RPC2}\"|}" "$CONFIG" +sed -i -E "/^\[statesync\]/,/^\[/{s|^trust_height\s*=.*$|trust_height = ${BLOCK_HEIGHT}|}" "$CONFIG" +sed -i -E "/^\[statesync\]/,/^\[/{s|^trust_hash\s*=.*$|trust_hash = \"${TRUST_HASH}\"|}" "$CONFIG" + +echo "Configuration file updated successfully." +```