拆解以太坊状态(State)问题:一个鲜为人知的严重威胁
Kyle以太坊基金会今日发文披露了一个2019年首次发现的安全漏洞,在上个月的柏林升级之前,该漏洞的严重程度为发生攻击时可能使主网瘫痪。该漏洞的本质是触发随机Trie查询,以太坊开发人员曾试图用EIP-1884、EIP-2583、EIP-2929、以及快照功能来抵御该漏洞,最终在柏林升级之后该漏洞危险性降低。
通过此博客文章,目的是正式披露以太坊平台所面临的一个严重威胁。在以太坊柏林硬分叉之前,这个威胁是切实存在的。
状态(State)
让我们从以太坊和状态的背景知识开始。
以太坊状态由一种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的开发人员被告知了有关提交的信息。
该漏洞的本质是触发随机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公开披露。