#152 以太坊核心开发者会议记录

前言：

看过ECN每周更新的“以太坊7天谈”的朋友可能会发现，“7天谈”已经停播近一个月了。 除了前段时间因为编辑感染新冠病毒而无法持续更新，ECN也在考虑是否要继续编辑《七日谈》。 新的一年，ECN计划对内容运营进行一些调整，其中就包括“七日谈”。

以太坊核心开发者会议笔记汇编一直是“七日谈”的重要内容，现决定独立更新。

如果您希望我们持续更新往期“七日谈”的内容，欢迎在各种社交媒体上私信我们。 我们非常愿意听取您的反馈，以提高我们内容的质量。

在第 152 届 ACDE 上，开发人员同意从上海升级中删除与 EOF 实施相关的代码更改。 关于EOF的更多信息，可以阅读《以太坊核心开发者会议更新014⛓》。 他们还同意不再接受任何添加到上海升级中的 EIP，主要是为了确保提取质押 ETH 的时间表不会延迟。 作为此次上海升级的唯一大规模代码修改，提现质押的ETH目前正在以开发者为中心的测试网上进行测试。 开发商的目标是在下个月（2023 年 2 月）为 Shanghai/Capella 升级启动公共测试网，然后在 3 月启动主网。 随后，开发人员讨论了更详细的 EVM 升级注意事项、以太坊执行层/共识层之间的不同序列化方法，以及引入 Poseidon 哈希函数作为 EVM 的预编译 EIP。

以下是详细的注释

上海升级的进展

上海升级方面，第一个开发者测试网已经在圣诞节前上线，所有客户端组合都在上面运行。 您可以查看以太坊基金会的 devops 仪表板。 某些客户端组合存在问题，但开发人员将尽快启动新的开发测试网。

()

此外，Geth 团队的 [emailprotected] 对 EIP 3860 提出了一个小的设计修改（限制 initcode 大小并引入 gas 计量）——纠正了该 EIP 中一个令人困惑的错误模式，即违反 initcode 限制导致零地址错误而不是 OOG（out气体）错误。 开发人员同意将错误模式更改为 OOG 错误然后终止或中止执行而不是返回零地址的提议将减少客户端实现中的混乱和错误。 以上是客户团队的意见。 如果智能合约开发者强烈反对此次修改，则不得修改。

EOF相关EIP在上海被移除升级

接下来，会议主要讨论了EOF相关的话题。

Geth 团队的开发人员@lightclients 向您介绍了 12 月 EOF 小组会议的最新情况。 （EOF即EVM Object Format，会对以太坊的代码环境引入一些改变，与之相关的EIP会更清晰地区分智能合约的代码和数据，让EVM在未来更容易升级。） , 该规范最终确定有两个小改动：删除 JUMPF 并强制数据 EOF 合同包含数据部分。

在测试方面，来自 Geth 团队的@mhswende 已经开始对实施进行模糊测试，查找错误并在所有客户端上修复它们。 目前的fuzz测试主要针对EOF容器/结构在客户端的实现，不包括部署的EOF代码。 以太坊基金会测试团队的 Mario[emailprotected] 补充说，由于 EOF 的复杂性，可能很难为错误用例编写静态测试用例，因为实现可能会在遇到确切的测试用例之前遇到另一个错误。

在客户端，Geth 和 Besu 有完整的实现并通过了大部分测试。 Nethermind 也有一个实现，但不确定最好使用哪个测试套件。 而 Erigon 将使用 Geth 的 EOF 实现。

基于EOF的实现和测试，Vitalik也表达了对仓促实现EOF的担忧，并发表了一份EOF提案：disable code introspection for EOF accounts：

Vitalik 在会上解释了这个提议背后的想法，并解释了为什么修改 EVM 通常比修改其他协议更困难。 他指出，从以太坊中删除工作量证明比弃用操作码更容易。 这是因为以太坊应用程序/合约依赖于 EVM 的特定行为，因此修改必须向后兼容，否则它们将破坏已部署的合约。 对协议其他方面的更改只需要每个人在特定时间更新，否则不会破坏网络上的任何东西。

这意味着当我们改进 EVM 或引入新版本（如 EOF）时，我们很可能需要永远使用它们，因为我们不能弃用以前的版本。 理想情况下，我们希望 EVM 更干净/简单，但如果我们只能向其中添加内容而从不删除内容，那将很难做到。 删除内容的最大挑战之一是 EVM 中的代码自省。

因此以太坊官网中文，Vitalik 的提议是在 EOF v1 中增加更多的内容，这将极大地限制 EOF 合约中的代码自省，从而潜在地使其在未来更容易升级。 Ipsilon 团队的@alexberegszaszi 提到，EOF 提案的作者之前其实也考虑过类似的特性，最终决定放弃，因为他们想让 EOF v1 保持简单。 他还提出了一个替代方案，将 Vitalik 的提议合并到 EOF v2 中：

然而以太坊官网中文，随着这个向 EOF v1 添加内容的提议，客户团队担心整体修订会太大。 @lightclients也表示，根据目前EOF测试的进度，可能会延迟一个月左右将其纳入上海升级。 如果要在2月初启动主网测试网升级，EOF部分应该还没准备好。 此外，这是一个重要的决定，因为对 EVM 的更改一旦部署就无法修改。

经过讨论，开发者最终决定花更多的时间思考EOF问题，所以在上海升级中去掉了，但是EOF方面的工作会保留。 他们应该能够在坎昆升级中部署一些带有 4844 的 EOF 版本。 在这次会议上，开发商没有对坎昆升级做出正式决定，将在下次会议上讨论。

上海升级是否需要补充其他EIP？ 开发者经过讨论，决定不再添加其他EIP，以免耽误上海升级。

其他EIP的讨论

随后，开发者还讨论了Nimbus团队的Etan Kissling的提议：在ExecutionPayloadHeader的交易链表中增加一个十六进制树根。

简单来说，执行层的区块头和共识层的执行负载头（ExecutionPayloadHeader）之间使用了不同序列化格式编码的字段。 这两个字段的不同编码格式给钱包和以太坊轻客户端的构建带来了额外的开销和复杂性。 Kissling 提出将 CL 的 SSZ 序列化格式添加到执行层，或者共识层客户端以各种方式支持执行层的 RLP 序列化格式。 这个提议关系到上海升级中的退出，所以比较紧急。 这个问题将在 1 月 12 日这周的共识层会议 (ACDC) 上再次讨论。

会议最后讨论了 EIP-5843（EVM 模块化的算术扩展）和 EIP-5988（添加 Poseidon 哈希函数预编译）。 由于 EIP-5843 的作者无法出席，开发人员同意稍后讨论此 EIP。 5988 由 StarkWare 提出，旨在提高以太坊网络上运行零知识证明的效率。 但这可能会对以太坊的安全产生未知的后果。