以太坊 - Mempool门票 - Fradamt

Blob mempool tickets

介绍

是什么

核心思想是：

• 镜像 mempool 抽样：使用 垂直分片 mempool，节点下载所有 blob txs，但仅对相关的 blob 进行抽样，索引的选择镜像了区块的列抽样，即下载第 i 列的节点，也会下载 mempool 中所有 blob txs 的第 i 个样本。
• Mempool 空间分配：为了避免分片 mempool 上的 DoS 问题，mempool 被限制为每个 slot 固定数量的 blob 容量，而这种稀缺的 mempool 写入权限通过以 mempool 票证的形式出售来分配。

为什么

• 这是一种相对简单的方法，可以对垂直分片 mempool 实施必要的限制，并且还具有使 mempool 吞吐量完全受所需网络吞吐量限制的额外好处。
• 对于所有通过 mempool 的 blob，抽样可以已经在其中发生，时间线更加宽松。这意味着：
  • 峰值带宽不是那么大的约束
  • 我们可以更安全地使用基于拉取的 gossip（就像现在的 blob mempool 已经做的那样）。这减少了冗余，因为平均每个节点每个 blob 只发送和接收一次。
  • CL 和 EL 之间没有带宽重复，只有 mempool 传播。
• 无需单独的 blob IL 机制：与其将制作 blob IL 的权利分配给验证者，通过在 IL 委员会中随机选举他们，我们可以将每个 mempool 票证视为也分配了 blob IL 委员会的席位。换句话说，mempool 中的每个 blob tx 本身都可以充当 blob IL。由于这些的数量很少，因此验证者无需将它们打包到 IL 中，我们可以依靠直接的 mempool 观察（尽管我们仍然需要不运行完整 mempool 的证明者具有某种可用性信号，例如委员会的投票。请参阅此处）。

Mempool

现在，让我们暂时不用担心如何分配票证，而只关注如何使用它们来构建 blob mempool。为此，我们唯一需要的是共识层以某种方式了解票证。假设 BeaconState 以循环数组 state.blob_tickets_record 的形式记录了接下来 SLOTS_PER_EPOCH 个 slot 的票证持有者。特别是，state.blob_tickets_record[slot % SLOTS_PER_EPOCH] 记录了 slot 的票证持有者，形式为 BLS 公钥。

class BeaconState(Container):
    ...
    blob_tickets_record: Vector[List[BLSPubkey, MAX_BLOBS_PER_BLOCK], SLOTS_PER_EPOCH]

blob mempool 完全存在于 CL p2p 网络上，由单个 blob_transaction_envelope 全局主题（用于共享 blob 交易）和 NUMBER_OF_COLUMNS mempool_cells 主题（用于共享与其关联的 blob 样本以及证明）组成。在 slot N 中发送这些主题的消息需要持有 slot N 的票证，可以通过针对为其记录的公钥进行检查，即 pubkeys = state.blob_tickets_record[N % SLOTS_PER_EPOCH]。特别是，消息必须包含一个 ticket_index，并使用 pubkeys[ticket_index] 进行签名。

Blob 交易主题

blob_transaction_envelope

class BlobTransactionEnvelope(Container):
    transaction: Transaction
    kzg_commitments: List[KZGCommitments, MAX_BLOBS_PER_TRANSACTION]
    slot: Slot
    ticket_indices: List[uint8, MAX_BLOBS_PER_TRANSACTION]

class SignedBlobTransactionEnvelope(Container):
    message: BlobTransactionEnvelope
    signature: BLSSignature

注意： 如果我们有 ssz 编码的交易，我们可以从 BlobTransactionEnvelope 中移除 kzg_commitments，因为我们可以访问版本化的哈希，并根据单元格中的 kzg 承诺检查它们。如果没有，我们还必须向 EL 提供与 kzg_commitments 对应的版本化哈希，并让它检查它们是否与 transaction 中的哈希相对应。

