观点：Glamsterdam 应该选择 EIP-7732

简而言之

我们应该选择 EIP-7732 作为我们在 Glamsterdam 的重点提案。

• EIP-7732 实现了基础的 slot 重构，在相同的 slot 时间内，比任何竞争提案提供更高的 gas 限制和更多的 blobs
• EIP-7782 将 slot 时间从 12 秒缩短到 6 秒，提供了用户体验的改进，但仅将开销占比从约 ⅔ 降低到约 ½，保留了可扩展性的上限
• 硬件 ZK prover 已经实现了 ~10.8 秒的 32M gas 区块（低于 12 秒），因此完全的 slot 重构现在可以在 slot 内进行 verifier。
• 7732 远远领先 于成熟度：在两个客户端上都有规范 + PoC 分支
• Payload-Block 分离更有效地利用了带宽，并干净地防止了执行层问题蔓延到共识层的不稳定性

舞台设置

自 2020 年 Beacon Chain 创世以来，共识层核心开发者已经主导了六次硬分叉 (Altair, Merge, Capella, Deneb, Electra, Fusaka)。在这些升级中的五次，"重点" EIP 在发布前很久就显而易见。Electra 是唯一的例外，其旷日持久的辩论预示了我们今天在 Glamsterdam 面临的局面。

这一次，有四个 EIP 似乎都值得占据首位：

为了比较它们，我们将其映射到以太坊的 每个 三个战略举措 今年春天宣布：

EIP-7805 略有不同：它针对可信中立/抗审查性，这是以太坊的核心价值观之一，但其本身并不推进 2025-2027 年的三大举措。广泛的预期是 FOCIL 将会发布——唯一的问题是何时。

为什么不选择“贪婪”的选项 (EIP-7782)

如果我们贪婪地问“这些 EIP 中哪一个能给用户带来最切实的利益？”，那么强烈的观点认为我们最终可能会选择 EIP-7782。更短的 slots 导致更快的交易包含、更快的 finality 以及可能更高的吞吐量。

要理解为什么我们不推荐这种贪婪的方法，我们需要退一步，研究更短的 slots 如何与我们扩展 L1 和 L2 的其他目标相互作用。最简单地说，我们可以将 slot 时间分为两个组成部分：

1. 区块和 Blob 广播和执行
2. 开销（证明、聚合、计算 head 等）

对于任何给定的 slot 设计，开销 是 必须 在每个 slot 的基础上完成的工作，并且不能与区广播和执行并行完成。

我们扩展 L1 和 L2 的越多，我们需要用于区块和 Blob 广播和执行的时间就越多。因此， 为了最大限度地扩展 L1 和 L2，我们必须最大限度地减少花费在开销上的 slot 时间的比例 。一旦 开销 最小化， 缩短 slot 会损害可扩展性 ，因为固定开销现在占据每个 slot 的更大份额。

我们尚未最小化 开销 时间，因此如今 开销占比 占 slot 的 2/3。EIP-7782 提倡通过调整证明/聚合截止日期来最小化开销，同时降低 slot 时间。最新的估计会将开销降低到 3 秒。在 6 秒的 slot 时间下， 这是 1/2 的开销占比。

虽然 EIP-7782 比现在有更好的开销占比，但它仍然严重限制了我们扩展 L1 和 L2 的程度。这就是为什么人们普遍认为 我们还需要某种 slot 重构 以进一步降低开销。

有些人认为我们应该为 Glamsterdam 选择 EIP-7782，并在未来的分叉中进行 slot 重构。我反对这一点，因为：

• 首先缩短 slots，然后重构 slots 将花费更长的时间来交付这两个升级，因为：
• 缩短 slots 需要仔细的物理网络限制的时间测量。如果在缩短后我们重构 slot，所有这些测量都需要重复和重新校准。
• Slot 重构允许比没有重构时可能的更短的 slots。之后重构可能会导致我们想要第二次缩短 slots，重复更多的工作。
• 实时 proving 目前约为 12 秒。这大约每六个月减少两倍。在 Glamsterdam 中交付 slot 重构将使实时 proving 在 Glamsterdam 中可行。在 Glamsterdam 中缩短 slots 可能会延迟这一点。
• EIP-7782 不太成熟；没有客户端完全实现它，并且基础设施和工具需要更新的下游影响很多。如果我们宣布我们有意为 Hstar 缩短 slots，我们将为此提供时间。

由于这些原因， 我认为我们必须优先考虑 Glamsterdam 中的 slot 重构，并在后续分叉中优先考虑更短的 slots 。

Slot 重构高级概述

有两种竞争的 slot 重构 EIP：

1. EIP-7732: Enshrined Proposer Builder Separation (内置提议者构建者分离)
2. EIP-7886: Delayed Execution (延迟执行)

目前，我将保持这篇文章的高级性，并简单地总结每个提案的优点。有关这些提案的更深入的技术讨论，请 参见我之前的文章。

