Blob包含列表与分布式区块构建

一年前更改

Blob IL 与分布式区块构建

Blob 内存池分片

https://notes.ethereum.org/wcg_u2qORiqpyZ7KbPjRAA?edit

https://notes.ethereum.org/@dankrad/Bky8ieRkye

https://learnblockchain.cn/article/25498

包含列表（IL）

理想情况下，我们同时具备这两点：

1. 高 blob 数量 且低延迟 的本地区块构建，这意味着即使是相当新的 blob 也能够被包含。
2. 涵盖整个 blob 内存池的 IL，由节点仅下载 \(1/k\) 的 blob 数据生成，其中 \(k\) 本质上就是我们的分片因子。

IL 中的 Blob

让我们尝试通过审视整个 IL 管道（从 IL 生成，到区块构建者纳入交易，再到验证者强制执行 IL）来理解支持此功能的难点。然而，由于在所有情况下主要挑战都是如何确定可用性，我们首先讨论一个在多个地方都会出现的问题。

多个独立的可用性检查

所谓多个独立的可用性检查，是指我们正在检查多个对象（如多个 IL 或多个 blob 交易）的可用性，并且我们不希望它们的可用性耦合在一起。也就是说，一个对象的检查失败并不意味着所有对象都被视为不可用。

这与我们在 PeerDAS 中进行采样时的可用性检查不同，后者可以被视为多个耦合的可用性检查，因为通过下载列我们实际上对每个 blob 进行了采样。关键在于，不存在列部分可用的概念，因此不存在一个 blob 可用而另一个 blob 不可用的概念：要么我们确定整个矩阵可用，要么不可用。

在 PeerDAS 采样的场景中，所有 blob 的可用性耦合是可以接受的，因为有一个单一的参与者负责所有 blob 的可用性。在许多其他情况下，我们没有这个条件。例如，有许多 IL 提议者，我们不希望所有 IL 的可用性耦合，因为恶意的 IL 提议者可能会包含不可用的交易。类似地，内存池中有许多不同发送者的 blob 交易，如果我们需要确定它们的可用性（如垂直分片内存池的情况），我们希望所有检查都是独立的。

既然我们已经确定可能需要进行多个独立的可用性检查，为什么这会是一个问题？本质上，我们总体希望的是将至少一个不可用对象误判为可用的概率保持在较低水平，而每次检查都会增加这一概率。例如，考虑验证者看到了 N 个 IL 并需要对其进行采样，只执行那些可用的 IL。对于每个 IL，采样提供了全局保证：最多只有一小部分验证者会错误地判断可用性。然而，在每种情况下，可能都会有不同的一小部分验证者被欺骗，因此如果有多个“攻击性 IL”，那么将至少一个不可用 IL 视为可用的验证者群体最终可能会大得多。

IL 生成：IL 提议者

• 水平分片内存池：
  • 简单的可用性检查 ✅：在此方案下，提议者完全下载 blob 交易，因此不存在确定可用性的问题。
  • 需要大量 IL 才能覆盖内存池 ❌：缺点是，由于我们希望 IL 只需下载所有 blob 的 \(1/k\)，我们需要 \(k\) 个 IL 来覆盖整个内存池，更精确地说是 \(rk\) 个，其中 \(r\) 是冗余因子（例如 8 或 16）。具体来说，假设我们将 blob 内存池划分为 32 个“水平”分片，使得每个节点只下载所有 blob 交易和 blob 的 1/32（之所以称为水平，是因为我们总是将 blob 表示为 DA 矩阵中的行）。那么，我们需要大约 256 个 IL 才能以足够的冗余覆盖整个 blob 内存池。
