以太坊核心开发者执行会议第184次会议记录

作者：

\ \ Christine Kim\ \ 研究副总裁

主题

• 以太坊

研究 • 2024年3月28日

以太坊核心开发者执行会议 #184 纪要

2024年3月28日，以太坊开发者通过 Zoom 召开了 核心开发者执行（ACDE）会议 #184。ACDE 会议由以太坊基金会（EF）协议支持负责人 Tim Beiko 主持，是一个双周会议系列，开发者在会上讨论和协调以太坊执行层（EL）的变更。

本周，开发者们分享了关于3月27日星期三区块遗漏数量增加的原因的见解。Prysm 开发者 Terence Tsao 表示，区块遗漏数量增加是由于 Bloxroute MEV 中继的问题，Bloxroute 团队正在调查中。Bloxroute 团队尚未确认该问题是否由他们的中继引起。开发者还讨论了 Paradigm 团队对以太坊状态和历史增长的新研究的结论。开发者批准将两个追溯性的以太坊改进提案（EIP）纳入 Prague/Electra，即 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 问题引起的。可能占比 99%，但仍然存在一个根本问题，即在昨天流量下会发生什么，我怀疑，是的，客户端导入区块的速度可能比以前慢，但这是我没有强烈证据的事情，这仍然有待观察，”Tsao 说。为了应对区块遗漏事件，Lighthouse 客户端团队发布了一个“热修复”版本，以提高节点性能和稳定性。此外，在调查正在进行中时，Bloxroute 首席执行官 Uri Klarman 在 X 上表示，他不认为这些问题与 Bloxroute 中继有关，而是与 blob 在以太坊上的传播方式有关。

以太坊基金会开发者运营工程师 Parithosh Jayanthi 询问该事件是否应该导致开发者重新评估客户端断路器条件，这些条件会自动导致验证者节点回退到本地区块生产。大多数客户端中，断路器条件的默认设置是连续遗漏五个插槽的事件。Tsao 指出，容易被触发的断路器条件是复杂的 MEV 参与者可能利用的潜在攻击媒介。

Prysm 开发者“Potuz”表示，在他看来，该事件突显了中继内客户端多样性实现的不足以及中继和协议开发者之间缺乏沟通。“Terence 已经谈论这些 blob 超过一周了，但没人注意到这件事，一旦爆发，只需要几个电话就能让正确的中继实际查看他们的日志。这是不可接受的，”Potuz 说。

一些开发者建议，下次在报告网络违规行为时，应创建书面帖子，以提高以太坊生态系统中的可见性。为了进一步讨论区块遗漏事件，以太坊基金会研究员 Alex Stokes 鼓励开发者参与下一次 MEV-Boost 社区电话会议。

状态和历史增长数据分析

Paradigm 的数据科学家工程师 Storm Slivkoff 展示了 一项关于以太坊状态和历史增长的新分析。根据他的发现，Slivkoff 指出，状态增长不是以太坊可扩展性的主要瓶颈。“我们发现，现有的消费级硬件可以在很长一段时间内，可能几十年，维持当前的状态增长率。请注意，我这里只讨论存储容量和内存容量。这并没有说明在这种框架下对状态的读取或写入，”Slivkoff 说，并补充说，在他看来，以太坊的“沉默杀手”是历史增长。

在书面分析中，Paradigm 研究团队解释说：“状态是构建和验证新的以太坊区块所需的数据集。状态由合约字节码、合约存储、账户余额和账户 nonce 组成。历史是从创世区块到最新区块同步节点所需的数据集。历史由区块和交易组成。状态和历史是不重叠的数据集。” Slivkoff 补充说，历史的增长速度明显快于以太坊状态。导致历史增长率飙升的最大用例是 rollup 和其他需要桥接到以太坊的协议类型。

Slivkoff 建议开发者认真考虑在下一个以太坊升级 Prague/Electra 中加速处理解决历史增长的 EIP，例如 EIP 4444 和 EIP 7623。他还表示，将进行进一步的分析，以分析以太坊上的其他扩展瓶颈，并将这些方法应用于分析 rollup 上的扩展瓶颈，作为其团队研究的下一步。Slivkoff 说，所有数据都将开源供公众消费，并欢迎反馈。

在 Slivkoff 的演讲之后，开发者们讨论了在短期内解决历史增长的不同方法。正如 在 ACDE #180 上讨论的那样，开发者们正在构建强大的替代网络，在这些网络中，用户仍然可以通过这些网络访问过去某个时期的历史数据，例如在 Merge 升级之前的历史数据，以防无法通过以太坊节点访问这些数据。为了进一步讨论历史过期和提供历史数据的替代方案，Geth 开发者“Lightclient”建议开发者们在以太坊研发 Discord 频道的“history expiry”子频道主题中继续进行讨论。

追溯性 EIP 7610 和 7523

开发者同意实施 EIP 7610 和 7523。这些是追溯性 EIP，它将向以太坊协议添加规则，这些规则可以从网络开始追溯应用，以进一步约束链上某些类型的行为。这些 EIP 的优点是简化了以太坊测试用例，并限制了各种边缘情况的范围，例如创建空账户的边缘情况。已经追溯应用的两个 EIP 包括 EIP 2681 和 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 重申了他的观点，即应该以更低的成本在 EVM 中对 TLOAD 和 TSTORE 操作码进行定价。

• EIP 2935 和 7545（在状态中保存历史区块哈希和 Verkle 证明验证预编译）：Geth 开发者 Guillaume Ballet 提出了这两个提案，作为代码更改，可以为 Verkle 实施提供未来的好处，同时帮助更广泛的以太坊生态系统了解即将到来的 Verkle 升级。

• Ethereum Object Format (EOF)：Besu 客户端维护者 Danno Ferrin 表示，多个客户端团队正在实施 EOF EIP，并且正在为它们编写参考测试。他要求开发者参考 EOF 准备情况矩阵 以获取更详细的更新。

• EIP 7212 和 EIP 3074（secp256r1 曲线支持的预编译和 AUTH/AUTHCALL 操作码）：Besu 开发者 Matt Nelson 强调了这两个正在由 Layer-2 rollup 实施的 EIP。他强调，为了鼓励以太坊和 rollup 之间的兼容性，应该在 Prague 中采用这两个 EIP。

• EIP 7664（访问密钥操作码）：OPLabs 开发者“Protolambda”提出了 EIP 3074 的替代方案，该方案利用访问列表来增强 AUTH/AUTHCALL 操作码的功能。

• EIP 6493（SSZ 交易签名方案）：Protolambda 还表示他支持与 SSZ 相关的代码更改，以提高验证以太坊数据的安全性和效率。

开发者没有时间讨论应该优先考虑 Prague 的此列表中的哪些 EIP。Beiko 说，在接下来的 ACDE 会议开始时，将留出时间在两周内再次讨论此列表。“在接下来的几周内，我们应该更深入地研究今天提出的所有内容，并争取在当时做出决定。我认为这意味着，如果我们想继续前进，那么从现在起两周内没有完全弄清楚或指定的任何内容可能都不会进入此分叉，”Beiko 说。

• 在 Twitter 上分享
• 在 Facebook 上分享
• 在 Linkedin 上分享
• Email

• 原文链接： galaxy.com/insights/rese...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～