以太坊最新一次核心开发者执行会议总结

8 月 31 日，以太坊开发人员聚集在 Zoom 进行了 Core Developers Execution (ACDE) 电话会议。ACDE 电话会议由以太坊基金会的 Tim Beiko 主持，每两周举行一次系列会议，以太坊客户端团队在会上讨论和协调对以太坊执行层(EL) 的更改。本周，开发人员讨论了以下方面的开发和测试进度：

1）坎昆/Deneb (Dencun) 升级

2）Verkle Trie 转换

3）SSZ 序列化更新

Devnet #8 于两周前的8 月 16 日推出。以太坊基金会的 DevOps 工程师 Barnabas Busa 表示，以开发人员为中心的坎昆升级测试网看起来很运转良好。Busa 提到，运行 Nethermind (EL) 客户端软件的节点似乎存在一些问题。Nethermind 客户端的开发人员 Lukasz Rozmej 解释说，问题的本质是由于 Blob 事务池实现中的配置错误造成的。（译者注：Devnet 8 是首个专用的测试网，其中包含了Cancun/Deneb 升级的所有最终确定的EIPs）

关于EIP 4788，开发人员简要地再次确认了代码更改的新部署策略。在 EL 上公开信标链数据的合约将像常规智能合约一样部署，这需要有人在升级激活之前为合约地址提供资金。坎昆升级的下一个测试网 Devnet #9 将采用此工作流程，并确保开发人员熟悉该流程。

开发人员没有推迟 Devnet #9 的发布日期，而是同意继续在 Devnet #8 上进行测试，直到客户端实现的所有问题都得到解决。“我宁愿对 Devnet #9 充满信心，而不是说我们希望这些事情能够发挥作用。......我宁愿解决我们知道的问题。否则，如果我们在 Devnet #9 中遇到很难的问题，那么我们肯定又会有 Devnet #10，我并不是说我们不应该有 Devnet #10。我们应该拥有有意义的开发网络数量。我认为现在我们可以尝试让 Devnet #9 变得真正可靠。”以太坊基金会研究员兼 ACDC 电话会议主席 Danny Ryan 说道。

电话会议中的其他人，包括 Tim Beiko、Marius Van Der Wijden 和 Justin Florentine，都赞成花更多时间在 Devnet #8 上进行测试，并稍后在 Devnet #9 上测试 EIP 4788 中的更改。Beiko 建议开发人员在下一次 ACDE 电话会议期间重新召集 Devnet #9 的时间。关于测试网部署策略，Beiko 建议以下顺序：

1）Devnet #9：又一个 Devnet，其 Dencun 规范已冻结。对网络进行压力测试并假设开发人员对此感到满意，然后转向公共测试网。否则，启动 Devnet #10。

2）Holesky：分叉新推出的 Holeksy 测试网并在其上部署 Dencun 升级。

3）Goerli：然后在Goerli上部署Dencun。作为主网之前倒数第二个测试网的启动，此时的升级规范应该是最终的，并为用户和应用程序在主网升级激活之前提供足够的时间来测试其软件。在 Goerli 被弃用并被 Holesky 取代之前，Dencun 很可能是 Goerli 上的最后一个分叉。（译者注：Dencun 一词为 Cancun（坎昆）和 Deneb 所组成的合成词。 Cancun 为本次以太坊执行层升级的名字，而 Deneb 则为协议层升级的名字。 因此，Cancun 升级与 Deneb 升级被合称为 Dencun 升级。）

4）Sepolia：最后，在 Sepolia 上部署 Dencun 以达到良好的效果。

对于 Beiko 在 Devnet #9 后发布测试网的提议，没有人提出异议。Beiko 提到，一旦 Holesky 测试网于 9 月 15 日正式启动，上述时间表将在一篇博客文章中与更广泛的以太坊社区共享。此外，Beiko 表示还有一个名为Ephemery的测试网正在开发中。Ehemery 是一个以太坊测试网，面向验证节点运营商，一两周后会重置回创世状态。有关 Ephemery 网络的更多信息，请在此处阅读该项目的 GitHub 页面。

在继续讨论 Verkle Tries 之前，Busa 强调了GitHub 上针对 Holesky 测试网的开放拉取请求 (PR) 。应 Erigon (EL) 团队的要求，PR 建议取消 Holesky 上 Dencun 升级的特定激活时间。开发人员稍后将为 Holesky 上的 Dencun 激活设置一个值，而不是重写现有值。Busa 还提出了关于测试 3/6 blob 目标/最大值（而不是 2/4 限制）的问题。关于这个话题，Beiko 建议在下周的 ACDC 电话会议上再次提出这个问题，Ryan 提到最近对大区块大小的实验将带来新的见解。