Payload 区块分离的优点：

• 稳定性：如果 L1 上生成区块时出现问题，以太坊可以继续 finality。如果主要客户端存在导致其生成无效区块的错误，或者类似地，如果主要构建者存在错误，则可能发生这种情况。今天，如果构建者/中继持续生成无效区块时出现问题，最终断路器会跳闸，每个人都会恢复到本地构建。随着我们越来越多地转向完全 danksharding 和实时证明，本地构建的可行性将越来越低，并且此回退将不可用。如果不分离 payload 和共识区块，我们将被迫放弃投票以及无效的执行区块，导致以太坊失去 finality。如果不迅速解决，这是一个主要问题。
• 提高传播效率：没有 payload 的共识区块更小，验证速度更快，从而缩短了传播时间。这允许将证明截止日期推到 slot 开始的很早的时候。有关更多讨论，请参见 EIP-7898 的动机部分。
• 执行层和共识层的 ZK 化成为独立的问题。
• 参见 此处的更多讨论

这些 EIP 之间的比较可以概括为一句话：

EIP-7732 比 EIP-7886 需要更多的代码更改，但它实现了更多，并在 Glamsterdam 之后使协议处于更好的状态。

我相信我们应该对该协议采取更长远的观点，并且我们不应该为了短期的利益而牺牲以太坊的中长期健康。鉴于 EIP-7732 也比 EIP-7886 成熟得多，因此不清楚我们是否可以更快地交付 EIP-7886。

由于这些原因，我认为 EIP-7732 应该是 Glamsterdam 的重点提案。

解决批评

在本节中，我将更深入地探讨技术细节，并解决对此观点的批评，这些批评主要体现在 Toni Wahrstätter 的设计权衡文章 中。Toni 提出了几个不同的论点，其中一些是明确的，另一些可能是暗示的，无论如何我都会为了完整性和清晰性而解决这些论点。

1. EIP-7732 强制提议者将构建者列入白名单，这是一项成本。

这与今天没有什么不同。今天的提议者维护着一份个人中继列表，他们在 7732 之后也可以这样做。7732 启用了两种类型的中继：仅保管从中继收集的 bids 的中继，以及保管完整区块并像今天一样运营的中继，绕过协议。

2. 如果提议者使用协议内机制，构建者必须计算证明以确保安全

今天，构建者的安全性是通过中继等到 就在 证明截止日期之前，然后同时从网络中的几个点传播块来实现的。这种认为构建者在不计算证明的情况下无法实现安全的说法似乎是基于这样的想法，即构建者无法访问基础设施来同时传播 bids，因此他们在不计算证明的情况下无法实现与此相同级别的安全性。我不同意这种推理方式，原因有两个。首先，目前尚不清楚构建者是否无法访问这种基础设施。即使他们不自己构建它，上面列出的两种形式的中继都能够拥有同时传播 bid 的基础设施。如果中继想要提供这项服务，他们可以提供这项服务，无论提议者是否使用中继，他们都可以帮助传播签名的 bid。其次， 不再需要同时传播区块，并且对于 bids 效果更好 。在证明截止日期之前很久就掌握签名的 bid 的构建者比在证明截止日期之前很久就掌握签名的区块的构建者安全得多。即使他们无权访问同时从多个点传播签名的 bid 的基础设施，他们也可以 更早地传播它，而无需泄露他们的区块 ，而持有签名 header 的构建者必须等到截止日期前的正确时间，并同时从多个点传播以确保安全。

3. 对于提议者来说，经济上理性的选择是退出协议

这里没有明确的解释，但是这种批评似乎源于这样的想法，即构建者可以使用协议外机制更早地发布区块，而无需牺牲安全性，因此他们可以创建更大的区块或具有更多 blobs 的区块。上面已经解决了这个问题。即使在计算证明之前，构建者也可以通过 7732 实现相同或更高水平的安全性。

4. EIP-7732 不利于预确认，除非牺牲流水线化

这种推理方式以及上面提出的围绕证明计算的大部分担忧都未能考虑 双截止日期 PTC 投票设计。这是一种简单的修改，我们仅将 blob 可用性截止日期与区块可用性截止日期分离。这将使我们能够迫使构建者放弃其后状态垄断，同时允许 blobs 的最大流水线化。这种相同的机制可能会迫使构建者依赖于同时 bid 传播基础设施来确保安全，而不是计算证明。

5. 我们可以现在做 EIP-7886，稍后做 EIP-7732

EIP-7732 消除了对 EIP-7886 的需求。但是反过来则不然。如果我们稍后执行 7732，我们将浪费这个硬分叉。

6. EIP-7886 比 EIP-7732 复杂性低

EIP-7886 的代码肯定比 EIP-7732 少，但这并不意味着整个协议的复杂性较低。鉴于共识客户端和执行客户端之间现有的分离，分离共识区块和执行区块在许多方面都是更自然的设计，这使得未来的升级更容易推理。

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

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