反对为 Glamsterdam 实施 EIP-7732 的理由

反对为 Glamsterdam 实施 EIP-7732 的理由

TLDR: 今天就确立提议者-构建者分离（PBS）是不必要的。但是，如果我们旨在短期内大规模扩展，我们可以实施不带无信任支付的 EIP-7732。

我赞成纳入 EIP 的标准是：

• EIP 具有时间敏感性，必须在 fork X 中实施，不能稍后
• 没有更好的替代方案
• 没有更简单的替代方案

EIP-7732 的优点已在此处 SigP 先前的博客文章 中得到了很好的概述，但总而言之，它通过给权益质押者更多时间来履行职责，从而允许进一步扩展。

但是，我对 EIP-7732 的保留意见可以概括为：

1. 今天没有确凿的证据表明确立某种形式的 PBS 是紧急的。
2. 主要的扩展优势（payload 分割 + 延迟执行）可以在没有无信任支付（ePBS）的情况下实现。
3. 即使是这些调整也可能为时过早，链在下一个 fork 周期中有足够的空间。
4. 对 slot 拍卖、执行层支付路径和 MEV-Burn 集成的积极研究表明，推迟以便获得更好的设计灵活性。
5. 质押构建者要求提高了资本门槛

没有确凿的证据表明确立是紧急的

MEV-boost 一直表现良好，偶发事件很少，几乎没有影响。在我看来，它遭受的极少数事件不会通过 ePBS 解决，也不证明更改它的紧迫性是合理的。

主要的扩展优势可以在没有 ePBS 的情况下实现

如果没有确立特定形式的 ePBS 的紧迫性，我们可以进行 slot 重组和 payload 解耦，而无需提交到特定的竞标市场并引入构建者的角色。

今天没有针对这种方法的规范这一事实不应成为放弃这个想法的理由。即便如此，我们现在可能不需要进行 slot 重组 和 payload 解耦。

即使是 slot 重组 + 解耦也可能为时过早

EIP 7732 的主要卖点是扩展，具体来说：

• 目标 1：有更多时间来验证 execution payload
• 目标 2：有更多时间来传播 execution payload

本质上，我们可以拥有更大的区块和更昂贵的区块来验证，而无需强迫权益质押者投资更多的带宽或更好的 CPU。我们希望避免这样一种情况：我们以在不太强大的硬件上运行的权益质押者为代价来扩展链。

让我们首先看一下今天 slot 的剖析。

有 4 秒钟的时间来计算、传播、验证和投票一个区块。但是，如果提议者想要最大化其收入，它将尽可能晚地提交 execution payload。这会将广播和验证 execution payload 的时间缩短到至少 40% 的 slot 委员会可以证明该区块的时间。

现在，对于资源较少的证明者来说，图表是什么样的？

请注意，慢速证明者将无法及时将该区块设置为 head，从而导致不正确的 head 投票并损失 1/8 的奖励。

我们的目标是确保所有权益质押者（在满足一些最低规范要求的情况下）可以及时处理大多数区块，以便正确地证明它们。但是，区块需要截然不同的资源量。我们必须考虑最坏情况下的处理时间，以便限制我们可以安全地增加区块 gas limit 的程度。我们正在通过单独的扩展工作来解决这种差异。然后，通过最小化最坏情况，我们可以扩展区块 gas limit，而无需 slot 重组。

为了给出一些数字，假设创建一个最坏情况的区块需要 1 秒，传播它需要 1 秒，那么我们有 4−1−1=24−1−1=2 秒来验证该区块。

最终，我们将达到 slot 开始和证明截止日期之间的时间不足以产生、传播和验证完整区块的限制。然后，我们必须实施某种形式的 slot 重组，以安全地进一步增加 gas limit。

延迟执行

第一种策略是实施延迟执行。目前，我们需要在其 slot 期间执行一个区块，以证明其 payload 是否有效。相反，我们可以在 slot NN 证明区块 NN 的 payload 可用，并在 slot N+1N+1 中证明其有效性。使用上面的示例数字，我们有：

• 3 秒钟来传播完整区块
• 12 秒的额外时间来验证 payload（证明者）
• 或 8 秒的额外时间来验证 payload（下一个 slot 提议者）

因此，在本例中，我们可以将最大区块大小增加 3 倍，并将 gas limit 增加某个因子，从而使最坏情况的时间增加 12 倍。请注意，EIP-7732 和 EIP-7886 都实施了不同形式的延迟执行。本节指的是一般概念，而不是具体的实现。

Payload 解耦

请注意，在延迟执行中，我们仍然要求证明者在证明截止日期之前收到 payload。我们可以通过将 execution payload 与区块解耦来消除该要求。现在，证明者只需对共识区块的可用性和有效性进行投票。

现在，他们必须在证明截止日期之前或为提议者在 slot 结束之前接收并验证 execution payload。使用与上述相同的示例数字：

• 3+12 秒来传播和验证 payload（证明者）
• 3+8 秒来传播和验证 payload（下一个 slot 提议者）

但是，要实施 payload 解耦，我们必须修改 fork-choice 并在协议中引入一个新角色：payload 及时性委员会（PTC）。我们不知道未来会占据主导地位的是：payload 传播时间还是 payload 验证时间。如果我们保持 payload 传播时间/payload 验证时间 的比率，并适当调整 opcode 定价，payload 解耦不会产生额外的 区块 gas limit 扩展优势。

Payload 解耦还将接收 blob 的最长时间从 3 秒延长到与上述相同的数字。但是，PeerDAS 和采样是活跃的研究领域，可以显着影响这种效果。

ePBS 仍在积极研究中

在过去的 3 年中，对 ePBS 进行了广泛的研究。slot 拍卖、执行层支付路径和 MEV Burn 集成等主题仍在积极研究中。我觉得现在提交到特定形式的 ePBS 还为时过早。由于不紧急，我们必须考虑过早提交和失去灵活性的成本。

质押构建者要求

EIP-7732 为构建者确立了资本要求。虽然这有利于问责制，但它为已经高度中心化的市场中的新参与者增加了摩擦。请回顾前面的观点，并注意存在没有此要求的 ePBS 设计。

结束语

EIP-7732 可能是确立提议者-构建者分离（ePBS）的最佳和最准备好的规范。如果我们必须尽快发布某种形式的 ePBS，我将投票将 EIP-7732 安排在 Glamsterdam 中。

但是，我没有看到今天确立某种形式的 PBS 的确凿紧迫性。它的主要扩展优势（payload 分割 + 延迟执行）可以在没有无信任支付的情况下实现。即使是这些调整对于未来几年来说也可能为时过早。对 slot 拍卖、执行层支付路径和 MEV Burn 集成的积极研究表明，推迟以便保持设计灵活性。

注意： 观点文章反映了 Sigma Prime 工程师的观点和经验。这些是受人尊敬的核心开发人员和安全研究人员提出的知情观点，但它们不一定代表整个组织。

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