请为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电话会议上根据需要重新讨论这个话题。