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

非常感谢 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 的评论和审阅（这些不代表认可）。我麻烦了很多人，哈哈。

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

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

这篇笔记讨论了 本地构建 并提出了以下问题：

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

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

协议角色和服务提供商

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

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

一个 staking 节点需要履行上述角色，或者可能需要（FOCIL 角色目前不存在，将在下文中讨论）。

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

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

\ 外部构建_1920×1063 76.4 KB

构建者角色主要由 staking 节点外包给外部构建节点。

验证和构建的不对称性

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

\ 耦合吞吐量_2080×1356 138 KB

精确满足最小验证要求的最小节点能够运行一个 validator。

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

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

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

\ 解耦吞吐量_1920×1249 75.9 KB

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

要实现的三个网络属性

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

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

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

1. 网络的抗审查性： 本地构建者是验证者集合的一部分，假设验证者集合足够去中心化，以提供良好的抗审查性。当外部构建者审查时，假设一些本地构建者继续生产区块，chain 会保留一些（可能较低的）抗审查性。
2. 实现目标吞吐量： 今天，吞吐量的设置使得本地构建者始终能够实现它，所以我们有相当好的保证，只要每个外部构建者都至少具有同等的能力，它就会被实现。
3. 区块生产活性： 本地构建者始终可以生成一个有效的区块，所以我们也有信心，始终会有一个构建者（本地或外部）能够推进 chain。

将吞吐量与本地构建者分离的影响

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

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

网络的抗审查性

通过 EIP-7805: 分叉选择强制包含列表 (FOCIL)，我们相信抗审查性属性基本上在网络层面得到了保证，因为以前的本地构建验证者可以通过 FOCIL 实现的抗审查性至少与本地构建一样多（但实际上更多）。

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

\ FOCIL_1000×760 196 KB

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

FOCIL 允许决定不再做本地构建者，将其构建功能委托给外部构建者市场的 staking 节点，仍然参与提供抗审查性。本地构建者不需要在本地构建以提供抗审查性和使用外部构建者以最大化其奖励之间做出选择，他们可以两者兼得。

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

实现目标吞吐量

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

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

区块生产活性

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

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

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

现在，我们给出一些论点来指导我们选择所需的防御手段：

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

这里没有关于部署哪种解决方案组合的简单答案，尤其是因为 ePBS 的论点不仅在于加强 staking 节点和构建者之间的交换，还在于通过提供更好的流水线来扩展（请注意，对于扩展论点，应该 在替代和/或补充方法（例如 [延迟执行](https://learnblockchain.cn/article/17620)）的上下文中考虑，这是未来说明/调用的主题）。

我们应该讨论什么

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

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

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

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

• 重温通往 SSF 的路径
• 扩展路线图中对本地节点有利的增量
• 证明者杀手的杀手：你构建，你证明

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