论稀疏内存池设计的DoS抵抗性

论稀疏 Blobpool 设计的抗 DoS 能力

接下来我们将探讨稀疏 blobpool 的抗 DoS 能力，指出当前设计的弱点，并提出可能的修复方案。

首先，我们注意到稀疏 blobpool 设计本质上是一种实现 blobpool 垂直分片的方式，其主要抗 DoS 机制建立在以下两个原则上：

1. 节点只有在看到某个 blob 可用时才会传播它。
2. 提供者节点简单地检查可用性。
3. 采样节点依赖于从相邻提供者收到的可用性信号。

从根本上说，稀疏 blobpool 设计依赖于提供者节点在网络中传播 blob 数据。因此，提供者节点恶意行为的重要性要高于当今 blobpool 中节点的恶意行为。这不仅对它们的相邻提供者节点成立，对其相邻采样节点更是如此，因为后者无法独立判断可用性。

这为对单个采样节点发动攻击提供了可能性，攻击者通过成功地向该节点（而对网络其他节点则不然）发出某个 blob 的可用性信号来实现。此类攻击的一个例子由 Bosul 强调。在这种攻击中，恶意方连接多个对等节点

$A_1,\ldots,A_k$

到受害节点

$V$。通过仅向

$V$ 发出 blob

$B_1$ 的可用性信号，如果

$V$ 最终采样了

$B_1$，则

$V$ 的本地 blobpool 中将持有一个其他节点都没有的 blob。这是因为

$B_1$ 不会在网络中传播，因为所有其他节点都看不到它可用。攻击者可以无成本地重复此操作（详见 Bosul 的笔记），最终用不会上链的 blob 填满

$V$ 的本地 blobpool。

应当指出，同样的攻击在当今的 blobpool 中也能实施，但需要控制

$V$ 的所有对等节点。

可用性信号

我们可以考虑至少两种方法使此类针对性攻击更加困难。根本问题在于，一个 blob 的可用性和传播本质上是由一小部分提供者节点决定的，这使得针对单个节点的攻击比当今的 blobpool 更容易。

因此，解决这个问题的一种方法是在节点之间引入关于可用性的进一步通信。在当前的稀疏 blobpool 设计中，节点无法了解其对等节点是否将某个 blob 视为可用，除非它们扮演提供者的角色。我们可以通过引入进一步的“可用性”消息交换来改变这一点。具体可以通过以下方式实现：

• 在获取/采样一个新 blob 后，提供者/采样节点会通过 NewPooledTransactionHashes 向其所有对等节点（包括 那些从其收到该交易的节点）宣布此交易。接收来自某个对等节点的宣布，即表示该对等节点认为此 blob 可用。
• 每个节点持有 availability_of_peers={"P_1": (1,0,1,1,...,1), "P_2": (1,1,...,0),...,"P_N":(0,1,1,...,1)}，其中 availability_of_peers["P_j"][k]=0/1 表示第

$j$

个对等节点是否宣布了第

$k$

个 blob 可用。

• 基于此，节点可以选择保留或丢弃某个 blob。这可以通过（可能按对等评分加权的）多数投票来实现。

有了这一机制，基于建立对 blob 可用性不同观点的攻击将变得更加困难。具体来说，攻击者需要控制足够多的受害节点的对等节点，才能迫使多数投票做出有利于自己的决定。

我们注意到，尽管这比当前提案有所改进，但并未降低到当今 blobpool 的水平——在当今 blobpool 中，要实现这一点，攻击者需要控制受害者的所有对等节点。

强制传播

上述描述机制基于在节点邻域内丢弃看似不可用的 blob 的原则。

我们可以使用的另一个潜在互补机制基于强制传播此类 blob 的原则。具体实现如下：

• 引入对等评分机制，并使对等节点的可用性信号计入评分。
• 根据宣布 blob 的对等节点的评分来调整成为提供者的概率

$p$。如果评分高，即我们对对等节点信心高，则保持

$p=0.15$。如果评分低，则相应增加

$p$。

我们可以考虑

$p$ 取连续值，或者简单地根据对等节点评分是否高于某个阈值，取

$p \in {0.15, 1}$。这里的逻辑很简单：如果对等节点的评分低，你就不能相信它们关于可用性的声明，因此你不太可能去采样。具体来说，如果你的对等节点的可用性信号表明某个 blob 不可用，你可以从采样者角色切换为提供者角色，以明确检查可用性，并在 blob 可用时强制其传播。

从局部攻击到全局 DoS

此时最重要的问题是，这种针对节点的攻击是否真的会导致系统层面的 DoS。

答案是“是的，但前提是攻击者控制着相对较大比例的节点”。具体来说，假设一个攻击者控制了大多数节点，不难看出他们可以利用上述讨论的攻击，为每个节点施加不同的本地 blobpool。结果，我们基本上没有有用的 blobpool 预传播，这可以被解释为对系统的成功 DoS 攻击。但不可能的是那种基于发送一个不可用 blob，并利用分片机制使其在网络中不受阻碍地传播的 DoS 攻击（例如，如果考虑最原始的垂直分片形式，由于节点无法验证可用性，这种情况可能发生）。

设

$k$ 为节点在获取 blob 之前需要观察到宣布该 blob 的对等节点的阈值数量。很明显，恶意方可以通过控制目标节点的

$k$ 个对等节点来使其获取某个 blob

$B_1$。

如果加上上述“可用性信号机制”，目标节点将保留

$B_1$ 当且仅当其大多数对等节点发出其可用性信号。

为了实现这一点，恶意方可以：

