以太坊ACDE会议：或于明年在Devnet3上发布代码变更

Pectra Devnet 3

EF 开发运营工程师 Parithosh Jayanthi 介绍了 Pectra Devnet 3 的发布情况。该开发网络于 9 月 11 日星期三启动。它包括对 EIP 7251 中验证器合并的修复以及 EIP 7702 的更新规范。根据迄今为止在 Devnet 3 上的测试，EIP 7251 和 EIP 7702 似乎都按预期运行。Jayanthi 指出，在 Nethermind 和 EthereumJS 客户端中发现了一些问题，这两个客户端团队正在努力解决这些问题。Jayanthi 补充说，由于 EIP 7702 在 Devnet 3 上线，最好让钱包开发人员测试该实现并提供他们对其使用的反馈。有关 Pectra Devnet 3 的所有信息，包括请求测试网 ETH 的水龙头，都可以在此网站上找到。

Pectra 规范更新

Geth 开发人员 Felix Lange 已提议对 Pectra 中 EL 触发请求的编码进行更改。作为背景，Pectra 将启用 EL 上的智能合约来启动 CL 上的验证器提款和合并。在上次 ACD 电话会议中，Lange 分享了一项建议，以减少 EL 客户端解析这些请求所需的工作量。自上周电话会议以来，Lange 已正式确定了他的建议以及 EL 客户端团队需要做的工作，以更新以下四个 EIP 的编码：

EIP 7685，通用执行层请求；

EIP 7002，EL 可触发提款；

EIP 6110，链上供应验证器存款；

EIP 7251，增加最大有效余额。

开发人员大体上同意 Lange 的提议。然而，网名为“Dustin”的 Nimbus 开发人员认为，该提议“毫无意义地灵活”，并且不向前兼容 EL 序列化格式的未来变化。他还强调，需要额外的规范来明确规范 EL 客户端的请求顺序以及 EL 向 CL 提交无效请求时 CL 客户端的行为。Lange 同意向 Engine API 添加更多文本以指定请求的顺序。他还同意 Dustin 的观点，即应该更深入地考虑 CL 客户端在 CL 客户端检测到来自 EL 客户端的无效请求时的行为。

以太坊基金会研究员 Peter Miller 指出，根据当前规范下 CL 客户端的逻辑行为，CL 客户端应该拒绝来自 EL 的未按正确方式排序的区块。此外，如果 EL 共享给 CL 的列表中存在无效请求，则 CL 应该简单地处理列表中所有有效请求并忽略无效请求。Dustin 同意 Miller 的观点，并建议开发人员在适当的文档中指定此行为。Beiko 表示，开发人员应该致力于解决 Lange 提案中的问题，并在下一次 ACD 调用之前完成它。

随后，Erigon 开发人员 Andrew Ashikhmin 提出了对 EIP 7702 的更新，设置 EOA 帐户代码。他指出，EIP 中指定的有效性检查与旧 EIP 中指定的有效性检查不一致。 Geth 开发人员 Matt Garnett（又名“Lightclient”）表示，他有一个替代方案来解决一致性问题并简化 EIP 7702 的有效性检查。开发人员大多赞成最终确定 Lightclient 的提案并将其添加到 Pectra Devnet 4 中。

接下来与 Pectra 相关的讨论是关于 EIP 2537 下 BLS 预编译的定价。Geth 开发人员 Jared Wasinger 表示，根据他的基准分析，BLS 预编译的价格应该是目前规定的两倍。目前，成本基于多线程执行，这不是定价其他预编译时执行的标准。因此，基于他使用单线程执行的分析，Wasinger 建议对 EIP 2537 中操作的折扣表进行更改。Nethermind 团队报告说，他们正在开发一种工具，以便其他客户端团队也可以轻松地对 EIP 进行自己的基准分析。 Beiko 建议团队对 BLS 预编译进行自己的基准测试，并在接下来的两周内提出有关重新定价这些操作的想法。

