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

出品 | 以太坊爱好者

头图 | 付费下载于视觉中国 

这篇文章的目的是正式公开一个对以太坊平台的严重威胁，其危险性清晰而明确，直到 “柏林” 硬分叉才解除。

问题

在 2019 年 3 月，Martin Swende 测量了 EVM 操作码的性能。这一研究后来导致了 EIP-1884 的创建。在 1884 激活的几个月前，这篇以 “Broken Metre” 为名的论文发表（2019 年 9 月）。

我们建议你完整地阅读他们提交的 告，写得非常好。

在一个专门讨论跨客户端安全性的频道里，来自 Geth 客户端、Parity 客户端和 Aleth 客户端的开发者被告知了这份 告，就在同一天。

该漏洞的本质是触发随机的树查找。一个非常简单的变体是：

在他们的 告里，研究员通过 eth_call RPC 端点对同步到主 的节点执行了这一负载，下面是它们消耗 1000 万 gas 所需的时间。

• 使用 EXTCOEHASH （名义 Gas 消耗量是 400）耗尽 1000 万 gas

• • Parity：约 90 秒

  • Geth：约 70 秒

• 使用 EXTCODESIZE （名义 Gas 消耗量是 700）消耗 1000 万 gas

• • Parity：约 50 秒

  • Geth：约 38 秒

（译者注：此处的意思是，如果一个 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 也被抛弃了，我们要寻找更好的替代方案。

• Alexey Akhunov 研究了 Oil 的概念 —— 一种次级的 “Gas”，但与 Gas 完全不同的是，它对执行层是不可见的，而且可能导致事务全局回滚（transaction-global revert）。

• Martin 提了一个类似的提案，称为 “Karma”，在 2020 年5 月。

虽然这许多方案都有进展，Vitalik Buterin 提议仅仅提高 Gas 消耗量，并维护一个 “访问清单”。在 2020 年 8 月，Martin 和 Vitalik 开始迭代后来成为 EIP-2929 及其同伴 EIP-2930 的想法。

EIP-2929 在根本上解决了许多上面提到的问题。

• 与 EIP-1884 相反；1884 是无条件提高 Gas 消耗量，但 2929 仅提高访问新对象的 Gas 消耗量。这使得净成本仅增加了不到一个百分点。

• 同样地，与 EIP-2930 配合后，就不会打破任何合约。

• 它还可以通过提高 Gas 消耗量来进一步调整（也不会打破合约）

在 2021 年 4 月 14 日，这两个 EIP 都在 “柏林” 分叉时激活。

在 2021 年 3 月/4 月， snap/1 协议已经在 geth 客户端推出，节点能够使用新的、基于快照的算法来同步区块链了。虽然还不是默认的同步模式，这是使快照能不仅作为攻击保护措施，也能显著提高用户体验的一部。

在协议层，“柏林” 升级已于 2021 年 4 月激活。

在我们的 AWS 监控环境中，我们的基准测试结果如下：

• “柏林” 前，没有快照，处理 2500 万 gas：14.3 秒

• “柏林” 前，有快照，处理 2500 万 gas：1.5 秒

• “柏林” 后，没有快照，处理 2500 万 gas：约 3.1 秒

• “柏林” 后，有快照，处理 2500 万 gas：约 0.3 秒

这个（粗糙）的数字表明，“柏林” 升级使攻击的效率降低了 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）。

更多阅读推荐

• 区块链+国潮艺术展，科技与艺术的梦幻联动也很美！

• 区块链“抢人”大战正在上演

• 赋能司法，区块链为正义指路

• 为何 Windows 10X 无法延续 Windows 的成功p>

• 张一鸣退一步，换字节跳动的“海阔天空”

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树使用JDBC操作数据库数据库操作92784 人正在系统学习中