以太坊核心开发者执行会议#185记录

作者：

\ \ Christine Kim\ \ 研究副总裁

主题

• 以太坊

研究 • 2024年4月11日

以太坊核心开发者执行会议 #185 纪要

2024年4月11日，以太坊开发者通过 Zoom 参加了核心开发者执行（ACDE）会议 #185。ACDE 会议是由以太坊基金会（EF）协议支持负责人 Tim Beiko 主持的，是一个双周会议系列，开发者在会上讨论和协调以太坊执行层（EL）的变更。本周，开发者讨论了哪些代码变更应该添加到 Prague 硬分叉中，Prague 是以太坊上即将进行的 EL 升级。Prague 将与一个名为 Electra 的 CL 升级同时激活。两者都暂定于 2024 年底之前激活。

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

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

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

• EIP 7002，EL 可触发的退出

• EIP 7251，增加 MAX_EFFECTIVE_BALANCE

• EIP 7549，将委员会索引移到证明之外

本周，他们同意将 EIP 3074（AUTH 和 AUTHCALL 操作码）和 EIP 2935（在状态中保存历史区块哈希）添加到上述列表中。他们还同意将 EIP 7547（包含列表）和 EIP 7667（提高哈希函数的 gas 成本）从 Prague 中排除。开发者强烈支持将 EIP 7667 与 Verkle 捆绑在 Prague 之后的下一个 EL 升级 Osaka 中。目前有 10 个 Ethereum Virtual Machine Object Format (EOF) EIP 和 EIP 7623（增加 calldata 成本）正在考虑纳入 Prague。

回顾 Prague 中已包含的内容

在深入研究 Prague 考虑的 EIP 列表之前，开发者花了一点时间回顾了对已包含在升级中的 EIP 的未决问题。

EIP 7251

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

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

EIP 2537

Stokes 还分享了 EIP 2537 的更新，该更新向以太坊虚拟机（EVM）添加了操作，以便开发者可以使用 BLS12-381 曲线结构 有效地执行加密签名验证。这是一种比使用 secp256k1 曲线结构 在 EL 上生成的 ECDSA 签名更安全、更快速的签名验证方法。Stokes 表示，为这些操作定价的初步基准测试工作已经完成，开发者可以期待在未来几周内收到关于其确切 gas 成本的最终更新。与此同时，鼓励客户端团队按照目前为第一个 Pectra 开发者测试网络 pectra-devnet-0 规划的范围来实现 EIP。

辩论 Prague 中还应包含哪些内容

在本周的会议之前，EL 客户端团队分享了关于他们希望在 Prague 中包含的其他 EIP 的书面更新，这些 EIP 不包括他们已经同意包含在升级中的五个 EIP。Beiko 在会议议程 中链接了 EL 客户端团队的偏好，为了便于查阅，它们也链接在下面：

• Erigon 偏好

• Besu 偏好

• Reth 偏好

• Nethermind 偏好

• Geth 偏好

Mega EOF Endgame

在开始讨论 Prague 中要包含的其他 EIP 时，Geth 开发者 Guillaume Ballet 表示反对在该升级中包含 EOF 更改。他说，他担心这些更改可能会“将我们自己逼入绝境”，从而难以或不可能在 Prague 之后的升级（称为 Osaka）中实施 Verkle。对此，Swirlds Labs 的首席软件工程师 Danno Ferrin 反驳说，EOF 可以与 Verkle 代码更改“100% 兼容”。Ballet 表示他对 Ferrin 的评估没有信心，并重申了在之前的 ACDE 会议 中发表的关于希望在 Verkle 测试网上看到 EOF 的评论。Beiko 插话说，根据 EOF 在未来硬分叉的测试网上的运行方式来评估 EOF 的兼容性不是一个合理的要求，并询问 Ballet 是否可以澄清关于 EOF 与 Verkle 的兼容性的具体担忧。Ballet 没有。他说，甚至没有 EOF 的代码规范供他审查。一位开发者在 Zoom 聊天中分享了最新的 EOF 规范 的链接。聊天中还链接了基于客户端实现的 EOF 的准备情况 的链接。

Geth 开发者 Marius van der Wijden 询问 EOF 将添加或更新多少个操作码。Beiko 指出，根据其最新的规范，EOF 将更改 18 个操作码。EOF 是对 EVM 的一揽子代码更改，来自10 个不同的 EIP。Van der Wijden 表示，他对 EOF 的主要担忧是其复杂性以及客户端团队充分测试 EOF 中所有边缘案例所需的工作量。Nethermind 开发者 Marek Moraczyński 同意 EOF 可能会“引入许多新的共识错误”，并且需要“仔细测试”，但现在不实施这些 EIP 的缺点意味着对 EVM 的这些改进将不得不等待两到三年。

