原文标题：Ethereum All Core Developers Consensus Call #107 Writeup
原文作者：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 有一个小的更改，将“getPayload V3”和“getBlobsBundle V1”调用合并为一个。 Beiko 强调，这个更改尚未合并到 GitHub 上的 EIP 4844 规范中，但将在接下来的几天内完成，以便该更改可以在 devnet＃ 5 上进行测试，Beiko 敦促客户端团队尽快审查此更改。
开发人员随后讨论了有关如何在链重组时将 blob 事务重新插入块的问题。这个问题是由 Geth（EL）开发者 Péter Szilágyi 在他在ETHTokyo上的演示中提出的（可以在 Szilágyi 的PPT中找到更多信息）。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、PR 3175 ，该提案将防止被惩罚的验证者在退出队列时提出区块。如果有超过 50 ％的验证者因恶意行为而被惩罚，在被强制从网络中驱逐的同时，这些验证者仍然能够提出区块。Ryan 表示，更改此逻辑是一个相对较小的 CL 层更改，可以提供对“高故障模式”的保护。
5、EIP-6493 ，该提案将解决节点应如何处理在 CL 上以 SSZ 格式进行格式化但在 EL 上编码不同的 blob 交易类型。这个 EIP 是更新以太坊序列化格式以实现跨层一致性内容的一部分。有关以太坊序列化格式的更多背景信息可以阅读先前开发者记录。
在 Deneb 范围的讨论中，开发人员倾向于于将 EIP-4788、EIP-3175 与 EIP-4844 一起包含在下次升级中。
