分阶段同步是什么？节点为什么把同步拆成一串流水线

不是”一路同步到底”，而是流水线上的一站一站

多数节点软件把同步当成一件事：边下载边执行边落库。Erigon 的官方设计文档选了另一条路：把同步拆成一串有固定顺序的命名阶段——下载区块头、建哈希索引、下载区块体、恢复交易签名者、执行、计算状态根、建交易索引等等。每个阶段有各自的进度记录，独立向前推进：阶段一不到本地头，阶段二不会开跑；但阶段二可能远远落后于阶段一，落后的量级和落盘节奏都由数据库里的进度字段说话。

每个阶段带两个方向的函数：向前推进的执行函数，和向后回退的撤销函数。这个对称性是整篇故事的关键，先记住它。

阶段序列不是随便排的。到下载区块体为止的几站使用网络，绝大部分流量发生在这里；从恢复签名者开始的后续站可以完全离线运转——执行阶段逐块重放交易，不查默克尔根、不联网，只做磁盘密集的状态变更。把”要网络的”和”要磁盘的”切开后，节点行为变得可拆解：断网的机器可以靠已下载的数据继续追赶；网络抖动只卡前面几站，后面已经完成的工序不用重做。

早期版本的执行阶段还有一处刻意的省：执行时不做状态根校验，校验推迟到下一阶段集中做——先建默克尔树、比对根哈希，对不上就回退。校验从每块一次的串行等待，变成一段区间一次的整体核对，失败的代价被摊到块级而非笔级。

重组来了：整条流水线倒着走一遍

链发生重组时，Erigon 的做法不是把数据库推倒重来，而是触发一次”回退到目标块”：每个阶段按相反顺序调用各自的撤销函数，各自只清理自己那部分数据——哈希索引抹掉多余条目，交易索引删掉失效映射，执行阶段沿变更历史反向恢复状态。全部撤销完成后，流水线从新的链尖重新向前。

这正是前面那个对称性的用处：因为每个阶段只拥有自己的产物、也只撤销自己的产物，回退不需要全局事务协调。设计文档也提到，绝大多数回退正是由重组在执行阶段触发。一次重组对主流水线来说，只是流水倒转一次、再重新进料。

对新用户与运维的实际含义

从使用者视角，这套结构解释了三件事。第一，进度条不是一格：链头高度、执行高度、索引高度是分开推进的，某站落后不代表别的站在偷懒，RPC 返回数据不全常常只是索引站还没到。第二，磁盘形态不同：分阶段流水线配合快照文件时，初始同步可以跳过从头重放历史的路径，历史查询走快照而不是活数据库。第三，故障恢复更像”续跑”：进程中断后从各阶段进度处继续，而不是从头再来。

也要说清代价：流水线意味着同一份数据在库里可能有多份表示，空间换时间；阶段间依赖固定，加站减站要守顺序；重组频繁时倒着走的成本真实存在。它赌的假设是重组少、顺序扫描多，这个假设在以太坊主网的历史上大体成立。

还有一处容易被忽略的细节：阶段进度本身是数据库里的持久字段，进程崩溃重启后，每个阶段从自己的进度记录上继续，而不是从头协商一遍谁做到哪了。这让”重启”在多数场景里是廉价操作，也意味着磁盘上的进度文件和数据库若被部分恢复（比如只回滚了数据文件没回滚进度记录），阶段间会出现对不齐的异常状态——这类不一致的修复手段通常是重建受影响的那一站，而不是手工改进度数字。理解这一点，也能理解为什么新版本的同步路径要在下载快照文件时逐分片校验哈希、先验证再续跑：流水线的信任基础是每一站的账都自洽，账不自洽时宁可重算也不能带病前进。本文是机制说明，不构成任何投资建议。