以太坊的验证者不是凭空上岗的：每一笔质押入场都要在信标链之外的一个存款合约里登记，合约把这些登记装进一棵深度固定的默克尔树，信标链靠树根核对每笔存款的真实性。麻烦出在新节点同步上：多数客户端重建这棵树的方式，是把合约自上线以来的全部存款日志重放一遍。日志永远只增不减，同步时间跟着链龄一起膨胀，而且这些日志被要求永久留在全节点上，想给状态增长减负时它是一块搬不动的石头。EIP-4881 由 Mark Mackey 在 2021 年 1 月提交，后来定稿为 Final，它用一份快照文件绕开了重放。
快照里只有五样东西
提案定义的 DepositTreeSnapshot 结构极小：一个已最终化哈希的可变列表、树根、存款计数、一个执行层区块哈希和对应区块高度。关键在”已最终化”那一项。存款每被信标链处理一次，就需要一条从它到树根的路径证明；处理完成后，路径上很多中间哈希在构造链上证明时永远用不回来了——它们可以被剪掉，保留的边界恰好就是列表里那些还在起作用的哈希。换句话说，快照不是压缩过的全量日志，而是一棵”只留承重墙”的残树加三行账目：数了多少笔、当前根是什么、账截止哪个区块。新节点从弱主观性检查点拿到这份小结构，就能把树恢复到同一时刻，再用增量存款补齐到当前，全程不碰历史日志。为了让节点廉价自检，快照自带树根字段，客户端可以按规范里的算法用残树重算一遍做交叉验证。
为什么不用别的办法
提案顺带否决了两条直觉路线。直接查存款合约不行：合约只提供链头时刻的树，而信标链看待存款永远滞后若干个区块，那些尚未被纳入信标链的存款需要更早版本的树来构造证明，合约给不了。从信标链历史里翻某笔存款也不行：要沿着链倒着扫描找锚点、处理未纳入存款的边界情形，还会把区块回填变成出块的前置条件，比从检查点读快照慢一个量级。字段设计上也留了余地：区块哈希与区块高度严格说给一个就够，但不同客户端各自的缓存逻辑不同，两个都给免得同步期去查还没跟上的执行引擎。
接口与影响
规范用必须、可以这类措辞画线：客户端内部怎么存树随意，但对外传给新同步节点的必须是这个格式，并且要在信标节点接口的固定端点上提供。对普通质押者，这条提案没有任何操作变化；对节点运营者，它换来更短的同步时间和”终于可以修剪存款日志”的许可证，也是限制状态增长讨论里少见的落地一步。
快速问答
问：这份快照可信吗，会不会被喂假的？ 答：快照可以用自带的根字段自洽校验，且它最终锚定在你信任的弱主观性检查点上——检查点本身的安全假设不变，快照没有引入新的信任方。
问：存款合约和信标链的存款树是两棵树吗？ 答：同一棵树的两个视图：合约在链下世界维护插入，信标链在链上按树根验证；快照描述的就是这棵共用的树。
一棵树的减法
拿盖楼做比方：存款树像一栋不断加盖的公寓，每户入住时要拍一张从自家门口到大厦门厅的走廊照片，门厅照片就是树根。多数住户住进去之后，走廊中段那些过渡照片再没用处——EIP-4881 允许把这些废片扔掉，只留还有住户需要作证的那几面墙。快照便是留墙清单加三行物业记录：住了多少户、门厅照片编号、账记到哪一天。新接手的物业照着清单就能复原同一面墙，不必把历年的废片全部重看一遍。省下的不只是硬盘，还有”每栋新楼都要重走全部旧楼”的同步仪式。
风险提示：节点软件与接口以当前客户端文档为准；本文仅为技术科普，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。