结合blobpool票据的稀疏mempool

结合 Blobpool 票据的稀疏内存池

在本说明中，我们提出了一种 Blobpool 票据的变体，作为一种可集成到稀疏 blobpool 设计中的机制，以增强其对 DoS 攻击的抵抗能力。

稀疏内存池

这里的核心思想是随机分配下载 Blob 数据的负担。具体来说，一旦 blob 交易及其相关负载被提交到 blobpool，节点将以概率 p 被分配“提供者”角色并下载整个负载。以概率 1−p，节点将被分配“采样者”角色，并从“提供者”节点接收负载的单个单元进行采样。选择 p=0.15 似乎足以使采样节点有足够高的概率从其 peers 处获取其托管单元。因此，在任何给定时间，每个节点对于一组 Blob 是“采样者”，对于另一组 Blob 是“提供者”。这提供了一种分配 Blob 传播负载的机制，因为提供者节点实际上负责并承担传播的负担（以带宽消耗计）。而采样节点仅间接参与传播。图 1 示意性地展示了上述结构。

采样节点仅拥有 Blob 的部分信息这一事实引入了根本性困难，即从本地样本确定可用性的困难。在缺乏某种协调策略（通过多个节点共同确定可用性）的情况下，这可能导致 DoS 攻击，如本文中详细描述的那样。

图 1：稀疏内存池中单个 Blob 的单元被各个节点下载的示意图。节点 1、5 和 8 是提供者节点，其余为采样节点。假设节点 1−4、5−7 和 8−11 分别互为 peers。那么，节点 2−4 从节点 1 获取单元，节点 6、7 从节点 5 获取单元，节点 9−11 从节点 8 获取单元。因此，提供者节点 1、5、8 承担了该 Blob 传播的主要负担（以带宽计）。

Blobpool 票据

Blobpool 票据 以及类似的方法（如无条件支付）可以通过确保无论 Blob 是否被包含在区块中都会收费来提供对 DoS 攻击的抵抗能力。换句话说，这种机制可以被视为一种区分通过 blobpool 的数据预传播服务和普通数据传播服务的方式。通过区分这两种资源并独立定价（例如，前者通过 Blobpool 票据，后者通过 Blob 基础费用机制），我们确保任何在 blobpool 中传播的 Blob 数据（无论可用与否）都以一定价格进行。

具体方案

我们提出了一种两步机制的 blobpool 票据分配方法。这里，blob 提交者获得在未来某个时间窗口 Δ 内传播一个 Blob 的权利。具体来说，blobpool 票据可以通过一个智能合约 TicketAllocator 来分配，获取过程通过一个普通的交易完成，该交易的字段为 to = TicketAllocator、data = l、beneficiary address 以及通常的费用字段。对于每个 slot，blobpool 票据的数量设定为某个常数 k=c×MaxBlobs，并且每个 slot 的构建者通过本地规则（例如按优先级费用顺序）决定如何分配它们。智能合约确保在一个 slot 中最多发行 k 个票据，然后通过发出包含这三个参数的日志，在发送者（或受益者）地址、某个区块和常数 l（获取的票据数量）之间建立对应关系。每个节点计算并维护一份所有当前活跃票据地址的记录，作为 blobpool 中 Blob 传播的条件。票据在某个时间段 Δ（以 slot 为单位，例如 3 个 slot）内被视为活跃。实现这一点的一种具体方法是使票据的有效性依赖于 slot，将其与生成该票据的区块关联起来。只要当前区块是该区块的后代且距离 ≤Δ，票据就被视为活跃。因此，当节点通过 blobpool 收到新的 blob 交易时，它会检查本地记录，并且仅当 blob 提交者的活跃票据计数 >0 时，才会根据稀疏 blobpool 机制获取/采样并转发该 blob。

如前所述，票据购买包括要关联票据的地址，该地址可以与交易发送者不同。一个从单一地址（例如排序器地址）提交 blob 交易的 L2 操作者可以使用任何 EOA 以及任意数量的 EOA 来购买票据，同时将所有票据绑定到该单一地址。这使得 L2 操作者能够提交 blobpool 允许的最大数量的 blob（最大并发活跃票据数），而不会遇到诸如客户端对单个 EOA 可排队交易（尤其是 blob 交易）数量的限制等约束。由于这已经是 L2 抱怨的一个点，并且随着 blob 吞吐量增加和并行提交 blob 变得必要，这个问题可能会变得更糟，我们认为这是本提案为现有稀疏 blobpool 机制带来的另一个非常有意义的益处。

图 1： 工作流程示意图。图的下半部分说明了 blobpool 中的传播如何依赖于票据机制。blob 提交者首先向交易内存池（或直接向构建者）发送一笔票据交易。一旦票据交易上链，blob 提交者就有一个时间窗口 Δ 来使用分配的票据在 blob 内存池中传播一个 blob。参与 blobpool 的节点检查其本地票据持有者记录，以获取并传播新宣布的 blob。在图中，Blobpool 节点 1 和 2 已经在链上看到了 Alice 的票据交易，因此获取了她宣布的 blob1，而 blobpool 节点 3 尚未看到她的票据交易，因此拒绝获取和传播 blob 1。该 blob 最终被某个构建者包含在后续区块中。

总之，该机制的工作流程如下：

1. 在 slot N 之前：交易被发送到内存池或私下传达给构建者。交易包含要获取的票据数量 l。
2. 在 slot N 中：交易被包含在区块中。交易调用智能合约，生成一张票据。票据引用发送者（或受益者）地址、l 和当前区块。
3. 一旦 blob 提交者收到区块：blob 交易和 sidecar 被提交到 blobpool。只要 blob 提交者根据节点本地记录视图拥有活跃票据，Blob 就会按照稀疏 blobpool 机制进行传播。特别地，如果节点收到新 blob 交易的公告，它会获取/采样该 blob（如果发送者有足够的活跃票据），并相应地减少发送者的票据计数器。

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