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

非常感谢 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 (scale the L1) 并为 rollups 提供更多 blobs (blobs)，我们是否应该将网络吞吐量与硬件配置最低的本地构建者所能实现的吞吐量解耦？如果是这样，我们还能否保留本地构建者所保证的良好属性？

我们建议通过文章和新的“协议研究通话 (Protocol research call)”中的公开讨论来策划更广泛的讨论。请参阅 ethereum-magicians 上的公告！另请参阅“重新审视通往 SSF 的路径 (Paths to SSF revisited)”，这是第二篇文章，讨论了家庭运营者在共识层中的作用，也在协议研究通话 #1 中进行了讨论。

协议角色和服务提供商

在本说明和后续说明中，我们将关注协议角色 (protocol roles)，例如 证明者 (attester) 或 构建者 (builder)，这些是协议期望履行的职能。负责履行角色的各方是服务提供商 (service provider)，最终由以太坊网络上的节点 (node) 代表。将正确的节点分配给正确的角色，来自于理解系统需要优化什么，以及各种节点根据其资源对这些目标做出多少贡献。

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

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

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

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

\ 外部构建1920×1063 76.4 KB

构建者角色主要由质押节点外部化给 外部构建节点 (external building nodes)。

验证和构建的不对称性

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

\ 耦合吞吐量2080×1356 138 KB

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

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

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

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

\ 解耦吞吐量1920×1249 75.9 KB

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

要实现的三个网络属性

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

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

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

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

将吞吐量与本地构建者分离的效果

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

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

网络的抗审查性 (Censorship-resistance of the network)

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

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

\ FOCIL1000×760 196 KB

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

FOCIL 允许决定不再成为本地构建者的质押节点（将其构建功能委托给外部构建者市场）仍然参与抗审查性的提供。 本地构建者不需要在本地构建以提供抗审查性或使用外部构建者来最大化其奖励之间做出选择，他们可以同时做到这两件事。

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

目标吞吐量实现 (Target throughput achievement)

网络必须仍然谨慎地选择目标网络吞吐量，以防止构建者交付越来越难以通过最小节点验证的块。 作为一个思想实验，我们是否可以简单地删除 gas (gas) 限制并让构建者（本地或外部）决定他们想要生成的块的大小？ 我们将有两个问题：

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

区块生产活性 (Block production liveness)

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

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

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

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

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

这里没有关于部署哪种解决方案组合的简单答案，尤其是在 ePBS 的论点不仅仅是加强质押节点和构建者之间的交换，而且还通过提供更好的流水线来扩展的情况下（请注意，对于扩展论点，应在 替代和/或补充方法（例如 延迟执行）的背景下考虑，这是未来说明/调用的主题）。

我们应该谈论什么

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

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

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

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

• 重新审视通往 SSF 的路径 (Paths to SSF revisited)
• 支持本地节点的扩展路线图增量 (A local-node-favoring delta to the scaling roadmap)
• Prover Killers Killer：你构建它，你证明它 (Prover Killers Killer: You Build it, You Prove it)

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