编者按：

以太坊所有核心开发者共识电话（ACDE）每两周举行一次，主要讨论和协调对以太坊执行层（EL）的更改。本次为 ACDE 第 178 次电话会议，本次会议重新确认 Goerli 测试网上坎昆升级时间为 1 月 17 日，并将 1 月 30 日和 2 月 7 日分别作为 Sepolia 测试网升级和 Holesky 测试网升级日期。若一切顺利，开发者将于下周发布 Goerli 客户端，如果分叉后前 24 小时内出现问题，将重新规划升级时间。

此外，会议讨论了 Cancun/Deneb（Dencun）升级的公共测试网激活日期，并重申了对硬分叉升级 Prague/Electra 的 EIPs 的优先级。开发者们对于 Verkle 树升级在 Prague/Electra 中的重要性进行了讨论，并就 EIP 7587 如何被形式化为信息性 EIP 以规范未来以太坊治理过程提出了建议。

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

2024 年 1 月 4 日，以太坊开发人员齐聚 Zoom 参加了 All Core Developers Execution (ACDE) call #178 会议。ACDC 电话会议是一个每两周举行一次的系列会议，通常由以太坊基金会协议支持主管 Tim Beiko 主持，开发人员在会上讨论和协调对以太坊执行层（EL）的更改。本周，电话会议由一个化名为「Lightclient」的 Geth EL 开发人员主持。开发者确认了 Cancun/Deneb（Dencun）升级的下三个公共测试网激活日期，并讨论了 Dencun 之后的下一个硬分叉升级 Prague/Electra 的代码更改优先级，这些更改通常被称为以太坊改进提案（EIPs）。本次会议是开发者讨论和协调对以太坊执行层（EL）的更改的系列会议之一。

Dencun 更新

在假期期间，Dencun 升级并未进行特定的更新。自 12 月 21 日的最后一次 ACD 电话会议以来，客户端团队一直在为 Goerli 测试网准备新版本。由于之前因为 Prysm 导致升级测试延迟的原因，Geth 开发人员 Marius van der Wijden 向 Prysm 客户端团队请求了关于他们切割新版本进展的更新。Prysm 开发人员 Terence Tsao 确认 Prysm 团队将在下周为 Goerli 硬分叉准备一个新版本。然而，Goerli 版本将是一个「预发布」，意味着这不是 Prysm 在以太坊主网上推荐使用的版本。在 Goerli 硬分叉之后，Prysm 团队计划发布另一个版本，其中包含某些更改和更新，将推荐用户在主网上运行，并在 Sepolia 和/或 Holesky 测试网上进行测试。客户端团队一直在为 Goerli 测试网准备新版本。

尽管 Tsao 表示 Prysm 团队对于在 ACDE #177 上讨论的 1 月 17 日 Goerli 硬分叉激活日期感到满意，但他建议在 Goerli 硬分叉之后再确定 Sepolia 和 Holesky 硬分叉激活的日期。自 ACDE #177 以来，以太坊基金会协议支持负责人 Tim Beiko 提出了所有三个以太坊公共测试网（Goerli、Sepolia 和 Holesky）的分叉时间。提议的分叉激活时间如下：

· Goerli - 2024 年 1 月 17 日 - 纪元 231680 – 时间戳 1705473120

· Sepolia - 2024 年 1 月 30 日 - 纪元 132608 - 时间戳 1706655072

· Holesky - 2024 年 2 月 7 日 - 纪元 29696 – 时间戳 1707305664

Lightclient 询问，在 Beiko 提议的 Goerli 硬分叉激活时间上，除了 Prysm 之外的其他客户端团队是否感到满意。电话会议上的所有客户端团队，包括 Geth、Lodestar、Lighthouse、Teku 和 Besu，都确认这个时间对他们来说看起来不错，并且他们将在最迟下周为 Goerli 节点运营商准备好发布。Lighthouse 客户端团队指出，与 Prysm 一样，由于他们仍在测试客户端上的某些网络功能，他们的发布可能是一个预发布。

Dencun 时间表分歧

接着，Lightclient 就 Sepolia 和 Holesky 测试网提议的激活时间向大家开放了讨论。一位化名为「Potuz」的 Prysm 开发人员建议在主网升级之前不要确定最后两个测试网的日期。「我们应该尽量不要现在确定日期，因为可能 Goerli 的情况不太好，而后退是一个问题。添加一个带有正确纪元但没有更改的新版本很容易。删除一个版本并修复错误是一个难题。这要花费多于几周的时间，」Potuz 说。