Ferrin 指出，当开发者们正在辩论 EOF 是否应该包含在 Shanghai 升级中时，他们反对这些代码更改的范围过于狭窄。现在 Ferrin 和其他开发者已经努力使 EOF 更加广泛，客户端团队又反对这些代码更改过于复杂且难以实施。“我们无法从 All Core Devs 组获得一致的要求，”Ferrin 说，并补充说听到关于 EOF 两个版本的抱怨都“令人沮丧”。Reth 和 Erigon 客户端团队都支持在 Prague 中包含 EOF。Beiko 建议开发者继续讨论其他 EIP，并在稍后的会议中重新讨论关于 EOF 的对话。

EIP 3074，AUTH 和 AUTHCALL 操作码

Beiko 询问客户端团队关于 EIP 3074（AUTH 和 AUTHCALL 操作码的引入）的想法。这些操作码将通过允许智能合约授权来自 EOA 的交易，从而在用户控制的账户（在以太坊上称为外部拥有的账户 (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 客户端团队的意见类似，但确实指出，如果像 EOF 这样更大的代码更改也包含在升级中，他们对将其包含在 Prague 中不太有信心。Beiko 建议继续讨论其他 EIP，并在稍后的会议中重新讨论 EIP 2935。

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

以太坊联合创始人 Vitalik Buterin 提出了一个 EIP，以提高哈希函数操作码和预编译的 gas 成本，以匹配它们通过零知识（ZK）系统（如 ZK EVM）的执行成本。有关 ZK EVM 的更多信息，请阅读这份 Galaxy Research 报告。关于在以太坊上重新定价哈希函数操作的动机，Buterin 在EIP 7667 文档 中写道：“哈希函数操作码和预编译的 Gas 成本最初是根据在普通 CPU 上执行它们所需的时间来设置的。然而，自那时以来，又出现了一种同样重要的执行底层，EVM 在其上执行：零知识证明（ZK-SNARK）系统。按照该标准，与其他操作相比，这些操作码和预编译的价格非常低。”

在会议上，Buterin 补充说，很容易低估 ZK 证明将成为常用操作的速度，这些操作不仅用于验证 Layer-2 rollup 上的区块链状态，而且还用于验证像以太坊这样的 Layer-1 区块链上的区块链状态。“我认为我们很有可能相信，即使在一两年内，我们也将有能力实时证明以太坊 L1。因此，我认为重要的是要在思想上适应这样一个事实，即 ZK 链和非 ZK 链之间不存在区别。我们基本上现在进入了一种模式，即每个严肃的链都是 ZK 链，”Buterin 说。

鉴于 Osaka 升级中由于 Verkle 将会对 gas 定价和计划进行更改，Ferrin 建议将此 EIP 与 Verkle 一起实施。EF 研究员 Carl Beekhuizen 表示，此 EIP 需要大量调查，开发者必须“非常小心”地分析这些 gas 更改将如何影响以太坊上的智能合约。Van der Wijden 同意 Beekhuizen 关于谨慎推进此 EIP 的观点。Ferrin 还建议可能首先在 Layer-2 rollup 上实施这些更改，同时以太坊开发者进一步调查其对 Layer-1 的影响。Beiko 同意这种观点，并建议开发者将 EIP 7667 的状态设置为“CFI”，即“考虑包含”在 Osaka 升级中，与 Verkle 一起。没有人反对。

EIP 7623，增加 calldata 成本

EF 研究员和 EIP 7623 的共同作者 Toni Wahrstätter 分享了关于他增加 calldata 成本的提案的更新，并询问客户端团队对此的想法。EF 研究员 Ansgar Dietrichs 和 Nethermind 开发者 Ahmad Bitar 都赞成该提案。Beekhuizen 补充说，当在最新的 Rollcall 会议（Layer-2 rollup 团队之间的系列会议）上提出 EIP 7623 时，没有人反对其实施。Beiko 建议继续讨论其他 EIP，并在稍后的会议中重新讨论此提案。

EIP 7645，将 ORIGIN 别名为 SENDER

Beiko 询问客户端团队关于 EIP 7645 的想法，该提案建议更改 ORIGIN 操作码的行为，以防止智能合约滥用它。Cyrus Adkisson 是以太坊的早期投资者，也是 EIP 7645 的作者，他指出更新 ORIGIN 操作码有三种可能的前进道路，每种道路都有不同的权衡。Ferrin 说，建议更改操作码行为的那个道路需要安全专业人士和审计公司仔细审查，因为以太坊协议开发者无法充分评估此类更改对现有智能合约和最终用户的影响。Beiko 建议开发者们为了节省时间，继续讨论其他 EIP。

EIP 7547，包含列表

Beiko 询问开发者们关于在 Prague 中包含 EIP 7547 的想法。EL 客户端团队似乎并不广泛支持该代码更改。Beiko 建议从升级中排除它。没有人反对。

发行曲线调整提案

Dietrichs 提出了一个减少以太坊发行的提案。鉴于发行量的变化主要会影响以太坊的 CL，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 升级的第一个 devnet 中包含 EIP 3074 和 EIP 2935。在此 devnet 之后，他们同意决定是否应在第二个 Pectra devnet 中包含 EOF 和/或 EIP 7623。

• 在 Twitter 上分享
• 在 Facebook 上分享
• 在 Linkedin 上分享
• 电子邮件

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