此前称为 Fast Sync 在工作量证明（PoW）区块链中，与链同步和保持共识最新状态其实是同一个过程：下载区块，并找到总工作量最大的那条链。在权益证明（PoS）中，共识过程更复杂，因为它需要节点之间进行多轮通信，以确定下一个应被提交的区块。如果从零开始通过这一过程与区块链同步，往往会耗费很长时间。相比运行实时共识 gossip 协议，直接下载区块并检查验证者的 Merkle 树会快得多。

​
使用 Block Sync

从零启动时，节点会使用 Block Sync 模式。 在该模式下，CometBFT 守护进程的同步速度会比使用实时共识流程快数百倍。完成追平后，守护进程会退出 Block Sync，切换到正常的共识模式。节点运行一段时间后，如果它至少有一个对等节点，且自身高度至少与对等节点报告的最大高度一致，则会被视为已追平。参见IsCaughtUp 方法。 注意：虽然 blocksync 历史上曾有多个版本（v0、v1 和 v2），但除 v0 之外的所有版本都已被弃用，转而采用最简单且最容易理解的算法。 
#######################################################
###       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"

​
AdaptiveSync

这是一个实验性功能。 它已经在多种网络条件和扰动场景下经过测试，但在生产主网链上启用之前，你仍应先针对自己的具体工作负载完成验证。
AdaptiveSync 允许节点同时运行 blocksync 和 consensus。 在默认流程中，节点会先进入 blocksync，完成追平后再切换到 consensus。 在持续负载下（例如繁忙的 RPC 节点），节点可能始终落后并难以追平。 在区块时间较短的情况下，这可能会损害网络活性。 启用 adaptive_sync 后，共识仍会按正常方式工作，但它也可以接收并处理 blocksync 已经获取到的区块。这在节点落后时提供了一条回退路径，使其能够在流量突增期间更快恢复，并继续跟随网络推进。 AdaptiveSync 不会改变共识安全性或终局性规则。它改变的是追平行为，而不是区块有效性规则。

​
范围与兼容性

  • AdaptiveSync 适用于可能暂时落后的节点，尤其是 RPC 负载较重或高吞吐部署场景。
  • 它仍处于实验阶段；请逐步启用，并在大规模推广前先在你自己的网络条件下完成验证。
  • 如果你运行的是混合节点角色（验证者、哨兵、RPC 节点），请分别测试每一种角色。

​
工作原理

  1. 节点照常继续运行共识。
  2. 如果节点落后，blocksync 获取到的区块可以交由共识接收处理。
  3. 如果候选区块已经被共识纳入，则跳过。
  4. 如果尚未被纳入，则通过正常的验证路径接收并应用。
  5. 节点会在短暂的负载高峰期间更快收敛，同时保持正常的共识行为不变。

​
何时使用

如果你的节点可能暂时落后，并且需要更好的恢复能力，可以启用 adaptive_sync：
  • 高吞吐或突发型流量：负载峰值可能会延迟投票处理。
  • 较短的区块时间：较慢的追平速度会更早影响活性。
  • RPC 负载较重的节点：在高请求量期间可能会出现落后。
如果你的网络比较稳定，且节点始终能够跟上进度，那么默认模式可能已经足够。 注意：
  • 在追平窗口期间运行这条回退路径，可能会略微增加 CPU 和 I/O 开销
  • 持续处理 blocksync 消息可能会增加网络流量。
  • 收益在临时过载场景下最为明显。

​
配置

AdaptiveSync 默认关闭。 要启用它，请在 config.toml 的 [blocksync] 部分中设置 adaptive_sync = true： 
[blocksync]
version = "v0"
adaptive_sync = true

​
指标

# counter: blocksync block was already included by consensus --> skip
cometbft_blocksync_already_included_blocks

# counter: blocksync block was ingested by consensus --> ingest
cometbft_blocksync_ingested_blocks

# histogram: duration of ingesting a non-skipped block
cometbft_blocksync_ingested_block_duration_bucket
cometbft_blocksync_ingested_block_duration_count
cometbft_blocksync_ingested_block_duration_sum
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 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 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. 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. 
#######################################################
###       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"

​
AdaptiveSync

This is an experimental feature. It has been tested under a range of network conditions and perturbations, but you should validate it for your specific workload before enabling it on a production mainnet chain.
AdaptiveSync allows a node to run blocksync and consensus at the same time. In the default flow, a node starts in blocksync, catches up, then switches to consensus. Under sustained load (for example, busy RPC nodes), a node can remain behind and struggle to catch up. With short block times, this can hurt network liveness. With adaptive_sync enabled, consensus still works normally, but it can also ingest already available blocks from blocksync. This acts as a fallback path when a node is behind, allowing it to recover more quickly during traffic spikes and continue progressing with the network. AdaptiveSync does not change consensus safety or finality rules. It changes catch-up behavior, not block validity rules.

​
Scope and compatibility

  • AdaptiveSync is intended for nodes that can temporarily lag, especially RPC-heavy or high-throughput deployments.
  • It is experimental; enable it gradually and validate in your own network conditions before broad rollout.
  • If you run mixed node roles (validators, sentries, RPC nodes), test each role separately.

​
How it works

  1. The node continues running consensus as usual.
  2. If the node is behind, blocks obtained by blocksync can be handed to consensus ingestion.
  3. If a candidate block is already included by consensus, it is skipped.
  4. If not already included, it is ingested and applied through normal validation paths.
  5. The node converges faster during transient load spikes while preserving normal consensus behavior.

​
When to use it

Enable adaptive_sync if your nodes can temporarily fall behind and need better recovery behavior:
  • High-throughput or bursty traffic where load spikes can delay vote processing.
  • Short block times where slow catch-up can impact liveness sooner.
  • RPC-heavy nodes that may lag during periods of high request volume.
If your network is stable and nodes consistently keep up, the default mode may already be sufficient. Notes:
  • Running this fallback path may slightly increase CPU and I/O during catch-up windows
  • Constant blocksync message processing may increase network traffic.
  • Gains are most visible during temporary overload.

​
Configuration

AdaptiveSync is disabled by default. To enable it, set adaptive_sync = true in the [blocksync] section of config.toml: 
[blocksync]
version = "v0"
adaptive_sync = true

​
Metrics

# counter: blocksync block was already included by consensus --> skip
cometbft_blocksync_already_included_blocks

# counter: blocksync block was ingested by consensus --> ingest
cometbft_blocksync_ingested_blocks

# histogram: duration of ingesting a non-skipped block
cometbft_blocksync_ingested_block_duration_bucket
cometbft_blocksync_ingested_block_duration_count
cometbft_blocksync_ingested_block_duration_sum