在工作量证明链上，“追块”和”保持同步”是同一件事：下载区块、找累计工作量最大的那条。权益证明链不成立——下一个区块由谁提交，要节点之间多轮通信投票来定。让一台落后的节点从头重放这些共识回合，会把追赶时间拉到难以忍受的量级。CometBFT 官方的解法叫 Block Sync（此前叫 Fast Sync），文档给出的速度对照是：比用真实共识流程同步快数百倍。
不陪跑共识回合，速度从哪来
区块同步的思路是跳过沟通环节：直接批量下载历史区块，用验证者默克尔树核验每个区块的签名集合，而不去模拟实时共识的提议与投票。追上之后，节点自动退出同步模式、切回正常共识模式。判定”追上了”的标准也很朴素：至少有一个对端，且自己的高度不低于所有对端报告的最大高度。配置层面需要注意，这个模块历史上出过 v0、v1、v2 三个版本，官方文档明确 v0.37 起其余版本全部弃用，统一回到最简单、最容易被理解的 v0 算法——配置项 version 写 v0 即可。
adaptive_sync：让两条路同时走
同步与共识原本严格先后接力。实验性开关 adaptive_sync 改变这个顺序：打开后，区块同步和共识并行运行，区块到达后直接经共识内部管道被吞入，官方文档称其能改善追块期间的活跃度、连接性与性能。代价是一段被官方用警告块标注的风险窗口。
并行窗口里，验证者可能签出矛盾票
共识一旦被立刻启动，只要节点还在验证者集合里，签名逻辑就会被触发。设想一台正在追块的验证者：它的共识线程在高度 H 给区块 B 签了票，而与此同时，区块同步的吞入线程在同一高度提交了网络早已定夺的另一个区块。两份签名的冲突发生在不同的（高度、轮次、步骤）元组上——这意味着本地防双签的最后两道保险，HRS 状态文件和远程签名器的双重签名保护，都不会在这里触发。官方文档的结论写得很硬：只有理解并接受这一风险的人，才应在验证者节点上启用 adaptive_sync；非验证者的全节点不受此风险影响，因为它们的共识引擎不签票。
运维与查询各自盯什么
节点运维者可以把两件事当默认：同步模式保持 version 为 v0；验证者节点默认不开 adaptive_sync，追块的稳定性优先于那点并行收益。还有一处细节值得记住：节点落后足够多时是否自动退回区块同步，官方文档标注这是一个仍未彻底解决的开放问题——换句话说，长期落后的节点可能一直在用慢速共识模式硬撑，需要运维自己监控高度差。判定追上的条件同样有边角：刚连上第一个对端、或对端普遍落后时，“高度不低于对端最大值”可能提前为真，这时节点看着正常，实际仍与网络主流状态有距离，把追块监控做成对多个独立节点交叉比对高度比单看一台更可靠。
区块同步与状态同步是两条互补的路：前者逐块下载区块并核验签名，保留完整历史区块记录；后者直接拉状态快照跳过逐块重放。选哪条取决于要多快的可用性、又能接受放弃哪些历史查询能力。对普通用户，节点处在哪种同步模式都不改变链上资产，但查询打到一台落后节点上，读到的就是旧状态：对时间敏感的核对，值得用第二个来源交叉一次。以上是节点机制与运行风险的说明，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。