1. 直接控制目标的大多数对等节点，即总共

$D/2$ 个（其中

$D$ 是对等节点数量）。或者 2. 通过同样的机制将

$B_1$ 传播给目标的大多数对等节点。这需要控制

$kD/2$ 个节点（对于每个

$D/2$ 需要对等节点控制

$k$ 个）。

对于方案 1，要使

$B_1$ 存在于

$M$ 个节点的 blobpool 中，攻击者必须独立地对所有这些节点重复攻击。这大致意味着他们需要控制总共

$MD/2$ 个对等节点。注意：这里我们假设对等节点集合基本上是随机的。因此对等节点集合之间的预期重叠很小。设

$S_A$ 为

$A$ 的对等节点集合。如果

$B$ 在

$S_A$ 中，那么

$S_A$ 和

$S_B$ 的重叠很可能只有边

$A-B$。这意味着方案 1 中攻击者需要控制的节点集合基本上是独立的。

对于方案 2，很明显我们得到一种嵌套结构。要使

$B_1$ 保留在那

$kD/2$ 个对等节点的 blobpool 中，攻击者必须独立地对每个节点重复相同的逻辑。显然，这种扩展方式（从攻击者的角度）远不如方案 1 有利。因此我们在这里忽略这种策略。

因此，要使系统大小相关的节点子集无法提供服务，

$M = f(N)$，那么攻击者需要控制的节点数量也按同样比例缩放。

此分析以及 Bosul 描述的攻击的逻辑主要关注消耗目标节点的本地 blobpool 容量。显然，更紧迫的问题是消耗目标节点的带宽。

这种针对带宽的攻击所需的资源（以节点数量计）将取决于可用性信号传播和处理的速度。在最坏情况下（即延迟很大），资源需求将为

$Mk$ 而不是

$MD/2$，这差了一个数量级（10 倍）。让我们从当今 blobpool 的情况开始看：

在当今的 blobpool 中，恶意方可以向节点发送无效 blob，消耗其带宽。在这种情况下，目标节点可以立即检查有效性，并立即决定断开与攻击者对等节点的连接。这意味着在当今的 blobpool 中，要成功实施带宽耗尽攻击，攻击者需要连接

$L$ 个恶意对等节点，其中

$L \times \text{blobsize} \geq \text{目标带宽}$。

在稀疏 blobpool 中，采样节点根本无法确定 blob 的有效性。因此，它必须利用上述外部可用性信号来决定是否断开恶意对等节点。所以问题在于，等待可用性信号引入的延迟有多大，以及在此情况下攻击者需要多少对等节点

$L'$ 才能实现其目标，满足

$L' \times \text{blobsize} 8 \geq \text{目标带宽} ; \quad L' \geq k$。

后一个条件源于目标节点只有在观察到至少

$k$ 个对等节点宣布某个 blob 时才开始获取。与之前同样的论证，很容易看出，要攻击

$M$ 个对等节点，恶意方需要控制

$ML'$ 个节点。最坏情况当然是

$L' = k$。这种情况下，如果延迟很大，节点在其带宽被耗尽之前无法断开恶意对等节点。

因此，选择一种不会引入太大延迟的可用性信号非常重要。例如，我们可以考虑不等待所有对等节点的可用性消息来进行多数投票，而是只等待一个预定义的时间窗口（由可容忍延迟的上限决定），并根据当时可用的信息做出可用性决策。

总结

总结一下，我们可以通过一种旨在建立 blobpool 通用视图的机制，在稀疏 blobpool 中实现一定程度的抗 DoS 能力。如我们所见，实现这一目标的薄弱点是采样节点。由于采样节点无法自行决定 blob 的可用性，它们容易受到恶意提供者节点的攻击。我们提供了两种可以缓解此问题的机制。在这两种机制中，采样节点从其对等节点接收可用性信号，并据此决定可用性。如果某个 blob 被认为不可用，节点可以：

• 从其本地 blobpool 中丢弃该 blob。
• 通过切换角色为提供者来强制传播。

在这两种方法中，节点都需要一种方式来“惩罚”恶意对等节点并防御自身。为此，我们需要一种基于对等评分机制的机制，节点可以据此确定对某个对等节点的信任程度。这可以用作选择性地增加/减少成为采样节点概率的机制，或者在极端情况下甚至完全断开对等节点。

如我们所见，这两种方法原则上都可以理解为建立通用 blobpool 的机制。然而，我们需要进一步研究如何最好地整合和结合它们。直觉上，让节点自行决定是丢弃 blob 还是强制传播似乎不是一个可行的选择。虽然最终目标相同，但它们基于相反的机制操作，可能导致两者都无效。

无条件支付

上述机制是否可行应基于我们所需的安全保证来决定。如果我们认为这些机制不足，我们建议在稀疏 blobpool 机制之外，并行引入一种“无条件支付”机制。我们不会在此详细讨论无条件支付机制，感兴趣的读者可以参考其他相关资料。然而，让我们简要回顾一下基本原则。

无条件支付机制的基本原则是，那些在 blobpool 中传播并因此消耗真实用户资源（带宽等）的交易必须支付费用。这里的想法是，对于 blob 是否被包含在后续的某个 blob 中，采取一种不可知的态度。一个不可用因此无法被包含的 blob，如果支付了“无条件”费用（可以理解为 blobpool 传播和资源使用的费用），则与可用 blob 受到同等对待。

具体来说，这种与给定 blob 关联的“无条件”费用交易，可以像当今正常交易一样在 blobpool 中传播。因此，无条件费用交易与当今 mempool 中的任何交易具有相同的安全保障。

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