Sunnyside Devnet更新 - 04/15
- testinprod
- 发布于 2025-05-16 22:40
- 阅读 9
本文总结了Sunnyside Devnet的最新进展，重点关注不同执行层（EL）客户端与Lighthouse共识层客户端的配对性能，以及Devnet-6的测试情况。文章分析了各EL客户端在blob处理能力、资源利用率以及稳定性方面的表现，并强调了统一EL指标的重要性，以便更深入地比较不同客户端的性能，并规划了后续的测试步骤。
Sunnyside Devnet 更新 - 04/15
你可以在此处找到所有已发布的报告：
概述
本周测试了两项核心举措：
CL 与不同 EL 的性能
Besu 实现了最多的 blob 数量 (50)，而 Erigon 最少 (18)。
Besu 的性能尽管不稳定，但值得怀疑。
我们需要更统一的 EL 指标。
Geth 是资源效率最高的 EL 客户端。
Devnet-6 上的性能
刚刚开始测试，但仍在修复小问题
1. 使用不同的 EL
上周，我们收集了 Lighthouse 客户端与 Reth、Erigon 和 Besu 以及 Geth 和 Nethermind 配对的数据。
getBlobs这次为所有测试启用了。
Lighthouse/Reth：
35 个 blobs/区块
Lighthouse/Erigon：
18 个 blobs/区块
Lighthouse/Besu：
50 个 blobs/区块
Lighthouse/Geth（上周）：
43 个 blobs/区块
Lighthouse/Nethermind（上周）：
45 个 blobs/区块
Lighthouse/Besu
Lighthouse/Besu 是表现最好的配对，最多可以提供
50 个 blobs 每个区块
。
主要见解
更不稳定，但结果更好
与表现不如他们的其他 EL 相比，使用 Besu 的客户端通常更不稳定。
例如，P2P 状态比其他状态更早开始降级。
Lighthouse/Besu 从
~4 小时
从开始
Lighthouse/Reth 从
~6 小时
从开始
请参阅下面 Besu 和 Reth 之间的比较（其他客户端也显示出与 Reth 类似的模式，在结束时下降）。
Besu 节点评分
ALT
Reth 节点评分
ALT
节点数（入/出）
其他指标比其他客户端的指标更早地显示出不稳定性。
在测试期间，有时交易会在队列中累积，并创建大型区块。
发生这种情况时，我们看到
节点在头部滞后一段时间，而
getBlobs 命中率暂时下降
但是，它很快恢复到 100% 的命中率，并且网络像往常一样进行。在我们的其他测试中，我们看到 getBlobs 的性能变得更差，减少了区块传播时间，导致 CL 相互降低评分，从而导致网络不稳定。
在 besu 中，我们观察到，当 EL 可以快速恢复 EL blob 传播时，CL 可以持续利用 getBlobs 来优化 blob 传播。
Lighthouse/Erigon
我们最多只能达到大约
18 个 blobs/区块
使用 Erigon。
我们正在再次运行 lighthouse/erigon devnet，以更具体地找出节点无法处理更多区块的原因。
主要见解
用于深入比较的统一和更多 EL 指标
在探索为什么 Erigon 客户端的表现不如其他客户端时，我们强烈感到需要在 EL 端使用统一指标。我们发现唯一有用的统一指标是从 EL 成功获取 blob 的速率。
Erigon Blob 获取成功率
ALT
Besu Blob 获取成功率
ALT
Lighthouse/Geth
从上周开始，测试结果为
43 个 blobs 每个区块
。
主要见解
高效与完全资源利用
在所有 EL 中，Geth 是 CPU 效率最高的，保持在 <~40%（除了 Erigon，它很早就停止了）。
Geth CPU 使用率
ALT
来自其他对的 CPU 使用率
Geth 也是内存使用量最少的。
Geth 内存使用率
ALT
Besu 较高的 RAM 使用率值得注意，提出了一个问题，即这是否是利用可用资源最大化性能的刻意尝试，或者仅仅是不稳定的迹象（例如，由于较低的 blob 命中率，需要更多资源来进行列gossiping）。
Besu 内存使用率
ALT
来自其他客户端的 Ram 使用率
Lighthouse/Reth
网络能够处理大约最多
35 个 blobs/区块
。
Lighthouse/Nethermind
Lighthouse-Nethermind 对显示
45 个 blobs/区块
上周。
2. Devnet-6
我们目前正在运行具有各种节点组合的 devnet-6 规范。
devnet-6 节点的运行方式存在一些不稳定性，因此我们正在运行多次测试迭代。
随着我们使用 devnet-6 运行更多测试，我们将返回更清晰的图片。
结论
本周的测试重点是确认 EL 性能如何影响 PeerDAS 的整体性能。
getBlobs 性能以及每个客户端中的其他资源利用率都会影响 CL 计算/将 blob 传播到网络的能力。
从 CL 相关的与数据列gossip/计算/重建相关的其他指标在所有测试中都相似。
理想的情况是找出每个客户端正在使用多少资源以及它如何随 blob 吞吐量变化，但我们还没有每个进程的资源指标。
下一步
我们的下一步行动是：
运行 devnet-6
使用相同的配置重新运行之前的 peerdas devnet，以比较分布式 blob 发布/单元证明对 EL 的影响
运行 CL 特定的 devnet，以查看带有 devnet-6 规范的每个 CL 的性能。
- 原文链接： testinprod.notion.site/S...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
