与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月合并到了代码库中。有了“动态快照”功能，我们就能喘口气了。如果以太坊网络遭到攻击，那会是很痛苦的，但至少，我们能通知用户打开快照功能。生成快照需要花一些时间，而且还没有办法同步快照，但网络至少能继续运行了。

结合

在2021年3月/4月，snap/1协议已经在geth客户端推出，节点能够使用新的、基于快照的算法来同步区块链了。虽然还不是默认的同步模式，这是使快照能不仅作为攻击保护措施，也能显著提高用户体验的一部。在协议层，“柏林”升级已于2021年4月激活。在我们的AWS监控环境中，我们的基准测试结果如下：

“柏林”前，没有快照，处理2500万gas：14.3秒

“柏林”前，有快照，处理2500万gas：1.5秒

“柏林”后，没有快照，处理2500万gas：约3.1秒

“柏林”后，有快照，处理2500万gas：约0.3秒

这个（粗糙）的数字表明，“柏林”升级使攻击的效率降低了5倍，而快照使之降低了10倍，最终使其影响降低了50倍。我们估计，在当前的主网上（区块为1500万gas），不使用快照的geth节点可能可以做到只需2.5~3秒就能执行一个区块。随着状态的增长，这个数字会继续恶化（对于不使用快照的节点来说是如此）。如果gas返还机制被用来造成单个区块的实际gas使用量提升，这个恶化的倍数（最大）是2倍。在EIP-1559实施后，区块的Gas Limit会有更高的弹性，在短时间内可爆发出最大2倍的恶化乘数。至于实施这种攻击的可行性，攻击者买断一个区块的成本大概在几个ETH这样的级别（1500万gas，100 Gwei的价格，乘出来就是1.5 ETH）。 (责任编辑：admin)