• 垂直分片内存池：
  • 可用性检查困难 ❌：IL 提议者没有强有力的可用性保证，这是因为上一节讨论的多个独立可用性检查问题，在此场景下，相关的对象是内存池中的 blob 交易。我们所能说的是，对于每个不可用的 blob 交易，最多只有一小部分节点可能被欺骗而认为它可用（理由与此处相同）。关键在于，对于不同的 blob 交易，被欺骗的节点集合可能不同，因此至少在一个 blob 交易上被欺骗的节点集合可能非常庞大。特别是，如果有足够多的 blob 交易来自攻击者，那么一个选择大量 blob 交易的 IL 提议者就有很高的概率至少选择一个不可用的交易。因此，我们需要设计协议，使得 IL 中包含一些不可用交易不会阻止整个 IL 被强制执行。 换句话说，IL 的执行必须基于逐笔交易。我们稍后将讨论如何实现这一点。
  • 只需少量 IL 即可覆盖内存池 ✅：在此方案下，我们只需要一个诚实的 IL 提议者即可覆盖整个内存池，因为任何内存池分片都包含所有 blob 交易，尽管只包含相关的 blob 数据的一部分。即使考虑冗余，我们也只需要 \(r\) 个 IL，而不是 \(rk\) 个。

IL 满足：（本地）区块构建者

区块构建者必须构建一个满足可用 IL 所施加约束的区块。如果某个 IL 中的 blob 交易不可用，区块构建者当然不应该将该 blob 包含在区块中，以免区块被重组。再次强调，确定可用性是有问题的，至少对于那些不下载或无法下载所有 blob 的本地区块构建者而言。我们可以通过两种方式解决这个问题：

1. 区块构建需要完整的内存池：一旦我们有涵盖所有交易类型（包括 blob）的 IL，本地区块构建主要作为备用方案以确保网络活性，无论专业构建者（以及中继等其他周边基础设施）发生什么情况。即使在 blob 数量较高的情况下，要求完整的内存池仍然使区块构建具有相当的可及性，只要我们拥有分布式区块构建基础设施。本质上，（非专业）区块构建者的任务将简化为监听完整的内存池并从中选择交易，尤其是那些出现在 IL 中的交易，而网络则帮助编码和传播。在每 Slot 128 个 blob 的情况下，跟踪内存池需要 1.3 MB/s，即约 10 Mbits/s。这肯定超过我们期望所有节点运营商都拥有或愿意专门用于其节点的带宽，但作为备用方案，这似乎是一个相当适度的要求，很可能让我们有信心，即在需要时总会有数百甚至数千个节点能够站出来。事实上，即使在正常条件下，许多节点也可能可以在即将提议前的几个 Slot 内即时开始监听完整内存池，前提是它们有足够的带宽偶尔这样做，但不愿持续将其全部用于节点。

2. 为区块构建者提供可用性信号：如果我们确实希望支持无需完整内存池参与的区块构建，那么此类区块构建者需要确定可用性。一个这样的本地区块构建者仅凭自身所能做的非常有限，除非有一个 DAS 协议能够提供强大的个体可用性保证，例如通过匿名查询路由。在没有此类协议的情况下，我们需要以某种方式帮助本地区块构建者，例如通过一个委员会投票作为可用性信号。正如我们将看到的，这对验证者也有帮助。

IL 执行：验证者

如果我们希望包含许多 blob（例如，尽可能多地利用 DA 吞吐量），显然我们不能将带有完整 blob 的 IL 进行传播，而只能传播不包含 blob 的 blob 交易，甚至仅传播哈希。然而，为了让验证者决定是否应强制执行某个 IL 的满足情况（即，是否要对不满足该 IL 的区块提议进行证明），它必须确定 IL 中包含的 blob 交易的可用性。

显而易见的方法是通过某种形式的采样，就像我们对区块所做的那样。例如，验证者可以对每个 IL 进行采样，将其中包含的所有交易的可用性耦合起来。如果内存池分片是垂直的，采样甚至可能已经在内存池层面完成了。

