原文标题：《Ethereum All Core Developers Execution Call #177 Writeup》

原文作者：Christine Kim

原文编译：Sharon，BlockBeats

编者按：

以太坊所有核心开发者共识电话（ACDE）每两周举行一次，主要讨论和协调对以太坊执行层（EL）的更改。本次为 ACDE 第 177 次电话会议，初步确定了 Goerli、Sepolia、Holesky 的分叉时间，分别为 1 月 17 日、1 月 31 日和 2 月 7 日。

此外，开发者们就 L2 的预编译地址范围、Prague/Electra 升级进行了讨论，同时决定跳过下周四的 ACD 电话会议，并在 1 月 4 日重新召开 ACDE＃178。Galaxy Digital 研究副总裁 Christine Kim 对本次会议要点做了详细记录，BlockBeats 将原文编译如下：

2023 年 12 月 21 日，以太坊开发者通过 Zoom 参加了第 177 次全核心开发执行（ACDE）电话会议。由以太坊基金会的协议支持主管 Tim Beiko 主持，ACDE 电话会议是一系列每两周一次的会议，开发者在会上讨论和协调以太坊执行层（EL）的变更。

本周，开发者确定了在所有三个公共以太坊测试网络上激活 Cancun/Deneb 升级的暂定日期。测试网络升级的时间表如下：

Goerli 分叉将于 1 月 17 日进行；

Sepolia 分叉将于 1 月 31 日进行；

Holesky 分叉将于 2 月 7 日进行。

由于开发者在接下来的几周内需要更新由于意外错误和客户端发布问题，以上日期可能会产生变更。此外，开发者还讨论了第二个 Goerli 影子分叉的性能、L2 的预编译地址范围以及 Prague/Electra 升级的预期。开发者同意取消下周四（12 月 28 日）的全核心开发者共识（ACDC）电话会议，并计划在 1 月 4 日星期四重新召开常规 ACD 会议。

Goerli 影子分叉

以太坊基金会的 DevOps 团队，于 12 月 19 日启动了 Goerli 测试网络的第二个影子分叉。这个影子分叉由分布在纽约、法兰克福、班加罗尔和悉尼的 290 个节点激活，每个节点运行 100 个验证器。除了 Erigon 客户端之外，几乎所有以太坊客户端都能够加入影子分叉并成功升级。

基金会的 DevOps 工程师 Parithosh Jayanthi 表示，自分叉启动以来，网络参与率在 99% 到 100% 之间波动，表明几乎所有 Goerli 影子分叉上的验证器都能正确连接到网络。

他指出，由于 Cancun/Deneb 升级，网络上的节点平均带宽增加了大约 200kbps。尽管如此，在 blob 垃圾邮件和 blob 延迟测试期间，网络没有发生任何区块重组事件或严重的区块传播延迟。然而，Jayanthi 也指出，区块传播事件在不同的 CL 客户端中以不同的方式发出。某些 CL 客户端将在验证之前为区块发出事件日志，而其他客户端将仅在验证后发出事件。

要阅读有关 Goerli 影子分叉（GSF）＃1 的更详细分析，请参阅基金会 DevOps 团队编写的文章。

Jayanthi 表示，DevOps 团队计划在 12 月 21 日星期四结束时弃用 GSF＃1。Lodestar 和 EthereumJS 客户端的开发人员 Gajinder Singh 指出，他仍在对影子分叉进行额外测试。Jayanthi 同意与 Singh 核实，确保他能在关闭 GSF＃1 之前在 Devnet＃12 上复制这些测试。

下一步

基于 GSF＃1 的结果，开发者讨论了测试 Cancun/Deneb 升级的下一步。Beiko 询问 Prysm 客户端团队是否愿意在 1 月份为 Goerli 测试网络设定一个暂定的分叉日期。Prysm 客户端的开发人员 James He 表示，该团队仍在解决其客户端中的一些错误，并计划在 1 月 8 日前查看修复版本的暂定发布日期。

