2023年初以太网核心开发者大会： EOF延期暂定于3月进行上海升级

1月5日，以太网开发者们休息了两周后，召开了2023年初的全核心开发者(ACD )电话会议。 从2023年开始，ACD电话会议将改为ACD执行(ACDE )电话会议

反映开发者对以太坊执行层变化的关注。 他们还在@EthereumProtocol YouTube频道进行直播，而不是在@EthereumFoundation YouTube频道进行直播。 ACDE电话会议是由以太坊基金会的Tim Beiko主办的，是以太坊开发者讨论和协调以太坊合同变更的两个会议系列之一，也是另一个会议系列

，开发者更名为ACD共识(ACDC )电话会议，重点讨论了以太坊共识层开发的相关主题。 在第152届全核心开发者执行(ACDE )电话会议上

开发者同意从上海的升级中删除与实施EOF相关的代码变更。 有关EOF的详细信息，请在此阅读以前的电话会议记录。 他们还同意拒绝将新的EIP添加到上海进行升级，这主要是为了避免质押ETH提款的时间表延误。 作为上海升级唯一主要的代码更改，质押ETH提款功能目前正在开发者测试网上进行测试。 听说开发者们的目标是下个月推出上海/Capella升级公共测试网，在2023年3月的某个时间点开始主网络的升级。 随后，开发者们简要讨论了以太网执行层和共识层之间不同序列化方法的问题

、以及引入Poseidon散列函数作为EVM预编译的新EIP。 上海升级计划

以太坊基金会的DevOps工程师Barnabus Busa更新了当铺ETH提款测试的状态。 他说，圣诞节前推出的上海开发者测试网，目前已进展到000个街区。 目前

，所有EL和CL客户端组合都在此测试网络上运行，其中某些客户端组合(如Teku-Erigon和Lighthouse-Erigon )存在问题。 Busa说

，开发人员们在客户端团队的帮助下，努力尽快启动新的开发人员测试网络。 然后呢

，以太网foundationgeth (EL )客户端的软件开发者Marius van der Wijden为上海升级的小EIP之一(EIP 3860 )提出了小的设计变更。 提议的更改将修复此EIP的混乱失败模式，如果违反initcode限制，则会出现零地址错误，而不是OOG错误。 据以太坊基金会的Ipsilon团队开发者Pawel Bylica称

这样做的最初动机是为了促进用户的友好性。 然而，开发人员认为，将失败模式更改为OOG错误可以减少客户端实现中的混乱和漏洞。 推迟EOF，将其排除在上海升级之外，然后

以太网财团的Geth(El )客户端软件开发者(别名“lightclient”)介绍了实现EOF的最新进展。 作为背景，EOF表示EVM对象格式

，对以太体的代码执行环境进行了一些更改。 在其他变化中，与实施EOF相关的EIP将改进以太网交易格式，更清晰地区分智能联系代码和数据，并帮助EVM将来更容易升级。 据lightclient称，假期中，致力于实现EOF的开发者们举行了两次会议，讨论了相关的EIP规范。 在这些会议期间，开发者们同意删除其中一个eip(eip6206 )，由于其复杂性)，通过强制这些EIP的数据部分而不是选项来稍微提高数据分析的简单性。 据lightclient称，EOF EIP的测试也在进行中

。 虽然EOF EIP参考测试尚未正式发布，但以太网基金会的安全主管Martin Holst Swende已经开始了EOF各种客户端实现的差异测试(也称为差异模糊测试)。

“为EOF创建最有效的[测试]案例并不容易。 问题是有很多陷阱。 例如，如果希望某事以某种方式失败，在EOF中，必须非常具体，在达到实际想测试的内容之前

测试在其他地方不会失败。 所以，如果我们以某种方式集中失误，我认为这非常有价值，”以太坊基金会测试团队的Mario Vega说。 基于EOF实现和测试的现状

，Tim Beiko提出了开发者们是否还可以在下一次(上海)以太网升级中包括这些EIP的问题。 在这个话题上以太网的联合创始人Vitalik Buterin表达了对仓促引入EOF的担忧。 因为目前还没有明确的路线图来避免未来EVM升级变得更加繁琐，以太网的技术债务也不会增加

。 Vitalik先生说。 “在EVM中，删除某些内容比删除其他功能要困难得多。 有用EVM代码写的APP应用程序。 如果EVM已更改

那么，这些APP应用程序就不能更改……我最大的担忧之一是改善EVM。 特别是因为很难舍弃或实际删除某些东西。 EVM开发的哲学并不是马上致力于真正不变的东西，而是基本上允许很多持续的改善

