关于blob mempool的未来

关于 blob 内存池的未来

由 Mike 和 Julian 与 Francesco 讨论得出

目录

1. 今天的 blobpool

1.1. 在 Fusaka 中会发生什么？

1.2. 为什么我们要在 Glamsterdam 做些什么？

2. 带退款的拍卖：一种基于市场的垂直分片机制

3. 更广泛的考虑

3.1. 主要的未解决问题

1. 今天的 blobpool

blob 内存池，在本文的剩余部分中我们将其称为 “blobpool”，是尚未包含在区块中的待处理 blob 交易的集合。每个节点都维护 blobpool 的一个视图，并通过拉取任何其尚未收到的已公布的 blob 交易来更新其视图（更多信息请参见 这里）。由于 pull 模型，每个节点应该下载每个 blobpool 交易一次。blobpool 由执行层（简称 EL）维护，默认情况下，节点会下载 blobpool 中的每个 blob。

在共识层（简称 CL）上，验证者必须在证明区块有效性之前确定区块中包含的 blob 交易的可用性（关于 CL 的 blob 下载路径的更多信息，请参见 这里）。目前，数据可用性检查验证区块中包含的每个 blob 交易的完整 blob 数据的可用性。因此，blobpool（EL）和数据可用性检查（CL）之间存在协同作用；两者都下载所有 blob。

1.1 在 Fusaka 中会发生什么？

Fusaka 包含了 PeerDAS，它改变了 CL 执行的数据可用性检查。CL 不再下载完整的 blob 数据，而仅检查区块中包含的每个 blob 交易的部分列的可用性。这种“垂直”分片是核心的解锁，允许大幅增加每个区块的 blob 数量，因为下载 48 个 blob 的 1/8 列的带宽需求相当于下载 6 个完整的 blob。然而，如果不改变 blobpool，PeerDAS 在 EL 和 CL 之间引入了根本的不对称性。EL 仍然旨在下载所有可用的 blob；CL 只需要检查每个 blob 的某些列的可用性。

按照目前的 6/9（目标/最大）blob 计数，blobpool 消耗的目标带宽为 64 kB/s，最大带宽为 96 kB/s。如果 blob 计数为 48/72，则 blobpool 带宽将跃升至 512/768 kB/s。虽然这个带宽对于大多数节点来说是合理的，但它将迫使一些资源较少的节点限制其 blobpool 视图。此外，让每个节点下载每个 blob 从一开始就消除了垂直分片 CL 数据可用性检查的优势。我们需要更精确地理解和描述 blob 数据在未来将如何进行 gossip 和验证。

1.2 为什么我们要在 Glamsterdam 做些什么？

Fusaka 的范围已经确定；PeerDAS 将在_没有_协议内机制的情况下实施，以尽量减少 blobpool 中 blob 数量显著增加对带宽的影响。尽管如此，在 Glamsterdam 中实施解决方案似乎是必要的，原因如下：

1. 我们希望维护公共 blobpool。截至今天，80% 的 blob 交易 通过公共 blobpool。中心化排序器的 rollup 会导致 “耐心的” blob 交易。因此，我们预计，只要这些 rollup 是主要的 blob 消费者，并且公共 blobpool 继续提供足够好的包含保证，公共 blobpool 仍将是 blob 发布的一个常见途径。
2. 继续扩展 DA 会继续扩展 blobpool 的带宽需求。这直接源于 DA 检查是分片的，但 blobpool 不是。只要我们不断增加 blob，如果没有对 blobpool 进行更改，它也会在线性地扩展带宽使用量。这种带宽增加可能是可以接受的，只要资源较少的节点仍然能够证明——更多信息请参见 第 3 节。

显而易见的“正确”解决方案是对 blobpool 进行垂直分片，以镜像 DA 检查的垂直分片（如 此处 所述）。换句话说，我们需要一种 blobpool 原生的方式来 gossip blob 列，而不是只 gossip 完整 blob，以便节点可以下载他们在 DA 检查中负责的数据。下图展示了这一点。