接下来，开发人员讨论了 Vitalik Buterin 的提议，即结合 Verkle Trie 和 State Expiry 路线图，以降低 Verkle Trie 实施的复杂性并加快 State Expiry 在以太坊上的优势。作为背景，Verkle Trie 或 Verkle Tree 是一种数据结构，允许用户依靠单个加密证明轻松验证大量数据。它们与 Merkle Patricia Trie (MPT) 没有什么不同，后者是用于存储以太坊状态的数据结构。然而，Verkle 树的证明效率相对高于 MPT，这就是开发人员一直致力于将 MPT 过渡到 Verkle 的原因。

状态到期是一项单独的计划，旨在解决状态无限制增长的问题。状态过期的目标是删除用户在一段时间内（例如 365 天内）未访问的部分以太坊状态，从而将状态大小从超过 100 GB 减少到小于 50 GB。Erigon (EL) 客户团队的 Andrew Ashikhmin 赞成将这两个升级捆绑在一起，假设如果与 State Expiry 结合起来，Verkle Trie 转换将会大大简化。来自 Geth (EL) 客户团队的 Guillaume Ballet 一直是 Verkle Trie 项目的带头人，他担心耦合会延迟 Verkle Tries，因为状态到期作为一个研究主题在过去两年已被“放弃”。

Buterin 附和了更多有关他提案动机的背景信息，他说：“随着 [Verkle] 的过渡过程，问题基本上是将50多 GB 的 Merkle Patricia Trie 转换为……实时网络中的 Verkle Trie只是相当复杂。这确实是研究团队苦恼了一整年多的事情。我记得去年在 Devconnect 上，它基本上是研究活动的主题，基本上与 Verkle 路线图的整个其余部分放在一起一样多的研发工作，只是如何进行最后一次过渡的过程。在某些方面，它的复杂性确实可以与合并相媲美。”

Buterin 继续说道 State Expiry 如何显着降低向 Verkle 过渡的复杂性。不过，他也提到，状态到期有复杂的先决条件，例如需要添加更多地址空间来支持新的“地址期”“ 每年。因此，尽管实现 Verkle 的复杂性会降低，但开发人员仍然需要解决难题才能同时执行两者。此外，如果 Verkle Tries 在 State Expiry 之前实现，State Expiry 的紧迫性就会降低，因此开发人员应该考虑使用 Verkle 进行过渡，或者等待几年在 Verkle 之后引入 State Expiry。开发人员不清楚将这两个升级捆绑在一起会产生的额外价值，并同意继续在 Discord 和 Verkle Trie Implementors' Call 上异步讨论该主题。

然后，Nimbus (CL) 客户端的开发人员 Etan Kissling 介绍了他将以太坊数据结构升级为 SSZ 序列化格式的最新进展。有关此问题的更多背景信息，请在此处阅读之前的以太坊开发人员通话记录。Kissling 强调了一种使用基于 SSZ“PartialContainer”的格式来更新以太坊数据序列化的新方法。Kissling在本周电话会议议程下的评论中写道，“这种[格式]本质上结合了[先前格式]的所有优点，并且还可以重复用于其他目的，从而淘汰当前未使用的 SSZ Union 和 SSZ 可选类型。”（译者注：简单序列化(SSZ) 是信标链上使用的序列化方法。 这种方法取代了除对等点发现协议以外的共识层各处执行层上所用的递归长度前缀序列化。 简单序列化设计具有确定性，也可以有效地进行默克尔化。）

更新后，Beiko 快速赞扬了 Python 中新创建的 EL 参考实现（称为 EELS）。在以太坊基金会最近的一篇博客文章中，EIP 编辑兼以太坊基金会研究员 Sam Wilson写道：“EELS 是以太坊执行客户端核心组件的 Python 参考实现，专注于可读性和清晰度。EELS 旨在作为黄皮书的精神继承者，对程序员更加友好，并且与合并后分叉保持同步，EELS 可以填写和执行状态测试，遵循主网，并且是构建新 EIP 原型的好地方。”

一些开发人员已经在使用 EELS 来重新实现他们的 EIP，并且以太坊基金会为有兴趣更新黄皮书的任何人提供了一笔赠款，以包括伦敦和巴黎等缺失的预合并网络升级，以补充 EELS。