[锦鲤论币]以太坊核心开发者最新会议摘要：三大测试网坎昆升级时间初步确认

原文标题:《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)直接执行可能太贵的复杂加密计算。SHA33、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 在实施过程中，可能不需要协议中的任何变更。更多关于相关数据可用性和区块链模块化的信息，请阅读此报告。