5 月 9 日，以太坊所有核心开发人员参加了第 187 次 All Core Developers Execution(ACDE) 电话会议。

撰文：Christine Kim

编译：Luccy，BlockBeats

编者按：以太坊所有核心开发者共识电话（ACDE）每两周举行一次，主要讨论和协调对以太坊执行层（EL）的更改。本次为 ACDE 第 187 次电话会议，本次会议上，开发者们就 Pectra Devnet 0 的准备工作、EIP 3074 的实施更新以及将执行层的序列化方法从 MPT 转换为 SSZ 的紧迫性进行了讨论。

除了针对 Pectra Devnet 0 的准备工作外，开发者们还探讨了新的 EIP 提案、对现有 EIP 的讨论和分析，以及对智能合约和交易的影响分析等。其中，对 EIP 7702 的讨论引起了与会者的广泛关注，该提案被视为取代 EIP 3074 的潜在方案。

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

2024 年 5 月 9 日，以太坊开发人员齐聚 Zoom 参加了 All Core Developers Execution (ACDE) call #187 会议。ACDE 电话会议是一个每两周举行一次的系列会议，由以太坊基金会协议支持主管 Tim Beiko 主持，开发人员在会上讨论和协调对以太坊执行层（EL）的更改。本周，开发者讨论了 Pectra Devnet 0 的准备工作，EIP 3074 实现的更新，以及将 EL 上的序列化方法从 MPT 转换为 SSZ 的紧迫性。

Pectra Devnet-0 更新

以太坊基金会开发者运营工程师 Barnabas Busa 表示，他的团队正在测试第一个 Pectra 开发者专注的测试网络的客户端配置，并将在 5 月 13 日星期一之前努力确保 Pectra Devnet 0 的稳定配置。根据 Pectra Devnet 0 的准备情况追踪器，Geth、Nethermind 和 EthereumJS 客户端团队已完全实现了 Pectra 代码规范。

在电话会议上，Besu 的开发者 Justine Florentine 表示，所有 Pectra EIP 已经在 Besu 上实现，但他的团队仍在努力调试代码。Erigon 的开发者 Andrew Ashikhmin 表示，他的团队已经开始处理除了 EIP 7002 之外的所有 EIP，即 EL 可触发式提款。Reth 团队在 Zoom 聊天中发布了他们的实现追踪器的链接，显示他们对 EIP 7002 的工作与 Erigon 团队一样仍在等待中。

在 CL 客户端方面，Grandine 的开发者 Saulius Grigaitis 表示，所有 EIP 都已经实现，但当与 EL 客户端一起运行时，他的团队遇到了一些错误。来自 Lighthouse 团队的代表表示，他们即将为 Pectra Devnet 0 准备好一个完整的实现，并指出引擎 API 中的规范需要更新。Teku 的开发者 Mikhail Kalinin 表示，他正在努力将这些更新添加到引擎 API 规范中。

来自 EF 测试团队的 Mario Vegas 表示，开发者正在处理为 EIP 3074、AUTH 和 AUTHCALL 操作码以及其他几个 EIP 添加测试用例的工作。

EIP-3074 更新

尽管开发者们同意将 EIP 3074 保留在 Pectra Devnet 0 的规范中，但已经讨论了一种替代性 EIP 来取代它，即 EIP 7702。Geth 开发者「Lightclient」总结了关于 EIP 3074 的最新分组会议，在这次会议中，参与者讨论了在 Pectra 升级中优先考虑哪些改变与提高用户控制账户可编程性有关。根据 Lightclient 的说法，所有参与者都同意完全本地账户抽象化距离在以太坊上实现还需要几年的时间。然而，对于这是否意味着优先考虑对外部拥有账户（EOAs）功能的变更，或者将 EOAs 迁移到智能合约钱包上，存在分歧。在这次 ACDE 电话会议的前一天，即 5 月 8 日，以太坊联合创始人 Vitalik Buterin 提出了一个新的 EIP，即 EIP 7702，该 EIP 将使以太坊支持一种新的交易类型，以支持 EOAs 在单个交易期间像智能合约钱包一样运行。Lightclient 表示，来自 EIP 3074 分组会议的参与者普遍对 EIP 7702 持积极态度。然而，他后来补充说，关于 EIP 7702 仍有重要细节需要解决。例如，有关如何撤销 EIP 7702 交易以及如何缩放这类交易的 gas 成本的详细信息仍不清楚。

如果 EIP 7702 被接受并纳入 Pectra 升级，那么就会考虑用它替代 EIP 3074，因为 EIP 7702 实现了与 EIP 3074 类似的结果，但却不会在以太坊上创建新的操作码，并且提高了对新 EOA 行为进行静态分析的便利性。EF 研究员 Ansgar Dietrichs 在 Zoom 聊天中建议考虑将 EIP 7702 纳入 Pectra，并在大约 2 到 4 周后正式决定是否用 7702 替换 EIP 3074。从开发者在电话会议上对 EIP 7702 的讨论可以清楚地看出，在将该提案认为已经准备好实施之前，还需要进一步工作。Nethermind 开发者 Ahmad Mazen Bitar 指出，已经为 EIP 3074 所做的工作可能不太可能被重用来实施 7702。Beiko 确认，开发者仍应继续推进 EIP 3074 的实施，用于 Devnet 0，并稍后重新讨论 Devnet-1 的规范。

EIP-7685, SSZ, 和 EIP-6110

