请为 2024 年 1 月 4 日，以太坊开发人员齐聚 Zoom for All Core Developers Execution (ACDE) Call #178 上。ACDE 电话会议通常由以太坊基金会协议负责人 Tim Beiko 主持，是一个开发人员讨论和协调以太坊执行层（EL）变更的双周系列会议。本周的会议由一位网名为「Lightclient」的匿名 Geth EL 开发人员主持。开发人员再次确认了 Cancun/Deneb（Dencun）升级的接下来三个公共测试网激活日期。他们还讨论了 Dencun 之后的下一个硬分叉升级 Prague/Electra 中代码更改（EIPs）的优先事项。
Dencun 更新
假期期间没有对 Dencun 升级进行具体更新。自 12 月 21 日上次 ACDE 电话会议以来，客户端团队一直在为 Goerli 测试网准备新版本。由于之前因 Prysm 导致升级测试延迟，Geth 开发者 Marius van der Wijden 要求 Prysm 客户端团队提供他们切割新版本的最新进展。Prysm 开发者 Terence Tsao 证实，Prysm 团队将在下周准备好 Goerli 硬分叉的新版本。不过，针对 Goerli 的版本将是一个「预发布」版本，这意味着它不会是推荐在以太坊主网上使用的 Prysm 版本。在 Goerli 硬分叉之后，Prysm 团队计划发布另一个版本，其中包含某些更改和更新，推荐用户在主网上运行，并在 Sepolia 或 Holesky 测试网上进行测试。
虽然 Tsao 表示 Prysm 团队对 Goerli 硬分叉激活日期为 1 月 17 日感到满意，正如 ACDE #177 上讨论的那样，但他建议在 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 询问 Prysm 之外的其他客户端团队是否同意 Beiko 提出的 Goerli 硬分叉激活时间。参加电话会议的所有客户端团队（包括 Geth、Lodestar、Lighthouse、Teku 和 Besu）都确认，他们认为时机不错，最迟下周就能为 Goerli 节点操作员发布版本。Lighthouse 客户端团队指出，鉴于他们仍在测试其客户端的某些网络功能，他们发布的版本可能与 Prysm 一样是预发布版本。
Dencun 时间线分歧
随后，Lightclient 就 Sepolia 和 Holesky 测试网的建议激活时间展开讨论。一位网名为「Potuz」的 Prysm 开发者（化名）建议暂缓确定主网之前最后两个测试网的升级日期。「我们应该尽量不要现在就承诺日期，因为 Goerli 的事情可能并不顺利，从那里返回是个问题。添加一个具有正确纪元的新版本，不做任何改动是很容易的。删除一个版本并修复错误则是个问题。这比几周的时间要长得多，」Potuz 表示。
Lightclient 强调说，客户端团队在 Goerli 硬分叉一周后才需要发布新版本，因此，除非在 1 月 24 日或之后在 Goerli 上发现升级问题，否则不一定要删除新版本。Geth 开发者 Marius van der Wijden 表示，他认为为 Sepolia 和 Holesky 测试网设定日期并没有什么坏处，因为如果 Goerli 上出现问题，开发者可以随时更改日期。
以太坊基金会 DevOps 工程师巴纳巴斯 - 布萨（Barnabas Busa）在 Zoom 聊天室中写道，在他看来，只有在确认 Goerli 的版本正常运行后，才有必要为 Sepolia 和 Holesky 的升级发布新版本。一位网名为「Sean」的 Lighthouse 开发者同意这一观点，他说开发者可以为 Sepolia 硬分叉设定一个「暂定」日期，但在 1 月 30 日之前应该先看看 Goerli 的进展情况。
Potuz 建议在 Goerli 和 Sepolia 硬分叉激活之间增加一周的测试时间，基本上用两周时间进行分析，而不是三周。他说，增加一周的测试时间可以让客户端发行版「浸泡」几天，然后客户端团队才需要为下一次测试网升级再次切割新版本。「两周时间太近了。这就是我要指出的问题。」Potuz 补充说，如果 Goerli 客户端发行版得到了充分的分析和测试，那么在 Sepolia 和 Holesky 硬分叉激活之间可能不需要三周的周转时间。
Potuz 的观点引发了争议。以太坊基金会的安斯加 - 迪特里希斯（Ansgar Dietrichs）称，升级的第一个公共测试网激活与升级的主网激活之间的时间通常是开发者的「截止时间」，不需要延长。不过，Dietrichs 也指出，对于延长测试网升级间隔时间的愿望，开发者应该在硬分叉背景下更认真地讨论，而不仅仅是 Dencun 升级。Dietrichs 说：「如果有人希望有一个更漫长的过程，那么我们应该在有时间的时候讨论这个问题，而不是在硬分叉之前。」
Lightclient 同意 Dietrichs 的观点，认为如果早在 10 月份就进行讨论，开发者很可能会对延长 Dencun 的测试网时间表更加宽容。Lightclient 说：我认为还有一部分原因是，我们想在去年秋天完成升级，所以现在我们真的在努力实现这一目标，我认为我们的时间表安排应该更积极一些。
坚持积极的时间表
根据开发者在电话会议上分享的观点，以太坊基金会 DevOps 工程师 Parithosh Jayanthi 建议将 Sepolia 硬分叉升级推迟一周左右，并将 Sepolia 硬分叉的日期定在 Goerli 升级之后的 1 月 25 日 ACDE 电话会议上。Marius van der Wijden 反对完全依赖 ACDE 电话来重新讨论测试网升级激活的日期。他说：「我真正希望避免的是，我们不得不再打一次 All Core Devs 电话来确认日期，」他补充说：我讨厌再打一次 All Core Devs 电话，只是为了说「好把，Sepolia 现在可以开始了。」而现在我们必须等待两周，才可以真正开始实现 Sepolia。
为了安抚各方的情绪，Geth 开发者 Guillaume Ballet 建议为 Sepolia 硬分叉创建两套暂定日期，如果 Goerli 硬分叉的结果是积极的，开发者可以坚持使用其中一套日期；如果 Goerli 硬分叉的结果是消极的，开发者可以使用另一套日期。然而，Lightclient 和 Dietrichs 都反对这个想法，因为在开发者为 Sepolia 硬分叉设定新的时间表之前，必须先对 Goerli 上的错误和问题的性质进行评估。
顺便说一句，以太坊基金会测试团队的一位网名为「Danceratopz」的化名开发者询问，开发者是否想等评估完 Goerli 测试网络上的 blob 过期问题后再升级 Sepolia。作为背景知识，blob 过期指的是在大约两周后从以太坊状态中删除 blob 数据。
来自 Lighthouse 的 Sean 和 Besu 团队的 Justin Florentine 都赞成在主网激活 Dencun 之前，先在三个测试网之一上评估 blob 到期情况。Florentine 强调说，在测试网上等待 blob 到期也将有利于第二层 Rollup 协议团队和应用开发人员为 Dencun 升级做好准备。来自 Lighthouse 的 Sean 说，虽然在 Goerli 上观察 blob 过期并不是必要的，但这可能是延长 Sepolia 和 Holesky 之间测试期的一个原因，这样开发人员和第二层团队就可以在 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）应优先考虑哪些 EIP。Marius van der Wijden 说，开发人员应集中精力完成 Prague/Electra 的默克尔树升级，而不是其他 EIP。他对这一观点补充了两点注意事项，首先是默克尔树的准备情况。正如在 ACDE #177 上所讨论的，开发人员正计划召开一次专门的 ACDE 电话会议，深入探讨默克尔树的实施细节及其硬分叉升级的准备情况。
Van der Wijden 提到的第二个注意事项是将 EL 上的升级与共识层（CL）解耦的能力。Van der Wijden 提到，CL 上有一些「高优先级、超级紧急」的 EIP，可能需要比 EL 上的默克尔树升级更快地实施。「我认为重要的是，共识层人员要讨论他们是否有必要对这些 [紧急] 变更进行硬分叉，是否可以在没有 EL 参与的情况下完成，或者是否需要 EL 参与，而我们无论如何都需要进行联合硬分叉，然后我可以接受一个较小的硬分叉」。van der Wijden 说：「所以，默克尔树绝对是重中之重，我们应该在考虑到这两点的情况下推动它。」
以太坊基金会研究员安斯加 - 迪特里希斯（Ansgar Dietrichs）在 Zoom 聊天室中写道，他「强烈反对」将 Prague/Electra 升级重点放在默克尔树上，因为考虑到默克尔树所需的代码更改的复杂性，这很可能意味着升级要推迟到 2025 年。Nethermind 客户端开发人员 Lukasz Rozmej 也同意 Dietrichs 的观点。Rozmej 说：「我的经验告诉我，状态的重新设计是非常困难的，而且需要非常长的时间，」他补充说，「虽然我认为默克尔树非常好，而且正在取得巨大进步，但我认为如果我们只关注默克尔，下一次硬分叉至少需要一年甚至更长的时间。因此，我的建议是，可能会专注于一些较小的硬分叉，同时每个团队都会致力于默克尔，并为这个主题分配适当的资源、工作量、脑力，无论你怎么称呼它。」
聚焦默克尔
对于 Prague/Electra 应专注于默克尔还是优先考虑比默克尔更快发布的较小代码变更，开发人员意见不一。Ballet 强调，在他看来，「不存在小分叉」，开发者在实施默克尔之前等待的时间越长，实施以太坊状态更新的难度就越大。Tomasz K. Stańczak 也是 Nethermind 客户端的开发者，他建议采取一种雄心勃勃的方法，承诺采用比 Prague/Electra 可能包含的更多的 EIP。[让我们] 利用团队的能力，在这一年里，我们必须证明我们能够应对最大的挑战。如果默克尔最终向团队表明，到 3 月份有越来越多困难堆积起来，那么人们可能会再次提出疑问，并说「好吧，默克尔下课」。但我们会继续使用我们将包括在内的一套相当不错的其他 EIP，Stańczak 说道，他指定除默克尔之外，Prague/Electr 还可能包括的其他一些重要 EIP，如与质押、重新质押与账户抽象相关的 EIP。
Lightclien 在回答 Stańczak 的问题时说，开发人员在承诺采用一套 EIP 之后，可能很难继续讨论 Prague/Electra 中应该包括哪些 EIP，而其中一个 EIP（指默克尔）是「一个需要 18 到 24 个月的项目」。Erigon 客户端的开发者安德鲁 - 阿西克明（Andrew Ashikhmin）赞成在布 Prague/Electra 分叉中发布较小的 EIP，并同时开发默克尔，以便在之后的分叉中使用。Ballet 赞成 Stańczak 的建议，即在 Prague/Electra 中重点开发默克尔，如果发现其实施过程中存在重大问题，需要更多时间来解决，则将其从升级中删除。
聚焦 CL 升级
关于将 EL (执行层) 和 CL（共识层）升级解耦的问题，Potuz 提到，Prague/Electra 只有一个 EIP 提议只需要对 CL 进行更改。「唯一的变化是取消了认证索引委员会...... 以及所有其他变化，即使是那些看起来只涉及 CL 的变化，如 Max EB，也取决于 EL 的其他变化。因此，我认为纯粹的 CL 分叉是不会发生的。至少，我认为今年不会，明年也不会。我们没有足够的纯 CL 提案，」Potuz 说。
尽管如此，Ansgar Dietrichs 还是说，有些 EIP 主要是以 CL 为中心的升级，只需要对 EL 稍作改动，EL 客户端团队就可以轻松执行。这些 EIP 仍需要 EL 和 CL 协调硬分叉。Dietrichs 随后补充说，他认为从 CL 方面来看，数据可用性采样（DAS）是 EIP 4844 之后最重要的代码变更。Dietrichs 和 Lightclient 就 DAS 是否需要硬分叉来实现存在一些分歧。
关注 EOF 和其他 EIP
一位网名为「Rodiazet」的化名开发者在以太坊基金会的 Ipsilon 团队工作，该团队致力于以太坊虚拟机（EVM）的研究。作为背景，EOF 是 EVM Object Format 的缩写，是对 EVM 的一系列改进，最初被考虑纳入 Cancun/Deneb 升级中。
除默克尔外，开发人员还提出一些其他 EIP 供考虑，如 EIP 5920（PAY 操作码）和 EIP 2537（BLS12-381 曲线操作的预编译）。Prague/Electra 候选 EIP 的完整列表可以在以太坊魔术师网站上的升级元线程中找到。虽然大多数开发者都赞成在 Cancun/Deneb 会议之后在某种程度上优先考虑默克尔，但目前还不清楚在多大程度上默克尔应被优先用于 Prague/Electra，而不是那些在 2024 年可以更快、更容易实现的小型 EIP。Lightclient 强调，开发者无需在本周的电话会议上就 Prague/Electra 的内容做出最终决定。他建议在即将举行的 ACDE 电话会议上继续讨论该主题。
随后，开发人员很快谈到了 Prague/Electra 主题中尚未在通话中讨论的 EIP，包括但不限于以下 EIP：
EIP-7002：执行层可触发退出
EIP-7549：将委员会索引移至认证之外
EIP-3074：AUTH 和 AUTHCALL 操作码
EIP-6110: 在链上提供验证器存款
EIP-6913: SETCODE 指令
EIP-7377: 迁移事务
EIP-4444：执行客户端中的绑定历史数据
EIP-6404：SSZ 交易根
EIP-6465：SSZ 提取根
EIP-6466：SSZ 收据根
EIP-7212：预编译 secp256r1 的曲线支持
有关对上述 EIP 的看法的详细概述，请参阅 YouTube 上发布的完整通话录音。
正式确定 EIP 7587
最后，以太坊基金会研究员 Carl Beekhuizen 重提了有关 EIP 7587 的讨论，该讨论将保留一组预编译地址，供第二层协议使用。Beekhuizen 询问开发人员如何才能最好地将 EIP 正式化，使其成为一个信息性的 EIP，为今后的以太坊治理流程创建规范。Nethermind 开发者 Ahmad Bitar 建议将 EIP 纳入 EIP 1 文件，该文件概述了 EIP 流程的指导方针。Lightclient 建议在以太坊魔术师网站上进一步讨论这个话题，并在下一次 ACDE 电话会议上根据需要重新讨论这个话题。
