Some checks are pending
docker-build-cometbft / vars (push) Waiting to run
docker-build-cometbft / build-images (amd64, ubuntu-24.04) (push) Blocked by required conditions
docker-build-cometbft / build-images (arm64, ubuntu-24.04-arm) (push) Blocked by required conditions
docker-build-cometbft / merge-images (push) Blocked by required conditions
docker-build-e2e-node / vars (push) Waiting to run
docker-build-e2e-node / build-images (amd64, ubuntu-24.04) (push) Blocked by required conditions
docker-build-e2e-node / build-images (arm64, ubuntu-24.04-arm) (push) Blocked by required conditions
docker-build-e2e-node / merge-images (push) Blocked by required conditions
49 lines
1.9 KiB
Markdown
49 lines
1.9 KiB
Markdown
---
|
|
order: 10
|
|
---
|
|
|
|
# Block Sync
|
|
|
|
*Formerly known as Fast Sync*
|
|
|
|
In a proof of work blockchain, syncing with the chain is the same
|
|
process as staying up-to-date with the consensus: download blocks, and
|
|
look for the one with the most total work. In proof-of-stake, the
|
|
consensus process is more complex, as it involves rounds of
|
|
communication between the nodes to determine what block should be
|
|
committed next. Using this process to sync up with the blockchain from
|
|
scratch can take a very long time. It's much faster to just download
|
|
blocks and check the merkle tree of validators than to run the real-time
|
|
consensus gossip protocol.
|
|
|
|
## Using Block Sync
|
|
|
|
When starting from scratch, nodes will use the Block Sync mode.
|
|
In this mode, the CometBFT daemon
|
|
will sync hundreds of times faster than if it used the real-time consensus
|
|
process. Once caught up, the daemon will switch out of Block Sync and into the
|
|
normal consensus mode. After running for some time, the node is considered
|
|
`caught up` if it has at least one peer and its height is at least as high as
|
|
the max reported peer height. See [the IsCaughtUp
|
|
method](https://github.com/cometbft/cometbft/blob/v0.38.x/blocksync/pool.go#L168).
|
|
|
|
Note: While there have historically been multiple versions of blocksync, v0, v1, and v2, all versions
|
|
other than v0 have been deprecated in favor of the simplest and most well understood algorithm.
|
|
|
|
```toml
|
|
#######################################################
|
|
### Block Sync Configuration Options ###
|
|
#######################################################
|
|
[blocksync]
|
|
|
|
# Block Sync version to use:
|
|
#
|
|
# In v0.37, v1 and v2 of the block sync protocols were deprecated.
|
|
# Please use v0 instead.
|
|
#
|
|
# 1) "v0" - the default block sync implementation
|
|
version = "v0"
|
|
```
|
|
|
|
If we're lagging sufficiently, we should go back to block syncing, but
|
|
this is an [open issue](https://github.com/tendermint/tendermint/issues/129).
|