2021 年 4 月 15 日，这两个 EIP 都在 Berlin 升级中被激活了。

开发工作

Peter 在 2019 年 10 月提出的解决方案是「动态状态快照」 (dynamic state snapshots)。

快照是用于以平面格式存储以太坊状态的辅助数据结构，在 Geth 节点的实时操作期间，可以完全在线构建。快照的好处在于充当状态访问的加速结构：

• 无需通过 O(log N) 次磁盘读取 (x LevelDB 开销) 来访问一个账户或存储插槽，快照可以提供直接的 O(1) 访问时间 (x LevelDB 开销)。

• 快照支持每项条目以 O(1) 复杂度迭代账户和存储，这使远程节点能够以比以前便宜得多的方式检索顺序状态数据。

• 快照还启用了更多奇特的用例，例如离线修剪状态 Trie 或迁移到其他数据格式。

快照的缺点在于原始帐户和存储数据实际上是重复的。对于主网来说这意味着将占用额外的 25GB SSD 空间。

动态快照的概念从 2019 年中就已经发轫，起初的目的主要是推动快照同步的实现。当时 Geth 团队在忙于许多「大项目」。

• 离线状态修剪

• 动态快照+快照同步

• 通过分片化状态实现 LES (Light Ethereum Subprotocol) 状态分发

然而，最终决定将快照的优先级排到最前，将其他项目暂时搁置。这为后来的 snap/1 同步算法奠定了基础，并于 2020 年 3 月合并。

随着「动态快照」功能的发布，我们有了一些喘息的空间。如果以太坊网络受到攻击，那将是痛苦的，是的，但是至少有可能通知用户启用快照。完整生成快照将花费大量时间，并且当时尚无法同步快照，但是网络至少可以继续运行。

总结

2021 年的三月到四月，snap/1 协议在 geth 客户端中实现了，使得通过新的基于快照的算法进行同步成为可能。虽然仍不是默认的同步模式，但这是很重要的一个步骤，使快照不仅可用作攻击防护措施，并且对于用户来说也是一项重要优化。

在协议方面，柏林升级于 2021 年 4 月完成。

以下是在我们的 AWS 监控环境中制定的一些基准：

• 柏林升级之前，无快照，25M gas: 14.3s
• 柏林升级之前，有快照，25M gas: 1.5s
• 柏林升级之后，无快照，25M gas: ~3.1s
• 柏林升级之后，有快照，25M gas: ~0.3s

大致的数据显示柏林升级能够将攻击的效率降低 5 倍，快照能够将其降低 10 倍，总计将影响降低了 50 倍。

我们估计目前在主网 (15M gas)，对于未使用快照的 geth 节点来说，有可能创建执行时间在 2.5-3 秒的区块。对于非快照节点来说，随着状态增长这个数字会持续恶化。 (责任编辑：admin)