回顾 EIP-7691 提高 blob 数量 与 gaslimit 的影响

介绍

EIP-7691 最近已在主网上通过 Pectra 硬分叉启用，将 blob 数量从 3 Target 6 Max 提升到 6 Target 9 Max。本分析侧重于这项变更对网络的影响结果，并断言我们之前为增加 blob 数量辩护的分析是正确的。

背景

当提议一个区块时，提议者需要在 4 秒内将区块和所有附带的 blob 快速广播到至少 66% 的网络，否则他们可能会面临区块变为孤块的风险。之前的分析 主要从两个角度考虑这种情况：

• 独立质押者提议本地构建的区块。
• 家庭用户观察这些区块。

这种方法假设这两个群体代表对带宽需求增加最敏感的节点。

评估方法

数据来源

我们的分析利用了 ethPandaOps 监控基础设施的数据，该基础设施通过 Xatu 数据收集系统提供以太坊网络性能的可视性。节点由 ethPandaOps 团队和社区运行。Xatu 连接到 Beacon API 事件流，该事件流不保证事件的发布或排序，因此可以认为是最坏情况的性能。

参数

我们分析了主网 7 天的时间，以了解其影响：

👑 主网

我们都了解并喜爱的 Layer 1

📅 期间：2025 年 5 月 21 日至 28 日

🔲 插槽（Slots）：50,025

📡 节点：123 (29 ethPandaOps, 94 家庭用户)

🌍 国家：27

🔧 共识层客户端：6

指标

我们的分析侧重于我们的 "New Head" 指标。对于那些阅读过我们之前关于 Sepolia & Hoodi 上的 60M Gas Limit 的博文的人来说，这与我们在该博文中使用的指标相同。

⏱️ 区块生产时间线

✓ New Head

当客户端将区块视为新的链头时

• 公式：max(block_event, head_event, blobs_events...)
• 包括执行时间
• 必须等待所有 blob

分析

自从为增加 blob 数量辩护的 ethresear.ch post 以来，Xatu 公共贡献者系统已从大约 20 个节点扩展到大约 80 个节点。我们已经从 9 个国家增加到 27 个国家，现在覆盖 52 个不同的城市。最近也出现了一股提高 gas limit 的浪潮，与之前分析时的 30M 相比，主网目抢跑在 36M。

鉴于这些变化，我们的分析基础略有变化。

1. 贡献给 Xatu 的节点的地理分布发生了变化，更多节点位于更多国家/地区。这一点尤其重要，因为区块传播的瓶颈之一是光速以及数据跨地球传输所需的时间。
2. 最坏情况下的区块大小略有增加，因为 gas limit 增加了。
3. 所有节点处理区块的时间都会稍长一些，因为 gas limit 增加了。

1. 6/9 对家庭用户来说安全吗？

我们可以观察由独立质押者提议并由家庭用户观察到的所有本地构建区块的 ✓ New Head 指标。

图 1：主网（✓ New Head 指标）与组合的区块 + blob 大小（压缩）。每个点代表 Xatu 节点的“New Head”观察。

我们观察到我们的家庭用户已经能够支持增加的 blob 数量，只有少数异常值超出 4 秒的阈值。我们还可以运行与锁定 6/9 相同的分析，以了解今天预测的最大 blob 数量是多少：

图 2：主网的预测最大 Blob 计数(✓ New Head 指标)，具有历史 p99 区块大小。每个点代表 Xatu 节点的“New Head”观察。

那些眼尖的人会注意到，此配置似乎最多支持 20 个 blob！不幸的是，这并不是完整的画面，因为除了我们的 9 个 blob 之外，我们还必须考虑最坏情况下的区块大小。

图 3：主网的预测最大 Blob 计数(✓ New Head 指标)，在 36M gas limit 下，具有最坏情况的区块大小。每个点代表 Xatu 节点的“New Head”观察。

此配置更准确地反映了今天的限制，我们可以观察到预测的最大 blob 计数为 14，这意味着 6/9 对家庭用户来说是安全的。