Gossip 检查

设 blob_tickets = state.blob_tickets[slot % SLOTS_PER_EPOCH]。在转发之前，我们实际上只是通过要求以下条件来检查消息是否由未使用票证的持有者正确签名：

• 与 ticket_indices 对应的所有票证的持有者都相同，即对于 ticket_indices 中的所有 ticket_index，blob_tickets[ticket_index].pubkey 相同。
• 对于 ticket_indices 中的每个 ticket_index，这是为 ticket_index 接收的第一个有效消息
• signature 是 pubkey 对 message 的有效签名，其中 pubkey 是拥有所有票证的唯一公钥，即对于 ticket_indices 中的任何 ticket_index，blob_tickets[ticket_index].pubkey。

样本主题

mempool_cells_{subnet_id}

class CellSidecar(Container)
    cell: Cell
    index: CellIndex
    kzg_proof: KZGProof
    kzg_commitment: KZGCommitment

class MempoolCells(Container):
    cell_sidecars: List[CellSidecar, MAX_BLOBS_PER_TRANSACTION]
    slot: Slot
    ticket_indices: List[uint8, MAX_BLOBS_PER_TRANSACTION]

class SignedMempoolCells(Container):
    message: MempoolCells
    signature: BLSSignature

注意： 与 CellSidecar 相比，开销为 105 字节（主要来自签名），当 NUM_COLUMNS = 128 时约为 5%，当 NUM_COLUMNS = 256 时约为 10%。与在单个（签名）消息中发送带有证明的 blob 相比，开销仅来自每个单元格中的 kzg_commitment、cell_index、slot 和 ticket_index，每个单元格总共 65 字节。

Gossip 检查

在转发之前，我们基于 slot 和 ticket_indices 执行与 BlobTransactionEnvelope 主题中完全相同的检查，这相当于检查消息是否由该 slot 的未使用票证的持有者正确签名。我们还检查子网是否正确：

• compute_subnet_for_cell_sidecar(cell_sidecar.cell_index) == subnet_id

有效性

在进行 gossip 时，我们不需要以下检查，但是为了使 MempoolCells 对象有效（以及 gossip 检查），需要进行以下检查：

• 通过 cell_sidecar.kzg_proof 验证 cell_sidecar.cell 是 cell_sidecar.kzg_commitment 在 cell_sidecar.cell_index 处的展开。

换句话说，我们不需要验证单元格 sidecar 本身。我们不这样做的原因是，验证单个单元格虽然相当便宜（约 3 毫秒），但远不如批量验证有效（例如，整个 blob 需要约 16 毫秒）。为了防止 DoS，检查签名就足够了。完整的验证可以在以后完成，一旦检索到某个 blob 的所有单元格（或者无论如何，客户端可以随意安排此操作）。这些单元格最终只有在验证了证明后才被认为是有效的。

替代设计

由于验证签名“仅”比验证单元格证明快约 2-3 倍，因此另一种设计可能是不对 MempoolCells 进行签名（这节省了 96 KB，约 10%），而是立即验证证明，无需等待批量验证。但是，节点只会验证和转发 MempoolCells 对象，如果它知道相应的 BlobTransactionEnvelope，因为这是签名验证（即通过票证对 mempool 进行门控）将在该设计中发生的唯一地方。

另一种设计，它重新引入了一些带宽开销，但完全消除了任何验证开销，是在 BlobTransactionEnvelope 中包含一个字段 mempool_cells_hashes: List[Root, NUMBER_OF_COLUMNS]，用于存储与交易关联的所有 MempoolCells 对象的哈希。这样，一旦节点拥有 BlobTransactionEnvelope，它就可以转发任何哈希匹配的 CellSidecar，而无需等待 kzg 证明验证，这可以在方便的时候进行批量处理。这样就没有验证开销，而带宽开销仅为每个单元格 32 字节（假设单个 blob 交易的最坏情况），比签名少 3 倍。

