编者按：

以太坊所有核心开发者共识电话（ACDE）每两周举行一次，主要讨论和协调对以太坊执行层（EL）的更改。本次为 ACDE 第 188 次电话会议，本次会议上，在这次会议上，开发者们就以太坊执行层的变化进行了讨论和协调。

会议涵盖了许多重要议题，包括新增执行 API 功能、Geth 的最低优先级小费要求、Pectra 开发网络 0 和 1 的讨论、Pectra 分叉范围以及历史记录过期等。开发者们就这些议题进行了深入的讨论和交流，并就 Pectra 升级的范围、时间表和具体实施细节达成了一些共识。

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

2024 年 5 月 23 日，以太坊开发人员齐聚 Zoom 参加了 All Core Developers Execution (ACDE) call #188 会议。ACDE 电话会议是一个每两周举行一次的系列会议，由以太坊基金会协议支持主管 Tim Beiko 主持，开发人员在会上讨论和协调对以太坊执行层（EL）的更改。本周，开发者们讨论了以下内容：

· 向执行 API 添加新功能，使用户能够访问交易的「返回数据」（returndata）

· Geth 的最低优先小费要求

· Pectra Devnet 0 和 1

· Pectra 分叉的范围

· Portal Network 的历史数据过期集成。

· 他们同意从 Pectra Devnet 0 中移除 EIP 3074，并在下一个以开发者为重点的 Pectra 升级测试网 Pectra Devnet 1 中包含 EIP 7702。

将返回数据（Returndata）添加到交易收据

维护智能合约编程语言 Vyper 的开发者 Charles Cooper 提出，应该调整执行 API 中的一个端点，这样用户在获取交易收据时，也可以接收交易的返回数据（returndata）。Cooper 解释说，目前开发者获取返回数据的常用方法，如使用交易跟踪，并未标准化，也未在所有客户端中普遍支持。根据 Reth 等客户端团队对其想法的反馈，Cooper 表示，另一种解决方案是创建执行 API 中的一个新端点，以获取交易的返回数据（returndata）。开发者们在电话会议中未能就此提案达成共识。Beiko 建议开发者继续在 GitHub 上讨论，并尝试在会议之外异步解决此问题。

最低矿工小费要求

随后，Geth 开发者 Péter Szilágyi 提出了最近几周用户对 Geth 客户端默认设置的担忧。自从 EIP 1559 实施以来，Geth 客户端总是强制执行交易的默认最低优先小费要求。合并后，默认的 1 gwei 优先小费未能正常工作，直到最近才被 Szilágyi 的团队发现并修复。恢复了这一默认设置后，用户发现使用 Geth 客户端构建的区块比其他区块明显更空，因为它们排除了几乎没有优先小费的交易。这引发了对默认设置可能对区块提议者和构建者动态产生负面影响的担忧，因为它可能会导致对没有优先费用的有效交易的延迟处理。

Nethermind 开发者 Tomasz K. Stańczak 表示，Geth 的默认最低优先小费要求是一个无关紧要的问题，协议开发者不应尝试标准化或强制执行。EF 研究员 Ansgar Dietrichs 建议降低默认的最低优先小费，因为目前以太坊的交易基础费用非常低。其他开发者建议，将 Geth 中的默认最低优先小费设定为基础费用的一个百分比，而不是固定金额。然而，Beiko 对此表示反对，他认为优先小费并不是为了作为交易被包含在区块中的费用。它应该仅用于优先确保交易被包含在下一个区块中，使用基于基础费用波动的默认最低优先小费可能会扭曲基础费用的变化，因为部分价值会反映在交易的优先小费中。

Beiko 补充说，讨论的另一个角度是如何鼓励构建者创建零小费区块并向提议者提供带外支付作为补偿。这种情况可能会在有或没有默认最低优先小费要求的情况下发生，但设置默认值可能会形成规范，鼓励构建者不要创建零小费区块。Szilágyi 表示，从某种意义上说，构建者是否应该在区块中包含零小费交易是一个哲学问题。从网络角度来看，这些交易是有效的，因此应该被包含在区块中。然而，从财务动机的提议者角度来看，包含零小费交易在区块中没有经济利益，因此不应该被包含。

开发者普遍认为 Geth 团队应该设置他们认为最好的默认值。验证节点运营者可以自由更改这个默认值，如果他们愿意的话，或者使用其他执行层客户端。

Pectra Devnet-0

