以太坊基金会今日发文披露了一个2019年首次发现的安全漏洞，在上个月的柏林升级之前，该漏洞的严重程度为发生攻击时可能使主网瘫痪。该漏洞的本质是触发随机Trie查询，以太坊开发人员曾试图用EIP-1884、EIP-2583、EIP-2929、以及快照功能来抵御该漏洞，最终在柏林升级之后该漏洞危险性降低。通过此博客文章，目的是正式披露以太坊平台所面临的一个严重威胁。在以太坊柏林硬分叉之前，这个威胁是切实存在的。
状态
让我们从以太坊和状态的背景知识开始。
以太坊状态由一种patricia-merkletrie组成。这篇文章将不做过多的详细介绍，随着状态的增长，这个树上的树枝变得越来越密。添加的每个帐户都是一片叶子。在树的根和叶本身之间，有许多“中间”节点。
为了在这棵巨大的树中查找给定的帐户或“叶子”，需要从根到中间节点来解析大约6-9个哈希的某个位置，以最终解析最后一个哈希hash，该哈希会指向我们正在寻找的数据。
简而言之：每执行一次Trie查找来查找帐户，就会执行8-9个解析操作。每个解析操作都是一次数据库查找，并且每词数据库查找可以是任意数量的真实磁盘操作。磁盘操作的次数很难估计，但是由于trie密钥是加密哈希，因此密钥是“随机的”，这对任何数据库来说都是最糟糕的情况。
随着以太坊的增长，有必要提高访问trie的操作的gas价格。这是在2016年10月区块高度2,463,000的TangerineWhistle中执行的，其中包括EIP150。EIP150在所谓的“上海攻击”之后大幅提高了某些操作的gas成本，并进行了一系列更改以防止DoS攻击。
另一项gas提升同样在伊斯坦布尔升级中被执行，即2019年12月区块高度9,069,000。在这次升级中，EIP1884被激活。
EIP1884引入了以下操作成本更改：
SLOAD从200提升到800gas，
BALANCE从400提升到700gas，
EXTCODEHASH从400提升到700gas。
问题
2019年3月，MartinSwende对EVM操作码性能进行了一些测量。这次调查之后促成创建了EIP-1884。在EIP-1884上线之前的几个月，《BrokenMeter》论文正式发表。
两位以太坊安全研究人员与该论文的一位作者DanielPerez合作“武器化”了一个漏洞，他们将漏洞提交给了以太坊赏金计划。这是在2019年10月4日。
我们建议您完整阅读那次提交的内容，这是一份精心撰写的报告。
在专门用于讨论跨客户端安全性的频道上，当天，来自Geth，Parity和Aleth的开发人员被告知了有关提交的信息。
该漏洞的本质是触发随机trie查询。一个非常简单的变体是：
在他们的报告中，研究人员通过eth_call对同步到主网的节点执行了此有效负载，这些是在使用10Mgas时执行的数量：
使用EXTCODEHASH?发动10Mgas攻击
Parity:?~90s
Geth:?~70s
使用EXTCODESIZE?发动10Mgas攻击
Parity:?~50s
Geth:?~38s
显而易见，EIP1884引入的更改确实在降低攻击方面产生了影响，但远远不够。
在大阪Devcon大会之前确实如此。在Devcon期间，主网客户端开发人员之间共享了该问题的知识。我们还与Hubert和Mathias以及GregMarkou进行了会面。ETC开发人员也收到了这份报告。
随着2019年临近尾声，我们知道我们遇到的问题比我们之前预期的要大，恶意交易可能导致区块时间间隔增加到分钟级。更糟的是，开发人员已经对EIP-1884感到不满意，因为EIP-1884中断了某些合约程序，而用户和矿工们都为提高gas限制而着急。
此外，仅两个月后的2019年12月，ParityEthereum宣布退出以太坊工作，而OpenEthereum接管了代码库的维护工作。
之后一个新的客户端协调频道被创建，在该频道中，Geth，Nethermind，OpenEthereum和Besu开发人员继续进行协调。
解决方案
我们意识到，我们必须采取两种方法来解决这些问题。一种方法是使用以太坊协议，并以某种方式在协议层解决该问题。最好不要违反合约，最好不要惩罚“良好”行为，但仍要设法防止攻击。
第二种方法是通过软件工程，通过更改客户端中的数据模型和结构。
协议层工作
如何处理这些类型的攻击的第一个迭代升级可以在这里查看。2020年2月，该解决方案以EIP2583的形式正式发布。其背后的想法是，每当一次Trie查找导致遗漏时，简单地增加一个罚款。
但是，Peter为这个想法找到了一种解决方法——“屏蔽中继”攻击——将这种惩罚的有效范围设定一个上限。
对于miss所导致的罚款的问题在于，首先需要进行查找，以确定必须施加罚款。但是，如果剩余的gas不足以进行罚款，则表明已执行了未付费用。即使确实导致抛出异常，也可以将这些状态读取包装到嵌套调用中。允许外部调用者继续重复攻击而无需支付罚款。
因此，这个EIP被弃置，而我们正在寻找更好的替代方案。
阿列克谢·阿克胡诺夫探索了Oil的概念，它是“gas”的第二种来源，但与gas本质上不同，因为执行层看不到它，并可能导致交易全局还原。
Martin在2020年5月提出了一个类似提案，关于Karma的。
在迭代这些计划时，VitalikButerin建议仅增加gas成本，并维持访问名单。2020年8月，Martin和Vitalik开始迭代，也就是后来的EIP-2929及EIP-2930。
EIP-2929有效地解决了许多以前的问题。
与EIP-1884相反，它仅针对尚未访问的内容增加成本。这导致净成本仅增加了不足百分之一。
此外，它与EIP-2930一样，不会破坏任何合约流
而且，可以通过提高gas成本来进一步调整它。
2021年4月15日，它们都随着柏林升级而上线。
开发工作
2019年10月，Peter尝试解决此问题的方法是进行动态状态快照。
快照是一种二级数据结构，用于以平面格式存储以太坊状态，在Geth节点的实时运行期间，可以完全在线构建。
照的好处在于，它充当状态访问的一种加速结构：
快照无需提供O磁盘读取来访问帐户/存储插槽，而是可以提供直接的O访问时间。
快照支持每项条目O复杂度的帐户和存储迭代，这使远程节点可以比以前便宜得多地检索顺序状态数据。
快照的存在还实现了更多奇特的用例，例如离线修剪状态Trie或迁移到其他数据格式。
快照的缺点是原始帐户和存储数据实际上是重复的。对于主网，这意味着要使用额外的25GBSSD空间。
动态快照的想法已经在2019年中期开始，主要目的是成为snap同步的推动者。当时，Geth团队正在开展许多“大项目”。
离线状态修剪
动态快照snap同步
通过分片状态进行的LES状态分布
但是，最后决定完全优先考虑快照，暂时将其他项目推迟。这些奠定了后来成为snap/1同步算法的基础。于2020年3月合并到主网。
随着“动态快照”功能的发布，我们有了一些喘息的空间。如果以太坊网络受到攻击，那将是痛苦的，是的，但是至少有可能通知用户有关启用快照的信息。整个快照生成将花费大量时间，并且尚无法同步快照，但是网络至少可以继续运行。
在2021年3月至4月，snap/1协议在geth中推出，从而可以使用基于快照的新算法进行同步。尽管仍然不是默认的同步模式，但这是使快照不仅可用作攻击防护，而且对于用户来说是一项重大改进。
在协议方面，柏林升级在2021年4月正式执行。
以下是在我们的AWS监控环境中制定的一些基准测试：
柏林升级前，无快照，25Mgas：14.3s
柏林升级前，有快照，25Mgas：1.5s
柏林升级后，无快照，25Mgas：~3.1s
柏林升级后，有快照，25Mgas：~0.3s
数字表示，柏林升级将攻击的效率降低了5倍，快照将攻击的效率降低了10倍，总共将攻击影响降低了50倍。
我们估计，目前在主网上，在没有快照的情况下，创建区块可能需要2.5-3s在一个geth节点上执行。随着状态的增长，该数字将继续恶化。
如果使用refund来增加一个区块内的有效gas使用量，则可以进一步提高2x倍。使用EIP1559，区块gas限制将具有更高的弹性，并允许在临时爆发中再增加2倍。
至于实施这种攻击的可行性；攻击者购买一个完整的区块所需的成本约为几个ETH。
为什么现在披露这个威胁？
长期以来，这种威胁一直是“公开秘密”，实际上至少有一次被无意间地公开披露，并且在ACD电话会议中多次被提及，但没有明确的细节。
由于柏林升级现在已经过去，并且默认情况下，geth节点正在使用快照，因此我们估计这个威胁的危险程度非常低，可以公开了，现在该对此前的开发者幕后工作进行全面披露。
至关重要的是，社区必须有机会了解对用户体验产生负面影响的变更背后的原因，例如增加gas成本和限制refund。
这篇文章是由马丁·霍尔斯特·斯文德和彼得·西拉吉2021-04-23撰写的。在2021-04-26与其他基于以太坊的项目共享，并在2021-05-18公开披露。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。