其他客户端团队也倾向于在 1 月中旬而不是 1 月底设定 Goerli 分叉日期，开发者们暂时同意在 1 月 17 日激活 Cancun/Deneb 升级。

Beiko 表示，客户端团队需要在 1 月 8 日或 9 日之前共享其软件的更新版本，以便 Goerli 节点运营商有时间升级他们的设备，如果他们决定在 1 月 17 日进行分叉。Beiko 还将在 1 月 8 日那周发布一篇博客文章，在以太坊基金会博客上宣布 Goerli 分叉日期，以便 Goerli 用户了解全网升级。

Ansgar Dietrichs 询问开发者，是否还应为将在以太坊主网之前升级的另外两个以太坊公共测试网络制定目标日期。经过一番讨论，开发者们同意在 Goerli 后的两周内，即 1 月 31 日，为 Sepolia 测试网络设定目标升级日期；在之后的一周，即 2 月 7 日，为 Holesky 测试网络设定升级日期。

开发者计划为 Sepolia 和 Holesky 测试网络升级捆绑一个单一的客户端发布和公告帖，以便在这两个 Cancun/Deneb 激活之间有一个更短的一周的周转时间。在 Zoom 聊天中，Dietrichs 说：「我认为在过去我们通常只有较少的测试网络，所以捆绑发布似乎是一个很好、很实用选择。」

以太坊基金会的 DevOps 工程师 Barnabas Busa 提到，在 Sepolia 测试网络升级之前升级 Holesky 测试网络可能更有用，以尽早捕捉与网络相关的错误，因为 Holesky 托管的验证器数量比 Sepolia 测试网络更多。然而，尽管规模较小，Sepolia 托管的用户比 Holesky 更多。

因此，如果先在 Holesky 之前升级，L2 团队可能会有更多时间测试其操作。开发者们同意在目前继续升级 Sepolia 之前升级 Holesky，并在 Goerli 分叉后重新审视此顺序。Jayanthi 表示：「我认为我们将从 Goerli 中学到最多，因为验证器集合足够小。有很多独特的 [节点] 设置等等。」

预编译地址范围

接下来，开发者们讨论了 L2 的预编译地址范围。

预编译（precompile）是以太坊上的地址，类似于智能合约，能够执行通过以太坊虚拟机（EVM）直接执行可能过于昂贵的复杂加密计算。SHA3、RIPEMD160 和 BLAKE2 是以太坊上已支持的预编译哈希函数的例子。

由于 L2 希望通过添加新的预编译功能来扩展智能合约执行功能，而这些功能可能在以太坊上尚不存在，有一个问题是 L2 是否应该使用以太坊未来可能使用的预编译地址。

Dietrichs 在 GitHub 的评论中解释说：「在未来，许多新的 EVM 预编译将首先在（某些或全部）L2 上引入…然后可能或可能不会在 L1 上后续引入。现在非常希望能够提出一种预编译地址方案，确保对于任何给定的 RIP 预编译，L1 上都保留了该地址，这意味着该地址上从未引入过其他冲突的预编译，如果在 L1 上以相同形式引入，则用于该 RIP 预编译。」

RIP 指的是新创建的「Rollup Improvement Proposal」（Rollup 改进提案）流程。RIP 流程是一种 L2 自愿选择的标准，旨在鼓励 EVM 相关变更的标准化和协调。L2 首次寻求以标准方式采用的第一个预编译是 secp256r1 椭圆曲线签名验证的预编译。有关此提案的更多信息，请阅读相关的 RIP文档。

Dietrichs 在电话会议上表示，L2 可以采取两种方式为此预编译分配地址。

首先在 L2 上启动的 EVM 更改可以分配一个与以太坊相同的预编译地址范围内的数字，或者使用一个与以太坊预编译地址范围不同的范围。