以太坊基金会（EF）开发者运营工程师 Parithosh Jayanthi 更新了 Pectra 开发网络的情况。第一个开发网络上周在肯尼亚名为 Nyota Interop 的以太坊协议开发者线下聚会上启动。Jayanthi 表示，开发网络包括所有执行层和共识层客户端。然而，EIP 3074 尚未进行密集测试，并且存在需要修复的错误。客户端团队已经在准备第二个开发网络 Pectra Devnet 1 的启动，后者将包括对 EIP 2935 实现的更改。

Pectra 范围更改

开发者随后讨论了 Pectra 升级范围的变化。独立以太坊协议开发者 Danno Ferrin、Reth 开发者 Georgios Konstantopoulos 和 Solidity 团队的代表都支持在 Pectra 中包含 EOF。Geth 开发者 Marius van der Wijden 表示，他正在实施 EOF 规范。然而，他强调，由于 EOF 的复杂性，包含 EOF 肯定会延迟 Pectra 升级的激活。Lodestar 和 EthereumJS 开发者 Gajinder Singh 在 Zoom 聊天中提到，开发者应该专注于发布当前版本的 Pectra，而不是扩大升级的范围。EF 研究员 Alex Stokes 和 Piper Merriam 同意 Singh 的看法。

在讨论 EOF 之后，开发者讨论了 EIP 7702 的进展。EIP 7702 由以太坊联合创始人 Vitalik Buterin 提出，作为 EIP 3074 的替代方案。关于 EIP 7702 的重要细节，如其可撤销设计，仍然未解决。一位名为「dror」的开发者在 Zoom 聊天中写道：「EIP 7002 是 EIP 3074 的一个版本，之前只接受带有 nonce 和链 ID（chainID）的版本。现在这些被移除了，我们需要重新讨论原因。我建议重新开始讨论这些限制。」Besu 开发者 Daniel Lehrner 建议向钱包开发者获取更多关于 EIP 7702 设计的意见。Erigon 开发者 Andrew Ashikhmin 强调，需要有一种方法让用户绕过钱包自行撤销授权。

Beiko 建议在一个单独的小组会议中继续讨论 EIP 7002 的实施细节。同时，开发者同意从 Devnet 0 中移除 EIP 3074，并在 Devnet 1 中加入 EIP 7702。

另外两个计划加入 Pectra 的 EIP 是 EIP 7623（增加 calldata 成本）和 EIP 7212（支持 secp256r1 曲线的预编译）。EF 研究员 Toni Wahrstätter 分享了关于 EIP 7623 的最新进展，智能合约钱包开发者 Ulaş Erdoğan 分享了关于 EIP 7212 的最新进展。开发者没有就这两个 EIP 是否应纳入 Pectra 达成一致。

Pectra 时间表预期

Konstantopoulos 提到开发者应何时在以太坊主网上激活 Pectra 升级。在通话前分享的一份文件中，Reth 客户端团队写道，在 2024 年底之前尝试发布升级的「价值不大」，开发者应准备在 2025 年初发布升级。EF Panda Ops 团队（EF 开发者运营团队的一个子集）也在通话前分享了一份文件，表达了他们对 Pectra 时间表和范围的看法。他们建议将 Pectra 分成两个分叉，一个在今年激活，另一个包括 MaxEB、EOF 和可能的 peerDAS，在明年初激活。Jayanthi 表示，EF Panda Ops 团队在观点上并不统一，但他个人认为应将 Pectra 的范围分成两个分叉。他指出，Pectra 升级的边缘情况和 EIP 交互尚未测试。

EF Solidity 开发者 Alex Beregszaszi 表示担忧，如果 EOF 未被包括在 Pectra 中，这些代码更改将永远不会被包含在以太坊的升级中。Geth 开发者 Marius van der Wijden 和 Guillaume Ballet 对此表示反对，认为 EOF 的好处足够显著，即使再延迟几个分叉，其有用性仍然存在。

Beiko 建议首先就如何优先处理 peerDAS 和 blob 大小增加达成共识，然后再确定升级的其余范围。他建议下周参加 All Core Developers Consensus（ACDC）会议的开发者集中讨论这个话题。他希望开发者在下一次 ACDE 会议上准备好最终确定 Pectra 的范围。

Portal Network 和历史过期

最后，Merriam 指出 Portal Network 团队已经准备好与协议开发者合作，以便与 Pectra 并行发布一个历史过期版本。有关 Portal Network 的更多信息可以在此处找到。