处理新区块的时候，我们不会直接合并这些写入操作到硬盘层，而仅仅是创建一个新的、包含这些变更的内存内 diff 层。当内存内部的 diff 层积累到足够高的层数时，最底部的一个就开始合并更新并推到硬盘层。当需要读取一个状态物时，我们就从最顶端的 diff 层开始查找，一直往下，直至在 diff 层中或者在硬盘层中找到。

这种数据表示方法非常强大，解决了很多问题。因为内存内部的 diff 层组成了一棵树，所以 128 个区块以内的链重组只需取出属于父块的 diff 层，然后就此开始构建即可。需要较旧状态的 dApp 和远程同步者可以访问到最近 128 个最近的状态。开销变成了 128 次映射查找，但 128 次内存内的查找比起 8 次硬盘读取及 Level DB 的 4～5 倍放大要快上几个数量级。

当然，这里面还有很多很多的坑。就不讲太深了，简单列举就有下面这张清单：

• Self-destruct （合约自毁操作）（以及删除操作）特别难以对付，因为它们需要短路 diff 层的沉降（descent）。
• 如果出现了比持久硬盘层更深的链重组，那现在的快照就要完全废弃掉、重新生成。整套操作非常昂贵。
• 在节点关机时，内存内的 diff 层需要持久化到日志并加载备份，不然重启之后快照就没用了。
• 使用最底层的 diff 层作为一个累加器，仅在其超过一定的内存使用时才刷新到硬盘。这就允许跨区块对同一存储槽执行去重写入操作（deduping write）。
• 要为硬盘层分配一个读取缓存，这样合约重复访问同一个古老的存储槽时硬盘才不会损坏。
• 在内存内 diff 层中使用累积的布隆过滤器（bloom filter），以便快速检测出状态物有没有可能存在于 diff 层中，还是应该直接跳到硬盘中查找。
• 不把原始数据（账户地址、合约存储键）设为键，而是以这些数据的哈希值为键，以保证快照的迭代顺序与默克尔帕特里夏树相同。
• 生成持久化硬盘层的时间要比剪除状态树窗口的时间多得多，所以即使是生成器，也需要动态地追踪链的运行。

美丑并存

Geth 的快照加速结构将状态读取的复杂性降低了一个数量级。这就意味着基于读取操作的 DoS 攻击的发动难度上了一个数量级，而 ethcall 调用也快了一个数量级（假设 CPU 不存在瓶颈的话）。

快照还让对最近的块进行极速状态迭代成为可能。实际上这曾是我们开发快照机制的主要理由，因为我们可以此为基础创造新的 snap 同步算法。讲清楚它需要一篇全新的文章，但最近我们在 Rinkeby 测试网上的基准测试很能说明问题：

当然，这一切同样不是没有代价的。当初始同步完成之后，参与主网的节点需要 9～10 小时来建构初始快照（此后再维持其可用性），还需要额外的 15 GB 以上的硬盘。

那糟糕的部分是哪里呢？我们花了 6 个月时间才积累起足够的自信、发布了快照机制，而且现在它仍然不是默认功能，需要主动使用 --snapshot 标记来开启，而且还有一些围绕内存使用和崩溃恢复的打磨工作要做。

总而言之，对于这一提升，我们非常自豪。其中有巨大的工作量，而且是在黑暗中摸索、自己实现所有东西并祈祷它能工作。还有一个有趣的事情，第一个版本的快照同步（leaf sync）是在两年半以前写的，但一直都处于被阻塞的状态，因为我们缺乏必要的加速结构来驱动它。

结语

希望你能喜欢 Geth 客户端有问必答 的这一篇文章。我花了比自己所预想的多出一倍的时间，但我并不后悔，因为这个主题值得。下周见。

[又：我故意不在文章里留下 提问 / 投票 的网站，因为我确信这个活动只是暂时的，我不想留下一个没用的超链接，也不希望有人会在未来买下那个域名并托管恶意信息。你可以在我的 Twitter 中找到那个网站。]