然而，当我们有多个 IL 时，就会遇到众所周知的多重独立可用性检查问题：可能被欺骗而认为至少一个不可用 IL 是可用的节点/验证者数量可能非常庞大。如果情况如此，许多（甚至大多数）诚实验证者可能被欺骗，认为提议者没有满足某个应该被满足的 IL，从而投票反对提议的区块。同样，解决这个问题的一种方法是使用委员会作为可用性信号。我们现在讨论这种方法。

IL 可用性委员会作为分布式区块构建基础设施

在高层面上，我们有 4 个阶段：

• IL 提议： 发送 blob IL，不包含 blob（例如，只包含交易哈希或不含 blob 的 blob 交易）。
• 委员会投票作为可用性信号： 委员会对这些 IL 关联的 blob 的可用性进行投票，每位委员会成员根据其本地内存池视图进行投票（在垂直分片内存池的情况下，这会自动涉及采样；但在水平分片内存池的情况下则不会）。
• 区块构建： 为下一个 Slot 构建负载的人，无论是本地区块构建者还是 PBS 构建者，必须决定从 IL 中包含哪些 blob 交易。下载所有内容的构建者（如同外部构建者出于自身利益所做的那样）会包含所有此类可用交易（如果有空间）。本地区块构建者无法自行确定可用性，因此会包含所有获得至少 50% 可用性委员会投票的交易。
• IL 执行： 在某个时刻，会有一轮针对负载的投票，其中除了其他事项外，还会强制执行有效且可用的 IL 交易。为了确定可用性，投票者依赖可用性委员会之前的投票，特别是强制执行获得至少 50% 投票的 IL 交易。

以下是在当今 Slot 结构中可能的样子：

而这是在 epbs Slot 结构中可能的样子，其中“委员会投票”指的是一个委员会，它同时充当 epbs 的负载时效性委员会（PTC）和本文中的可用性委员会（一条消息将包含两种投票）。

假设垂直分片内存池的具体协议

IL 提议

垂直分片内存池的一个可能优势是，我们只需要少量 IL 即可覆盖整个内存池并具有冗余。要实现这一点，我们必须接受 IL 提议者无法完全确定其包含的 blob 交易的可用性（或者，虽然这在垂直分片内存池中更自然，但我们可以要求 IL 提议者只包含他们完全下载的少量 blob 交易，代价是需要更多 IL 才能覆盖整个内存池）。IL 提议者将简单地包含他们看到的任何有效 blob 交易，只要 blob 块在他们参与的内存池分片中可用。尽管出于我们已经讨论的原因，这并不构成充分的可用性检查，但协议的其余部分被设计为不要求这一点。

IL 可用性委员会

鉴于 IL 提议者缺乏完整的可用性检查，如果 IL 满足的执行是基于逐个 IL 进行的（即，仅当 IL 中所有 blob 交易都可用时才强制执行该 IL），那将是不希望的，因为即使一个不可用的 blob 也会阻止整个 IL 被强制执行。因此，我们转而采用逐笔交易的方式执行 IL 中的 blob 交易，就像我们对常规交易所做的那样。为了让本地区块构建者和验证者能够处理这一点，委员会必须为每笔交易提供可用性信号，他们通过在每条委员会消息中添加一个位域来实现。

IL 可用性委员会成员发出的每个投票将如下所示，包含：

• 所有被看到的 IL 的哈希列表，无论其交易的可用性如何。
• 每个 IL（哈希）对应的位域，指定该 IL 中每笔交易在委员会成员本地视图中的可用性。

注意：为了使某个 IL 出现在此类投票中，唯一需要满足的条件是 IL 发送者确实是当前 Slot 的 IL 提议者（无论通过 VRF 选举（类似聚合器）还是通过 RANDAO（类似其他委员会）定义）。当然，相关的委员会成员也需要在其发出投票之前收到该 IL。

例如，本地区块构建者可以包含所有被委员会多数判断为可用的 blob 交易。如果它们确实可用，分布式区块构建基础设施可以处理其余部分：收到区块后，能够检索所有 blob 的节点可以构建列并代替提议者进行传播。

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