Sunnyside Devnet更新 - 04/08
- testinprod
- 发布于 2025-09-04 23:43
- 阅读 31
本文是Sunnyside Devnet 2025年4月8日的更新报告，主要探讨了CL（共识层）对EL（执行层）中getBlobs的依赖性，通过禁用EL端的getBlobs功能，观察blob吞吐量的变化以及CL的传播效果。实验结果表明，在有良好的getBlobs命中率时，网络性能更优，且getBlobs有助于更快地准备好区块。
Sunnyside Devnet 更新 - 04/08
你可以在这里找到所有已发布的报告：
概览
本周，我们专注于研究 CL 对 EL 的 getBlobs 的可能依赖性。
我们想确定当我们在 EL 端禁用 getBlobs 时，blob 吞吐量如何变化，并观察 CL 的传播效果如何。
没有 getBlobs 的 Pectra：
50 个 blobs/区块
带有 getBlobs 的 lighthouse/geth：
43 个 blobs/区块
没有 getBlobs 的 lighthouse/geth：
35 个 blobs/区块
带有 getBlobs 的 lighthouse/nethermind：
45 个 blobs/区块
从以上测试得出：
没有 getBlobs，Lighthouse 单独处理了 35 个 blobs/区块。
良好的 getBlobs 命中率确实能提升网络性能。
没有 getBlobs 的 Pectra
使用 50 个 lighthouse-geth 节点，我们手动修改了
getBlobs函数，使其始终返回
nil
在没有 getBlobs 的情况下，我们观察到 pectra devnet 可以处理大约
50 个 blobs/区块
。
我们可以观察到上述指标保持在合理的时间范围内，这允许 blob/区块在网络中正确传播。
我们之前在 pectra devnet 上的测试表明，网络可以处理高达
72 个 blobs/区块
而没有问题。
在一个具有无限带宽限制的最佳网络中，我们观察到网络可以处理超过 50 个 blobs，仅通过 CL 传播 blobs，这仍然远高于当前限制。
Lighthouse/Geth
在这里，我们将比较具有 getBlobs 和禁用 getBlobs 的 lighthouse-geth devnet。
带有 getBlobs
ALT
使用 getBlobs，我们看到网络处理大约
43 个 blobs/区块
。
没有 getBlobs
ALT
在没有 getBlobs 的情况下，我们也看到了相似的数字，大约
35 个 blobs/区块
。
观察
带有 getBlobs
ALT
对于具有 getBlobs 的网络，节点大多显示 100% 的 getBlob 命中率，直到网络变得不稳定。
带有 getBlobs
ALT
没有 getBlobs
ALT
无论有没有 getBlobs，都有类似数量的数据列 sidecars 被 gossip 和验证。
带有 getBlobs
ALT
没有 getBlobs
ALT
然而，使用 getBlobs 存在更高的数据列处理失败率。
带有 getBlobs
ALT
没有 getBlobs
ALT
数据列 sidecar gossip 验证运行时对于 getBlobs 来说也更高。这似乎是由于 Lighthouse 会处理/验证来自 gossip 和 getBlobs 的数据列。这是 Lighthouse 中一个已知的改进，将被合并。
带有 getBlobs
ALT
该指标也与带有 getBlobs 的 devnet 中记录的数据列处理等待时间一致。
带有 getBlobs
ALT
没有 getBlobs
ALT
在没有 getBlobs 的情况下，节点显示更高的 beacon_block_delay_attestable_slot_start，表明区块变得可证明的速度较慢。由于该值超过 8 秒，我们看到网络变得不稳定。 使用 getBlobs，区块在 slot 时间内更早地被导入。
以上指标表明
getBlobs通过从 EL 获取 blobs，有助于更快地准备好区块。
带有 getBlobs 的 Lighthouse/Nethermind
在 Nethermind 中，我们观察到大约 45 个 blobs/区块，直到网络变得不稳定。
在整个测试过程中，getBlob 命中率大多保持在 100%，直到网络变得不稳定。
观测
在 lighthouse-nethermind-3 中，我们观察到在网络变得不稳定之前 getBlob 命中率较低（我们尚未找出原因）。
在同一时间戳期间，该特定节点显示的 beacon_block_delay_attestable_slot_start 比其他具有 100% blob 命中率的节点高出约 5 倍。
这也与 lighthouse/geth 的发现一致，即 getBlobs 在可证明的延迟方面表现更好。
我们还类似地看到了更高数量的数据列 sidecar gossip 验证和列处理失败，就像带有 getBlobs 的 lighthouse/geth 一样。
结论
在 pectra 测试中，我们确实观察到在没有 getBlobs 的情况下 blobs/区块的数量较少。
在 lighthouse/geth 测试以及 lighthouse/nethermind 测试中，我们观察到网络通过更好的 getBlobs 性能处理了更多的 blobs/区块。
我们假设
45 blobs/block是在出现计算瓶颈之前的最大 blob 计数。 在没有 getBlobs 的情况下，CL 的 gossip 可以处理
35 blobs/block没有问题。
如果响应中缺少任何 blobs，CL 当前会丢弃它们，并且仅使用 100% 命中率的 getBlobs。 因此，最好了解当前主网或测试网中的平均 getBlobs 命中率。
下一步
我们的下一个行动项目是：
识别带有 getBlobs 的 lighthouse/geth 中的列处理失败原因。
使用其他 EL（如 besu / erigon / reth）和不同的 blobpool 性能验证上述发现。
使用其他 CL 测试上述场景，并提供 PeerDAS 的不同计时指标
一旦分布式 blob 发布准备就绪，量化其相对于现状的性能改进
- 原文链接： testinprod.notion.site/S...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