中选择所需的族。 [EVM] V2存在创建V2、V3、V4的风险，但需要V1、V2、V3作为共识代码的一部分。 这是因为没有删除这些的好方法。 ”对此

，Erigon(El )客户团队的Andrew Ashikhmin表示，如果开发者将EOF的实施推迟到“完美”，他们也担心失去测试实施的动力和机会

无法获得有关建议的代码更改的实际反馈。 Ashikhmin在电话会议上说：“如果我们想要完善它，它就像是一个永远不会结束的超级项目”。

为了应对围绕实施EOF的持续不确定性，以太网基金会研究员Ansgar Dietrichs建议开发者们将相关的EIP撤出上海

，在未来几周内积极解决这些问题，致力于EVM升级的前进道路。 Van der Wijden表示，从他的观点来看，试图在本周的电话会议上决定实施EOF似乎有点仓促，他说：“我认为现在对EOF作出决定有点压力。 我不认为这是件好事。 ”。 对此，lightclient基于假期EOF测试的进展，承认如果纳入上海升级，整个升级将推迟约一个月

。 我想lightclient在电话会议上试图在：月初升级主网络测试网络的话，到那时就准备好不了。 ”。 在开发者们同意将EOF的实施排除在上海升级之外后

，Beiko建议再等两周，然后再决定是否将EOF纳入上海以后的Cancun升级。 在上次的电话会议上，开发者们同意将Cancun的升级集中在EIP4844(proto-Danksharding )上，如果从Beiko的立场来看EOF再次被拒绝那么快在Cancun中包含EOF就有可能导致混乱。 Lightclient反对这一想法，声称如果开发者们不承诺通过Cancun这样的升级来实施EOF，实施工作将被推迟这进一步削弱了EOF的势头。 Beiko回答说，在两周后的下一次ACDE电话会议上重新讨论何时包括引进EOF应该不会对EOF的势头产生大的影响

。 查看此处和此处了解有关EOF部署和EVM升级发展方向的各种核心开发人员建议的详细信息。 随着EOF被排除在上海升级之外

，Marius van der Wijden暂时提出将EIP 1153纳入上海升级，但参加电话会议的几位开发者强烈反对在上海升级中添加新的EIP，减少了延迟质押ETH的提款风险

。 此后，开发商们重申了他们的承诺。 也就是说，我试图以2月初为目标启动上海公共测试网。 是RLP还是SSZ？

开发者们还讨论了EtherEumnimbus(cl )客户端团队的开发者Etan Kissling的提案。 Kissling在以前的ACDC电话会议上分享了这个提案

中选择所需的族。 简单来说，在EL块标题和CL执行负荷标题之间有两个以不同序列化格式编码的字段。 由于这两个字段的编码方式不同，因此构建wallet和以太网轻型客户端会产生额外的开销和复杂性。 Kissling提出的解决方案之一是在EL中添加一种在CL (称为SSZ )中使用的新序列化格式。 或者，CL客户端可以结合几种方法来支持在EL中称为RLP的代码。 但是，这并不理想因为SSZ格式是对结构化数据进行编码的更现代、更新的序列化格式。 在所有情况下，EL或CL方为了确保数据格式的一致性而进行的更改，因为相关的编码数据字段与质押ETH的提款相关

需要以太坊的客户团队做额外的工作。 Andrew Ashikhmin强调，围绕这个问题的决定是“紧急的”，因为这会导致上海的升级。

为了让客户团队有更多时间考虑Kissling提出的解决方案之间的权衡，Beiko建议开发者在下周的ACDC电话会议上重新讨论这个话题

，在1月19日的下一次ACDE电话会议上决定了应该怎么做。 下周四(1月12日)的ACDC电话会议议题就在这里。 EIP 5843和EIP 5988最后一次

开发者们简单讨论了两个新的EIP。 EIP 5843在以太网VM中引入了高效的模块化加法、减法和乘法，这是以太网基础架构软件开发商Jared Wasinger提出的一种EIP

。 但是，Jared没有出席这周的电话会议。 因此，开发者们同意在未来的某一天重新讨论EIP。 之后

StarkWare的搜索负责人Abdelhmaid Bakhta介绍了EIP 5988，在以太网上引入了新的预编译，提高了在网络上执行零知识证明的效率。 “基本上每次尝试证明存储证书(如Merkle证书)，对以太网来说都非常昂贵。 因为没有ZK友好的散列函数，”Bakhta解释说。 关于此EIP，以太网基金会的研究人员Dankrad Feist认为将任何类型的算术散列函数纳入协议还为时尚早，因为这可能对以太网的安全产生未知的影响。

相关内容

标签： 升级中 代码更改 上海升级