|
EIP-2929有效地解决了许多以前的问题。 与EIP-1884（无条件增加成本）相反，它仅针对尚未访问的内容增加成本。这导致净成本仅增加了不足百分之一。此外，它与EIP-2930一样，不会破坏任何合约流而且，可以通过提高gas成本（不中断操作）来进一步调整它。2021年4月15日，它们都随着柏林升级而上线。 开发工作 2019年10月，Peter尝试解决此问题的方法是进行动态状态快照。 快照是一种二级数据结构，用于以平面格式存储以太坊状态，在Geth节点的实时运行期间，可以完全在线构建。 照的好处在于，它充当状态访问的一种加速结构： 快照无需提供O（log N）磁盘读取（x LevelDB开销）来访问帐户/存储插槽，而是可以提供直接的O（1）访问时间（x LevelDB开销）。快照支持每项条目O（1）复杂度的帐户和存储迭代，这使远程节点可以比以前便宜得多地检索顺序状态数据。快照的存在还实现了更多奇特的用例，例如离线修剪状态Trie或迁移到其他数据格式。快照的缺点是原始帐户和存储数据实际上是重复的。对于主网，这意味着要使用额外的25GB SSD空间。 动态快照的想法已经在2019年中期开始，主要目的是成为snap 同步的推动者。当时，Geth团队正在开展许多“大项目”。 离线状态修剪动态快照+snap同步通过分片状态进行的LES状态分布但是，最后决定完全优先考虑快照，暂时将其他项目推迟。 这些奠定了后来成为snap / 1同步算法的基础。 于2020年3月合并到主网。 随着“动态快照”功能的发布，我们有了一些喘息的空间。 如果以太坊网络受到攻击，那将是痛苦的，是的，但是至少有可能通知用户有关启用快照的信息。 整个快照生成将花费大量时间，并且尚无法同步快照，但是网络至少可以继续运行。 在2021年3月至4月，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）上，在没有快照的情况下，创建区块可能需要2.5-3s在一个 geth节点上执行。 随着状态的增长，该数字将继续恶化（对于非快照节点）。 如果使用refund来增加一个区块内的有效gas使用量，则可以进一步提高（max）2x倍。 使用EIP 1559，区块gas限制将具有更高的弹性，并允许在临时爆发中再增加2倍（ELASTICITY_MULTIPLIER）。 (责任编辑：admin) |