将吞吐量与本地构建解耦 - 权益证明/经济学

非常感谢 Alex Stokes, Ansgar Dietrichs, Carl Beekhuizen, Caspar Schwarz-Schilling, Dankrad Feist, Data Always, Drew van der Werff, Eric Siu, Francesco d’Amato, Jihoon Song, Julian Ma, Justin Drake, Ladislaus von Daniels, Mike Neuder, Nixo, Oisín Kyne, Parithosh Jayanthi, Potuz, Sacha Saint-Leger, Terence Tsao, Thomas Thiery, Tim Beiko, Toni Wahrstätter 的评论和审查（这些不是背书）。我打扰了很多人，哈哈。

以太坊社区在接下来的几个月里应该进行重要的对话：如何看待本地构建（local building）？验证者集合（validator set）的未来是什么？如何扩展 L1（scale the L1）？如何扩展 blobs（scale the blobs）以便 L2 可以扩展？

为了做出这些决定，我们需要明确以太坊的目标是什么，以及我们实现审查抵抗、安全（例如，安全 + 活性）、规模或可验证性等目标的手段是什么。鉴于协议研发的最新进展，我们希望参与到探索这些特性如何进一步提升我们的用户和构建者的目标。

本笔记讨论了 本地构建（local building） 并提出了以下问题：

为了扩展 L1 并为 rollups 提供更多 blobs，我们是否应该将网络吞吐量与硬件配置最低的本地构建者所能实现的吞吐量解耦？如果是这样，我们还能保持本地构建者所保证的良好属性吗？

我们建议通过文章和新的“协议研究电话会议”中的公开讨论来组织更广泛的讨论。请查看 ethereum-magicians 上的公告！另请参阅“ 重新审视通往 SSF 的路径”，这是第二篇讨论家庭运营商在共识层中的作用的文章，也在第一次协议研究电话会议中讨论过。

协议角色和服务提供商

在本笔记和后续笔记中，我们将关注协议角色（protocol roles），例如 证明者（attester） 或 构建者（builder），这些是协议期望履行的职能。负责履行角色的参与方是服务提供商（service provider），最终由以太坊网络上的一个 节点（node） 代表。将正确的节点分配给正确的角色，需要理解系统需要优化什么，以及在给定资源的情况下，各种节点对这些目标有多大的贡献。

\ 验证器服务地图2830×1572 384 KB

一个 staking 节点预计会履行上述角色，或可能被期望履行（FOCIL 角色目前不存在，将在下面讨论）。

我们希望网络上的每个满足特定 硬件要求 的节点始终能够验证（verify） 以太坊的可用性和有效性。这是一个不可协商的约束。 一个拥有满足硬件要求的最基本（the most basic）资源的节点可以被称为最小节点（minimal node）。控制验证器（validator）的节点（一种捆绑了 证明者（attester），提议者（proposer），同步委员会（sync committee） 和其他功能的协议角色）被称为 Staking 节点（staking node）。

在本笔记中，我们讨论如何利用验证和构建之间的 不对称性。构建（building） 是将数据（无论是交易还是 blobs）追加到账本的行为。验证（verifying） 是接收这些数据并确信数据是可用的（“我知道构建者发布的所有数据都可以在网络上的某个地方恢复”）和有效的（“数据遵循协议规则，例如，包含在区块中的交易必须有效”）。构建（building） 为网络提供 吞吐量（throughput），即单位时间内提供的 gas 和 blobs。验证（verifying） 限制了这种吞吐量，使其达到节点在执行其他任务（例如证明）之前可以验证的数量。

\ 外部构建1920×1063 76.4 KB

构建者角色主要由 staking 节点外包给 外部构建节点（external building nodes）。

验证和构建的不对称性

今天，硬件要求的设置使得最小节点始终能够完全验证链，并执行验证职责，包括为最终确定链生成 FFG 证明，以及为更新分叉选择规则生成 LMD-GHOST 证明。链的目标吞吐量的设置使得最小节点能够完全提供此吞吐量，即创建区块以提供高达目标吞吐量（及其相应的限制）。

\ 耦合吞吐量2080×1356 138 KB

精确地满足最低验证要求的最小节点能够运行验证器。

然而，在越来越多的地方，我们在 验证（verifying） 和 构建（building） 之间存在严格的不对称性。存在一个潜在的未来，其中拥有最基本资源并且仍然满足硬件要求的节点停止关注与构建相关的任何事情，而只是进行验证。在这种模型中，构建者将处理与扩展区块和 blobs 可能需要的大量吞吐量相关的要求。

