因此，这个 EIP 也被抛弃了，我们要寻找更好的替代方案。

• 　　Alexey Akhunov 研究了 Oil 的概念 —— 一种次级的 “Gas”，但与 Gas 完全不同的是，它对执行层是不可见的，而且可能导致事务全局回滚（transaction-global revert）。

• 　　Martin 提了一个类似的提案，称为 “Karma”，在 2020 年5 月。

　　虽然这许多方案都有进展，Vitalik Buterin 提议仅仅提高 Gas 消耗量，并维护一个 “访问清单”。在 2020 年 8 月，Martin 和 Vitalik 开始迭代后来成为 EIP-2929 及其同伴 EIP-2930 的想法。

　　EIP-2929 在根本上解决了许多上面提到的问题。

• 　　与 EIP-1884 相反；1884 是无条件提高 Gas 消耗量，但 2929 仅提高访问新对象的 Gas 消耗量。这使得净成本仅增加了不到一个百分点。

• 　　同样地，与 EIP-2930 配合后，就不会打破任何合约。

• 　　它还可以通过提高 Gas 消耗量来进一步调整（也不会打破合约）

　　在 2021 年 4 月 14 日，这两个 EIP 都在 “柏林” 分叉时激活。

　　开发工作

　　Peter 尝试用动态的状态快照解决这个问题，时值 2019 年 10 月。

　　快照是一个次级的数据结构，用来以扁平格式（flat format）存储以太坊状态。快照可在 Geth 节点正常运行期间创建，无需下线专门执行。快照的好处是，它可以作为状态访问的一种加速结构：

• 　　不再是执行 O(log N) 次硬盘读取（还要乘以 LevelDB 的开销）来访问一个账户/存储项，快照可以提供直接的，O(1) 级别的访问时间（再乘以 LevelDB 的开销）。

• 　　快照还支持以每个条目 O(1) 的复杂度迭代账户和存储项，这使得远程节点可以检索连续的状态数据，比以往便宜非常多。

• 　　快照的存在还支持其它更奇怪的用途，比如离线修剪状态树，以及迁移到另一种数据格式。

　　弊端是，快照等于是完全复制了账户和存储项的未经处理（raw）的数据。若在主网环境中使用，这意味着需要额外 25 GB 的固态硬盘空间。

　　动态快照的想法从 2019 年中就有了，当时的主要目标是启用 “快照同步”。那时候 Geth 团队还在开发许多 “大项目”：

• 　　离线的状态修剪

• 　　同态快照 + 快照同步

• 　　通过共享状态实现 LES 状态分散

　　不过，后来他们决定一心一意做快照功能，推迟了其他项目。这些工作为后来的 snap/1 同步算法打下了基础。这一算法已在 2020 年 3 月合并到了代码库中。

　　有了 “动态快照” 功能，我们就能喘口气了。如果以太坊网络遭到攻击，那会是很痛苦的，但至少，我们能通知用户打开快照功能。生成快照需要花一些时间，而且还没有办法同步快照，但网络至少能继续运行了。 (责任编辑：admin)