以太坊核心开拓者最新会议摘要：EIP-2935和EIP-3074将纳入Pectra进级_以太_人员

原文作者：Christine Kim

原文来源：galaxy

编译：Luccy，BlockBeats

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 客户端团队的偏好，并且为了长期保存，链接如下：

Erigon 偏好

Besu 偏好

Reth 偏好

Nethermind 偏好

Geth 偏好

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。