例如，使用 PeerDAS，具有 8 倍资源的构建者可以创建一个 8 倍大的区块，而 1 倍的证明节点只需使用构建者的一小部分资源即可完全验证。虽然构建者必须自己上传 blobs，最坏情况下是 8 倍的数据（如果最小证明节点之前没有在自己的 mempool 中收到 blobs），但最小证明节点只需要下载 1 倍的量即可验证可用性并正确执行其职责。然后，我们可以允许具有严格更高上传带宽的构建节点来传播这些数据，而证明节点只需要一小部分带宽即可验证数据的可用性并将其传播给其对等点。

我们期望会出现巨大不对称性的另一个例子是，当 L1 EVM 被 snark 化时。然后，构建区块的主要成本将包括生成其有效性的证明，而网络上的每个其他节点只需要确保区块数据是可用的（你可以考虑将区块转储到 blob 中，随着我们 朝着完整的 DAS 发展，可用性检查变得更加轻量级）并进行恒定时间的计算以验证有效性证明。这个未来 可能比我们想象的要近得多，作为一个思考实验，我们是否应该充分利用构建 zkEVM 证明区块和验证它之间存在的巨大资源不对称性？这应该让我们意识到不对称性是扩展的机会，并引导我们询问是否应该在更直接的地方采取行动，例如扩展 blob 吞吐量。

\ 解耦吞吐量1920×1249 75.9 KB

虽然我们有许多 staking 节点执行证明服务，但网络中计算，带宽或订单流方面，资源更好（在计算、带宽或订单流方面）的构建节点较少。考虑到这些构建节点的存在，是否可以提高目标吞吐量？

要实现的三个网络属性

到目前为止，我们将网络吞吐量保持在所有（all） staking 节点在执行构建角色时都可以达到的水平。我们阐明了我们希望满足的三个网络属性，以指导我们设计网络架构：

1. 网络的审查抵抗性（Censorship-resistance of the network）：我们希望任何付费交易都能被包含，前提是有可用的吞吐量来包含该交易。
2. 目标吞吐量实现（Target throughput achievement）：假设以太坊网络通过设置 EIP-1559 gas 和 EIP-4844 blob 目标来设置某个目标吞吐量。我们可以忽略设置此吞吐量的原因，我们只需将其视为给定的某个目标。我们是否可以大概率地对网络实现此吞吐量感到满意，而不会导致不良结果，例如隐式增加最低硬件要求？
3. 区块生产活性（Block production liveness）：任何单个参与方或串通的参与方集团都不应能够阻止链的进展，例如，通过成为唯一能够向网络提供有效区块的参与方。

当 staking 节点不将其构建功能委托给单独的外部构建者时，我们称该节点为 本地构建者（local builder）。 本地构建者的存在在三个网络属性方面为我们带来了很多好处：

1. 网络的审查抵抗性（Censorship-resistance of the network）：本地构建者是验证器集合的一部分，假设该集合足够去中心化，以提供良好的审查抵抗。 当外部构建者进行审查时，假设一些本地构建者继续生产区块，则链会保留一些（可能较低的）审查抵抗。
2. 目标吞吐量实现（Target throughput achievement）：今天，吞吐量的设置使得本地构建者始终能够实现它，因此我们有很好的保证可以实现它，前提是每个外部构建者都至少具有同等的能力。
3. 区块生产活性（Block production liveness）：本地构建者始终可以创建一个有效的区块，因此我们也有信心始终会有一个构建者（无论是本地的还是外部的）能够推进链。

将吞吐量与本地构建者解耦的影响

如果现在将网络吞吐量设置为高于最小本地构建者可以实现的水平，会发生什么？ 第一个属性可能是受损最严重的，因为本地构建者可能无法以目标数量提供吞吐量。 然而，这种吞吐量可以通过外部构建者来恢复，因为 EIP-1559 目标并实现了某个固定数量。 值得注意的是，鉴于公共 mempool 的耗尽而倾向于私人池（请参阅 Data_Always 的分析），即使在今天，本地构建者平均也无法以当前目标提供吞吐量。 在这种假设情况下，其余两个属性受到的损害不会超过今天，因为在更高的网络吞吐量下，本地构建者仍然可以按今天的吞吐量提议区块，从而保证最小的活性，并以较低的吞吐量包含可能被审查的交易。

我们可能仍然会发现这种情况令人不安：如果我们希望本地构建者在经济上与外部构建节点保持竞争力，我们应该要求他们委托其构建功能。 但是，如果我们要求他们这样做，我们可能对上述任何三个属性的质量都不满意。 因此，如果我们想将网络吞吐量与本地构建者可以提供的吞吐量解耦，我们必须确保我们仍然实现这三个属性。 我们将在以下各节中讨论每一个属性。

网络的审查抵抗性