结果：家庭用户能够支持 9 个 blob 🎉

2. 我们可以支持 60M gas limit 吗？

让我们首先看看在相同配置下，60M gas limit 下最坏情况下的区块大小。

图 4：主网的预测最大 Blob 计数(✓ New Head 指标)，在 60M gas limit 下，具有最坏情况的区块大小。每个点代表 Xatu 节点的“New Head”观察。

现在情况有点危急了！使用 60M gas 的最坏情况区块大小仅支持 10 个 blob，因此 6/9 配置确实达到了我们家庭用户的标准。提醒一下，这些都是最坏情况，但令人欣慰的是，我们可以将这些类型的场景结合起来，并且仍然能够支持我们带宽最敏感的节点。

注意：这突显了将 Pectra 中的 gas limit 限制为 60M 的重要性。

结果：60M gas limit 对于 6/9 本地构建区块的家庭用户来说是安全的 🎉

3. 使用 MEV Boost 时会怎样？

让我们看一下历史 p99 区块大小，但适用于由 MEV Relays 提供的区块。这是一个很好的基准，因为 ~91% 的区块由 MEV Relays 提供。

图 5：主网的预测最大 Blob 计数(✓ New Head 指标)，具有 p99 历史区块大小，MEV Relay 区块。每个点代表 Xatu 节点的“New Head”观察。

与本地构建的区块大致相同，这令人放心。现在让我们看看 60M gas limit 下的最坏情况区块大小。

图 6：主网的预测最大 Blob 计数(✓ New Head 指标)，在 60M gas limit 下，具有最坏情况的区块大小，MEV Relay 区块。每个点代表 Xatu 节点的“New Head”观察。

乍一看，这是一个令人担忧的结果，预测的最大支持 blob 计数为 5！然而，这是 60M gas 下最坏情况的区块大小。一些中继已开始延迟标头响应（进行计时游戏），这很可能是造成这种情况的原因。我们预计随着情况的发展，中继会调整他们的计时游戏，从而使这种对网络的前瞻性分析变得毫无意义。

为了调查我们的 MEV Relay 发现，我们可以以不同的方式查看数据，选择 Xatu 网络“接受”插槽的分布情况。这是一种很棒的说法：

• 对于每个插槽，找到 66% 的 Xatu 节点将区块视为新链头的时间。
• 绘制此指标的 CDF。

图 7：各种配置中每个插槽的 p66(✓ New Head) 的主网 CDF。

我们观察到，与 MEV Relay 区块（实线）相比，本地构建的区块（虚线）始终实现更快的接受时间。这与预期一致，因为本地构建的区块不会受到 MEV 投标-接受舞蹈的开销。在 MEV 数据中也有运营商在玩他们自己的 计时游戏。

与家庭用户节点的 97.1% 相比，高带宽 ethPandaOps 节点达到 <4 秒的 99.5% 接受率。这种差异可能归结为带宽限制，并且可能因家庭用户组中的一些异常值而加剧（...例如我们的团队成员 Barnabas，他的设置可能运行在 20 世纪 90 年代的旋转 HDD 和氛围上）。随着我们继续在 Fusaka 中使用 PeerDAS，这些潜在的异常值将需要进一步调查。

结果：正如预期的；需要监控

结论

我们的评估证实，6/9 对于家庭用户来说是正确的选择，并且我们的数据表明，即使在最坏情况的区块大小条件下，60M gas limit 仍然可行。但是，我们发现 60M gas limit 似乎是家庭用户可以在 Pectra 分叉上支持的上限。

从 MEV Boost 区块收集的见解浮出水面，显示了前瞻性分析的固有问题，但总体上与我们的预期一致。该团队现在专注于 Fusaka，其中包括 PeerDAS，大大增强了我们 Layer 2 朋友的 blob 可扩展性。

致谢

特别感谢我们的贡献者社区，他们提供了分布式监控数据，使这项分析成为可能。他们的参与使我们能够以前所未有的可见性了解以太坊网络行为。

想为我们的监控工作做出贡献吗？成为一个贡献者！

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