\ upload_55eaa9bf01e5c79260a3f683d2246e692596×796 214 KB

我们将 blob 分为两类：公共（绿色）和私有（紫色）。公共 blob 由 blob 发起者进行垂直分片并 gossip 到 blobpool。私有 blob 由构建者进行垂直分片并直接 gossip 到 CL 网络（构建者从 rollup 接收私有 blob，并且在 blob 提交到区块之前不会 gossip 它们）。无论哪种方式，证明者都只下载其分配的列来执行其 DA 检查。如果没有垂直分片的 blobpool，证明者将被迫下载完整的公共 blobpool blob。

垂直 blobpool 分片的_方式_更加细致。第 2 节 概述了一种潜在的机制来启用 blobpool 的垂直分片，而 第 3 节 则放大了范围，更广泛地考虑了这种情况。

2. 带退款的拍卖：一种基于市场的垂直分片机制

在考虑垂直分片的 blobpool 时，DoS 攻击是限制因素。我们如何确保 gossip 的列属于一个支付费用的交易？我们的目标是使用最简单的市场机制来分配对 blobpool 的写入权限。在此模型下，任何 gossip 的列必须来自一个已经支付了在特定 slot 期间将该数据写入 blobpool 的能力的身份。我们专注于强制对每个 slot 可以传播的 blob 数量进行硬性限制的机制，因为这可以防止 DoS 攻击并允许系统以其最大容量运行。最后，我们的目标是提供免费的 blobpool 访问，并为 rollup 提供良好的用户体验。

我们提案的核心部分是一个简单的具有储备价的一级价格拍卖，其中出售 slot n 的 k 个 blobpool 票证。k 等于 blob 限制。

• 竞标： 在 slot n-2 期间提交 (bid_per_blob, number_of_blobs) 形式的竞标。竞标是执行层交易。
• 拍卖： 竞标包含在区块 n-1 中的系统合约中。只要 blob 的总数不超过 k（即，如果每个竞标都针对单个 blob，则通过贪婪地选择 k 个最高竞标），并且每个竞标都超过 reserve_price，系统合约就会选择使拍卖收入最大化的竞标。
• Blob 传播： Blobpool 票证持有者可以在 slot n 中在垂直分片的 blobpool 中传播他们的 blob。诚实的构建者将其 blob 包含在他们的区块中，诚实的节点一旦 blob 进入 blobpool 就会对其进行采样。
• 退款： 在 slot n+1 中，每个 blob 都包含在 slot n 中的 blobpool 票证持有者都会收到 reserve_price 的退款。

重要的是要注意，通常，对 blobpool 票证的需求将低于 k，因为 blob 基本费用使用 1559 控制器进行调整，因此只有对 blob 目标的需求，该目标低于限制。目前，目标是每个 slot 6 个 blob，限制是 9 个。这意味着竞标者通常只需要支付 reserve_price，如果他们确实使用了垂直分片的 blobpool，并且构建者包含了所有 gossip 的 blob，他们将获得退款。你可以将 blobpool 票证视为通常只需要 blob 提交者的存款，他们会在 2 个 slot 中收到退款，从而使该机制免费。

对于对 blob 的需求超过 blob 限制的特殊情况，我们需要实施拟议的拍卖。我们不能退还高于 reserve_price 的竞标，因为那样拍卖将不允许竞标者表达他们在这个特殊情况下对 blobpool 票证的重视程度。

储备价格应该设置得足够高，以暗示攻击者想要阻止其他竞标者访问 blobpool 的实际成本。我们建议使用 EIP-7918 中 blob 的基本费用的 reserve_price。

3. 更广泛的考虑

在 blobpool 的未来背景下，构建者、证明者和 rollup 之间的交互有许多细微之处需要考虑。

