以太坊核心开发者执行会议#186总结

作者：

\ \ Christine Kim\ \ 研究副总裁

主题

• 以太坊

研究 • 2024年4月25日

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

2024年4月25日，以太坊协议开发者通过 Zoom 参加了 核心开发者执行（ACDE）会议 #186。ACDE 会议由以太坊基金会（EF）协议支持负责人 Tim Beiko 主持，是一个双周会议系列，开发者在会上讨论和协调对以太坊执行层（EL）的更改。本周，开发者讨论了 Pectra Devnet 0 的准备工作和 EIP 3074 的实施。他们还辩论了应该考虑将哪些其他 EIP 纳入 Pectra 升级，以及关于以太坊“rollup-centric roadmap（以 Rollup 为中心的路线图）”的治理变更的广泛想法。

Pectra Devnet 0

Beiko 要求参加会议的客户端团队分享他们在 Pectra Devnet 0 方面的进展。Nethermind 团队的 Marek Moraczyński 表示，Nethermind 已经实施了所有 Pectra EIP，并且正在对它们进行完善并编写测试。Besu 团队的 Justin Florentine 表示，Besu 正在进行 Pectra EIP 的实施，并预计所有 EIP 都将为 Devnet 0 的启动做好准备。Erigon 团队的 Andrew Ashikhmin 表示，他不确定 Erigon 是否能够为 Devnet 0 准备好全套 EIP，部分原因是这些 EIP 的一些规范仍在不断变化，并且 Erigon 客户端正在过渡到新的主要版本 Erigon 3，这占用了团队的资源和时间。Erigon 3 和 Pectra EIP 将最终确定并一起构建到 Erigon 客户端中。Geth 团队的“Lightclient”表示，Geth 距离为 Devnet 0 做好准备还有“几天”。EthereumJS 团队的 Gajinder Singh 表示，Ethereum JS 也将为 Devnet 0 “做好准备”。开发者尚未确定 devnet 的启动日期，但根据这些客户端的回复，开发者可能会在未来几周内决定一个日期。

EIP 7685

Lightclient 已经合并了 EIP 7685，该 EIP 创建了一个通用框架，用于存储 EL 触发的对共识层（CL）的请求，以及其对 EIP 6110 和 7002 的影响到 Pectra 规范中。Beiko 表示，开发者应该将此 EIP 及其后续对其他 Pectra EIP 的更改纳入其 Devnet 0 版本中。

关于测试，EF 测试团队的 Mario Vega 分享说，已经完成了对 EIP 6110 和 2537 的测试。EIP 7002 和 EIP 2935 的测试将在本周或下周完成。EIP 3074 的测试将无法为 Devnet 0 做好准备。EF 研究员 Antonio Sanso 表示，EIP 2537 规范已经更新，并且新的测试向量已添加到 GitHub 存储库中。他建议所有客户端团队都在 GitHub 上查看。EF 研究员 Hsiao Wei Wang 指出 CL 规范测试向量中存在一个错误，她将尽快更正并发布新版本。

EIP 3074

在本周的 ACDE 会议上，有人对 EIP 3074 规范提出了几项更改建议。Ahmad Mazen Bitar 建议 更改 EIP 3074 的行为，允许在 AUTHCALL 之前进行 DELEGATECALL，以扩大 EIP 的使用案例。区块链钱包操作系统 ZeroDev 的创始人兼首席执行官 Derek Chiang 建议 创建一个“noncemanager”，以便在需要时促进 AUTH 消息的全局撤销，以及其他更改。会议上的一些开发者反对修改 EIP 3074，因为这会大大增加其实现的复杂性。

Beiko 建议开发者在单独的 breakout 会议中讨论对 EIP 3074 的拟议更改。他指出，为了有足够的时间在 Pectra 中实施 EIP 3074，开发者应该尝试在“未来一两个月内”最终确定其规范。Lightclient 同意组织 EIP 3074 breakout 会议。对于 Devnet 0，Beiko 确认客户端团队应该实施没有任何更改的 EIP 3074，即使开发者可能决定在未来的 devnet 中以不同的方式实施该 EIP，或者将其从升级中完全移除。

