编者按：

以太坊所有核心开发者共识电话（ACDE）每两周举行一次，主要讨论和协调对以太坊执行层（EL）的更改。本次为 ACDE 第 186 次电话会议，本次会议上，开发人员讨论了 Pectra Devnet 0 和 EIP 3074 实施的准备工作。他们详细介绍了各客户团队在准备 Pectra Devnet 0 方面的进展，并讨论了关于 EIP 3074 规范的修改建议以及相关的测试进展。

另外，本文还提及了其他重要议题，如对 Pectra 升级中可能包含的其他代码更改的讨论，以及对以太坊 EIP 流程的更改如何受到 L2/RIP 流程的影响的讨论。Galaxy Digital 研究副总裁 Christine Kim 对本次会议要点做了详细记录，BlockBeasts 将原文编译如下：

2024 年 4 月 25 日，以太坊开发人员齐聚 Zoom 参加了 All Core Developers Execution (ACDE) call #186 会议。ACDE 电话会议是一个每两周举行一次的系列会议，由以太坊基金会协议支持主管 Tim Beiko 主持，开发人员在会上讨论和协调对以太坊执行层（EL）的更改。本周，开发人员讨论了 Pectra Devnet 0 和 EIP 3074 实施的准备工作。他们还讨论了应考虑将哪些其他 EIP 纳入 Pectra 升级，以及考虑到以太坊「以 Rollup 为中心的路线图」对治理变革的广泛思考。

Pectra Devnet 0 最新进展

Beiko 在电话会议上要求客户团队分享 Pectra Devnet 0 的最新进展。Nethermind 团队的 Marek Moraczyński 表示，Nethermind 已经实现了所有 Pectra EIP，正在对其进行测试工作。Besu 团队的 Justin Florentine 表示，Besu 正在实施 Pectra 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「做好准备」。

EIP-7685

Lightclient 合并了 EIP 7685，它创建了一个通用框架，用于将 EL 触发的请求存储到共识层 (CL) 及其对 EIP 6110 和 7002 的影响。Beiko 表示，开发人员应该在其 Devnet 0 版本中加入此 EIP，并不断完善 Pectra EIP。

在测试方面，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 Jiang 建议创建一个「noncemanager」，以便在需要时促进全球撤销 AUTH 消息和其他更改。一些参加电话会议的开发人员认为应该推迟对 EIP 3074 的更改，因为这将大大增加其实现的难度。

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

除了 EIP 3074 的实现细节之外，开发者们还认真讨论了 EIP 是否有足够的社区支持。一位显示名为「Siri」的开发人员在电话会议中表示担心，「EIP 3074 原则上很糟糕，会减慢我们实现完全帐户抽象的速度」。Beiko 回应称，根据以太坊魔术师和 ACD 通话讨论，客户团队似乎支持 EIP 3074，而不是其他与账户抽象 (AA) 相关的提案。Beiko 表示：「这似乎是短期内最有共识的提案，我们实际上可以在下一个分叉中改善 EOA 的状态。」对此 Siri 认为客户团队不应该孤立地做出这个决定。「我们应该听取其他利益相关者的意见，」Siri 说道，并补充，「我们不想转向制造有争议的硬分叉领域。……我认为最好了解一下其他利益相关者的看法以及他们如何看待这个提案。」

Beiko 和 Siri 还讨论了在 ACD 通话之外应如何为 EIP 建立更广泛的共识。Chiang 建议首先召开 EIP 3074 分组会议，深入讨论 EIP 的技术规范，然后决定是否应该保留在 Pectra 升级中。EF 研究员 Ansgar Dietrichs 表示「我们应该明白，除非我们取得足够的进展，否则 EIP 3074 将会被撤出。」

以太坊联合创始人 Vitalik Buterin 补充说，「未来几年用户的账户功能即将发生变化，特别是外部拥有账户 (EOA)。激活帐户抽象相关的 EIP，例如 EIP 3074 等。」

其他 Pectra 提案

开发人员继续讨论应考虑将哪些其他代码更改包含在 Pectra 升级中。Geth 开发者 Marius van der Wijden 表示，这应该取决于像 EOF 这样复杂度较高的 EIP 是否会进入 Pectra。「如果我们要包括 EOF，那么会导致分叉饱和。如果我们不包括 EOF，也许我们可以包括更多内容，」van der Wijden 说道。

