以太坊 Glamsterdam 分叉中可能包含的多个EIP提案

我们的意见总结

我们认为 Glamsterdam 分叉将是开发者们的一项重要工作，同时专注于 ePBS 本身。然而，考虑到社区对 FOCIL 的支持，以及它可能被包含的时间安排，我们认为我们也应该尝试在 Gloas 中实现它。

我们注意到，根据预期的分叉日期，这可能会使团队的交付能力达到极限。考虑到这一点，任何额外的 CL EIP 都应仔细评估，以确定 Gloas 是否需要它们的好处，或者是否可以合理地推迟到 Heka 或更晚。

以下是简要总结，详细原因将在以下章节中给出。

Glamsterdam EIP

计划包含

• EIP-7732: Enshrined Proposer-Builder Separation (ePBS) - 嵌入式提议者-构建者分离 - 分叉的重点和核心。

考虑包含

• EIP-7805: Fork-Choice Inclusion Lists (FOCIL) - 分叉选择包含列表 (CL) - 支持包含。

提议包含

• EIP-7688: Forward compatible consensus data structures - 向前兼容的共识数据结构 - 不支持包含。

• EIP-8045: Exclude slashed validators from proposing - 排除被罚没的验证者提出区块 - 不支持包含。

• EIP-8061: Increase churn limits - 增加流失限制 - 支持包含此 EIP 或 8071，首选 8071。

• EIP-8062: Add sweep withdrawal fee for 0x01 validators (CL) - 为 0x01 验证者添加清扫提款费 - 不支持包含。

• EIP-8068: Neutral effective balance design (CL) - 中性有效余额设计 - 不支持包含。

• • *

讨论

EIP-7732: Enshrined Proposer-Builder Separation (ePBS) - 嵌入式提议者-构建者分离

ePBS 是 Glamsterdam 分叉的重点和主要关注点。我们预计 ePBS 的实施将需要大量的开发者努力和关注，因此，任何正在考虑的其他 EIP 都必须根据其对及时交付 EPBS 能力的影响进行评估。

EIP-7805: Fork-Choice Inclusion Lists (FOCIL) - 分叉选择包含列表

建议： 我们支持包含 FOCIL (SFI)，并注意到这将对我们交付 ePBS 的速度产生一定的影响。FOCIL 似乎得到了社区和开发者的重大支持，并解决了关键的新出现的审查和中心化风险。然而，我们也承认生态系统利用包含列表的程度仍不清楚，并且可能存在一些基于国家压力审查或制裁交易的反对意见。

优点

• 本地区块构建的衰落影响了整体的抗审查性。如果中继/构建者决定审查交易，FOCIL 提供协议内保护，以保证本地 内存池 参与。
• 实现经过了相当周全的考虑，有几个客户端实现 - 注意到这些实现尚未基于 ePBS 重新构建。
• 将 FOCIL 的实施推迟到 ePBS 之后可能会导致网络上出现一段潜在的审查期。

缺点

• ePBS 本身就是一个复杂而困难的改变。添加 FOCIL 可能会影响交付时间表。

• 需要一个新的委员会来构建包含列表。

• 相对于其复杂性而言，对包含列表的需求是不确定的。这可能意味着我们在一个未使用的功能上花费了大量的精力。

• FOCIL 可能会引起有兴趣强制审查交易的国家或其他实体的反对。

• • *

EIP-8045: Exclude Slashed Validators from Proposing - 排除被罚没的验证者提出区块

建议： 我们不支持包含此 EIP (DFI)。我们总体上同意这个想法，并认为它可以在大规模罚没的情况下为网络提供一些好处（例如，如果 50% 的验证者被罚没）。但是，我们对这种情况的现有恢复机制充满信心，并且不认为除了 ePBS 和 FOCIL 之外，这种改变的复杂性是其好处所能证明的。

优点