通过 EIP-7805：分叉选择强制包含列表（Fork-choice enforced Inclusion Lists，FOCIL），我们相信审查抵抗属性在网络级别基本上是有保证的，从某种意义上说，以前的本地构建验证器可以通过 FOCIL 实现至少与本地构建一样多（但在实践中远多于）的审查抵抗。

FOCIL 机制从每个 slot 的验证器集合中选择 16 个新的包含者（includer），并且每个包含者都能够提出一个必须有条件地包含在为此 slot 提议的区块中的交易列表。 这些包含列表约束了当前 slot 的提议者或他们选择的构建者，从而阻止他们任意地将交易排除在网络之外。

\ FOCIL1000×760 196 KB

FOCIL 每隔一个 slot 选择 16 个包含者，以对区块构建过程施加约束。

FOCIL 允许决定不再是本地构建者，将其构建功能委托给外部构建者市场的 staking 节点仍然参与提供审查抵抗。 本地构建者不需要在本地构建以提供审查抵抗或使用外部构建者来最大化其奖励之间进行选择，他们可以同时做到。

FOCIL 目前尚未部署，我们仍然需要选择一个将 FOCIL 扩展到 blobs 的设计。

目标吞吐量实现

网络必须仍然仔细选择目标网络吞吐量，以防止构建者交付的区块越来越难以被最小节点验证。 作为一个思考实验，我们是否可以简单地移除 gas 限制，让构建者（无论是本地的还是外部的）决定他们想要生产的区块大小？ 我们将有两个问题：

1. 构建者可能会输出最小节点几乎无法验证的区块。 只要区块收到足够的证明，就足以成为规范链的一部分。 但这可能会导致一场军备竞赛，其中对最小节点的要求不再足以进行正确的证明，从而增加了对最小节点的期望，使其硬件超出最低规范。 请注意，例如，zkEVM 可以缓解这种情况，因为构建者提供的任何 gas，只要它也附带证明，都会对验证节点产生恒定的验证成本。 对于 blobs 和数据可用性，情况可能并非如此，对于 blobs 和数据可用性，吞吐量的增加必须始终与总体验证资源的增加相匹配。
2. 存在公地悲剧，其中大型区块的某些外部性只有随着时间的推移才能感受到，例如，状态增长或节点同步时间。
   1. 我现在可能能够交付一个非常大的区块，该区块获得了足够的证明，但我的这样做会增加未来每个人的状态大小，并使随着时间的推移实现一致的吞吐量变得更加困难。 请注意，无状态架构可以部分缓解此问题。
   2. 通过交付更大的区块，我还会增加新节点赶上链头的同步时间。 同样，有效性证明和无状态性的结合可以缓解此问题。

区块生产活性

依赖外部网络意味着它的失败成为系统的失败。 委托的本质决定了我们永远无法完全控制由我们的 staking 节点委托人（principals） 选择的构建“代理”的行为，或者阻止他们失败。 但最终，staking 节点本身也是协议的代理（agents to the protocol），并且可能会失败，或者未能提供协议寻求提供的服务。 因此，我们应该问的问题是我们能走多远，以及我们愿意走多远来减轻这些风险？

获得这些缓解措施有两种广泛的方法：改进链外基础设施 或 在协议中添加新功能。提议者-构建者分离（Proposer-Builder Separation，PBS） 今天通过链外 MEV-Boost 和 Commit-Boost 实例化，中继承担信任锚的角色以访问市场。 PBS 将通过链上 EIP-7732：链上提议者-构建者分离（Enshrined Proposer-Builder Separation，ePBS） 得到加强。 使用 ePBS，我们可以为市场参与者提供更好的保证，即，一方是 staking 节点，另一方是外部构建者，因为协议保证了两者之间的公平交换。

为了理解需要什么，我们必须理解委托构建角色的风险和失败。 我们永远无法完全排除“超时”活性失败的最坏情况，即即使在 staking 节点和构建者之间达成合约后，构建者仍未能交付区块。 我们可能面临更系统性的风险，即与外部市场的接口失败。 我们可能还会遇到一个构建者卡特尔，他们拒绝为任何人构建任何区块，除非 staking 节点向他们支付某种勒索租金。

我们现在给出一些论点来指导我们选择所需的防御武器库：

