除了备受瞩目的EIP-4844，坎昆升级还会包含哪些提案？

原文标题：

原文作者：Christine Kim （编译有删减）

2023 年 4 月 20 日，以太坊开发者齐聚一堂，召开第 107 次核心开发者共识电话会议 (ACDC) 。 ACDC 是一个双周会议系列，由以太坊基金会研究员 Danny Ryan 主持，此次会议中，以太坊开发人员讨论对以太坊共识层 (CL) 方面的修改内容，更新了围绕 Deneb 的进展，并讨论了下一次坎昆升级中，除了以太坊EIP-4844 之外还有哪些提案包含其中。

Deneb Devnet #5

自4 月 12 日上海成功激活以来，以太坊开发者第一时间将注意力转移到坎昆的筹备工作上。Cancun 是以太坊执行层（EL）下一次升级的名称，而 Deneb 是对应 CL 的升级名称。在 ACDE 电话会议期间，开发人员讨论了 Cancun/Deneb 升级的最终范围，该升级将以 EIP 4844 为中心，即 blob 交易类型的实施，Deneb 的准备工作，从推出 devnet #5 开始。

自去年 10 月，开发人员就为 EIP 4844 启动了多客户端测试网络，也称为 devnets。ACDE 电话会议主席 Tim Beiko 表示，EIP 4844 的第五个 devnet 将于下周某个时候启动。以太坊基金会的 DevOps 工程师 Paritosh Jayanthi 表示，他正在为 Ethereum JS (EL) 和 Lodestar (CL) 等客户进行试运行，为下周的 devnet 发布做准备。

其中，引擎API有一个小的更改，将“getPayloadV3”和“getBlobsBundleV1”调用合并为一个。 Beiko强调，这个更改尚未合并到GitHub上的EIP 4844规范中，但将在接下来的几天内完成，以便该更改可以在devnet＃5上进行测试，Beiko敦促客户端团队尽快审查此更改。

开发人员随后讨论了有关如何在链重组时将 blob 事务重新插入块的问题。这个问题是由 Geth（EL）开发者Péter Szilágyi在他在上的演示中提出的（可以在Szilágyi的中找到更多信息）。Ryan表示，由于 blob 事务与常规事务分离的特性，重新组织后的 blobs 只能从公共 mempool 的交易中获得。鉴于有很多交易会绕过 mempool，即MEV交易和捆绑包bundles，一种保证所有 blob 都可以重建的方法（即使是绕过内存池的交易），即让 CL 将每个块的 blob 数据传递给 EL ，然后 EL 可以缓存它直到块完成。或者，网络可以要求提交了跳过 mempool 的交易用户，在链重新组织事件中重新提交其交易。

Szilágyi表示，他更喜欢前者，即将 blob 数据传输到EL中，以便在重新组织时可以重新插入交易，甚至是绕过内存池的交易。在Szilágyi看来，这对EL的额外负载并不大，如果这个过程变得相当繁琐而让节点无法支持，则开发人员可以调整EL和CL之间的消息以减轻负担。“最简单的解决方案是，在共识客户端发送新的有效载荷时将blob提供给执行客户端。” Szilágyi说道。Ryan回应称，虽然所提出的解决方案很简单，但它会进一步破坏EL和CL层之间的抽象。此外，该解决方案将强化节点存储完整数据的假设，而该假设在未来实施数据可用性采样（DAS）升级中可能会被打破。

关于DAS的实施，Szilágyi表示，在这次升级中，数据可用性方面会有其他期望需要改变，并建议开发人员“到那时再试着解决问题”。Ryan同意了他的看法，并询问其他开发人员对链重组和blob交易重新插入情况的看法。Lodestar (CL)客户端的开发者Gajinder Singh表示，由于MEV交易是绕过公共内存池最常见的类型，并且MEV交易高度依赖特定链状态进行执行，因此在链重组后删除它们并不重要，因为链状态已经改变，MEV交易可能需要重新执行。

由于缺少EL客户端团参与，下次ACDE电话会议上再次提出这个问题。

Deneb Add-Ons

除了 EIP-4844，Deneb 升级还考虑了其他的代码升级。

1、第一个是EIP-4788，它可以在EL中公开CL Beacon Chain的状态。这将允许在EL上执行的智能合约对CL进行最小化信任访问，这与质押池、再质押协议、MEV等相关。以太坊基金会研究员Alex Stokes是EIP的作者之一，他表示该功能是对CL的“轻量级”更改。电话会议上没有人反对将EIP 4788包含在Deneb中。并将在下次ACDE电话会议上向EL客户端团队征求支持该EIP的意见。

2、EIP-6914，该提案能将已完全退出网络并且有一段时间未活动的验证器索数字重复使用。在验证器退出以及新的验证器加入到网络的过程，该EIP将有助于减少验证器列表的无限增长。Stokes表示，EIP 6914 的复杂性比较高，代码更改应推迟到 Deneb 后面的下一次硬分叉。在对 EIP-6914 复杂性进行讨论后，开发人员同意继续磨合代码更新的详细信息，但将最终的实施留到 Deneb 之后。

3、Ryan提出了一个潜在的代码更改，涉及从Beacon Chain创世区块开始回填数据并创建新的“历史摘要”内容。关于这个代码更改的细节尚未在EIP中指定。Ryan同意与此更改的提议者Jacek Sieka（Status研究开发负责人，正在构建Nimbus (CL)客户端）联系以获取更多详细信息。

4、，该提案将防止被惩罚的验证者在退出队列时提出区块。如果有超过50％的验证者因恶意行为而被惩罚，在被强制从网络中驱逐的同时，这些验证者仍然能够提出区块。Ryan表示，更改此逻辑是一个相对较小的CL层更改，可以提供对“高故障模式”的保护。

5、EIP-6493，该提案将解决节点应如何处理在CL上以SSZ格式进行格式化但在EL上编码不同的blob交易类型。这个EIP是更新以太坊序列化格式以实现跨层一致性内容的一部分。有关以太坊序列化格式的更多背景信息可以阅读先前。

在 Deneb 范围的讨论中，开发人员倾向于于将 EIP-4788、EIP-3175 与 EIP-4844 一起包含在下次升级中。