2024 年 1 月 18 日，以太坊开发人员齐聚 Zoom 参加了 All Core Developers Execution (ACDE) call #179 会议。ACDE 电话会议是一个每两周举行一次的系列会议，由以太坊基金会协议支持主管 Tim Beiko 主持，开发人员在会上讨论和协调对以太坊执行层（EL）的更改。本周，开发者们分享了有关在 Goerli 网络上激活 Cancun/Deneb（Dencun）升级的事后总结。开发者还一致同意在即将到来的 1 月 30 日和 2 月 7 日在 Sepolia 和 Holesky 测试网络上激活 Dencun。最后，开发者们讨论了 Prague/Electra（Petra）升级的优先事项，与会的大多数客户端团队一致认为该升级应包含较小的代码更改，以便在 2024 年底之前准备在主网上实施。

Goerli 上的 Dencun 硬分叉

Dencun 升级于 2024 年 1 月 17 日星期三在 Goerli 网络上激活，大约在 6:30（UTC）左右。根据以太坊基金会（EF）的 DevOps 工程师 Parithosh Jayanthi 总结，激活升级后，Goerli 网络的参与率立即下降。这一下降的根本原因是 Prysm（CL）客户端中存在的一个错误。Prysm 团队在发现问题不到四个小时后发布了热修复。一旦运行 Prysm 客户端软件的节点运营者更新了他们的设备，网络参与率从大约 40% 上升到 70%，这使得网络能够完成块、Blob 和交易。

自 Dencun 在 Goerli 网络上激活以来，EF 测试团队一直在 Goerli 上提交大量的 Blob 交易，以测试网络处理这些类型交易的能力。Jayanthi 表示，初始指标，包括 Blob、块和 Attestation 传播速度，看起来很健康。有关这些指标的更详细分析可以在 EF DevOps 团队的这篇文章中找到。

Prysm 团队的 Terence Tsao 还分享了有关在 Goerli 上修复的 Prysm 客户端中的 bug 的更详细解释。Tsao 解释说，问题是由于 Prysm 客户端中的历史根字段为空引起的。历史根是从先前的以太坊升级 Shanghai/Capella（Shapella）中延续过来的传统字段，开发者忘记更新为非零值。这是一个「容易」发现的错误，Tsao 说，只需要对经历了 Shapella 等升级的测试网络进行长时间的分析。所有之前实施 Dencun 的开发网络和影子分叉都在网络上太快地经历了先前的升级，以至于无法捕捉到这个 bug。展望未来，开发者们同意将这种边缘情况包含在他们的测试向量中，并更加慎重地在升级测试过程中更早地测试这种边缘情况。

关于 Dencun 后在 Goerli 上观察到的其他不规律性，Tsao 提到某些 CL 客户端似乎「不管什么情况都」在请求 Blob，甚至是对于没有 KZG 承诺的块。鉴于这种行为是「浪费的」，Tsao 建议客户端团队研究他们客户端的行为，并确保仅在具有适当 KZG 承诺的块时触发 Blob 请求。

随后，Jayanthi 在电话会议上向开发者们询问，关于第二层协议（L2s）何时开始在 Goerli 上提交 Blob 交易的见解。考虑到他的团队正在「人为地垃圾邮件式」地用 Blob 充斥测试网络，Jayanthi 表示，在 L2s 准备提交自己的 Blob 交易时，他希望减少这种活动。来自 Prysm 客户端团队的 Tsao，该团队是 L2 协议 Arbitrum 拥有的软件客户端，表示 Arbitrum 团队可能会在 Sepolia 测试网络而非 Goerli 上测试 Blob 交易。Optimism L2 协议的一位化名开发者，以「Protolambda」为屏幕名，表示 Optimism 团队计划在未来几周开始在 Goerli 上进行测试。EF 研究员 Ansgar Dietrichs 表示，他将在下一次 Rollcall 会议上提到这个问题，Rollcall 是一个专注于第二层协议的标准化和协调的会议系列。

Dencun 的 L2 准备情况

ACDE 会议主席 Tim Beiko 就开发者们对 Dencun 升级对 L2 的立即可用性有多大信心提出了更为具体的问题。「我们是否看到 4844 在某种程度上对 L2s 来说不足够？显然，你可以想象它在主网上使用了几个月，然后 L2 选择使用它。这可能没问题，但我们希望确认它被认为是可用的的最低确认程度是多少，我们是否已经达到了？」Beiko 说。（4844 是指以太坊改进提案 4844，也称为 proto-danksharding，这是 Dencun 升级中为 L2 设计的主要代码更改。有关 proto-danksharding 的详细信息，请阅读这份Galaxy Research 报告。

Protolambda 回应说，虽然 Optimism 团队「接近」能够支持 Dencun，但他对 Blob 交易的基础设施和工具的准备性表示担忧。「在第一层之外还有更多的基础设施需要更新，」Protolambda 说。Beiko 澄清说，他不会阻止以太坊主网在 L2s 能够支持升级之前更快地采用 Dencun。但是，在激活后不久，L2s 可能会提供「额外的验证」，以确保 Dencun 是以太坊协议的有用变更。