以太坊基金会的研究员 Danny Ryan 支持 L2 使用不同范围的地址，因为 RIP 流程仍然存在很多不确定性。他说：「我支持为 L2 添加一个范围，如果在 L1 采用 EIP 之前对其进行了重大采用，可以使用不同的顺序并使用从该范围中选择的内容为 L1 使用，因为目前对 RIP 会发生什么仍然非常不清楚。」

Geth 开发人员 Marius van der Wijden 也支持 L2 在被以太坊采用之前使用不同的预编译地址范围。他还补充说，开发者应该根据情况讨论是否在 L1 上和 L2 上使用相同的地址：「我并不完全同意只使用 L2 提出的内容。我认为需要对此进行辩论。」

Ryan 补充说，在 L2 和以太坊主网之间使用不同的预编译地址，并在 L2 上对预编译功能进行更改的情况下，创造出使用不同预编译地址的选择性，与 RIP 流程的 EIP 过程解耦尤为重要。然而，以太坊基金会的研究员 Carl Beekhuizen 对在 L2 和以太坊主网之间使用不同的预编译地址提出了异议，并称「仅因为未来可能会发生变化，我们就不必要地默认进入一个最坏情况。」

由于存在争议，Dietrichs 建议 L2 目前使用与以太坊主网不同的预编译地址范围。他补充说，当在未来激活新的在 L2 上已被广泛采用的 Ethereum 预编译时，开发者可以随后决定是否要使用与 L2 上已实施的相同的预编译地址。关于自定义地址范围，开发者们同意为 L2s 保留 0x512 地址范围，通过 RIP 流程使用。

开发者们还同意创建一个新的信息性 EIP，说明这一点，并在 RIP GitHub 存储库中引用其他有关 L2 使用哪些地址进行预编译的信息。

ACD 电话会议安排

正如在 ACDC＃124 上讨论的那样，开发者们将跳过下周四的 ACD 电话会议，改为在 Discord 上进行非正式的检查。他们将在 1 月 4 日星期四重新召开 ACDE＃178。ACDE＃178 将由 Geth 开发人员「lightclient」主持，代替 Beiko，因为他将不参加该电话会议。

Prague/Electra 提案

作为讨论的最后一个主题，Beiko 在以太坊魔法师社区中呼吁开发者关注 Prague/Electra升级。Beiko 强调，客户端团队应该审查 Prague/Electra 的提案，并准备讨论应该优先考虑哪些代码更改用于下一次以太坊升级。

关于 Prague/Electra 的范围，Dietrichs 提到，开发者应该尽量在 Cancun/Deneb 之后，即在 2024 年底之前，实现一次小型升级的激活，而不是试图捆绑复杂的代码更改，这可能会延迟对更加时间敏感的 EIP 的激活。

Ryan 补充说，开发者在 Prague/Electra 升级时不必进行「跨层分叉」。EL 和 CL 的代码更改可以独立地进行部署。

开发者们预计在 Cancun 升级后不久，EL 上将激活的主要代码更改是 Verkle Trie 升级。正如在先前的通话中讨论的那样，用更强大的 Verkle 树替换当前对数据组织使用的 Merkle Patricia 树的升级在过去一年中取得了显著进展，并且可能在 2024 年准备好实施。

然而，由于升级的复杂性和风险，Geth 开发者 Guillaume Ballet 表示，Verkle 升级不应与其他复杂的代码更改或 EIP 捆绑在一起。开发者们同意在新的一年重新讨论「仅 Verkle 升级」的问题。他们还同意安排一个专门的 ACDE 电话会议，深入讨论 Verkle 升级的细节。

此外，Dietrichs 提到，数据可用性抽样是一项旨在降低以太坊数据可用性成本的升级，正在取得「良好的进展」，并且在准备在 CL 上实施时可能不需要任何协议内的更改。有关数据可用性和区块链模块化的更多信息，可以阅读这份报告。

「原文链接」

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方账号：https://twitter.com/BlockBeatsAsia