Lightclient 强调，客户端团队在 Goerli 硬分叉之后一周内不必发布新版本，因此，除非在 1 月 24 日或附近发现了与升级相关的问题，否则可能不必删除版本。Geth 开发人员 Marius van der Wijden 表示，鉴于开发人员随时可以更改它们，他认为在 Sepolia 和 Holesky 测试网上设定日期不会有任何问题，即使 Goerli 出现问题。

以太坊基金会 DevOps 工程师 Barnabas Busa 在 Zoom 聊天中写道，在他看来，确认 Goerli 版本正常运行后，才有意义为 Sepolia 和 Holesky 升级切割新版本。赞同这一观点的 Lighthouse 开发人员，化名「Sean」，表示开发人员可以为 Sepolia 硬分叉设置一个「暂定」日期，但应在确认 Goerli 版本正常运行后再决定是否继续 1 月 30 日的计划。

Potuz 建议在 Goerli 和 Sepolia 硬分叉激活之间增加一周的测试时间，基本上是两周的分析时间，而不是三周。他说，额外的一周测试时间将为客户端发布提供时间，让其在客户端团队需要再次为下一个测试网升级切割新版本之前「浸泡」几天。「两周太紧张了。这是我指出的问题，」Potuz 说，并补充说，如果 Goerli 客户端版本经过充分分析和测试，那么在 Sepolia 和 Holesky 硬分叉激活之间可能不需要三周的周转时间。

Potuz 的观点引起了争议。以太坊基金会的 Ansgar Dietrichs 称升级的第一个公共测试网激活和主网激活之间的时间通常是开发人员不需要延长的「死时间」。然而，Dietrichs 还指出，在测试网升级之间延长时间的愿望是开发人员应该在硬分叉的整体背景下更认真讨论的问题，而不仅仅是在 Dencun 升级中。「如果有延长过程的愿望，那么我们可能应该在有时间的时候进行讨论，而不是在硬分叉之前，」Dietrichs 说。

Lightclient 同意 Dietrichs 的观点，表示如果在例如十月早些时候进行讨论，开发人员可能会更愿意延长 Dencun 测试网的时间。「我认为其中的一部分原因是我们希望在去年秋天发布这个升级，所以现在我们真的在努力实现它，我认为我们制定了一些更为积极的时间表，」Lightclient 说。

坚持积极的时间表

根据开发人员在会议上分享的观点，以太坊基金会 DevOps 工程师 Parithosh Jayanthi 建议将 Sepolia 硬分叉升级推迟一周左右，并在 1 月 25 日的 ACD 会议上为 Sepolia 硬分叉设定一个日期，该日期在 Goerli 升级后。Marius van der Wijden 反对仅仅依赖 ACD 会议重新讨论测试网升级激活日期。「我真的不希望我们必须去另一个 All Core Devs 来确认日期，」他说，并补充说：「我不想再参加另一个 All Core Devs 会议只是为了说，『好的，Sepolia 现在可以进行。』然后我们必须等待两周才能真正进行 Sepolia。」

试图安抚各方，Geth 开发者 Guillaume Ballet 建议为 Sepolia 硬分叉创建两组暂定日期，一组是在 Goerli 硬分叉的结果积极的情况下开发者坚持使用的，另一组是在 Goerli 硬分叉的结果为负的情况下开发者回退使用的。然而，Lightclient 和 Dietrichs 都反对这个想法，因为在开发人员实际上可以为 Sepolia 硬分叉设置新的时间表之前，必须首先评估 Goerli 上的错误和问题的性质。

顺便说一句，以太坊基金会测试团队的一位化名开发者，屏幕名为「Danceratopz」，询问开发者是否希望等待在升级 Sepolia 之前在 Goerli 测试网上评估 blob 到期。背景是，blob 到期是指在大约两周的时间后从以太坊状态中删除 blob 数据。有关 blobs 和 proto-danksharding 的更多信息，请阅读这份 Galaxy Research 报告。

