以太坊ACDE通话205：2月24日、3月5日和4月8日即将进行的主要以太坊升级

以太坊开发者已确定即将进行的网络升级时间表。主要变更将于2月24日、3月5日和4月8日进行。关键决定在最近举行的2025年2月13日全核心开发者执行（ACDE）通话205中最终确定。

每两周一次的Zoom会议 讨论 由以太坊基金会（EF）协议支持主管Tim Beiko领导。开发者确认Pectra升级将于2月24日在Holesky测试网上激活。随后，Sepolia测试网将于3月5日上线。

如果两个测试网升级都顺利进行，以太坊主网将在4月8日左右完成升级。 

Beiko表示，他将与团队协调，寻找在两个测试网上部署Pectra系统合约的志愿者。

关于未来以太坊分叉和升级速度的争论

此外，开发团队讨论了Pectra和Fusaka之后的下一次计划升级。Beiko 提议 在Pectra在主网上线时冻结Fusaka的范围。

这一时间表允许开发人员在开始Fusaka工作的同时，也为随后的硬分叉Glamsterdam进行规划。 

Geth开发团队不希望遵循这一时间表。他们认为过早确定Fusaka的范围为时过早。将以太坊改进提案（EIP）EOF纳入Fusaka引发了相当大的争议。一部分开发人员主张将其排除在即将到来的升级之外。

EOF（以太坊对象格式）是一种 升级 旨在改善以太坊区块链上智能合约的结构和执行方式。

Geth开发人员Lightclient反对加快Fusaka范围冻结的速度。该开发人员认为，以太坊的优先事项可能会在未来两年内发生变化。他指出，虽然开发人员旨在实现六个月的升级周期，但现实世界的延迟可能会将其延长至八个月或更长时间。 这意味着重要的改进可能需要数年才能实施。 

Lightclient对纳入EOF表示担忧，并强调了以太坊零知识滚动技术（zkEVMs）的快速进展。开发人员对这些更改与虚拟机之间的相互作用仍不清楚。

在讨论过程中，Geth开发人员Marius van der Wijden列出了他偏好的Fusaka范围，包括PeerDAS、FOCIL、EOF以及modexp的上限。EF开发人员运营工程师Parithosh Jayanthi表示反对，称FOCIL的实施准备程度不如PeerDAS和EOF。

Pectra软件测试网升级和社区反馈

开发人员超越了他们对Fusaka的分歧，表达了对正在进行的 Pectra部署. 的信心。EF开发和运营工程师Parithosh Jayanthi报告称，Pectra Devnet 6运行良好，验证者参与率接近完美。 

此外，以太坊的Ephemery测试网在ACDE电话会议结束后几小时激活了Pectra升级，允许开发人员进一步进行测试。

Beiko要求Pectra EIP作者将他们的提案移至 GitHub. 上的“最后召集”阶段。这标志着主网实施前的最后步骤。他还研究了以太坊社区的反馈。为此，他指出，最常见的要求是加快升级周期。 

对此，他建议以太坊开发人员应争取在每次升级在主网上线后立即确定其范围。

Beiko的提议完成Fusaka范围的时间表指出，到3月13日，开发者必须提出包含在升级中的EIP。两周后，在3月27日，客户端团队将分享他们希望考虑哪些EIP用于Fusaka。最后，到4月10日，升级的范围将最终确定。

然而，EF研究员Ansgar Dietrichs对时间提出了例外。他指出，PeerDAS代码改进是Pectra升级的关键组成部分，应尽快上传到以太坊主网。没有人反对这一要求。

对EELS和EIP测试标准的担忧

ACDE电话会议期间的另一个关注点是EF测试工程师Mario Vega提出的提案。这与以太坊执行层测试框架有关。Vega建议将EELS（以太坊执行层规范）和EEST（以太坊执行规范测试用例）作为任何包含在硬分叉中的EIP的强制性要求。 

他认为这将改善测试工作流程，并标准化EIP在采用前的评估方式。

然而，几位开发人员反对该提案。原因是什么？该要求可能会减缓升级过程。Van der Wijden认为，EELS维护者可能会成为EIP纳入的事实上的守门人。为什么？并非所有开发人员都能编写基于Python的提案实现。 

Wijden建议采取另一种方法。ETH应该拥有 EELS实现 可以作为未合并的拉取请求提交。这防止了EELS团队对升级拥有最终批准权。

Justin Florentine与 以太坊 客户端Besu建议社区考虑创建额外的脚本语言。这将澄清是否可以在没有EELS或EEST测试用例的情况下包含EIP。