然后，开发者们讨论了 Nimbus 开发者 Etan Kissling 对 EIP 7685 提出的一些担忧，即通用的执行层请求。在本周电话会议议程下的 GitHub 评论中，Kissling 问道是否需要通用执行层请求的提议设计，以及如果这个机会是否可以更好地用于切换到 SSZ，这是开发者们自合并升级以来一直希望在执行层上更新的序列化格式。电话会议上的大多数执行层客户端团队支持将 EIP 7685 保留在 Pectra 中，如果从将 EIP 包含在操作中出现任何阻碍，比如客户端的乐观同步，那么重新审视这个设计。

在转向 SSZ 的话题上，Kissling 解释说，通用执行层请求的新设计格式是基于传统的序列化格式 MPT 和 RLP，因此当开发者过渡到 SSZ 时，它将必须进行更新。他指出，如果开发者继续创建新的 MPT/RLP 数据结构，推迟转向 SSZ 只会给开发者带来更多的工作。然而，并没有得到执行层客户端团队的强烈支持将 EIP 7495，即 SSZ 稳定容器，纳入 Pectra 中。一位名叫「Dustin」的开发者在 Zoom 聊天中写道，推迟 SSZ 过渡的决定「疯狂」，而 EL 中 SSZ 库工作不良的问题是「一个严重问题」。

关于 EIP 6110，即链上的供应验证器存款，Kissling 提出了有关存款排序的问题。Kalinin 表示同意这个问题是「一个重大关切」，他将与主要的质押池合作进行更深入的调查。

EOF 更新

独立的以太坊协议开发者 Danno Ferrin 和 EF Solidity 研究负责人 Alex Beregszaszi 分享了有关 EOF 实施工作的更新。背景是，EOF 是一系列改进以太坊虚拟机（EVM）的代码更改，开发者正在考虑将其纳入 Pectra 升级。EOF 的元 EIP 已经最终确定。开发者还简化了 EOF 中的交易创建过程，并正在进行 EOF 的客户端实现工作。

EIP-7623 更新

一位在电话会议上以「William Morris」为屏幕名称的开发者提出了有关 EIP 7623 中 calldata 存储的 gas 成本变更的担忧。他解释说，这些变更将允许一些用户通过合并他们的交易以降低费率来进行交易，从而鼓励为 gas 折扣创建二级市场，以便二层 rollup（L2s）和其他参与者可以更便宜地在网络上进行交易。他推荐了一种另一种 EIP，即 EIP 7703，它以固定费率增加 calldata 成本以解决这些问题。

Buterin 表示，尽管 Morris 的担忧是合理的，但实际上由于 EIP 7623 而创建 calldata 的二级市场的可能性并不高，因为选择参与这种市场的用户数量将极其有限。Buterin 指出，受 EIP 7623 影响的主要参与者是二层开发团队 Starkware 和铭文创作者。他补充说，虽然二级 calldata 市场的总可寻址市场很小，但通过 calldata 增加限制最大块大小的上涨空间极高，因为它可以允许开发者提高 blobgas 限制，从而扩展以太坊支持 L2 的能力。Vitalik 还表示，正如 Morris 建议的那样，对 calldata 成本进行平坦增加也会对 L2 和其他利益相关者产生比当前 EIP 更严厉的影响。Buterin 在电话会议之前的博客文章中分享了更多关于 blob 的 gas 定价的思考。

EIP 7623 的共同作者 Toni Wahrstätter 同意 Buterin 的观点，他表示他认为从实用性的角度来看，大多数 L2 并不会创建 calldata 的二级市场。「从实用性的角度来看，这并不是非常可行的，特别是考虑到这样的市场需要参与者之间的信任和高度的协调。想象一下，作为 L2，你想把你的数据发布到 L1，但你不知道哪个地址会发布数据，数据最终会在哪里。从实用性的角度来看，你需要定制索引等等。所以，我不认为这是非常可行的，」Wahrstätter 说。

Reth 开发者 Georgios Konstantopoulos 问道，如果 EIP 7623 被纳入 Pectra，开发者是否正在研究增加 blobgas 限制的可能性。如果没有随着 EIP 7623 的增加而增加 blob gas 限制，Konstantopoulos 表示该 EIP「解决不了太多问题」。EF 研究员 Dankrad Feist 建议将 blob gas 限制提高到以太坊最大块大小不变的程度，这意味着随着 calldata 成本的增加而释放的空间将被 blob（二进制大对象）填满。EF 研究员 Ansgar Dietrichs 表示，该 EIP 不仅在与 blob gas 限制的增加相结合时有用，而且从安全的角度来看也是有用的，因为它可能确保网络不会因包含最大数量的交易和 blob 的区块而不稳定。

对于 EIP 7623 对智能合约和交易的影响分析的问题，Wahrstätter 表示，他提出的提案对 98% 的用户不会产生影响。Beiko 还提到，EF 开发者运营工程师 Parithosh Jayanthi 可能正在对提高 blobgas 限制的具体程度进行更深入的分析，考虑到 EIP 7623。

EIP 7609 的新替代方案

在电话会议上，一位以「Charles C」为屏幕名称的开发者提出了一个新的 EIP，用于防止智能合约中的重入攻击。Charles 表示，该提案创建了两个新的操作码来保护智能合约，是他之前提交的一项名为 EIP 7609 的提案的替代方案，EIP 7609 旨在减少 Pectra 中 TLOAD/TSTORE 的基本成本。Charles 表示，他不确定为什么 EIP 7609 没有被考虑纳入 Pectra，并且仍在从开发者那里收集关于以一种成本有效的方式防止重入的反馈。他指出，当前的解决方案，如 OpenZeppelin 的 Reentrancy Guard 和 TLOAD/TSTORE 操作码，对于去中心化应用程序开发者来说成本太高，无法默认使用。Beiko 建议开发者在以太坊魔术师论坛上就这个新的 EIP 给 Charles 提供反馈。