通过此博客文章，目的是正式披露以太坊平台所面临的一个严重威胁。在以太坊柏林硬分叉之前，这个威胁是切实存在的。
让我们从以太坊和状态的背景知识开始。
以太坊状态由一种patricia-merkle trie（一种前缀树）组成。这篇文章将不做过多的详细介绍，随着状态的增长，这个树上的树枝变得越来越密。添加的每个帐户都是一片叶子。在树的根和叶本身之间，有许多“中间”节点。
为了在这棵巨大的树中查找给定的帐户或“叶子”，需要从根到中间节点来解析大约6-9个哈希的某个位置，以最终解析最后一个哈希hash，该哈希会指向我们正在寻找的数据。
简而言之：每执行一次Trie查找来查找帐户，就会执行8-9个解析操作。每个解析操作都是一次数据库查找，并且每词数据库查找可以是任意数量的真实磁盘操作。磁盘操作的次数很难估计，但是由于trie密钥是加密哈希（抗冲突），因此密钥是“随机的”，这对任何数据库来说都是最糟糕的情况。
随着以太坊的增长，有必要提高访问trie的操作的gas价格。这是在2016年10月区块高度2,463,000的Tangerine Whistle中执行的，其中包括EIP150。EIP150在所谓的“上海攻击”之后大幅提高了某些操作的gas成本，并进行了一系列更改以防止DoS攻击。
另一项gas提升同样在伊斯坦布尔升级中被执行，即2019年12月区块高度9,069,000。在这次升级中，EIP 1884被激活。
EIP 1884引入了以下操作成本更改：
SLOAD从200提升到800gas，
BALANCE从400提升到700gas（SELFBALANCE有所降低），
EXTCODEHASH从400提升到700gas。
2019年3月，Martin Swende对EVM操作码性能进行了一些测量。 这次调查之后促成创建了EIP-1884。 在EIP-1884上线之前的几个月，《Broken Meter》论文正式发表（2019年9月）。
两位以太坊安全研究人员（Hubert Ritzdorf和Matthias Egli ）与该论文的一位作者Daniel Perez合作“武器化”了一个漏洞，他们将漏洞提交给了以太坊赏金计划。这是在2019年10月4日。
我们建议您完整阅读那次提交的内容，这是一份精心撰写的报告。
在专门用于讨论跨客户端安全性的频道上，当天，来自Geth，Parity和Aleth的开发人员被告知了有关提交的信息。
雪崩协议首个跨链DEX HurricaneSwap主网上线:10月12日，据官方最新消息，雪崩协议Avalanche上首个LP跨链DEXHurricaneSwap已于10月10日14:00UTC上线主网并平稳运行。官网TVL已达8,150,000U。据悉，HurricaneSwap的V2版本也已经完成开发，即将上线测试网，将主要对HurricaneStation等主要功能进行开放测试。[2021/10/12 20:23:42]
该漏洞的本质是触发随机trie查询。 一个非常简单的变体是：
在他们的报告中，研究人员通过eth_call对同步到主网的节点执行了此有效负载，这些是在使用10M gas时执行的数量：
使用EXTCODEHASH （400 gas）发动10M gas攻击
Parity: ~90s
Geth: ~70s
使用EXTCODESIZE （700gas）发动10M gas攻击
Parity : ~50s
Geth : ~38s
显而易见，EIP 1884引入的更改确实在降低攻击方面产生了影响，但远远不够。
在大阪Devcon大会之前确实如此。在Devcon期间，主网客户端开发人员之间共享了该问题的知识。我们还与Hubert和Mathias以及Greg Markou（来自Chainsafe的ETC工作人员）进行了会面。 ETC开发人员也收到了这份报告。
随着2019年临近尾声，我们知道我们遇到的问题比我们之前预期的要大，恶意交易可能导致区块时间间隔增加到分钟级。更糟的是，开发人员已经对EIP-1884感到不满意，因为EIP-1884中断了某些合约程序，而用户和矿工们都为提高gas限制而着急。
此外，仅两个月后的2019年12月，Parity Ethereum宣布退出以太坊工作，而OpenEthereum接管了代码库的维护工作。
之后一个新的客户端协调频道被创建，在该频道中，Geth，Nethermind，OpenEthereum和Besu开发人员继续进行协调。
我们意识到，我们必须采取两种方法来解决这些问题。 一种方法是使用以太坊协议，并以某种方式在协议层解决该问题。 最好不要违反合约，最好不要惩罚“良好”行为，但仍要设法防止攻击。
第二种方法是通过软件工程，通过更改客户端中的数据模型和结构。
如何处理这些类型的攻击的第一个迭代升级可以在这里查看。 2020年2月，该解决方案以EIP 2583的形式正式发布。其背后的想法是，每当一次Trie查找导致遗漏（miss）时，简单地增加一个罚款。
但是，Peter为这个想法找到了一种解决方法——“屏蔽中继”攻击——将这种惩罚的有效范围设定一个上限（约800gas）。
对于miss所导致的罚款的问题在于，首先需要进行查找，以确定必须施加罚款。 但是，如果剩余的gas不足以进行罚款，则表明已执行了未付费用。 即使确实导致抛出异常，也可以将这些状态读取包装到嵌套调用中。 允许外部调用者继续重复攻击而无需支付（全部）罚款。
因此，这个EIP被弃置，而我们正在寻找更好的替代方案。
阿列克谢·阿克胡诺夫（Alexey Akhunov）探索了Oil的概念，它是“gas”的第二种来源，但与gas本质上不同，因为执行层看不到它，并可能导致交易全局还原。
Martin在2020年5月提出了一个类似提案，关于Karma的。
在迭代这些计划时，Vitalik Buterin建议仅增加gas成本，并维持访问名单。 2020年8月，Martin和Vitalik开始迭代，也就是后来的EIP-2929及EIP-2930。
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）。
至于实施这种攻击的可行性； 攻击者购买一个完整的区块所需的成本约为几个ETH（以100Gwei的价格购买15Mgas为1.5ETH）。
长期以来，这种威胁一直是“公开秘密”，实际上至少有一次被无意间地公开披露，并且在ACD电话会议中多次被提及，但没有明确的细节。
由于柏林升级现在已经过去，并且默认情况下，geth节点正在使用快照，因此我们估计这个威胁的危险程度非常低，可以公开了，现在该对此前的开发者幕后工作进行全面披露。
至关重要的是，社区必须有机会了解对用户体验产生负面影响的变更背后的原因，例如增加gas成本和限制refund。
这篇文章是由马丁·霍尔斯特·斯文德（Martin Holst Swende）和彼得·西拉吉（Peter Szilagyi）2021-04-23撰写的。 在2021-04-26与其他基于以太坊的项目共享，并在2021-05-18公开披露。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。