除了 EIP 3074 的实施细节外，开发者还认真地辩论了社区是否对该 EIP 有足够的支持。会议上一位显示名称为“Siri”的开发者表示担心 EIP 3074 “原则上不好，并且会减缓我们实现完全账户抽象的道路”。Beiko 回应说，根据 Ethereum Magicians 和 ACD 会议的讨论，客户端团队似乎更喜欢 EIP 3074，而不是其他账户抽象（AA）相关的提案。“从短期来看，这似乎是共识最多的提案，实际上我们可以改进下一个 fork 中 EOA 的状态，”Beiko 说。Siri 对此表示反对，称客户端团队不应孤立地做出此决定。“我们应该听取其他利益相关者的意见，”Siri 补充说，“我们不希望转向进行有争议的硬分叉。……我认为最好了解其他利益相关者如何看待此提案。”

Beiko 和 Siri 之间的来回争论引发了 Zoom 聊天中关于如何在 ACD 会议之外为 EIP 建立更广泛共识的问题。Chiang 在聊天中写道：“不幸的是，事实仍然是 4337/AA 社区中的大多数人都感到惊讶，……对于大多数 4337 人来说，实际上看起来是 3074 基本上从‘它已经死了’变成了‘哦，等等，它现在被奉为神圣了。’”Chiang 建议首先举行 EIP 3074 breakout 会议，以便对该 EIP 的技术规范进行深入讨论，然后决定是否应将其保留在 Pectra 升级中。EF 研究员 Ansgar Dietrichs 表示同意，并表示开发者还应该花时间为在 Pectra 升级后启用其他 AA 相关 EIP 制定一个具体的计划。“我们应该达成这样的理解，即除非我们在那里取得足够的进展，以便在我们做出决定时，每个人都感到满意，否则 3074 将被撤出，”Dietrichs 说。

以太坊联合创始人 Vitalik Buterin 补充说，开发者应该讨论如何最好地通过信息性 EIP 等方式提前提醒以太坊用户，告知他们在未来几年内即将对其账户功能进行的更改，特别是外部拥有的账户（EOA），随着 EIP 3074 等账户抽象相关 EIP 的激活。

其他 Pectra 提案

然后，开发者继续讨论应该考虑将哪些其他代码更改纳入 Pectra 升级。Geth 开发者 Marius van der Wijden 表示，这应该取决于像 EOF 这样高度复杂的 EIP 是否会进入 Pectra。“如果我们要包含 EOF，那么这个 fork 肯定是满了。如果我们不包含 EOF，也许我们可以包含更多东西，”van der Wijden 说。

Siri 提出了关于在没有安全审计的情况下将 EIP 3074 纳入 Pectra 的担忧。Beiko 建议将此讨论搁置，直到 EIP 3074 的规范最终确定，并且基于这些规范存在可以通过审计解决的“合理担忧”。

Bitar 表示，他希望看到 EIP 7212 添加到 Pectra 中。EIP 7212 将创建一个新的预编译，用于执行 secp256r1 椭圆曲线中的签名验证。这可以与支持用户生物识别的硬件设备结合使用。根据 Bitar 的说法，支持生物识别来签署以太坊交易将大大改善用户体验。Ashikhmin 表示他也赞成该提案。Dietrichs 指出，这是唯一一个通过“Rollup Improvement Proposal”（RIP）流程获得 Layer-2 rollup 实施批准的提案。

包括 Dietrichs、van der Wijden 和 Moraczyński 在内的其他开发者表示支持 EIP 7623，该提案将增加调用数据的成本，从而限制最大区块大小。Beiko 建议将 EIP 7623 和 EIP 7212 标记为“考虑纳入”，并在 Devnet 0 启动后重新评估客户端团队支持这两个提案的带宽。