• Staking 节点可以调整其行为以应对外部市场的重复失败，例如，通过使用断路器回退到本地构建。
• 我们可以确保，如果达成交易并且构建者未能交付，付款仍然会进行。 有多种方法可以通过链上解决方案来保证这一点。 如果中继本身没有失败，一些乐观的中继还需要构建者提供托管付款，以补偿构建者未能按承诺交付的情况。
• 我们可以采取这样的观点，即区块构建过程的活性假设用户需求的特定实现，并严格询问给定一组可构建的交易，是否有构建方会承担这项工作。 换句话说，我们可能关心是否存在任何一个可以至少与 staking 节点本身一样好的构建者，并且如果 staking 节点没有收到大多数用户交易（他们可能更喜欢通过私人池进行交易），则确定这不是区块生产活性问题。 尽管如此，订单流 仍然是构建者成功的决定性因素。 即使在少数主要实体的活性受到质疑时，由少数根深蒂固的实体主导的市场也可能会阻止更多参与者的进入，作为临时的后备方案。中立中继（neutral relays） 的存在增加了进入市场的切入点，从而有利于此类后备方案。 此外，随着诸如 BuilderNet 之类的新协议的出现，我们观察到构建者市场在朝着中立基础设施方向进行更多创新，至少在其理想化的形式中是如此。
• 有多种方法可以加强当前的链外基础设施，例如，确保 MEV-Boost 和 Commit-Boost 之间的充分多样性，它们都是中立的软件，或者改进我们的断路器和回退程序，以最大程度地降低活性风险，如果沿链的某个位置发生故障。
• 存在一个真正的最坏情况，即世界上只有少数节点可以构建网络所需的区块。 这在某种程度上是理论上的，因为没有太多情况可以迫使 staking 节点处于只有少数参与方可以满足节点施加的构建要求的位置。 一个简单的例子是想象 FOCIL 输出一个非常大的交易和 blob 集合以进行包含，可能在 zkEVM 制度下，区块还必须接收有效性证明。 如果 staking 节点本身无法构建此区块（如果网络吞吐量与本地构建者功能解耦，则完全有可能），则 staking 节点将被要求依赖外部构建者。 我们应该确保这种依赖性尽可能广泛，即始终存在一个准备好交付此区块的构建者。 如果我们发现自己处于只有超级计算机规模的节点才能交付的状态，则并非如此，但可以通过将网络吞吐量限制设置为保证足够广泛的市场水平来轻松缓解这种情况，即使此限制超过了本地构建者的能力。
• 纳入链上成本高昂，主要体现在增加了协议的复杂性，尤其是在减少 slot 时间和将共识机制更改为 SSF 的道路上。 考虑到诸如 证明者-提议者分离（Attester-Proposer Separation） 之类的替代提案，对于任何单一机制的未来适用性也存在疑问。 我们通常希望在协议中拥有需要 诚实多数（honest majority） 的功能，例如，共识机制，让大量参与者的全部力量来承担此属性的安全保障。 同时，从构建者那里获得有效的区块需要 1-of-N 诚实性假设，因为在需要该服务时，需要一个构建者活着来执行该服务。 鉴于 1-of-N 诚实性假设，仅依赖链外解决方案来委托区块构建可能是合理的。

这里没有关于部署哪种解决方案组合的简单答案，特别是因为 ePBS 的论点不仅在于加强 staking 节点和构建者之间的交换，还在于通过提供更好的流水线来扩展（请注意，对于扩展论点，应该 在以下上下文中考虑 诸如 延迟执行（delayed execution） 之类的替代和/或补充方法，这是未来笔记/电话会议的主题）。

我们应该谈论什么

总的来说，有两个独立的讨论需要进行：

1. 决定是否将网络吞吐量与本地构建者可以实现的吞吐量解耦。 上面提出了论点，讨论了这三种属性在这种情况下如何表现，以及如何通过诸如 FOCIL 之类的新机制来改进它们。
2. 决定如何确保区块生产活性。 虽然这是一个广泛的范围，但我们大致看到了两种前进的方式，这两种方式并非互斥：
   1. 在链上做更多的事情（Doing more in-protocol）：通过部署诸如 ePBS 之类的协议基础设施，我们加强了对外部构建者市场的访问。
   2. 改进链外选项（Improving out-of-protocol options）：也许我们对将此构建者接口保留在协议之外并让 staking 节点决定他们的方法感到满意。

本地构建是获得区块生产服务活性以及审查抵抗的一种手段。 如果我们决定将吞吐量与网络中最差节点可以提供的最高水平相关联，那么本地构建也是对吞吐量的一种约束。 如果本地构建是我们 唯一 获得区块活性和审查抵抗的工具，那么这是一个合理的选择。 但如果它不是唯一的工具，也不是最好的工具，我们应该问自己：如果所有节点仍然能够以这种吞吐量可持续地验证链，我们是否可以将网络吞吐量移到本地构建者能够提供的吞吐量之上？ 为了对此需求感到满意，我们需要进行哪些更改或改进？

_另请参阅 最近的关于此主题的演讲。_

• 重新审视通往 SSF 的路径
• 对扩展路线图的有利于本地节点的增量
• Prover Killers Killer：你构建它，你证明它
• Blob Notaries：一种分布式 blob 发布设计，用于扩展 DA

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