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 提款测试的状态。 他表示，在圣诞节前推出的上海开发者测试网络，当前已进展到 4,000 个区块。 目前，所有 EL 和 CL 客户端组合都在该测试网上运行，其中 Teku-Erigon 和 Lighthouse-Erigon 等一些客户端组合遇到了问题。 Busa 提到，开发者们正努力在客户端团队的帮助下尽快启动一个新的开发者测试网。
然后，以太坊基金会 Geth (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（EIP 6206，因为它的复杂性），并使这些 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 代码编写的应用程序，如果 EVM 发生了变化，那么这些应用就无法更改 …我最大的担忧之一是对 EVM 的改进，特别是因为它很难弃用和实际删除一些东西，EVM 开发的哲学允许基本上大量的持续改进，而不是很快地致力于真正接近于不会更改的东西，这会让我们冒着创建一个 [EVM] 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 在电话会议上提到说:“如果我们试图在 2 月初进行主网测试网升级，我认为到那时我们无法准备好。”
在开发者们同意将 EOF 实施排除在上海升级之外后，Beiko 提议再等两周，然后再决定是否应将 EOF 包括在上海之后的 Cancun 升级中。 在之前的电话会议中，开发们同意将 Cancun 升级集中在 EIP 4844（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 ？
开发者们还讨论了 Ethereum Nimbus (CL) 客户端团队开发者 Etan Kissling 的提议。Kissling 在之前的 ACDC 电话会议上分享了这个提案，总结如下：简而言之，在 EL 区块头和 CL 执行负载头之间有两个使用不同序列化格式编码的字段。由于这两个字段的编码方式不同，因此会为构建钱包和以太坊轻客户端带来额外的开销和复杂性。Kissling 提出的解决方案之一，是向 EL 添加一种在 CL 中使用的新序列化格式（称为 SSZ）。或者，CL 客户端可以合并一些方法，以支持 EL 中称为RLP 的代码。然而，这并不理想，因为 SSZ 格式是编码结构化数据的更现代和更新的序列化格式。在任何一种情况下，所涉及的编码数据字段都与质押 ETH 提款相关，因此，EL 或 CL 端为确保数据格式一致性而进行的任何更改，都需要以太坊客户团队进行额外的工作。Andrew Ashikhmin 强调，围绕这个问题做出的决定是“紧急的”，因为它关系到了上海升级。
为了让客户端团队有更多的时间来考虑 Kissling 提出的解决方案之间的权衡，Beiko 建议开发人员在下周的 ACDC 电话会议上重新讨论这一话题，并在 1 月 19 日的下一次 ACDE 电话会议上决定该怎么做。下周四 （1月12日）ACDC 电话会议的议程可在这里找到。
EIP 5843 和 EIP 5988
最后，开发者们简要讨论了两个新的 EIP。 EIP 5843 向以太坊虚拟机 (EVM) 引入了高效的模块化加法、减法和乘法，它是由以太坊基金会软件开发者 Jared Wasinger 提出的 EIP。然而，Jared 并没有出席本周的电话会议，这就是为什么开发者们同意在未来某个日期重新讨论该 EIP 的原因。
随后，StarkWare 的探索主管 Abdelhmaid Bakhta 介绍了 EIP 5988，它为以太坊引入了一种新的预编译，提高了在网络上运行零知识证明的效率。 “基本上，每次我们想要证明像 Merkle 证明这样的存储证明时，在以太坊上都非常昂贵，因为我们没有任何 ZK 友好的哈希函数，”Bakhta 解释道。 关于这个 EIP，以太坊基金会研究员 Dankrad Feist 表示，在他看来，将任何类型的算术哈希函数纳入协议还为时过早，因为它们当前还处于早期测试性质，并且它们可能会对以太坊的安全性产生未知的影响。
