以太坊 - Sepolia事件 - Eth Cn

这篇博文揭露了以太坊网络自合并（the Merge）到 Dencun 硬分叉之前存在的一个威胁。

背景

在合并之前，为防止客户端遭受拒绝服务（DOS）攻击，对RPC通信设置了不同的消息大小限制。这些限制适用于通过HTTP端点接收的消息，并被沿用到引擎API，该API在区块生产期间起着连接执行层和共识层客户端的关键作用。由于引擎API参与区块生产，因此有可能生产出超过某些客户端的RPC大小限制，但仍在其他客户端可接受范围内的区块。

如果攻击者创建的消息超过了设置最低的客户端的大小限制，同时仍然符合gas限制的要求，然后等待区块被生产出来，就可能导致一种情况：一些客户端认为该区块有效，而另一些客户端则拒绝该区块，并发出HTTP错误代码“413：内容过大”。

影响

能够构造这些消息的攻击者可以强制大多数节点（=geth）拒绝少数节点会接受的区块。这些区块将被分叉掉，提议者将错失奖励。

起初，我们认为只能通过使用构建者（builders）或修改后的客户端版本来创建这些区块。Geth 对交易有一个 128KB 的内置限制，这意味着像讨论中的这样的大型交易不会进入任何 geth 节点的交易池（transaction pools）。然而，仍然可以通过让具有更高限制的客户端提议区块，并且 CL 请求验证这个提议的更大的区块来触发这个限制。

我们提出了一个解决方案，即暂时将所有客户端的 RPC 限制降低到最低值（5MB）。这将使区块无效，并且攻击者在网络中可能造成的混乱将受到很大限制，因为大多数节点会拒绝他们的区块。

然而，在 2 月 7 日，我们发现有可能创建一个区块，该区块通过一堆小于 128KB 限制且不超过 3000 万 gas 的交易达到 5MB 的限制。

这是一个更大的问题，因为我们意识到攻击者可以创建一堆高额支付的交易并将它们发送到网络。由于他在 mempool 中支付的价格高于其他所有人，因此每个节点（甚至 geth 节点）都会在其区块中包含攻击交易，从而创建一个不会被网络中的大多数节点接受的区块，导致大量分叉（所有分叉都被少数节点视为有效），并且链会不断地重新组织。

后来在 2 月 7 日，我们得出结论，每个人都提高他们的 RPC 限制将是更安全的替代方案。

时间线

• 2024-02-06 13:00: Toni (EF)，Pari (EF) 和 Justin (Besu) 尝试向网络提交一个专门研磨的交易。当 snappy 压缩时，该交易贡献高达 2.7 MB 的区块。
• 2024-02-06 13:25: Pari 从他本地的 Geth 节点收到错误，尽管该交易应该是有效的。
• 2024-02-06 15:14: Justin 设法将交易放入一个区块，并通过 Besu 客户端提交了它。
• 2024-02-06 20:46: Sam (EF) 提醒 Pari（特别感谢 X 上的 mysticryuujin），Toni 和 Alex 关于某些 Sepolia 节点正在挣扎。
• 2024-02-06 21:05: 团队与来自 Geth 的 Marius 再次核实并确认了这个错误。
• 2024-02-06 21:10: 大家聚在一起进行调试
• 2024-02-07 23:40: 我们决定所有客户端将其 RPC 请求限制限制为 5MB
• 2024-02-07 6:40: 我们发现可能存在更大的问题，并且可以使用小于 128KB 大小的交易执行攻击。
• 2024-02-07 10:00: 我们决定所有客户端增加 RPC 请求限制。
• 2024-02-07 21:00: 该修复程序已合并到 geth 中。
• 2024-02-09: Geth 发布

补救措施

虽然 Geth 是唯一受此 bug 影响的客户端，但其他客户端也更新了他们的默认设置，以确保即使 gas 限制增加也能安全地免受此攻击。 客户端团队表示，以下更新具有安全的 rpc 限制：

Geth: v1.13.12

Nethermind: v1.25.4

Besu: 24.1.2

Erigon: v2.58.0

Reth: v0.1.0-alpha.18

上一篇文章 下一篇文章

• 原文链接： blog.ethereum.org/2024/0...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～