不重放历史也能入网：CometBFT state sync 的快照与信任锚

从创世重放，是一笔多大成本

跑过 Cosmos 系链的节点运维都熟悉这条分岔：新节点要么老老实实从创世高度一路重放，逐块执行直到追上链头；要么用 CometBFT 内置的 state sync，直接把某个高度的状态机快照取回来恢复。官方规范把两种路径的差距说得毫不含糊——对规模较大的链，逐块重放常常要按天甚至按周计，而快照恢复按应用的不同，可以快上几个数量级。

快照是什么：元数据加一串分块

CometBFT 自己不理解应用的状态，快照完全由 ABCI 应用负责拍。规范给快照定的结构是”一些元数据加任意格式的二进制分块”，元数据里至少有：拍快照的高度（必须在该高度已经提交之后，且不能混入任何更晚高度的数据）、格式编号（应用自己用来给快照格式做版本）、分块总数与快照哈希。一致性是硬性要求：快照必须在单一隔离的高度完成，恢复出来的状态要与其他节点在同一高度独立执行出来的结果完全一致。

新节点怎么找到可信的快照

光有文件不够，还得敢信。规范要求节点在 statesync 配置段里给出两类外部信息：一组 CometBFT RPC 服务器，用来查询和校验快照所在的元数据；以及一个来自可信来源的”可信区块头哈希加对应高度”。流程大致是：新节点接上 P2P 网络后开始发现快照，通过 ListSnapshots 从候选应用处拿到快照清单，用 OfferSnapshot 递给本地应用决定接不接受，接受之后用 LoadSnapshotChunk 循环拉取二进制分块，边下边交给应用恢复，全部完成后节点再按常规流程追块、入共识。

值得留意的是，这条信任锚短得近乎苛刻——本质上你只需要信一个高度和一个哈希。这不是”不需要信任”，而是把信任从”整条历史”压缩到了”一个点”：这个点可以来自你信任的验证者、官方发布页或别的已核验渠道，取谁的、怎么核验，是运维自己的决定。反过来说，网络里愿意拍快照并在线 serve 的节点越多，后来者可选的快照来源才越多——reactor 的职责被规范拆成两半正是这个意思：一半替本地应用把已有快照分发给新节点，一半替空节点去发现并拉取分块，两边缺一边，这条路都走不通。

快是有代价的：历史区块是残缺的

官方规范特意用一段 Note 提醒：state sync 目前不回填历史区块。用快照上来的节点，本地只从所选高度往上有完整块数据，更早的历史是空缺。这不只是”这台机器硬盘省了”的问题——一个网络里用 state sync 起节点的越多，历史区块的可得性、可审计性就越依赖少数保留全历史的节点，规划网络结构和数据可得性时要算进这笔账。

什么时候该用、什么时候不该

可以按角色粗略划线：只做 RPC 读最新状态、或作为验证者快速补位的节点，快照恢复的收益最直接；承担历史查询归档、给轻客户端供数的节点，则应评估重放或额外归档链路，别拿”同步已完成”当作”历史都在”的证明。两条路径也不是互斥的：完全可以先用 state sync 把节点拉进共识，再另行补齐历史数据。

运维排查时的对照点也来自同一份规范：如果一直卡在发现快照，多半是快照源 RPC 或 P2P 网络里根本没有可服务快照的节点（本地应用没有拍快照的，就不会有东西可分发）；如果快照频繁被本地应用拒绝，问题多半出在应用的快照格式与 OfferSnapshot 返回码的处理上——这两类故障的根因分别在网络侧和应用侧，修法完全不同。

提示：以上机制以 CometBFT 官方规范（main 分支）为准，具体方法与返回码可能随版本调整；节点软件配置与密钥保管责任自负，本文内容不构成投资建议。