OPRR 快讯深度活动

Search Extension

以太坊核心开发者最新会议摘要：EIP-2935和EIP-3074将纳入Pectra升级

24-04-12 11:54

阅读本文需 21 分钟

AI 总结

看总结

原文标题：《Ethereum All Core Developers Execution Call #185 Writeup》

原文作者：Christine Kim

原文编译：Luccy，BlockBeats

编者按：

以太坊所有核心开发者共识电话（ACDE）每两周举行一次，主要讨论和协调对以太坊执行层（EL）的更改。本次为 ACDE 第 185 次电话会议，会议上，开发者们就即将到来的 Prague 硬分叉所需的代码更改以及其他 EIPs 进行了深入的讨论和评估。

开发者们就各项提案进行了激烈的辩论，并就其中一些提案是否应该包含在 Prague 中达成了初步共识。然而，也存在一些争议，例如关于 EOF 是否应该与 Verkle 升级捆绑在一起的讨论。会议的最后，开发者们就下一步的工作计划达成了一致，并决定在未来的开发网络中进一步测试和评估各项提案的影响。

Galaxy Digital 研究副总裁 Christine Kim 对本次会议要点做了详细记录，BlockBeasts 将原文编译如下：

2024 年 4 月 11 日，以太坊开发人员齐聚 Zoom 参加了 All Core Developers Execution (ACDE) call #185 会议。ACDE 电话会议是一个每两周举行一次的系列会议，由以太坊基金会协议支持主管 Tim Beiko 主持，开发人员在会上讨论和协调对以太坊执行层（EL）的更改。本周，开发者们讨论了应该添加到即将到来的以太坊 EL 升级——Prague 硬分叉中的代码变更。Prague 将与 CL 升级 Electra 同时激活，预计在 2024 年年底之前完成激活。

最初，开发者们同意将 Prague/Electra（Pectra）的范围确定为包括五个以太坊改进提案（EIPs）。它们分别是：

EIP 2537，BLS12-381 曲线操作的预编译

EIP 6110，在链上供应验证者存款

EIP 7002，EL 触发式退出

EIP 7251，增加最大有效余额

EIP 7549，将委员会索引移出认证外

本周，他们一致同意在上述列表中包括 EIP 3074（AUTH 和 AUTHCALL 操作码）和 EIP 2935（在状态中保存历史区块哈希）。他们还决定从 Prague 中排除 EIP 7547（包含列表）和 EIP 7667（提高哈希函数的 gas 成本）。开发人员强烈倾向于将 EIP 7667 与 Verkle 捆绑在 Prague 之后的下一个 EL 升级 Osaka 中。目前，仍在考虑将 10 个以太坊虚拟机对象格式（EOF）EIP 和 EIP 7623（增加 calldata 成本）纳入 Prague。

回顾 Prague 中已包含的内容

在深入讨论 Prague 中正在考虑的 EIP 列表之前，开发人员花了一小段时间回顾了升级中已经包含的 EIPs 存在的问题。

EIP 7251

其中一个 EIP，EIP 7251，将允许节点运营者将有效余额高达 32 ETH 的验证者合并为一个有效余额高达 2048 ETH 的大型验证者。有效余额指的是验证者获得发行奖励的抵押 ETH 余额。超过 32 ETH 的余额不会给验证者带来更多的发行奖励，这就是为什么节点运营者必须运行多个验证者以增加他们的发行奖励。EIP 7251 旨在通过启用验证者合并和抵押奖励的自动复利来减少以太坊上的活跃验证者数量。

根据开发人员与 Lido 等大型以太坊抵押池的讨论，他们已经同意考虑对 EIP 进行更改，使验证者合并成为由 EL 上的智能合约触发的操作。以太坊基金会研究员 Alex Stokes 强调了他关于协议内合并如何运作的论文，并要求在电话会议上向客户端团队征求对他提出的代码更改的反馈。

EIP 2537

Stokes 还分享了关于 EIP 2537 的最新消息，该提案向以太坊虚拟机（EVM）添加了操作，使开发人员能够使用BLS12-381 曲线构造有效地执行加密签名验证。这是比在 EL 上使用secp256k1 曲线构造生成的 ECDSA 签名进行验证更安全和更快的方式。Stokes 表示，对这些操作定价的初始基准测试工作已经完成，开发人员可以在接下来的几周内期待对它们的确切 gas 成本的最终更新。与此同时，鼓励客户端团队按照当前的范围实施 EIP，用于第一个 Pectra 开发者测试网络pectra-devnet-0。

辩论 Prague 还应该包括什么

