原文标题：《Ethereum All Core Developers Execution Call #184 Writeup》
原文作者：Christine Kim
编译：Luccy，BlockBeats
编者按：
在太坊社区中，所有核心开发者共识电话（ACDE）每两周举行一次，主要讨论和协商对以太坊执行层（EL）的改进。本次为 ACDE 第184次电话会议，本次会议将讨论重点关注了导致3月27日错误过区块数量上升的原因，以及 Paradigm 团队关于以太坊状态和历史增长的新研究。
开发人员在会议上分享了有关 Bloxroute MEV 中继问题以及对 Prague/Electra 中的两个追溯性 EIP 的讨论。此外，还有 EIP 7547（包含列表）、EIP 5920（PAY 操作码）和 EIP 7545（Verkle 证明验证预编译）的开发更新进行了讨论。
Galaxy Digital 研究副总裁 Christine Kim 对本次会议要点做了详细记录，BlockBeasts 将原文编译如下：
On March 28, 2024, the Ethereum development community convened a Zoom meeting for the All Core Developers Execution (ACDE) call #184. The ACDE call is a biweekly series of meetings where decisions related to Ethereum's development are discussed and coordinated. Tim Beiko, the main coordinator supported by the Ethereum Foundation, led the developers in the discussion and consensus-building on proposed changes to the Ethereum Improvement Proposals (EIPs).
本周，开发人员分享了有关导致 3 月 27 日错误过区块数量上升的原因的见解。Prysm 开发人员 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 行为者可以利用的潜在攻击媒介。
Prysm 开发人员「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 频道上以标题为「历史到期」的子频道主题中进行对话。
追溯性 EIPIP7610 和 7523
开发人员同意实施 EIP 7610 和 7523。这些是追溯性 EIP，它们将向以太坊协议添加规则，这些规则可以从网络开始追溯应用，以进一步限制链上某些类型的行为。这些 EIP 的好处是简化了以太坊测试用例，并限制了各种边缘情况的范围，例如创建空账户的边缘情况。两个已追溯应用的 EIP 包括 EIPIP2681 和 3607。开发商同意在 Prague/Electra 激活另外两个追溯性 EIP。有关这些 EIP 约束哪些行为的背景信息，请参阅此处的先前通话记录。
EIP 2537，BLS 预编译
Geth 客户团队已经完成了一些基准测试，以估算 EIP 2537 BLS 曲线操作的 gas 成本。这些新业务将在 Prague/Electra 升级中激活，开发人员目前正在权衡这些业务的定价。Reth 团队的一位代表表示，他的团队还将完成 BLS 曲线操作的额外基准，以协助确定这些操作的 gas 成本。
EIP 7547，包含列表
正如ACDC #130上所讨论的，开发人员正在强烈考虑将 EIP 7547 包含在 Prague/Electra 升级中。本周，以太坊基金会研究员 Mike Neuder 分享了如何修改 EIP 7547 以与账户抽象向前兼容的最新信息。账户抽象是一项持续的举措，旨在为以太坊上的外部账户（EOA）引入更大的灵活性和可编程性，这些账户是用户控制的账户。Neuder 提出了三种不同的方法来解决 EIP 7547 和帐户抽象 EIP 之间的兼容性问题。关于这些解决方案，Neuder 说，「这确实感觉像是包容性设计的复杂性，但我确实认为这三种选择确实有效，而且我也不认为会有灵丹妙药来解决这个问题。我不认为我们会找到一个更好的设计解决这些问题。
Beiko 建议在有限的时间内，在单独的分组会议上继续讨论纳入列表设计。
Prague/Electra 的其他候选 EIP
接下来，开发人员浏览了 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 说。