Jayanthi 表示，他将把 Goerli 上 Blob 的目标垃圾邮件数量从每个 Blob 的六个减少到三个，以便在 L2 准备好时，他们可以测试 Blob 的基础设施。EF 研究员 Alex Stokes 还提到，Flashbots 团队一直在 Goerli 上提供一些包含 Blob 的区块构建器负载，以测试 MEV-Boost 工作流。

执行 API 规范变更

Geth（EL）客户端的一位名为「Lightclient」的开发者提出了与 Dencun 升级相关的执行 API 规范的待定更改。正如在ACDE＃174上讨论的那样，Blob 交易的引入意味着获取有关 Blob 燃气价格和费用的新方法。为了与已在以太坊上检索常规交易有关燃气信息的方法的命名一致，提议将执行 API 方法中的「eth_blobgasprice」更新为「eth_blobbasefee」。该提案还建议将 Blob 费用数据添加到「eth_feeHistory」执行 API 方法中。

开发者们同意在 Ethereum Research and Development Discord 频道中发出最后的评论邀请，并明确标记一个可能受到这一变更影响的 Infura 代表，以便审查并合并这些变更，如果没有反对意见的话。

EIP 4788 合约部署

正如在先前的ACDE＃168通话中讨论的那样，Dencun 升级中的一个代码变更，即EIP 4788，要求手动部署代码并创建一个智能合约地址，然后可以在硬分叉时激活。开发者们同意提前在以太坊主网上部署代码。Beiko 要求有人在 Ethereum R&D Discord 上自愿参与，并表示他将为参与者报销用于提交交易的燃气费。

EF 研究员兼 ACDC 通话主席 Danny Ryan 简要介绍了为 Dencun 发布的新 CL 规范。最新版本将包含在ACDC＃125中提到的分叉选择过滤更改，以及用于检查历史根字段的新测试向量和一些其他小型更新。新版本预计将在本周发布，并成为 CL 客户端团队在其各自的代码发布中遵循的标准。

Sepolia 和 Holesky 分叉时间

接下来，开发者们讨论了在最后两个以太坊公共测试网络 Sepolia 和 Holesky 上激活 Dencun 的时间安排。在在 Goerli 上激活 Dencun 之前，开发者们已经同意在 1 月 30 日和 2 月 7 日分别在 Sepolia 和 Holesky 上激活 Dencun。在本周的 ACD 通话中，开发者们重新确认了这些日期，并同意采取单一客户端发布的方式进行这两个升级，以便 Holesky 升级可以更快地进行，即在 Sepolia 升级后的一周。来自 Lighthouse 客户端团队的代表在 Zoom 聊天中提到，Sepolia 和 Holesky 的发布可能再次是「预发布」，意味着这是一个尚未准备好用于主网的发布，可能需要更新。Prysm 在之前的通话中表示，他们针对 Goerli 升级的发布是一个预发布。目前尚不清楚他们针对 Sepolia 和 Holesky 的发布是否同样会是另一个预发布

Sepolia 和 Holesky 升级的具体时间可以在 Dencun 硬分叉 Meta EIP 文档中找到。

Protolambda 在 Zoom 聊天中询问开发者们对于在最终测试网络 Holesky 上激活 Dencun 和以太坊主网之间的时间感觉。「在 Holesky 和主网 L1 之间的最小推出时间，大家估计是多少？一个月，两个月？有足够时间来测试 L2 效果，包括 blob 过期，会很好，」Protolambda 写道。作为回应，Beiko 写道，「我期望的最小时间是一个月？」Jayanthi 表示，最早可以在 Goerli 上测试 blob 的到期时间是 2 月 5 日，并建议开发者在之后的 ACD 通话中于 2 月 8 日更详细地讨论这个话题。Danny Ryan 建议 2 到 3 周。

Prague/Electra 提案

接下来，开发人员讨论了一些提议纳入 Petra 升级的 EIP。

EIP 3074

由一位使用屏幕名「Foobar」的匿名开发者在通话中介绍，EIP 3074 引入了两个新的 EVM 指令「AUTH」和「AUTHCALL」，以实现更大功能的外部拥有账户，其中最重要的之一是能够签署批量交易。Foobar 详细介绍了为什么批量交易是以太坊终端用户的重要功能，将提高其资产安全性，并改善去中心化交易所（DEXs）上的用户体验。有关 EIP 3074 的更多信息，请阅读由 Foobar 撰写的这篇博客文章。

EF 研究员 Ansgar Dietrichs 表示，他对 EIP 3074 的两个主要反对意见是其在较窄版本的 EIP 上的实现优势。其次，Dietrichs 表示，在他看来，改进以太坊用户体验的 EIP 应首先在 Layer 2 上实施和测试，因为 Layer 2 更灵活，更快地采用新技术，而不是以太坊主网。VM Capital 创始人 William Morriss，一家 DeFi 交易公司的创始人，对 Dietrichs 的第二个反对意见表示不同意。「我认为 Layer 2 不应被视为一个功能测试网。制作 Layer 2 的开发者非常关心与主网的兼容性，如果他们部署了一个有临时规范的功能，那么当最终到达主网时，即使它具有相同的操作码编号，行为可能会有差异，这对他们来说将是技术债务。因此，他们通常不特别有兴趣为我们扮演那个角色，」Morriss 说。