在本周的电话会议之前，EL 客户端团队提供了关于他们希望在 Prague 中包含的其他 EIPs 的书面更新，除了他们已经同意包括在升级中的五个 EIPs 之外。Beiko 在电话会议议程中链接了 EL 客户端团队的偏好，并且为了长期保存，链接如下：

Mega EOF 残局

在讨论要在 Prague 中包含的其他 EIPs 时，Geth 开发人员 Guillaume Ballet 表示反对在升级中包含 EOF 的变更。他担心这些变更可能会在 Prague 之后的升级（被称为 Osaka）中实施 Verkle 变得困难或不可能。对此，Swirlds Labs 的首席软件工程师 Danno Ferrin 提出了反对意见，称 EOF 可以与 Verkle 代码变更「100% 兼容」。Ballet 对 Ferrin 的评估表示怀疑，重申了之前一次ACDE电话会议上关于希望在 Verkle 测试网络上看到 EOF 的评论。Beiko 解释说，基于 EOF 在未来硬分叉的测试网络上的功能来评估其与 Verkle 的兼容性并不合理，并询问 Ballet 是否能澄清 EOF 与 Verkle 兼容性方面的具体顾虑。Ballet 未作回答。他表示，没有 EOF 的代码规范供他审查。一名开发人员在 Zoom 聊天中分享了最新的 EOF 规范链接。聊天中还分享了基于客户端实现的 EOF 准备情况的链接。

Geth 开发人员 Marius van der Wijden 询问 EOF 将添加或更新多少个操作码。Beiko 指出，根据最新的规范，EOF 将更改 18 个操作码。EOF 是来自10 个不同 EIPs的 EVM 的代码更改捆绑包。Van der Wijden 表示，他对 EOF 的主要关注点是其复杂性以及客户端团队需要花费多少工作来充分测试 EOF 中的所有边缘情况。Nethermind 开发人员 Marek Moraczyński 同意 EOF 可能会「引入许多新的共识错误」，并且需要「仔细测试」，但不实施这些 EIPs 的负面影响意味着这些对 EVM 的改进将不得不等待另外两三年。

Ferrin 指出，当开发人员在辩论 EOF 是否应包含在上海升级中时，他们反对这些代码变更范围过窄。现在，Ferrin 和其他开发人员已经努力使 EOF 更加广泛，客户端团队却因代码变更过于复杂和难以实施而反对。Ferrin 说：「我们无法从所有核心开发人员小组中得到一致的请求。」他补充说，听到有关两个版本 EOF 的抱怨是「令人沮丧」的。Reth 和 Erigon 客户端团队支持在 Prague 中包含 EOF。Beiko 建议开发人员转而讨论其他 EIPs，并在电话会议后期回顾 EOF 的讨论。

EIP 3074，AUTH 和 AUTHCALL 操作码

Beiko 询问客户端团队对 EIP 3074，即 AUTH 和 AUTHCALL 操作码的引入，有何想法。这些操作码将通过允许智能合约授权来自 EOA（以太坊的外部拥有账户）的交易，为用户控制的账户增加了更多的可编程性。电话会议上的许多开发人员，包括 Georgios Konstantopoulos、Danno Ferrin 和「protolambda」，都支持这一代码更改。Protolambda 重新提出了他的建议 EIP 7664，旨在修复与访问列表交互时 EIP 3074 逻辑的漏洞。Geth 开发人员和 EIP 3074 的合著者 Matt Garnett，也被称为「Lightclient」，表示认为EIP 7664是一个好主意。另一位开发人员询问 EIP 3074 将如何影响 ORIGIN 操作码，该操作返回发起交易的地址。Beiko 表示，这些影响在 EIP 中列出，并询问是否有任何开发人员反对在 Prague 中包含此代码更改。没有反对意见。

EIP 2935，保存历史区块哈希状态

Ballet 在ACDE #184上介绍了 EIP 2935，这是一项代码更改，将为 Verkle 的实现带来未来的好处。Reth 客户端团队对该 EIP 持「中立到积极」的态度，并表示，考虑到这是一个简单的改变，他们不反对将其纳入 Prague。Erigon 客户端团队持类似态度，但指出，如果 Prague 中包含像 EOF 这样的更大的代码更改，他们对将其纳入 Prague 的信心会较低。Beiko 建议继续讨论其他 EIP，并在电话会议后期回顾 EIP 2935。

EIP 7667，提高哈希函数的 gas 成本

以太坊联合创始人 Vitalik Buterin 提出了一项 EIP，旨在提高哈希函数操作码和预编译的 gas 成本，使其与通过零知识（ZK）系统（如 ZK EVMs）的执行成本相匹配。有关 ZK EVM 的更多信息，请阅读Galaxy Research 报告。关于重新定价以太坊哈希函数操作的动机，Buterin 在EIP 7667文件中写道：「哈希函数操作码和预编译的 gas 成本最初是基于在常规 CPU 上执行它们所需的时间来设置的。然而，随后，另一个同样重要的执行底层出现了: 零知识证明（ZK-SNARK）系统。按照这一标准，这些操作码和预编译相对于其他操作定价过低。」

