Skip to content

Commit 51dc55a

Browse files
mergify[bot]ziscky
andauthored
docs: add syncing documentation (backport #23344) (#23474)
Co-authored-by: Eric Mokaya <[email protected]>
1 parent 27ff1eb commit 51dc55a

File tree

1 file changed

+102
-0
lines changed

1 file changed

+102
-0
lines changed

Diff for: docs/learn/advanced/18-syncing.md

+102
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,102 @@
1+
---
2+
sidebar_position: 1
3+
---
4+
5+
# Syncing
6+
7+
Syncing is the process of downloading the blockchain and state from a remote node.
8+
9+
There are the following types of syncing:
10+
11+
1. Genesis Sync: operator downloads genesis, sets peers and syncs the blockchain by executing all blocks since genesis.
12+
> **NOTE:** requires a peer node that doesn't prune blocks (CometBFT state).
13+
14+
2. State Sync: operator need to set `trust_height` and `trust_hash` of a block that s/he trusts as well as `trust_period` - the time how long the operator will trust the given block height. The app will query peer nodes to stream state from that blocks as well as all following blocks. Once the state is downloaded, the node will start executing all blocks since the `trust_height`.
15+
> **NOTE:** requires a peer node that provides a state sync and is trusted by the validator.
16+
17+
3. Snapshot Sync: operator downloads a snapshot from snapshot provider (usually validators) s/he trusts. From there the operator needs to unpack the snapshot to the node directory, update config, set peers, set moniker, setup validator keys. Once the data directory is properly configured, the validator can start a node. The node will query blocks since the snapshot and execute them.
18+
> **NOTE:** requires a snapshot directory that is trusted by the validator.
19+
20+
Genesis Sync has zero trust assumptions, but it's the most resource heavy. It also requires a node with all blocks - many validators prune the blocks to optimize space.
21+
22+
23+
24+
## Observing syncing progress
25+
26+
> ### Note: This section applies to comet users
27+
>
28+
> To enable the Prometheus metrics, set `instrumentation.prometheus=true` in your config file. Metrics will be served under `/metrics` on `26660` port by default. Listen address can be changed in the config file (see `instrumentation.prometheus_listen_addr`).
29+
>
30+
> More [here](https://github.com/cometbft/cometbft/blob/main/docs/explanation/core/metrics.md).
31+
32+
### Block Sync Metrics
33+
34+
They are defined [here](https://github.com/cometbft/cometbft/blob/main/internal/blocksync/metrics.go) and are accessible from the node's metrics endpoint.
35+
36+
- `blocksync_syncing`: Indicates whether a node is currently block syncing.
37+
- `blocksync_num_txs`: Number of transactions in the latest block.
38+
- `blocksync_total_txs`: Total number of transactions.
39+
- `blocksync_block_size_bytes`: Size of the latest block in bytes.
40+
- `blocksync_latest_block_height`: Height of the latest block.
41+
42+
### Block sync configuration
43+
44+
```toml
45+
[blocksync]
46+
version = "v0" # version of the block sync protocol to use
47+
```
48+
49+
### State Sync Metrics
50+
51+
They are defined [here](https://github.com/cometbft/cometbft/blob/main/statesync/metrics.go) and are accessible from the node's metrics endpoint.
52+
53+
- `statesync_syncing`: Indicates whether a node is currently state syncing.
54+
55+
### State sync configuration
56+
57+
```toml
58+
[statesync]
59+
enable = true # set to true to enable state sync
60+
rpc_servers = "" # comma-separated list of RPC servers for state sync
61+
trust_height = 0 # block height to trust for state sync
62+
trust_hash = "" # block hash to trust for state sync
63+
trust_period = "168h0m0s" # trust period for light client verification
64+
discovery_time = "15s" # time to spend discovering snapshots before picking one
65+
temp_dir = "" # directory for temporary state sync files
66+
chunk_request_timeout = "10s" # timeout for chunk requests
67+
chunk_fetchers = "4" # number of concurrent chunk fetchers
68+
```
69+
70+
### Checking if sync is complete
71+
72+
Query the status using the app cli:
73+
74+
```bash
75+
app q consensus comet syncing
76+
```
77+
78+
Query for the node status using the REST or GRPC API:
79+
80+
REST example:
81+
```bash
82+
curl http://localhost:1317/cosmos/base/tendermint/v1beta1/syncing
83+
```
84+
85+
Expected response:
86+
```json
87+
{
88+
"syncing": false
89+
}
90+
```
91+
92+
GRPC example:
93+
```bash
94+
grpcurl -plaintext localhost:9090 cosmos.base.tendermint.v1beta1.Service/GetSyncing
95+
```
96+
97+
The response includes `SyncInfo.CatchingUp` field
98+
Syncing is complete when this field is `false`
99+
100+
101+
102+

0 commit comments

Comments
 (0)