• Blob 过渡到私有订单流是非常可能的，但并非不可避免，因为它对构建者不利。 截至目前，blobpool 的可行性取决于 (i) blob 本质上是 “耐心的”，因为它们来自中心化的排序器，因此不携带 MEV，以及 (ii) blobpool 为 rollup 提供足够好的 “包含服务”。只要发送到 blobpool 的 blob 继续及时包含，我们预计 blob 的公共流将保持。然而，一旦 blobpool 的包含服务降级，我们预计 blob 将开始直接流向构建者。对 blobpool 有利的一个重要因素是 源自 blobpool 的 blob 对构建者来说包含的风险更小。 这是因为当构建者在区块中包含一个公共 blob 时，他们可以确信大多数证明节点已经看到了它，因此将准确地投票支持该区块的有效性。[1] 下图显示了这一点。

\ upload_ebc48e7cf9988f84af77bf8871f930f22088×950 110 KB

请注意，证明者可以从 blobpool 或 CL 网络获取公共 blob。相比之下，下图显示了私有 blob 流。

\ upload_8fbedb9180c1b545718975459a6347d72076×936 84.5 KB

在这种情况下，证明者的唯一 blob 来源是 CL 网络。

\quad 另一种看待这个问题的方式是，blobpool 向构建者提供了一种 “blob 分发服务”，构建者不再需要在构建区块后立即担心传播 blob，这对于任何私有 blob 都是必需的。考虑到时序博弈的现实情况，这一点尤为重要，在这种情况下，构建者渴望尽可能地延迟其区块（以及私有 blob 数据）的发布。我们认为，这更有理由努力维护 blobpool，以及为什么我们不必期望所有直接通过构建者流动的 blob 成为唯一稳定的结果。

• 其他类型的 blobpool 分片是可能的，并且易于实现，但它们不可避免地会降低 blobpool 的服务。 正如 此处，此处，此处 以及可能在其他地方讨论的那样，水平分片 blobpool 是一种相对简单的方式来减少 blobpool 的带宽占用。有很多方法可以限制节点下载的 blob 数量（例如，通过接受在 slot 期间到达的前 10 个 blob，或者通过基于发送者 ID 下载随机子集）。尽管如此，它们都会导致相同的结果——每个节点只检索 blobpool 中的 blob 的子集。在所有其他条件相同的情况下，水平分片必须降低 blobpool 的包含服务，因为给定的提议者在其 slot 期间拥有任何给定的 blob 的概率会降低。 这似乎是水平分片的一个根本性问题，因为正如在上一个要点中讨论的那样，blobpool 包含服务的任何降级都可能会将 blob 推向通过私有通道流动，从而杀死 blobpool。但是，这里有两个重要的警告需要考虑。

\quad 首先，许多节点可能会选择_不_进行水平分片，因此将继续下载所有 blob。根据对大约 90+% 的 stake 受到专业管理的估计，这可能意味着大多数提议者仍然可以访问所有 blob，并且 blob 包含保证基本保持不变。在这种理想化的结果中，我们可以两全其美，因为居家运营商可以限制 blobpool 的带宽影响，并且 blobpool 继续为 rollup 和构建者提供良好的服务。其次，由于对于居家运营商来说，提议是一项罕见的任务，他们可以通过_仅在他们被选为提议者时_下载所有 blob 来处理带宽的短暂峰值；通过这种方式，他们的带宽峰值将每年只会发生几次。当然，这仍然取决于他们的连接足以处理峰值负载，这在某些地区可能是不可能的。

\quad 无论如何，这些简单的 blobpool 水平分片方法可能可行。