Lighthouse 的 Sean 和 Besu 团队的 Justin Florentine 都支持在三个测试网之一上评估 blob 到期，然后再在主网上激活 Dencun。Florentine 强调，等待测试网上的 blob 到期也将有助于 Layer-2 滚动协议团队和应用开发者为 Dencun 升级做准备。Lighthouse 的 Sean 表示，虽然在 Goerli 上观察 blob 到期并非必要，但这可能是延长 Sepolia 和 Holesky 之间测试期间的一个理由，以便开发人员和 Layer-2 团队可以在 Sepolia 上经历完整的 blob 生命周期。关于 Sean 的建议，其他开发人员在会议上并没有明确的一致意见。

相反，Lightclient 在电话中问开发者是否愿意坚持 Beiko 提出的时间表，即在 1 月 30 日升级 Sepolia，然后在 2 月 7 日的一周后升级 Holesky。由于开发者没有更多的明显反对意见，Lightclient 表示开发者将坚持原定的时间表。Potuz 在 Zoom 聊天中写道，他更喜欢在 2 月 7 日一次性升级 Sepolia 和 Holesky 测试网，而不是提前一周升级前者。在电话结束后的 Discord 消息中，Lightclient 再次确认 Dencun 测试网的时间表目前将保持不变。

Prague/Electra

接下来，开发者讨论了在 Dencun 之后的下一个升级 Prague/Electra 中应该优先考虑哪些 EIPs。Marius van der Wijden 表示，开发者应该把重心放在 Prague/Electra 中交付 Verkle 树升级上，而不是其他 EIPs。他对这一观点提出了两个注意事项，第一个是 Verkle 的准备情况。正如在 ACDE #177 上讨论的那样，开发者计划召开专门的 ACDE 电话会议，深入研究 Verkle 的实施细节以及它是否准备好进行硬分叉升级。

van der Wijden 提到的第二个注意事项是在执行层（EL）和共识层（CL）上升级的解耦能力。van der Wijden 提到，共识层中有一些「高优先级、非常紧急」的 EIPs 可能需要比 EL 上的 Verkle 升级更快地实施。他说：「我认为共识层的人讨论是否有意义对它们进行硬分叉，以及是否可以在没有执行层参与的情况下完成，还是是否需要执行层的参与，我们总归需要进行一个联合硬分叉，那么我同意进行一个较小的硬分叉。因此，高优先级肯定是 Verkle，我们应该在这两个注意事项的基础上推动它。」

以太坊基金会研究员 Ansgar Dietrichs 在 Zoom 聊天中写道，他「强烈反对」将重点放在 Prague/Electra 升级的 Verkle 上，因为这可能意味着由于 Verkle 所需的代码变更的复杂性，升级将延迟到 2025 年。Nethermind 客户端的开发者 Lukasz Rozmej 也同意 Dietrichs 的观点。「我的经验告诉我，状态重设计非常困难，需要非常长的时间，」Rozmej 说道，他补充说：「虽然我认为 Verkle 很棒，而且它正在取得很大的进展，但我认为如果我们只专注于 Verkle，至少需要一年才能进行下一个硬分叉，甚至更久。因此，我的建议是可能专注于一些较小的硬分叉，而每个团队都将承诺 Verkle 并分配适当的资源，工作力量，智力，无论您想如何称呼它，用于这个主题。」

聚焦 Verkle

开发者对于 Prague/Electra 是否应专注于 Verkle 还是优先考虑较小的代码更改，这些更改可以比 Verkle 更快地发布，存在分歧。Ballet 强调，在他看来，「小分叉」这种说法是不存在的，开发人员在实施 Verkle 之前等待的时间越长，实施以太坊状态更新就越困难。同样是 Nethermind 客户端的开发者 Tomasz K. Stańczak 建议采取雄心勃勃的方法，承诺包含在 Prague/Electra 中可能比实际能够包含的更多 EIPs。「利用团队的能力和我们必须展示我们处理最大挑战的一年。如果到三月份，Verkle 向团队显示出越来越多的困难，那么也许人们会再次质疑并说，『好吧，放弃 Verkle 吧。』但然后我们将拥有一套相当不错的其他 EIPs，我们将包含在其中，」Stańczak 说道，具体指出了除 Verkle 之外可以包含在 Prague/Electra 中的其他一些重要 EIPs，如与质押、再质押和账户抽象相关的 EIPs。