关于与将 EL 的序列化方法更新为 SSZ 相关的一组 EIP，van der Wijden 表示担心这些 EIP 难以在 Pectra 中发布。他的 Geth 团队同事 Guillaume Ballet 同意这一评估。Buterin 插话说，至少更新交易收据的序列化方法除了以太坊本身之外，还具有“重要价值”，因为它消除了为构建在以太坊之上的 Layer-2 rollup 提供额外安全审计开销的需求。SSZ 相关 EIP 的主要倡导者，Nimbus 团队的 Etan Kissling 没有参加会议，但他在 GitHub 上 详细解释了 为什么这些代码更改很重要，并且应该考虑将其纳入 Pectra 中。

开发者还 重新讨论了 EOF。独立的以太坊协议开发者 Danno Ferrin 分享说，EOF 团队正在为代码更改编写 EL 规范测试。据报道，EVMOne 和 Reth 是两个已经完成 EOF 实现的 EL 客户端团队。Ferrin 表示，Geth 团队在其实现方面取得了“良好进展”。Ferrin 补充说，Ballet 正在与 Solidity 团队的“Daniel”合作，以解决关于 EOF 和 Verkle 兼容性的担忧。

Ballet 指出，根据他与 Daniel 和 Dietrichs 等其他开发者的对话，如果不削弱 EOF 的目的，并为开发者日后实施另一组类似 EOF 的代码更改增加更多工作，那么很难缩小 EOF 的范围。

会议上一位屏幕名称为“Charles C”的开发者建议，与其在小型或大型 EOF 升级之间做出选择，不如找到一种通过 side car 机制（例如用于 blob 交易的机制）以迭代方式轻松实施 EOF 的方法。Dietrichs 在聊天中询问，如果 EOF 的复杂性降低，客户端团队是否会更愿意在 Pectra 中采用 EOF。Ipsilon 团队指出，EOF 中导致最大复杂性的新提议的操作码（如“TXCREATE”）已经得到解决，移除“EOFCREATE”等特定功能的请求不会大大降低整体 EOF 复杂性。作为背景，Ipsilon 是由 EF 资助的 EVM 研究和开发团队的名称。Beiko 建议开发者继续在 经常性的 EOF breakout 会议 期间讨论 EOF 的实施。

ACD/EIPs & L2/RIPs

作为 ACDE #186 上的最后一个讨论主题，开发者讨论了考虑到新的 RIP 流程，以太坊的 EIP 流程的变更。Dietrichs 指出，自开发者启动 rollup 协调会议系列 RollCall 和 RIP 流程以来，已经过去了六个月。关于这些流程将如何以及应该如何影响未来的以太坊 EIP 流程，仍然存在一些悬而未决的问题。Dietrichs 说，L2 之间正在进行的一个研究问题是，对于 rollup 来说，与以太坊虚拟机（EVM）的长期等效性是否是可取的。他还补充说，一个悬而未决的问题是，在 L2 上实施的更改最终将在多大程度上影响 Layer 1 以太坊的协议决策。

Geth 开发者 Péter Szilágyi 表示，在 L2 上发布的一些功能可能不适合在 L1 上发布，并且在某些情况下，即使遵循在 L2 上发布的功能，L2 之间也可能存在差异，这可能会给以太坊协议开发者带来困惑。EF 研究员 Carl Beekhuizen 指出，RollCall 和 RIP 流程不会要求以太坊协议开发者在 L2 上发布任何功能，而是会改善 rollup 和以太坊开发者之间的沟通，以便可以避免 Szilágyi 描述的令人困惑的情况。Van der Wijden 提出了关于我们处于一种情况的担忧，在这种情况下，协议开发者花费时间来支持在最终变得过时或不必要的 L2 上实施的更改，因为 L2 本身关闭或停止使用。

对于这些担忧，Dietrichs 说：“我认为给人的印象一直是 Layer 2 可以随意试验并变得更加狂野。我认为实际上我们所看到的是，他们中的大多数人决定不这样做，或者甚至至少开始这样做，然后随着时间的推移，大多停止了。因此，现在他们实际上主要遵循 Layer-1 规范。我认为至少鉴于以 rollup 为中心的路线图，或者我们都决定这是生态系统发展的最佳方式，我们至少应该为 Layer 2 提供明确的指导和沟通，说明这里的最佳前进道路。”

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

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