【2021年4 月1日23点】以太坊状态问题

最爱小笼包

  

微信、浏览器扫描下载杏吧APP

    我们先来了解一些以太坊和 “状态” 的背景知识。

    为了查找某个账户，或者说在这棵庞大的树上找到某片 “叶子”，需要解析 6 ~ 9 个哈希值，从根节点开始，经由中间节点，最终解析到一个能够给予我们所需数据的哈希值。

    随着以太坊状态的增加，就有必要提高访问状态树的操作的 Gas 消耗量。早在 2016 年 10 月，我们就曾用 “橘子口哨（Tangerine Whistle）” 分叉（纳入 EIP 150，在区块高度 246 3000 激活）做过这样的事。EIP 150 大幅提高了特定操作的 Gas 消耗量，并引入了一系列的措施来保护网络免于 DoS 攻击；这是在所谓的 “上海攻击” 之后推出的。

    另一次这样的 Gas 消耗量提升是在 “伊斯坦布尔” 分叉的时候，在区块高度 906 9000 （2019 年 12 月）激活，引入了 EIP 1884。1884 的内容包括：

    SLOAD 操作码的 Gas 消耗量从 200 提高到 800 gas

    BALANCE 消耗量从 400 提高到 700 gas （还加入了一个更便宜的 SELFBALANCE 操作码）

    EXTCODEHASH 消耗量从 400 提升到 700 gas

    问题（们）

    两位以太坊安全研究员 —— Hubert Ritzdorf 和 Matthias Egli —— 与这篇论文的作者之一 Daniel Perez 展开了合作，并 “武器化” 了一个漏洞，并提交给了以太坊的 bug 悬赏项目。那是在 2019 年 10 月 4 日。

    在一个专门讨论跨客户端安全性的频道里，来自 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 秒

    显而易见的是，EIP-1884 确实减少了攻击的效果，但还是远远不够的。

    随着 2019 年接近尾声，我们发现，这问题比我们之前以为的还要棘手，恶意的事务可能导致出块时间延长到以分钟计。更难办的是，开发者社区已经对 EIP-1884 感到不满，它打破了一些合约，而且用户和矿工都希望提高区块的 Gas Limit。

    于是大家创建了一个新的客户端协作频道，Geth、Netheremind、OpenEthereum 和 Besu 的开发者继续合作。

解决方案

    另一方面，我们可以依靠软件工程，改变客户端内的数据模式和结构。

协议层工作

    不过，Peter 找出了一个绕过它的办法 ——“shielded relay” 攻击 —— 使得本质上惩罚有了一个上限（约为 800）（译者注：此处没有单位，疑为 gas）。

    因此，这个 EIP 也被抛弃了，我们要寻找更好的替代方案。

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

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

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

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

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

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

    Peter 尝试用动态的状态快照解决这个问题，时值 2019 年 10 月。

    快照是一个次级的数据结构，用来以扁平格式（flat format）存储以太坊状态。快照可在 Geth 节点正常运行期间创建，无需下线专门执行。快照的好处是，它可以作为状态访问的一种加速结构：

    不再是执行 O(log N) 次硬盘读取（还要乘以 LevelDB 的开销）来访问一个账户/存储项，快照可以提供直接的，O(1) 级别的访问时间（再乘以 LevelDB 的开销）。

    快照还支持以每个条目 O(1) 的复杂度迭代账户和存储项，这使得远程节点可以检索连续的状态数据，比以往便宜非常多。

    快照的存在还支持其它更奇怪的用途，比如离线修剪状态树，以及迁移到另一种数据格式。

    动态快照的想法从 2019 年中就有了，当时的主要目标是启用 “快照同步”。那时候 Geth 团队还在开发许多 “大项目”：

    离线的状态修剪

    同态快照 + 快照同步

    通过共享状态实现 LES 状态分散

    有了 “动态快照” 功能，我们就能喘口气了。如果以太坊网络遭到攻击，那会是很痛苦的，但至少，我们能通知用户打开快照功能。生成快照需要花一些时间，而且还没有办法同步快照，但网络至少能继续运行了。

结合

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

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

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

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

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

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

    我们估计，在当前的主网上（区块为 1500 万 gas），不使用 快照的 geth 节点可能可以做到只需 2.5 ~ 3 秒就能执行一个区块。随着状态的增长，这个数字会继续恶化（对于不使用快照的节点来说是如此）。

    至于实施这种攻击的可行性，攻击者买断一个区块的成本大概在几个 ETH 这样的级别（1500 万 gas，100 Gwei 的价格，乘出来就是 1.5 ETH）。

为何要在此时公开

    因为我们已经激活了 “柏林” 升级，也因为 geth 客户端已经默认使用快照功能，我们认为，威胁已经足够低，而透明化才是更重要的了。所以是时候把幕后的工作都公开了。

    重要的是，社区得到了一次理解和思考这些影响用户体验（这些 EIP 会提高 Gas 消耗量，也会限制返还机制的效果）的变更的机会。