Pectra EIP 补充

开发人员随后开始讨论为 Pectra 升级添加新 EIP 的话题。在开始讨论时，Beiko 警告说：“我们已经在 Pectra 中拥有大量 EIP。从 EIP 数量来看，它已经是迄今为止最大的分叉。”根据开发人员在电话会议前分享的观点，Beiko 表示，很明显，EIP 7742（EL 和 CL 之间的 blob 计数分离）是仍在考虑纳入升级的 EIP 列表中争议最小的。

EF 研究员 Alex Stokes 再次提出将 Pectra 拆分为两个较小的硬分叉的想法。“我认为每个人都同意这是一个非常大的分叉。因此，自然的做法就是将其一分为二。通常，较小的分叉风险较小。特别是，现在的 Pectra 有很多跨层 EIP，这确实增加了测试、安全和审查负担，”Stokes 说。Jayanthi 在之前的电话会议上也提出了这个想法，他说他仍然支持这个想法。“我认为主要原因是，目前我们有很多 EIP，我们倾向于触及堆栈的许多层，我们添加的越多，即使在当前负载下，任何一个人都很难对所有变化有一个全局的了解，”Jayanthi 说。

关于当前 Pectra EIP 可以分为两个分支的方式，Stokes 建议使用当前在开发网络上运行的所有 EIP 来发布 Pectra 的第一部分，然后使用 PeerDAS、EOF 和其他一些额外的 EIP 来发布 Pectra 的第二部分。开发人员有信心，通过这样做，他们将能够在明年 2 月之前发布 Pectra 的第一部分。 “我认为，如果我们仍然只在 6 月份发布前半部分，那么这种分叉将是一种失败，”EF 研究员 Ansgar Dietrichs 在 Zoom 聊天中表示。

Beiko 赞成分叉的想法，但警告不要从开发网中删除任何 EIP，因为这可能会给客户团队带来更多工作，并延长而不是缩短为激活主网而准备这些代码更改的时间线。独立的以太坊协议开发人员 Danno Ferrin 建议尽快在 Devnet 3 上完善 EIP 以激活主网，然后从 Devnet 4 或 5 开始并行工作，将 PeerDAS 和 EOF 重新定位到 Pectra EIP 上。实际上，在 Pectra 之后的升级中，Devnet 4 或 5 将成为 Devnet 0，而开发人员对如何命名并不确定。

在之前的电话会议上，开发人员同意以 Pectra Fusaka 的名字命名升级，但他们也同意将此升级保留给 Verkle 过渡。关于这一点，Ferrin 建议开发人员在确信代码更改已准备好用于主网激活之前，不要提前预订升级。这引起了 Geth 开发人员 Guillaume Ballet 的愤怒，他一直在领导 Verkle 过渡工作，并坚持认为 Verkle 过渡“很久以前”就准备好了。为了缓解紧张局势，Beiko 表示，将 Pectra 一分为二的目的最终是为了尝试在更快的时间表上发布 Pectra 代码更改，这有利于为此后的 Verkle 过渡扫清道路。

然而，存在这样的风险：Pectra 升级的第二部分可能会随着更多 EIP 的增加而变得更大，因此与当前 Pectra EIP 列表同时发布相比，需要更多时间才能发布。Nethermind 开发人员 Ben Adams 质疑，如果将升级分为两部分，Pectra 的测试过程将如何进行。鉴于这一决定将彻底改变以太坊下一次立即升级的范围，Beiko 建议开发人员花一周时间考虑这个想法。他要求开发人员准备在下周四的全体核心开发人员共识电话会议上就此事做出最终决定。

网络配置结构对齐

最后但并非最不重要的是，EF 开发运营工程师“pk910”分享了他的工作更新，以清理以太坊公共测试网 GitHub 存储库并调整其结构以更易于使用。他要求客户团队检查以太坊主网和测试网的节点配置，并将任何缺失的信息添加到相应的存储库中。