从零同步一个以太坊节点，主干流程是快照下载：按账户路径批量领状态，速度快、损耗低。麻烦出在收尾的修复阶段——快照之后还有一串新区块要重放，重放碰到本地缺的节点数据，就得现问现补。旧协议里这笔账问得很难看：一次问一个键，问完这轮再看缺不缺，缺则再来一轮。EIP-8189 在 2026 年 3 月提出 snap/2，把修复合并进快照协议本身，用区块访问清单一次问全。提案目前处于 Review 阶段，依赖 EIP-7928。
缺数据时的旧节奏
状态树不是一次性拷来的。节点领快照时按路径切分领，树形结构决定了有些分支注定暂时缺席——账户合约的存储、代码，常常要等重放触碰时才发现本地没有。旧协议的处理办法是为这些查询保留一对专用消息（按哈希取节点数据），修复阶段于是退化成单点问话：发一个键、等一个值，一轮下来才看清还缺什么。树越深、缺失越碎，往返轮数越多。对同步中的节点，这是耗时的大头之一。
访问清单从哪来
EIP-7928 给每个区块配了一份访问清单 BAL，把这段区间内被触碰的状态键集中登记，并把清单哈希写进区块头。这份清单本来是给无状态路径与计费研究用的副产品，snap/2 看出了它的另一重价值：修复阶段要问的键，恰好就藏在历史区块的 BAL 里。于是新协议删掉旧的单键查询消息，换上一对按区块请求访问清单的消息：节点把要补的那段历史块对应的清单领回来，缺什么一目了然，再一次性发起快照式批量下载。
一次合并换来了什么
直观账是这样的：旧流程每轮修复的开销在往返次数里，新流程把发现缺口的成本从问话变成读清单——读清单是一次批量请求，代价固定；补齐缺口走批量通道，效率与快照主干一致。提案在安全性章节专门讨论了放大攻击：新消息按区块返回清单，体积可控，且服务方可以只对已确认的历史块供数，拒绝为未来块编造清单。对同步节点的另一项红利是内存：不必为多轮试探同时挂住大量中间状态。
它站在哪条路线上
把 BAL 系列拼起来看会更清楚：EIP-7928 造出了键清单，EIP-8037 之类的研究想给它配上状态费用，EIP-8189 则先用它解一个工程痛点——让新节点少熬几轮修补夜。这种先吃工程红利、再养共识用途的路径，正是协议演进的常见节奏：一份数据结构先在性能改进里站稳，之后才被更大的用途引用。snap/2 因此也像一个风向标：BAL 越常被下游引用，它进升级清单的引力就越大。
快速问答
问：同步会变快多少？ 答：取决于缺口的碎片程度；碎片越多，批量问话相对单点问话省得越多，具体倍数要看实测。 问：这要求历史节点存 BAL 吗？ 答：需要能提供历史区块访问清单的服务方；提案同时定义了不可得时的降级与拒绝策略。 问：会影响已同步节点的验证逻辑吗？ 答：不会，改动限于同步协议的消息集合，共识规则不变。
一次修复的旧流程走查
把旧节奏放慢看一遍：重放某笔交易，虚拟机触碰某个存储槽，本地状态树里没有该节点，客户端把这批缺口攒起来，发一轮按键取数请求，等回复、插回树里，再继续重放；很快第二笔、第三笔又戳出新的缺口，同样的问话再来一轮。每轮的网络往返加上树重挂的开销，就是同步收尾最磨人的部分。snap/2 的改动相当于把这段流程倒过来：先按区块历史把会碰到的键问成一张总清单，再照着清单一次性补齐，把多轮小步问话换成一轮大步下载。
风险提示：本文为节点同步机制科普，不构成投资建议；相关提案均未进入主网升级，细节以仓库为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。