总而言之，至少有三种可能的设计，具有以下权衡：

票证分配

1559 式销售

票证可以通过 EL 上的系统合约出售，实现类似于 1559 的机制，很像用于 EIP-7002（EL 触发的提款）的机制。但是，批量出售一段时间（大于一个 slot）的票证可能更有意义。例如，我们可以出售

目标值和最大值可以设置为与 blob 交易的费用市场相同的值，因为我们希望 mempool 具有足够的容量来支持网络的吞吐量，但不能超过该值：理想情况下，我们不希望通过 mempool 但最终没有上链的交易。例如，最终我们可能每个 slot 出售 128 张票证的目标值，以及 256 张的最大值。

注意： 这种方法的一个弱点是，每 당错过 slot 时，“IL 票证”就会被浪费。我们可以退还错过 slot 的票证，但这样区块提议者可能会做一些事情，比如购买所有票证并故意错过 slot，如果他们无法以足够的利润转售它们。

退款

票证分配机制必须确保 DoS 抵抗：我们只想允许在 mempool 中存在有限数量的 blob 交易，因此我们只能分配有限数量的票证。如果我们能提前知道哪些发送者会将 blob 上链，我们就可以将票证分配给他们。实际上，我们当然没有这种知识，我们可能被迫为票证收费。

为了避免阻止 blob 交易发送者使用 mempool，我们可以退还上链票证的价格，而不会放弃 DoS 抵抗：只有当你将相应的交易上链时，票证才是免费的，在这种情况下，交易已经支付了费用，我们可以允许它进入 mempool。但是，每当其 tx 上链时退还票证可能会被滥用：通常每个 epoch 会将一些 blob txs 上链的人可能会购买一段时间内的所有 mempool 票证，远远超过他们自己的需求，然后通过将其（真实）blob txs 直接发送给构建者来慢慢获得退款。这不是什么攻击，但它仍然可以自由地暂时阻止其他人访问 mempool，这并不理想。为了防止这种情况，我们可以缩短退款期限。如果我们将其设置为一个 slot，这意味着只有当你在 slot N+1 中将 tx 上链时，你才能获得 slot N 票证的退款，此时攻击向量不再存在。本质上，只有当你证明你确实有理由在 slot N 中使用 mempool 时，你才能获得退款。

为什么不使用 blob 票证

先前的文章 探讨了协议出售 blob 票证的想法，这既可以用于控制对 blob mempool 的访问，又可以赋予包含权。这个想法是一石二鸟：获得一个具有 DoS 抵抗能力的垂直分片 blob mempool，并确保它用于提前对 blob txs 进行抽样，而不是在区块传播的关键路径中进行抽样。

这种解决方案似乎非常适合当前排序主要不是由 L1 完成的世界，因此 blob 提交的时间并不特别敏感，因为它只确认了在 rollup 级别已经知道的内容。但是，在一个充满Based Rollup 的未来，甚至更多的是不断交互的基于和原生 rollup 的未来，事情可能会变得更加复杂。届时，blob txs 允许人们访问跨 L1 和所有此类 L2 的统一状态，并且 blob txs 的包含时间和排序在这个扩展状态中与今天对于常规 L1 状态一样重要，例如，区块中的第一个 blob tx 可能会在 L1 和多个 L2 上的 AMM 之间进行套利。

在这样的世界中，提前出售 blob txs 的包含权类似于今天确立某种形式的部分区块构建，因为每个 blob 本质上将是统一状态的部分区块。至于部分区块构建，由于状态争用而导致的潜在问题非常多，并且不清楚该系统是否会崩溃回由单个超级构建者购买大多数票证。此外，时序游戏现在也适用于 blob txs（同样，它们基本上只是此统一状态的 txs），因此几乎没有理由期望 mempool 传播会在整个 slot 中发生，而不是尽可能晚地发生。

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