Buterin 在电话会议上补充说，很容易低估 ZK 证明将变得日益普遍，不仅用于验证 Layer-2 rollups 等内容，还涉及 Layer-1 区块链，如以太坊。他表示：「我认为，甚至在一两年内，我们都可能具备实时证明以太坊 L1 的能力。因此，我认为重要的是要适应这一事实，即 ZK 链与非 ZK 链之间不再有区别。我们现在基本上进入了每个严肃链都是 ZK 链的模式。」

考虑到在 Osaka 升级中由于 Verkle 会对 gas 定价和计划进行更改，Ferrin 建议将这项 EIP 与 Verkle 一起实施。EF 研究员 Carl Beekhuizen 表示，这项 EIP 需要进行大量调查，开发人员必须「非常小心」地分析这些 gas 变化将如何影响以太坊上的智能合约。Van der Wijden 同意 Beekhuizen 关于谨慎推进这项 EIP 的看法。Ferrin 还建议可能首先在 Layer-2 rollups 上实施这些更改，而以太坊开发人员进一步调查其对 Layer-1 的影响。Beiko 同意这种看法，并建议开发人员将 EIP 7667 与 Verkle 一起考虑纳入 Osaka 升级，并给予「CFI」或「考虑纳入」的状态。没有反对意见。

EIP 7623，增加 calldata 成本

EIP 7623 的合著者、EF 研究员 Toni Wahrstätter 分享了他提议增加 calldata成本的更新，并询问客户端团队对此的看法。EF 研究员 Ansgar Dietrichs 和 Nethermind 开发人员 Ahmad Bitar 对此表示赞成。Beekhuizen 补充说，当 EIP 7623 在最新的 Rollcall 会议上提出时，即 Layer-2 rollup 团队之间的会议系列，对其实施没有任何反对意见。Beiko 建议继续讨论其他 EIP，并在电话会议后期回顾此 EIP。

EIP 7645，将 ORIGIN 重命名为 SENDER

Beiko 询问客户端团队对 EIP 7645 的看法，该提案旨在更改 ORIGIN 操作码的行为，以防止智能合约误用。早期投资以太坊并撰写 EIP 7645 的 Cyrus Adkisson 指出，更新 ORIGIN 操作码有三种可能的路径，每种路径都有不同的权衡。Ferrin 表示，建议更改操作码行为的路径需要安全专业人士和审计公司进行仔细审查，因为以太坊协议开发人员无法充分评估此类更改对现有智能合约和最终用户的影响。Beiko 建议开发人员为了时间考虑，继续讨论其他 EIPs。

EIP 7547，包含列表

Beiko 询问开发人员对将 EIP 7547 纳入 Prague 的看法。从 EL 客户端团队的回应来看，似乎并没有广泛支持这一代码更改。Beiko 建议将其从升级中排除。没有反对意见。

发行曲线调整提案

Dietrichs 提出了减少以太坊发行量的提案。考虑到这一变化主要影响以太坊的执行层，Beiko 建议开发人员在 ACDC 电话会议上进一步讨论此提案的优点。

重新审视 EOF、EIP 7623 和 2935 对于 Prague

开发人员随后重新审视了为 Prague 提出但尚未达成共识的 EIP。Beiko 询问 EOF 是否可以与 Verkle 升级捆绑在一起。Ballet 强烈反对这个想法，称两项代码更改都很复杂，同时进行将会「太冒险」。Protolambda 强调 EIP 7664 是另一个应考虑纳入 Prague 的 EIP。Garnett 补充说，EIP 7639，一个关于客户端停止提供合并升级（2022 年 9 月）之前历史数据的提案，也应该被考虑。

针对 EOF 的包含会给客户端团队增加太多额外负担的担忧，Reth 开发人员 Georgios Konstantopoulos 鼓励开发人员「全力以赴」。但是，对于 EOF 仍然没有达成共识。开发人员最终同意继续处理 EOF，特别是需要的测试，并在稍后确定是否应将其纳入 Prague。他们还同意推迟对 EIP 7623 的决定。关于 EIP 2935，开发人员同意将其包含在 Prague 中。

对电话会议上做出的所有决定进行总结，Beiko 表示，开发人员将在 Pectra 升级的第一个开发网络中包含 EIP 3074 和 EIP 2935。在这个开发网络之后，他们同意决定是否在第二个 Pectra 开发网络中包含 EOF 和/或 EIP 7623。