• 有助于网络在大规模罚没事件期间的韧性。
• 来自被罚没的验证者的区块被认为是无效的；选择被罚没的验证者没有任何意义。

缺点

• 在 ePBS 之上的额外工作。

• 鉴于潜在的复杂性，好处没有明确的定义。

• • *

EIP-7688: Forward Compatible Consensus Data Structures - 向前兼容的共识数据结构

建议： 我们不支持包含此 EIP (DFI)。虽然我们同意此更改具有价值，但我们建议考虑将其用于下一个分叉（或精简链），或者等待 snarkification 工作取得更显着的进展。我们认为，目前，过渡的成本可能比维护索引更糟糕。

优点

• 提出新的共识数据结构，这些结构将在分叉之间向前兼容，从而允许开发人员在更改字段时不会破坏跨分叉边界的 merkleization。

缺点

• 触及大量代码，而带来的好处主要集中在开发人员身上。

• 可能会破坏现有的智能合约和/或对更广泛的生态系统产生无法预料的影响。

• • *

EIP-8061: Increase Churn Limits - 增加流失限制

建议： 我们有条件地支持包含 8061 或 EIP 8071，目的是解决合并队列提款错误。我们不认为这是引入队列时的预期行为，并且不应将其用作优先级退出队列。8071 更直接地解决了这个问题，并且实现起来会简单得多，考虑到 ePBS 和 FOCIL 的实施，我们更倾向于选择它。

我们注意到，使用 ePBS，构建者可能会比现在更慢地执行退出队列，并且增加的流失限制可能是合理的。如果是这种情况，我们希望看到更好地阐明修改弱主观性的风险。

优点

• 通过三倍的限制，减少了提议者激活/退出/合并队列的延迟。
• 提高了验证者的机会成本。
• 解决了合并队列跳过问题。

缺点

• 影响弱主观性周期。

• 我们需要看到此更改的好处得到更明确的阐述。

• • *

EIP-8062: Add Sweep Withdrawal Fee for 0x01 Validators - 为 0x01 验证者添加清扫提款费

建议： 虽然我们不支持将此更改包含在 Glamsterdam 中，但我们承认验证者合并的目标和好处。在这个阶段，我们建议此 EIP 保持为“提议包含 (PFI)”，因为我们希望在完全支持之前更清楚地了解其好处。

特别是，每个 32 ETH 验证者每年约 2 美元的费用似乎不足以鼓励过渡，同时也引入了重大的复杂性。额外的费用总是会引起社区的负面评价，我们认为，如果要鼓励合并，则应该更果断地进行。

优点

• 激励 0x01 验证者迁移到复合验证者。
• 合并对网络有利，并且是实现快速最终性的路线图所必需的。

缺点

• 为验证者引入新的费用。

• 相对于其复杂性而言，此更改的好处没有得到很好的阐述。最低费用不太可能实现更改（鼓励合并）的目标，同时引入了重大的复杂性。

• • *

EIP-8068: Neutral Effective Balance - 中性有效余额

建议： 与 8062 类似，虽然我们不支持将此更改包含在 Glamsterdam 中，但我们承认 0x01 验证者和复合验证者之间有效余额处理差异造成的经济差距。

如果实施不涉及添加到验证者的额外字段，和/或作为更大、更有针对性的 EIP 的一部分来鼓励合并，我们更有可能支持此 EIP。

优点

• 提高了复合验证者和 skimming 验证者之间的公平性。
• 提供基于奖励的激励措施来合并 - 尽管注意到一个旨在实现均等而不是积极激励的激励措施。

缺点

• 需要在验证者上添加两个新字段：temporary_upward_threshold 和 reset_eb。

• • *

总结

我们的主要重点应仍然是成功交付 EIP-7732 (ePBS) 作为 Glamsterdam 的核心功能。虽然我们看到了 FOCIL 和某些其他 EIP 的价值，但我们必须仔细权衡额外的范围与 ePBS 的复杂性和交付时间表。

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