Siri 对未经安全审核就将 EIP 3074 纳入 Pectra 表示担忧。Beiko 建议搁置此讨论，直到 EIP 3074 的规范最终确定。

Bitar 表示，他希望看到 Pectra 中添加 EIP 7212。EIP 7212 将创建一个新的预编译，在 secp256r1 椭圆曲线中执行签名验证。这可以与支持用户生物特征识别的硬件设备一起使用。Bitar 表示，支持生物识别来签署以太坊交易将是用户体验的重大改进。阿希赫明表示，他也赞成这一提议。Dietrichs 指出，这是唯一一个通过「Rollup 改进提案」（RIP）流程被 Layer-2 Rollups 批准实施的方案。

其他开发者包括 Dietrichs、van der Wijden 和 Moraczyński 都表达了对 EIP 7623 的支持，这将增加通话数据的成本，从而限制最大区块大小。Beiko 建议将 EIP 7623 和 EIP 7212 标记为「考虑纳入」或 CFI 进入 Pectra，并在 Devnet 0 启动后重新审视客户端团队的带宽以支持这两个改进提案。

关于与将 EL 的序列化方法更新为 SSZ 相关的 EIP 捆绑包，van der Wijden 表示担心这些在 Pectra 中运输太困难。他在 Geth 团队 Guillaume Ballet 的同事也同意这一评估。Buterin 插话道，「至少更新交易收据的序列化方法将具有超越以太坊本身的「重大价值」，因为它消除了以太坊上构建的第 2 层 Rollup 的额外安全审计开销。」。SSZ 相关 EIP 的主要支持者、来自 Nimbus 团队的 Etan Kissling 没有出席电话会议，但他在 GitHub 上写了一份详细的解释，讲述了为什么这些代码更改很重要，并且应该考虑将其包含在 Pectra 中。

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

Ballet 指出，根据他与 Daniel 和 Dietrichs 等其他开发人员的对话，很难在不违背其目的的情况下缩小 EOF 的范围，并为开发人员今后实现另一组类似 EOF 的代码更改创造更多工作。

一位屏幕名为「Charles C」的开发人员建议寻找一种通过 Side Car 机制（例如用于 Blob 事务的机制）轻松迭代地实现 EOF 的方法，而不是在小型或大型 EOF 升级之间进行选择。Dietrichs 在聊天中询问，如果降低 Pectra 的 EOF 复杂性，客户团队是否会对它有更大的兴趣。Ipsilon 团队指出，导致 EOF 中最高复杂性的代码更改（例如「TX create」）已经得到解决，删除「EOF create」等功能的特定请求不会大大降低整体 EOF 复杂性。作为背景，Ipsilon 是 EF 资助的 EVM 研发团队的名称。Beiko 建议开发人员在反复出现的 EOF 分组讨论中继续讨论 EOF 实现。

ACD/EIP 和 L2/RIP

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

Geth 开发人员 Péter Szilágyi 表示，L2 上提供的某些功能可能不适合在 L1 上提供，并且在某些情况下，即使遵循 L2 上提供的功能，L2 之间也可能有所不同，这可能会给以太坊协议开发人员带来困惑。EF 研究员 Carl Beekhuizen 指出，RollCalls 和 RIP 流程不需要以太坊协议开发人员在 L2 上发布任何功能，而是改善 Rollups 和以太坊开发人员之间的通信，以便避免像 Szilágyi 描述的那样令人困惑的情况。Van der Wijden 对协议开发人员花时间支持在 L2 上实施的更改表示担忧，而这些更改最终会变得过时或不必要，因为 L2 本身会关闭或停止使用。

对于这些担忧，Dietrichs 表示：「我认为人们一直认为 Layer 2 可以进行实验并变得更加疯狂。我认为在实践中我们看到的是，他们中的大多数人决定不这样做，甚至或至少可能开始这样做，然后随着时间的推移，大多数人停止了。所以现在他们实际上主要遵循第一层规范。我认为至少考虑到以 Rollup 为中心的路线图，或者我们都认为这是生态系统发展的最佳方式，我们至少欠 Layer 2 明确的指导和沟通，就像这里的最佳前进道路一样。」