以太坊开发人员最终确定了即将进行的网络升级的时间表。重大变化定于2月24日，3月5日和4月8日进行。在最近的所有核心开发人员处决（ACDE）呼叫205年2月13日举行的所有核心开发商执行期间，关键决定已完成。
每两周的缩放会议 讨论由以太坊基金会（EF）协议支持蒂姆·贝科（Tim Beiko）领导。开发人员确认，Pectra升级将在2月24日在Holesky Testnet上激活。之后，Sepolia Testnet将于3月5日上升。
如果两种推出都顺利进行，以太坊的主网将在4月8日左右进行升级。
贝科说，他将与团队协调，以寻找一名志愿者，以在两个测试网络上部署Pectra系统合同。
关于未来以太坊叉和升级速度的辩论
此外，开发人员团队还讨论了Pectra和Fusaka之后的下一个计划升级。贝科 建议的佩克拉（Pectra）在主网上发射时，冻结了富萨卡（Fusaka）的范围。
时间表使开发人员可以开始在Fusaka上工作，同时还计划随后的Hardfork Glamsterdam。
Geth开发团队不想与此时间表合作。他们认为，巩固福萨卡的范围还为时过早。 Fusaka中纳入以太坊改进建议（EIP）EOF引发了很多争论。开发人员的一个派别主张将其排除在即将进行的升级之外。
EOF（以太坊对象格式）是 upgrade 旨在改善在以太坊区块链上结构和执行智能合约的方式。
Geth Developer Lightclient反对加速Fusaka范围冻结。开发人员认为，以太坊的优先事项可能会在未来两年内发生变化。他指出，尽管开发人员的目标是六个月的升级周期，但现实世界中的延误可能会将其扩展到八个月或更长时间。这意味着多年来可能无法实施重要的改进。
Lightclient引起了人们对EOF合并的担忧，突出了以太坊的零知识汇总技术（ZKEVMS）的快速进步。关于这些变化与虚拟机的相互作用，开发人员仍然处于黑暗状态。
在讨论期间，Geth开发人员Marius van der Wijden列出了他对Fusaka的首选范围，其中包括Peerdas，focil，eof和Modexp上限。 EF开发人员运营工程师Parithosh Jayanthi向后推，指出Focil并没有像Peerdas和Eof那样准备实施。
Pectra软件TestNet升级和社区反馈
开发人员超越了他们对fusaka的分歧，以表达对正在进行的人的信心 Pectra部署.EF开发和运营工程师Parithosh Jayanthi报告说，Pectra Devnet 6的性能良好，近乎完美的验证者参与率。
此外，以太坊的Ephemery Testnet在ACDE呼叫几个小时后激活了Pectra升级，从而使开发人员可以进行进一步的测试。
Beiko要求Pectra EIP作者将他们的建议转移到“最后一个电话”阶段 Girub.这标志着主网实施之前的最后一步。他还研究了以太坊社区的反馈。为此，他指出，最常见的要求是加速升级周期。
作为回应，他建议以太坊开发人员应旨在在上一个升级后立即最终确定每次升级的范围。
贝科的建议的最终确定Fusaka范围的时间表指出，到3月13日，开发人员必须提议将EIPS纳入升级。两周后的3月27日，客户团队将分享他们在Fusaka的EIPS上的偏好。最后，到4月10日，升级范围将完成。
但是，EF研究人员Ansgar Dietrichs为时间安排添加了例外。他指出，Peerdas代码改进是Pectra升级的关键组成部分，应在完成后立即将其上传到以太坊主网。没有人反对这一要求。
对鳗鱼和EIP测试标准的担忧
ACDE呼叫期间的另一个关注点是EF测试工程师Mario Vega的提议。这是关于以太坊执行层测试框架的。 Vega建议对硬叉中包含的任何EIP强制进行EEL（以太坊执行层规格）和EEST（以太坊执行规范测试用例）。
他建议这将改善测试工作流程，并在采用之前如何评估EIP。
但是，一些开发商反对该提议。原因？要求可能会减慢升级过程。范德维登（Van der Wijden）认为，鳗鱼维护者可能会成为EIP包容性的事实上的守门人。为什么？并非所有开发人员都能够编写基于Python的建议的实现。
Wijden提出了另一种方法。 ETH应该有 鳗鱼实现可以将其作为未合并的拉请请求提交。这样可以防止鳗鱼团队对升级具有最终认可的能力。
贾斯汀·佛罗伦萨与Ethereum客户besu建议社区考虑创建额外的脚本语言。这将阐明如果没有鳗鱼或Eest测试用例，是否可以包括EIP。
加密大都会学院：免费的Web3简历备忘单 - 立即下载
标签:
