稀疏blob池中的恶意节点攻击

稀疏 blobpool

稀疏 blobpool 是一种扩展 EL blobpool 的方法，主要依赖概率性获取和可用性信号。收到 blob 交易公告的对等节点将以概率 p 获取完整 blob，以概率 1 − p 获取部分 blob（cells）。在部分获取的情况下，为了缓解数据扣留攻击，对等节点会在给定超时内检查至少 k 个邻居节点的可用性信号，仅当满足条件时才将部分 blob 与交易一起存储在 blobpool 中。

恶意节点

在稀疏 blobpool 中，接受决策依赖于发出可用性信号的邻居节点。这些节点是否会恶意行为并欺骗某个节点关于可用性的信息？引入此类恶意节点会产生什么影响？

最坏情况的攻击是对 blobpool 的拒绝服务攻击，攻击者用永远不会被包含在区块中的交易填满受害者的 blobpool。当前的 blobpool 实现包含几种针对此情况的缓解措施。例如，blobpool 中不允许存在 nonce 间隙，因为存在间隙的交易在间隙解决之前不会被包含在区块中。因此，为了提高拒绝服务攻击的恢复能力，最安全的做法是只存储那些很可能在近期被包含并从内存池中移除的交易。

以下场景描述了恶意行为，这些行为可以在本地针对与恶意节点连接的特定节点执行。需要进一步研究来估计这些行为的概率和可重复性，但攻击者的目标是浪费受害者 blobpool 的部分或全部空间。主要影响是降低受害者的 blobpool 服务（blob 构建和 getBlobs API 服务）。我不认为这会影响链的最终性或活性。然而，从工程角度来看，我认为每当发生这种情况时，要求操作员删除所有磁盘上的交易并重新启动是不可取的，需要考虑到这种风险。

场景

1. 攻击者将 k 个节点连接到受害者节点。
   • 在现实情况下，攻击者能否创造这种局面？
   • 计算表显示 k 将被设置为 2 到 4 之间。
   • Geth 节点通常将三分之二的连接分配给入站连接。
     • 当 MaxPeers = 50 时：34 个入站连接和 16 个出站连接。
   • 此外，每 3–7 分钟会随机断开一个入站或出站连接。
   • 攻击者占据受害者 2–4 个入站连接的可行性如何？
   • 故意增大 k 会使这种设置更难实现，但这是否会阻止传播，或者增加 p 从而降低缩放因子？
2. 攻击者创建 blob 交易 A0: {address: A, nonce: 0} 并公告给受害者节点。使用步骤 1 中的攻击者节点，攻击者利用其 k 个节点专门向受害者发出 A0 的可用性信号。攻击者不使此可用性信号对网络的其他部分可见。
   • 2-1. （概率 p）如果受害者请求完整获取，攻击者节点不响应并返回步骤 1，寻找其他受害者节点。
     • 如果成本可接受，攻击者也可以直接响应此请求并支付 A0 的成本，然后发送 B0, C0, … 直到出现 2-2 的情况。
   • 2-2. （概率 1 − p）如果受害者请求部分获取，攻击者节点响应。
     • 然后受害者向邻居节点公告 A0。
     • 然而，由于攻击者不会向网络的其他部分发出可用性信号，A0 无法被传播。
     • 结果，A0 不会被传播到网络的其他部分，而是仅存储在受害者的 blobpool 中。
3. 攻击者创建 blob 交易 A1: {address: A, nonce: 1} 并公告给受害者节点。
   • 3-1. （概率 p）如果受害者进行完整获取，攻击者节点响应。
     • 受害者向邻居公告 A1。
     • 然而，相邻节点由于不知道 A0（因为之前未能传播），会将 A1 视为有间隙的交易并拒绝它。
   • 3-2. （概率 1 − p）如果受害者进行部分获取，攻击者节点响应，并且与 2-2 结果相同。

• 无论受害者的获取决定如何，A1 都不会传播到网络的其他部分，并且仅存储在受害者的 blobpool 中。
• 因此，如果攻击者成功在受害者的 blobpool 中存储了一个无法传播的 blob 交易（A0）（情况 2-2），攻击者随后可以使用同一地址（A1, A2, A3, …）在受害者的 blobpool 中积累额外的 blob 交易。
  • 这些交易永远不会被包含在区块中，因为它们没有向网络的其他部分公开。
• 从受害者的角度来看，在 2-2 之后无法将攻击者节点识别为恶意节点，因为这些节点已经响应了受害者节点的请求。

幸运的是，Geth 的 blobpool 将每个账户存储的交易上限设为 16。因此，单个卡住的交易不会立即导致 blobpool 拒绝服务攻击。然而，由于无法识别攻击者，因此也无法识别攻击者的交易，受害者节点无法移除攻击者每个账户最多插入的 16 笔交易。为了防止这种浪费，我们需要一种方法来移除这些交易。

此外，另一个遗留问题是攻击者能在多大程度上浪费我们的 blobpool。攻击者能否重复执行此攻击以慢慢填满 blobpool？这又可以追溯到上面的问题 1，但我不清楚如何量化这种可能性。

未来工作

• 在稀疏 blobpool EIP 中记录 blobpool 每个账户 16 笔交易的上限。
  • 不强制执行此限制的客户端将容易受到拒绝服务攻击。
  • 据我所知，此限制尚未在 EIP 中明确规定。
  • 考虑到当前的 blobpool 不鼓励重新传播，明确此条件会比较好。
• 将 blobpool 中在合理时间段内未被包含在槽位中的 blob 逐出。
  • 这需要进一步规范。
  • 当前的 blobpool 实现认为逐出 blob 交易是禁止的。
    • 删除已经传播的 blob 交易可能成为拒绝服务攻击的载体。
    • （我需要进一步研究此行为的基本原理。）
  • 注意，这并不能消除恶意节点浪费 blobpool 空间的可能性。这些节点仍然可以尝试占据 blobpool 空间，但我们也会尝试移除它们。
    • 因此，如果攻击者能在短时间内重复此类攻击，这种方法将无法缓解。
    • 整个稀疏 blobpool 的概念是，我们可以根据节点行为以一定概率识别恶意节点。在我看来，如果没有方法实际验证每个响应是否对我们有帮助，节点总是有办法绕过我们的雷达。例如，如果我们进行概率性验证，它们也可以概率性地攻击我们。
• 我们能否有意延长两次攻击之间的时间间隔？能否结合以下三种策略？

1. 优先考虑分数足够高的节点发出的信号。
   • 为了积累节点分数，节点必须维持一段时间的稳定连接，并且为我们的 blobpool 做出贡献（Csaba 提出了类似的想法）。
   • 这可以防止在短时间内发起多次攻击。
2. 当 blobpool 满时，删除其中的旧交易。
   • 这可以移除攻击者使用的交易，但也会移除一些诚实节点的便宜交易。
   • 对于本地 blob 交易，我们可能需要一个交易追踪器，以防止我们客户端的交易被删除。
3. 每个账户 16 个交易上限

• 原文链接： hackmd.io/@yZzECM-fQt2eP...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～