躲避子弹:以太坊状态问题

这篇文章的目的是正式公开一个对以太坊平台的严重威胁,其危险性清晰而明确,直到 “柏林” 硬分叉才解除。我们先来了解一些以太坊和 “状态” 的背景知识。以太坊状态是一棵 帕特里夏-默克尔树(particia-merkle trie,一种兼有前缀树规则的默克尔树)。本文不会深入过多细节,你只要知道,随着状态数量的增长,这个树结构的分支会变得越来越密。以太坊区块链上每多一个账户,这棵树就多一个叶子节点。在树的根节点与叶子节点,是许多所谓的 “中间” 节点。为了查找某个账户,或者说在这棵庞大的树上找到某片 “叶子”,需要解析 6 ~ 9 个哈希值,从根节点开始,经由中间节点,最终解析到一个能够给予我们所需数据的哈希值。用大白话来说:无论什么时候要在这棵树上查找某个账户,都要经过 8 ~ 9 次解析操作。每次解析操作都是一次数据库查询,而每一次数据库查询都意味着不确定数量的多次硬盘操作。硬盘操作的次数很难估计,但是因为状态树的 “键(key)” 是密码学哈希值(抗碰撞的),所以这些键都是随机的,这对所有数据库来说都属于最坏的情况。随着以太坊状态的增加,就有必要提高访问状态树的操作的 Gas 消耗量。早在 2016 年 10 月,我们就曾用 “橘子口哨(Tangerine Whistle)” 分叉(纳入 EIP 150,在区块高度 246 3000 激活)做过这样的事。EIP 150 大幅提高了特定操作的 Gas 消耗量,并引入了一系列的措施来保护网络免于 DoS 攻击;这是在所谓的 “上海攻击” 之后推出的。另一次这样的 Gas 消耗量提升是在 “伊斯坦布尔” 分叉的时候,在区块高度 906 9000 (2019 年 12 月)激活,引入了 EIP 1884。1884 的内容包括:在 2019 年 3 月,Martin Swende 测量了 EVM 操作码的性能。这一研究后来导致了 EIP-1884 的创建。在 1884 激活的几个月前,这篇以 “Broken Metre” 为名的论文发表(2019 年 9 月)。两位以太坊安全研究员 —— Hubert Ritzdorf 和 Matthias Egli —— 与这篇论文的作者之一 Daniel Perez 展开了合作,并 “武器化” 了一个漏洞,并提交给了以太坊的 bug 悬赏项目。那是在 2019 年 10 月 4 日。我们建议你完整地阅读他们提交的报告,写得非常好。在一个专门讨论跨客户端安全性的频道里,来自 Geth 客户端、Parity 客户端和 Aleth 客户端的开发者被告知了这份报告,就在同一天。该漏洞的本质是触发随机的树查找。一个非常简单的变体是:躲避子弹:以太坊状态问题在他们的报告里,研究员通过 eth_call RPC 端点对同步到主网的节点执行了这一负载,下面是它们消耗 1000 万 gas 所需的时间。(译者注:此处的意思是,如果一个 1000 万 gas 的区块全用这两个操作码填满,则节点需要这么长时间才能处理完这个区块)显而易见的是,EIP-1884 确实减少了攻击的效果,但还是远远不够的。那时候离大阪 Devcon 已经很近了。在 Devcon 期间,关于这一问题的知识在主网的客户端开发者之间传开来。我们也会晤了 Hubert 和 Mathias,还有 Greg Markou(他来自 Chainsafe 团队,一直在做 ETC 的工作)。ETC 区块链的开发者们也收到了这份报告。随着 2019 年接近尾声,我们发现,这问题比我们之前以为的还要棘手,恶意的事务可能导致出块时间延长到以分钟计。更难办的是,开发者社区已经对 EIP-1884 感到不满,它打破了一些合约,而且用户和矿工都希望提高区块的 Gas Limit。此外,仅仅两个月之后,到了 2019 年 12 月,Partiy Ethereum 就宣布要退出了,OpenEthereum 项目接管了 Parity 客户端的代码维护工作。于是大家创建了一个新的客户端协作频道,Geth、Netheremind、OpenEthereum 和 Besu 的开发者继续合作。我们意识到,只有双管齐下才能解决这个问题。一方面,我们要改进以太坊协议,也就是在协议层解决这个问题;最好是不要打破合约,也不要惩罚 “善意” 的行为,但又能防止攻击。另一方面,我们可以依靠软件工程,改变客户端内的数据模式和结构。处理此类攻击的第一个思路是这个。在 2020 年2 月,其正式版本作为 EIP 2583 发布。该提案背后的观念是增加一个惩罚措施,每次树查找导致 miss (“未找到”)时就触发。不过,Peter 找出了一个绕过它的办法 ——“shielded relay” 攻击 —— 使得本质上惩罚有了一个上限(约为 800)(译者注:此处没有单位,疑为 gas)。惩罚 miss 方法的问题在于,必须先有查找的过程,然后才能确定要不要实施惩罚。但如果剩余的 gas 已不足于实施惩罚,则(从协议的角度看)一个没有得到充分支付的消耗流程又已经执行了。即使这会导致抛出错误,这些状态读取也可以封装到嵌套调用中,使得外部调用者可以重复执行攻击而不必支付(完整的)惩罚。因此,这个 EIP 也被抛弃了,我们要寻找更好的替代方案。虽然这许多方案都有进展,Vitalik Buterin 提议仅仅提高 Gas 消耗量,并维护一个 “访问清单”。在 2020 年 8 月,Martin 和 Vitalik 开始迭代后来成为 EIP-2929 及其同伴 EIP-2930 的想法。EIP-2929 在根本上解决了许多上面提到的问题。在 2021 年 4 月 14 日,这两个 EIP 都在 “柏林” 分叉时激活。Peter 尝试用动态的状态快照解决这个问题,时值 2019 年 10 月。快照是一个次级的数据结构,用来以扁平格式(flat format)存储以太坊状态。快照可在 Geth 节点正常运行期间创建,无需下线专门执行。快照的好处是,它可以作为状态访问的一种加速结构:弊端是,快照等于是完全复制了账户和存储项的未经处理(raw)的数据。若在主网环境中使用,这意味着需要额外 25 GB 的固态硬盘空间。动态快照的想法从 2019 年中就有了,当时的主要目标是启用 “快照同步”。那时候 Geth 团队还在开发许多 “大项目”:不过,后来他们决定一心一意做快照功能,推迟了其他项目。这些工作为后来的 snap/1 同步算法打下了基础。这一算法已在 2020 年 3 月合并到了代码库中。有了 “动态快照” 功能,我们就能喘口气了。如果以太坊网络遭到攻击,那会是很痛苦的,但至少,我们能通知用户打开快照功能。生成快照需要花一些时间,而且还没有办法同步快照,但网络至少能继续运行了。在 2021 年 3 月/4 月, snap/1 协议已经在 geth 客户端推出,节点能够使用新的、基于快照的算法来同步区块链了。虽然还不是默认的同步模式,这是使快照能不仅作为攻击保护措施,也能显著提高用户体验的一部。在协议层,“柏林” 升级已于 2021 年 4 月激活。在我们的 AWS 监控环境中,我们的基准测试结果如下:这个(粗糙)的数字表明,“柏林” 升级使攻击的效率降低了 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)。这一威胁在很长时间里都是 “公开的秘密” —— 因为疏忽,它至少被公开披露过一次;而且在核心开发者会议中也多次提到它,虽然没有公开细节。因为我们已经激活了 “柏林” 升级,也因为 geth 客户端已经默认使用快照功能,我们认为,威胁已经足够低,而透明化才是更重要的了。所以是时候把幕后的工作都公开了。重要的是,社区得到了一次理解和思考这些影响用户体验(这些 EIP 会提高 Gas 消耗量,也会限制返还机制的效果)的变更的机会。

原创文章,作者:惊蛰财经,如若转载,请注明出处:http://www.xmlm.net/wang/3864.html

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注