基于上述访问模式，如果我们可以短路（short circuit）读取操作而不触及状态树，则许多节点操作都可以变得快 很多。这样甚至能开启一些新奇的访问模式（比如状态迭代），让原来因为太过昂贵而不可行的模式变为可能。

当然，还是不免有所牺牲。没有去掉树结构，任何新的加速结构都会带来额外的开销。问题只在于：额外的开销是否能带来足够多的好处，值得我们一试？

请循其本

我们已经开发出了神奇的默克尔帕特里夏树结构来解决我们所有的问题，现在，我们希望让读取操作能绕过它。那么，我们应该用什么样的加速结构来让读取操作重新变得快起来呢？显然，如果我们不需要树结构，那就大可以把伴随树结构而生的复杂性都丢在一边，我们可以直接回到原始状态。

如同在本文开头说到的那样，理论上的理想状态下 以太坊状态的数据存储方式应是简单键值对，没了默克尔帕特里夏树构成的限制，那就没有什么能阻止我们去实现这种理想方案了！

不久之前，Geth 引入了 snapshot（快照）加速结构（不是默认开启的）。一个快照就是给定一个区块处的以太坊状态的完整视图。抽象掉实现方面的细节，它就是把所有账户和合约存储槽堆放在一起，都由扁平的键值对来表示。

每当我们想要访问某个账户或者某个存储槽的时候，我们只需付出一次 LevelDB 的查询操作即可，而不用在每棵树上查询 7～8 次。理论上来说，更新快照也很简单，处理完一个区块后，我们只需为每个要更新的存储槽多做 1 次额外的 LevelDB 写入操作即可。

快照加速结构实际上将读取操作的复杂性从 O(log n) 降到了 O(1) （乘以 LevelDB 的开销），代价是将写入操作的复杂性从 O(log n) 变成了 O(1 + log n) （乘以 LevelDB 的开销），并将硬盘存储空间从 O(n log n) 增加到了 O(n + n log n)。

魔鬼藏在细节中

维持以太坊状态快照的可用性也不容易。只要区块还在一个接一个地产生，一个接一个地摞在最后一个区块上，那将最新变更合并到快照中的粗疏办法就能正常工作。但是，哪怕有微小的区块链重组（即便只有一个区块），快照机制就崩溃了，因为根本没有设计撤销操作。对扁平数据表示模式来说，持久化写入是单向的操作。而且让事情变得更糟糕的是，我们没办法访问更老的状态了（例如某些 dApp 需要 3 个区块以前的状态；或者 fast/snap 同步模式中要访问 64 个区块以前的状态）。

为了克服这些限制，Geth 客户端的快照由两部分组成：一部分持久化的硬盘层，是对旧区块（例如顶端区块前 128 个区块）处状态的完整快照；还有一棵内存内 diff 层组成的树，用于收集最新的写入操作。 (责任编辑：admin1)