• 有其他方法可以以防 DoS 的方式提供 blobpool 写入权限。 阻止 DoS 攻击是垂直分片 blobpool 的主要障碍。第 2 节 概述了一种基于市场的方法，其中 blobpool 的访问权限被拍卖。还有其他可能更简单的方法来确保垂直分片的 blobpool 具有防垃圾邮件功能。Dankrad 提出 一种基于数据的方法，其中 blobpool 写入权限仅限于最近已成功发送 blob 或已烧毁一些 ETH 的地址。这种基于身份的方法是信誉系统的一个实例。可以实施许多其他启发式方法和方法（无论是在协议内还是协议外）来限制 DoS 风险。如果我们采用基于市场的解决方案，我们应该确信，与这些相对更直接、由工程驱动的方法相比，其好处大于复杂性的增加。
• 需要考虑 blobpool 票证拍卖的设计空间。 第 2 节 概述了 blobpool 票证拍卖的一个简单版本，但仍然存在许多潜在的调整。例如，blobpool 访问权限应该以每个 slot 的粒度出售，还是在更长的时间范围内出售？应如何跟踪和处理退款？应如何设置和更新票证的储备价格？这些都是拍卖本身相对较小的差异，但可能会导致非常不同的竞标策略和均衡。如果我们继续解决拍卖设计问题，我们必须在与 rollup 的讨论中仔细考虑这些方面，以确保他们会发现它有价值且易于参与。此外，再次回到第一点，只有当它比直接通过私有通道到达构建者更好时，拍卖才值得做。
• 我们可以考虑更全面地重新设计blob费用机制和生命周期。 Blob 在许多方面与普通交易不同。例如，它们具有耐心这一事实可能使得基本费用的 1559 控制器不太理想。在考虑 blobpool 的未来时，我们也可以考虑更大的变化。例如，我们可以通过 FOCIL 将 blobpool 票证与执行保证捆绑在一起。通过这种方式，票证价格有效地取代了优先级费用（因为 blob 只要及时传播就肯定会被包含）。我们应该确保对 blobpool 所做的任何更改要么是未来兼容的，要么与更广泛的 blob 更改捆绑在一起。
• 拍卖不应给 L1 带来太大的负担。 拍卖可以使用带有执行层交易的系统合约。应尽量减少平均和最坏情况下使用的交易数量，以防止 blobpool 票务系统给 L1 带来太大的负担。第 2 节 中显示的基本实现可能需要每个 slot 最多 k 个交易，这对于 k 等于 128 或 256 个 blob 的扩展目标来说可能过高。减少拍卖负载的方法包括出售少量的一个 blob 小票证，其余的以至少六个 blob 的大票证出售，或者默认情况下，将票证分配给父区块的票证持有者。这些方法虽然导致了更具表现力但也更复杂的竞标语言，但需要与票务系统的用户体验相协调。

3.1 主要的未解决问题

希望本文档能够作为讨论 blobpool 未来的起点。至关重要的是，在提出建议之前，我们仍然需要解决许多悬而未决的问题。我们根据这些问题对其影响最大的利益相关者进行划分。

1. rollup 团队的问题

a. 你是否计划继续使用 blobpool 发布你的 blob？

b. 在发送 blob 和将其放入链上之间，你可以容忍多少延迟（以 slot 衡量）？

c. 如果我们按照 第 2 节 中所述运行 blobpool 票证拍卖，参与需要多少工作？你会考虑转到私有通道吗？

d. 如果我们运行拍卖，你想参加每个 slot 的拍卖吗？还是更长的时间范围更可取？

e. 你如何看待一种基于信誉系统的方式来发送 blob？

2. 区块构建者的问题

a. 在决定在区块中包含哪些 blob 时，你在多大程度上依赖于你对 blobpool 的看法？

b. 你更喜欢通过私有通道接收 blob 吗？你为私有 blob 提供哪些包含保证？

c. 需要哪些基础设施变更才能促进每个 slot 的 blob 数量增加 8 倍？这是否会显着影响你构建和分发区块的方式？

3. Staker（专业和居家）的问题

a. 你计划如何处理 PeerDAS 下 blob 数量增加导致的带宽增加？

b. 峰值与平均带宽消耗有多重要？

c. 你是否计划在水平分片世界中继续下载所有 blob？

1. 这里有一个细微的说明：只有在可以 gossip 部分列的情况下，构建者才能实现这种好处。正如 此处 所述，按照目前的构建方式，一个私有 blob 会导致构建者需要 gossip 完整的列。因此，除非我们可以通过将公共 blobpool 数据与准时私有 blob 列相结合来重建列，否则 blobpool 的 gossip 好处是不存在的。↩︎

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