ethPandaOps 在5 月 30 日的报告中表示，以太坊Pectra 硬分叉的 blob 容量增强正在分析师预测的阈值范围内运行。
此次更新于 5 月 7 日通过以太坊改进提案 7691 (EIP-7691) 发起，将默认 Blob 数量从 3 个增加到 6 个，并将上限从 6 个提高到 9 个。Blob 是包含在以太坊区块中的数据片段。
该报告对 27 个国家/地区的 123 个信标链节点（其中 29 个位于受控数据中心）和 94 个位于住宅环境中的节点进行了检测，以追踪“新链头”事件。这是客户端宣布某个区块及其 blob 为新链头时记录的时间戳。
基准要求 66% 的节点在四秒内到达新头部，否则该区块有被孤立的风险。
截至 5 月 28 日，涵盖 50,025 个时段的图表显示，家庭用户节点在 99.5% 的时间内可以在四秒内接受本地构建的单独质押者区块，只有少数异常值。
通过对区块大小和到达时间的回归分析，我们发现主节点在达到最后期限之前可以容忍最多 14 个 blob，远高于 9 个 blob 的上限。
报告的结论是“家庭用户能够支持九个 blob”，验证了假设网络边缘带宽敏感度的分叉前模型。
然后，该报告针对6000 万 gas 的最坏情况区块大小对该模型进行了压力测试，反映了 Pectra 下的上限。
同样的回归将安全容量削减至 10 个斑点，留下一个狭窄的余地，但仍然清除了实时 6/9 信封。
报告指出，更高的 gas 上限将进一步收紧窗口，加强社区呼吁，停止未来 gas 上限的增加，直到点对点数据可用性采样 (PeerDAS) 在随后的 Fusaka 版本中发布。
大约 91% 的主链区块通过 MEV-Boost 中继路由，从而在提议者和构建者之间插入投标接受往返。
中继源区块到达新头部的速度略慢，主节点在四秒内注册率为 97.1%，而本地构建的区块注册率为 99.5%。
分布图将尾部归因于中继器，这些中继器作为竞争性时间策略的一部分，延迟了头部广播。最坏情况下的 6000 万 gas 模拟表明，安全的中继器容量为 5 个 blob，但 ethPandaOps 预计，一旦竞争格局对延迟交付进行惩罚，中继器就会进行调整。
此外，开发人员计划在 Fusaka 硬分叉下从提议方 blob 传播转向 PeerDAS。
EthPandaOps 表示，该团队正在全力以赴地整合 PeerDAS，这将减少每个块的带宽，并在部署后为更高的 gas 限制和更大的 blob 数量腾出空间。
报告的结论是，Pectra 第一周的遥测显示，6/9 blob 计划功能符合设计，让客户团队有时间专注于 Fusaka 的数据可用性升级，而无需立即重新审视带宽上限的压力。