Nethermind 客户端的开发者 Ben Adams 同意 Foobar 的观点，即批量交易是改善以太坊终端用户体验的可取功能。Lightclient 补充说，在他看来，下一个升级对以太坊用户体验进行某种改进的需求很大，因此如果不是 EIP 3074，开发者应考虑另一个更容易实现的版本。Beiko 建议继续在Ethereum Magicians上讨论 EIP 3074 的优点。

EIP 6913

随后，Morriss 介绍了EIP 6913的不同实现设计。在他的演示中，Morriss分享了一种名为「SETCODE」的新 EVM 指令的动机，该指令能够替换智能合约账户中的代码，而无需将代码迁移到新地址。开发者对该 EIP 提出了几点反对意见。来自 Geth 团队的 Marius van der Wijden 表示，该 EIP 将破坏对燃气估算，并在节点上创建 DoS 攻击向量。Dietrichs 表示，EIP 6913 应该只在「全面的 AA 路线图」的背景下考虑，这指的是以太坊上的账户抽象路线图。Lightclient 表示，在他看来，该 EIP 对于「改变协议并不足够有用」。Morriss 同意开发者应该以某种方式在以太坊上实现账户抽象，无论是通过 EIP 6913 还是其他以 AA 为重点的 EIP。

EIP 7251 和 EIP 7545

EF 研究员 Mike Neuder 介绍了EIP-7251和EIP-7547，它们是两个专注于共识层（CL）的代码更改，对执行层（EL）的影响较小。

· EIP-7251 增加了验证者的最大有效余额。它需要与 EIP-7002 结合使用，该提案允许验证者使用其 EL 提款凭据从 Beacon Chain 触发对 EL 的部分提款。

· EIP-7547 实现了一个机制，通过该机制，区块提议者可以强制将某些交易包含在一个区块中。关于通过包含列表强制包含以及它们对帮助防止以太坊上的交易审查的详细信息，请阅读 Mike Neuder 在 Ethereum Research 上的这篇文章。

在会议上，许多开发者支持将 Neuder 提出的 EIP 列为 Petra 的优先考虑。特别是关于 EIP 7547，Neuder 强调：「我们目前处于一个稍微微妙的情况中，一些大型矿工已经开始审查某些交易，而有一些矿工则没有这样做。如果那些矿工决定开始审查，情况可能会迅速变得糟糕…如果超过九成的区块都受到审查，这不仅会给我们造成负面形象，而且用户在获取这些交易时的体验将明显下降。因此，我目前认为情况非常不稳定，越来越多的建设者和验证者的反馈也让我认为，在监管事务仍然不确定的情况下，获得一些固定的包含是非常重要的。

关于 Petra 的想法

在提出的 Petra 升级的完整 EIP 列表中，Beiko 询问客户团队对升级内容的「高层次」想法是什么。Reth 客户团队的 Georgios Konstantopoulos 表示，他的团队将支持在年底之前发布的 Petra 升级，其中包括与质押相关的 EIP 和孤立的 EVM 更改。有关将包括哪些 EIP 的更详细概述，请阅读 Reth 关于 Petra 升级的博客文章。

EF 研究员 Alex Stokes 支持 Reth 关于 Petra 的观点。其他客户团队，如 Nethermind 和 Geth，也支持在年底之前发布的升级。大多数客户团队还倾向于在之后的升级中专注于Verkle 树。在会议上有一些关于 EOF 相关代码更改是否应在 Verkle 升级之前实施的辩论，因为 EOF 可能增加 Verkle 实施的复杂性。有关 EOF 的更多信息，请参阅之前的ACD会议记录。

基于客户团队在会议上对 Petra 的高层次看法，Beiko 建议至少在 Prague 升级中包含 EIP 6110、7002 和 2537。（有关包含在 Electra 升级中的伴随 CL 专注的 EIP 的讨论将在下一次 ACDC 会议上进一步详细讨论。）至少将这三个 EIP 包含在 Prague 升级中，Beiko 还建议将下一次 ACDE 会议的重点放在决定更大、更复杂的代码更改的时间表上，如 Verkle、EOF 和历史数据修剪。一个化名为「Potuz」的 Prysm 客户团队的匿名开发者补充说，如果升级可能在 2025 年或之后发布，开发人员应致力于在 2024 年底之前将 Petra 用于主网实施，因为有关 Petra 应包含什么的意见可能会改变。Potuz 还向 Reth 团队的详细博客文章致以敬意，该文章阐述了 Petra 的优先事项。他鼓励其他客户团队准备类似的文档。

1 月 6 日 Besu 主网活动

由于本周 ACD 会议时间有限，关于1 月 6 日影响 Ethereum 主网上 Besu 节点的故障和在最新的 EF 研究团队 Reddit AMA中分享的有关少数客户端性能数字的不准确信息的最后一个讨论项目被跳过。Beiko 表示，这个讨论项目将作为下一次 ACDE 会议的第一个话题提出。