2024 年 3 月 28 日，以太坊开发人员齐聚 Zoom 参加了 All Core Developers Execution (ACDE) call #184 会议。ACDE 电话会议是一个每两周举行一次的系列会议，由以太坊基金会协议支持主管 Tim Beiko 主持，开发人员在会上讨论和协调对以太坊执行层（EL）的更改。
本周，开发人员分享了有关导致 3 月 27 日错过区块数量上升的原因的见解。Pry** 开发人员 Terence Tsao 表示，这种上升是由 Bloxroute MEV 中继的问题引起的，Bloxroute 团队正在解决该问题。开发人员还讨论了 Paradigm 团队对以太坊状态和历史增长进行的新研究的要点。开发人员批准在 Prague/Electra 中包含两个追溯性以太坊改进提案（EIP），即 EIP 7610 和 7523。
**，他们分享了其他候选 EIP 的开发更新，例如 EIP 7547（包含列表）、EIP 5920（PAY 操作码）和 EIP 7545（Verkle 证明验证预编译）。
3 月 27 日，缺失区块的数量有所增加。通常，以太坊上每 30 分钟就会错过 2% 到 4% 的区块。但是，在网络经历大量 Blob 事务期间，此百分比在几个小时内上升到 14% 以上。这一时期的 blob 价格上涨了 10 倍以上。Tsao 说，一旦 Bloxroute 团队关闭了他们的 MEV 中继，缺失块的问题就立即得到了解决。导致 Bloxroute 中继问题的细节尚不清楚，Bloxroute 团队正在研究修复程序，他们将在未来几天内分享该修复程序以及对问题的完整事后分析。
「所以，昨天错过的块并不是说客户无法处理这种类型的工作量，因为基本上所有错过块都是由 Bloxroute 问题引起的。但仍然存在一个基本问题，即在昨天的流量下会发生什么，我怀疑，客户导入区块的速度可能比以前慢，但这是我没有确凿证据的事情，这还有待观察，「Tsao 说。为了应对丢失区块事件，Lighthouse 客户端团队发布了一个「热修复」版本，以提高节点性能和稳定性。此外，虽然调查仍在进行中，但 Bloxroute 的**执行官 Uri Klarman 在 X 上表示，他认为这些问题与 Bloxroute 中继无关，而是与 blob 在以太坊上的一般传播方式有关。
以太坊基金会开发人员运营工程师 Parithosh Jayanthi 询问该事件是否会导致开发人员重新评估客户端断路器条件，这些条件会自动导致验证器节点回退到本地区块生产。在大多数客户端中，断路器条件的默认值是连续错过五个插槽的事件。Tsao 指出，太容易触发的断路器条件是复杂的 MEV 行为者可以利用的潜在攻击媒介。
Pry** 开发人员「Potuz」表示，在他看来，这一事件凸显了中继中缺乏客户端多样性实现，以及中继和协议开发人员之间缺乏沟通。「Terence 已经谈论这些 blob 一个多星期了，没有人注意到这一点，一旦它**，只需要打几个电话就可以让正确的继电器实际查看他们的日志。这是不可接受的，「波图兹说。
一些开发人员建议下次在报告网络违规行为时创建书面帖子，以提高以太坊生态系统的知名度。为了进一步讨论丢失区块事件，以太坊基金会研究员 Alex Stokes 鼓励开发人员参加下一次 MEV-Boost 社区电话会议。
Paradigm 的数据科学家工程师 Storm Slivkoff 对以太坊的状态和历史增长进行了新的分析。根据他的发现，状态增长并不是以太坊可扩展性的主要瓶颈。「我们发现，现有的消费类硬件可以在很长一段时间内维持当前的**增长率，可能是几十年。请注意，我在这里只谈论存储容量和内存容量。这并不是说在这种框架下要声明的读取或写入」。在他看来，以太坊的「沉默杀手」是历史增长。
在书面分析中，Paradigm 研究团队解释说：「状态是构建和验证新以太坊区块所需的数据集。状态由合约字节码、合约存储、账户余额和账户随机数组成。历史记录是将节点从创世同步到**区块所需的数据集。历史由区块和交易组成。状态和历史是非重叠的数据集。Slivkoff 补充说，历史的增长速度明显快于以太坊状态。冲击历史增长率的**用例是 rollups 和其他类型的协议，需要桥接到以太坊。
Slivkoff 建议开发人员认真考虑在下一次以太坊升级 Prague/Electra 中加快解决历史增长的 EIP，例如 EIP 4444 和 EIP 7623。他还表示，将进行进一步的分析，以分析以太坊上的其他扩容瓶颈，并将这些方法应用于分析 rollup 的扩容瓶颈，作为其团队研究的下一步。Slivkoff 说，所有数据都将开源供公众使用，欢迎提供反馈。
在 Slivkoff 的演讲之后，开发人员讨论了在短期内解决历史增长的不同方式。正如 ACDE #180 上所讨论的，开发人员正在构建强大的替代网络，其中经过**时期的历史数据，例如合并升级之前的历史数据，在数据无法通过以太坊节点访问的情况下，用户仍然可以访问这些数据。有关历史到期和服务历史数据的替代选项的进一步讨论，Geth 开发人员「Lightclient」建议开发人员继续在以太坊研发 Discord 频道上以标题为「历史到期」的子频道主题中进行对话。
开发人员同意实施 EIP 7610 和 7523。这些是追溯性 EIP，它们将向以太坊协议添加规则，这些规则可以从网络开始追溯应用，以进一步限制链上某些类型的行为。这些 EIP 的好处是简化了以太坊测试用例，并限制了各种边缘情况的范围，例如创建空账户的边缘情况。两个已追溯应用的 EIP 包括 EIPIP2681 和 3607。开发商同意在 Prague/Electra 激活另外两个追溯性 EIP。有关这些 EIP 约束哪些行为的背景信息，请参阅此处的先前通话记录。
Geth 客户团队已经完成了一些基准测试，以估算 EIP 2537 BLS 曲线操作的 gas 成本。这些新业务将在 Prague/Electra 升级中激活，开发人员目前正在权衡这些业务的定价。Reth 团队的一位代表表示，他的团队还将完成 BLS 曲线操作的额外基准，以协助确定这些操作的 gas 成本。
正如 ACDC #130 上所讨论的，开发人员正在强烈考虑将 EIP 7547 包含在 Prague/Electra 升级中。本周，以太坊基金会研究员 Mike Neuder 分享了如何修改 EIP 7547 以与账户抽象向前兼容的**信息。账户抽象是一项持续的举措，旨在为以太坊上的外部账户（EOA）引入更大的灵活性和可编程性，这些账户是用户控制的账户。Neuder 提出了三种不同的方法来解决 EIP 7547 和帐户抽象 EIP 之间的兼容性问题。关于这些解决方案，Neuder 说，「这确实感觉像是包容性设计的复杂性，但我确实认为这三种选择确实有效，而且我也不认为会有灵丹妙药来解决这个问题。我不认为我们会找到一个更好的设计解决这些问题。
Beiko 建议在有限的时间内，在单独的分组会议上继续讨论纳入列表设计。
接下来，开发人员浏览了 Prague/Electra 升级的其他候选 EIP 列表。它们包括：
EIP 5920（PAY 操作码）：以太坊基金会研究员 Sam Wilson 指出，该操作码的测试工作已经开始。
EIP 7609（** TLOAD/TSTORE 的基本成本）：Vyper 编译器的贡献者 Charles Cooper 重申了他的观点，即 TLOAD 和 TSTORE 操作码在 EVM 中应该定价更便宜。
EIP 2935 和 7545（在状态和 Verkle 证明验证预编译中保存历史块哈希值）：Geth 开发人员 Guillaume Ballet 将这两个提案作为代码更改提出，这将为 Verkle 实现提供未来的好处，同时，有助于提醒更广泛的以太坊生态系统即将到来的 Verkle 升级。
以太坊对象格式（EOF）：Besu 客户端维护者 Danno Ferrin 表示，EOF EIP 正在由多个客户端团队实施，并且正在为它们编写参考测试。他要求开发人员参考 EOF 就绪矩阵以获取更详细的更新。
EIP 7212 和 EIP 3074（secp256r1 曲线支持和 AUTH/AUTHCALL 操作码的预编译）：Besu 开发人员 Matt Nelson **介绍了 L2 rollup 正在实现的这两个 EIP。他强调，为了鼓励以太坊和 rollups 之间的兼容性，这两个 EIP 应该在 Prague 采用。
EIP 7664（访问密钥操作码）：OPLabs 开发人员「Protolambda」提出了 EIP 3074 的替代提案，该提案利用访问列表来增强 AUTH/AUTHCALL 操作码的功能。
EIP 6493（SSZ 交易签名方案）：Protolambda 还表示支持与 SSZ 相关的代码更改，以提高验证以太坊数据的安全性和效率。
开发人员没有时间讨论此列表中的哪些 EIP 应该优先用于 Prague。Beiko 表示，在两周后的下一次 ACDE 电话会议开始时，时间将被封锁，以再次审查这份名单。「在接下来的几周里，我们应该更深入地研究今天提出的所有问题，并致力于做出决定。我认为这意味着，如果我们想继续前进，两周后**尚未**弄清楚或指定的事物都可能不会进入这个分叉，「Beiko 说。