对于 Stańczak 的回应，Lightclient 表示，在承诺了一组 EIPs 之后，开发人员继续讨论应该包含在 Prague/Electra 中的 EIPs 可能会很困难，其中之一，指的是 Verkle，是「一个 18 到 24 个月的项目。」Erigon 客户端的开发者 Andrew Ashikhmin 支持在 Prague/Electra 分叉中发布较小的 EIPs，并在之后的未来分叉中并行进行 Verkle 的工作。Ballet 支持 Stańczak 的提议，将 Prague/Electra 的重点放在 Verkle 上，并在其实施中发现需要更多时间解决的重大问题时将其从升级中剔除。

专注于仅 CL 的升级

在 EL 和 CL 升级脱钩的话题上，Potuz 提到，Prague/Electra 只提出了一个 EIP，它仅需要对 CL 进行更改。「唯一的变化 纯粹是 CL 的是删除 attestation index committee。而所有其他的变化，即使那些看起来只是 CL 的变化，比如 Max EB，它们都依赖于其他来自 EL 的变化。所以，我认为纯粹的 CL 分叉是不会发生的。至少，我看不到它们在今年和明年会发生。我们没有足够的纯粹 CL 的提案，」Potuz 说道。

尽管如此，Ansgar Dietrichs 表示，有一些主要是 CL 专注的 EIPs，它们对 EL 需要进行轻微的更改，这些更改可以由 EL 客户端团队轻松执行。这些 EIPs 仍然需要在 EL 和 CL 之间进行协调的硬分叉。然后，Dietrichs 补充说，在他看来，从 CL 方面来看，数据可用性抽样（DAS）是 EIP 4844 之后要发布的最重要的代码更改。Dietrichs 和 Lightclient 对于 DAS 是否需要硬分叉来实施存在一些分歧。

关注 EOF 等 EIP

一位网名为「Rodiazet」的匿名开发人员在以太坊基金会 Ipsilon 团队工作，该团队致力于研究以太坊虚拟机（EVM），他赞成在布拉格/Electra 实施 EOF。作为背景，EOF（代表 EVM 对象格式）是对 EVM 的一系列改进，最初考虑包含在 Cancun/Deneb 升级中。请参阅之前的ACDE#158以了解有关 EOF 的更多信息。

在通话中，除了 Verkle 之外，开发者们提出了一些其他值得考虑的 EIPs，比如 EIP 5920（PAY 操作码）和 EIP 2537（BLS12-381 曲线操作的预编译）。Prague/Electra 的 EIP 候选列表可以在以太坊魔法师网站的升级元线程中找到。尽管大多数开发者支持在 Cancun/Deneb 之后以某种方式优先考虑 Verkle，但目前尚不清楚在 Prague/Electra 中应该在多大程度上优先考虑 Verkle，而不是在 2024 年更快、更容易实施的较小 EIPs。Lightclient 强调，在本周的通话中，开发者们不需要就 Prague/Electra 的内容达成最终决定。他建议在即将举行的 ACD 通话中继续讨论这个话题。

开发者们随后迅速涉及了 Prague/Electra Meta Thread 上尚未在通话中讨论的 EIPs，包括但不限于以下 EIPs：

· EIP-7002：执行层可触发退出

· EIP-7549：将委员会索引移至认证之外

· EIP-3074：AUTH 和 AUTHCALL 操作码

· EIP-6110：在链上提供验证者存款

· EIP-6913：SETCODE 指令

· EIP-7377：迁移事务

· EIP-4444：执行客户端中的绑定历史数据

· EIP-6404：SSZ 交易 Root 6

· EIP-6465：SSZ 提款 Root 4

· EIP-6466：SSZ 收据 Root 4

· EIP-7212：预编译 secp256r1 曲线支持

有关上述 EIPs 的详细概述，请参阅在YouTube上发布的完整通话录音。

正式化 EIP 7587

最后，以太坊基金会研究员 Carl Beekhuizen 重新提起了有关 EIP 7587 的讨论，该 EIP 将为 Layer-2 协议保留一组预编译地址。关于 EIP 7587 的背景，请参阅先前的通话记录。Beekhuizen 询问开发者如何最好地将这个 EIP 正式化为一个信息性的 EIP，为未来以太坊治理流程创建一个规范。Nethermind 开发者 Ahmad Bitar 建议将该 EIP 包含在 EIP 1 文档中，该文档概述了 EIP 过程的指导方针。Lightclient 建议在以太坊魔法师网站上进一步讨论这个话题，并在下一次 ACD 通话中根据需要重新讨论这个话题。