8月31日，以太坊开发人员在 ACD E会议上讨论了Cancun升级、Verkle Trie 转换和 SSZ序列化更新等开发和测试进展。本文源自 Christine Kim 所着文章 《Ethereum All Core Developers Execution Call #169 Writeup》，由白话区块链编译、整理。 （前情提要：以太坊EIP-4844：坎昆升级的核心 ） （背景补充：ETH Taipei》V神出席以太坊台北聚会：台湾开发者超优秀、坎昆升级重点.. ）

本文目录

• 1、坎昆升级
• 2、Verkle Trie 转换
• 3、SSZ 序列化

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

1、坎昆升级

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 建议以下顺序：

对于 Beiko 在 Devnet #9 后释出测试网的提议，没有人提出异议。Beiko 提到，一旦 Holesky 测试网于 9 月 15 日正式启动，上述时间表将在一篇部落格文章中与更广泛的以太坊社群共享。此外，Beiko 表示还有一个名为 Ephemery 的测试网正在开发中。Ehemery 是一个以太坊测试网，面向验证节点运营商，一两週后会重置回创世状态。

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

2、Verkle Trie 转换

接下来，开发人员讨论了 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 上非同步讨论该主题。

3、SSZ 序列化

然后，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。