Sunnyside Devnet更新 - 08/13
- testinprod
- 发布于 2025-06-13 14:31
- 阅读 15
本文是Sunnyside Devnet在8月13日的更新报告，主要介绍了在混合devnet环境中进行的blob吞吐量、网络使用情况、共识机制以及CPU和RAM使用情况的测试结果。报告指出，即使在带宽受限的情况下，网络也能达到较高的blob吞吐量，但随着压力增加，稳定性和传播速度会受到影响，同时不同客户端在执行层的表现也有差异。
Sunnyside Devnet 更新 - 08/13
你可以在这里找到所有已发布的报告：
概览
我们的 fusaka-devnet-3 规范混合 devnet 在所有场景中实现了 72 个 blobs/块——包括带宽限制的运行——并在 60 M gas 下维持了 >60 个 blobs/块（10 分钟平均），一个 25% 超级节点 / 75% 完整节点混合，以及 1 Gbps/500 Mbps（超级节点）和 50/25 Mbps（完整节点）的上限。
随着负载的增加，稳定性下降：在仅 blob 的基线中，超过约 60 个 blob 时，区块时间变得不稳定；在 +30 M gas 下，超过约 45 个 blob 时变得不稳定；在带宽上限下，超过约 30 个 blob 时变得不稳定——这与完整节点上行链路在 25 Mbps 时的饱和、更慢的传播（峰值时约 7 s 平均）、更高的证明不一致以及 reorgs（在两个连续的运行中分别为 78 和 120）相吻合。
在高 blob 负载下，GetBlobsV2 因 EL 而异：Geth 显示出最高的可用性和命中率；Besu 的性能下降最严重；Nethermind 报告的平均 blob 池可用性高于 Reth，但命中率较低，这意味着每个区块的完整 blob 集合较少。
介绍
这是在准备与 EthPandaOps 合作的 fusaka‑devnet‑4 时执行的一个简短的混合 devnet 运行，但它仍然产生了有用的信号。我们运行了一个 fusaka-devnet-3 规范的 devnet，其中 25% 是超级节点，75% 是完整节点，对超级节点应用了千兆位上限，对完整节点应用了 25/50 Mbps 的上/下行链路。我们将 gas 限制提高到 60 M，并在“大型 tx”阶段中，将每个区块的目标值设置为 ~30 M gas。我们逐步分阶段加载：从基线开始（仅 blobs 或仅大型交易），然后将两者结合，最后应用带宽限制。目的是推断出 fusaka-devnet‑4，后者将在比例上减少超级节点、提高 gas 和限制带宽的情况下，将 blob 目标推向 48/72。
Devnet 信息
设置 & 配置
| 节点组合 | 80 个节点，带有 4 个 Grandine/Lighthouse/Prysm/Teku x Besu/Erigon/Geth/Nethermind/Reth |
|---|---|
| 硬件 | 8 个 vCPU / 16GB RAM / NVMe SSD |
| 验证器分布 | 每个客户端 8 个验证器 |
| 超级节点分布 | 25% 超级节点 / 75% 完整节点 |
| 客户端镜像版本 | |
| 网络配置 |  GitHubfusaka-devnets/network-configs/devnet-ssl-8 at main · testin… |
测试场景
| 场景 | Blob 吞吐量 | TX 吞吐量 | 带宽 | 仪表盘 |
|---|---|---|---|---|
| 1. 基线 Blobs | a) 增量 0 → 72<br>b) 稳定高负载 72 (0.5 小时) | - | - | Grafana (a) Xatu (a) Grafana (b) Xatu (b) |
| 2. 基线大型 Txs | - | ~30M gas @ 2.5~3MB 区块大小 | - | Grafana Xatu |
| 3. Blobs w/ 大型 Txs | a) 增量 0 → 72<br>b) 稳定高负载 72 (1 小时) | ~30M gas @ 2.5~3MB 区块大小 | - | Grafana (a) Xatu (a) Grafana (b) Xatu (b) |
| 4. Blobs w/ 大型 Txs 带宽限制 | 增量 0 → 72 | ~30M gas @ 2.5~3MB 区块大小 | 超级节点：<br>- 1Gbps 下载<br>- 500Mbps 上传<br>完整节点：<br>- 50Mbps 下载<br>- 25Mbps 上传 | Grafana (第一次运行) Xatu (a) Grafana (第二次运行) Xatu (b) |
结果
1. Blob 吞吐量
带宽限制场景下的 Blob 吞吐量
ALT
带宽限制场景下的 Gas 使用量
ALT
带宽限制场景下的平均区块时间
ALT
在所有场景中——包括带宽限制的运行——我们能够在峰值时交付每个区块 72 个 blob，并在 10 分钟平均值上维持 >60 个 blob，这表明网络可以在有利的条件下满足 48/72 的目标。值得注意的是，这是在比早期测试更少的超级节点（1/4）和更高的 gas 限制（60 M）下实现的；上面的数字反映了带宽限制的情况。主要关注的领域是区块时间：不稳定性（>14 s）开始于纯 blob 基线中约 60 个 blob，添加 30 M gas 交易时约 45 个 blob，以及应用带宽约束时约 30 个 blob。
| 1) 基线 blobs | 3) Blobs + 30M gas | 4) Blobs + 30M gas + 带宽限制 | |
|---|---|---|---|
| 区块时间不稳定 (≥14s) | 60 | 45 | 30 |
| 最大 10 分钟平均吞吐量 | 60 | 60 | 60 |
| 最大吞吐量 | 72 | 72 | 72 |
2. 网络使用情况
2.1. 带宽限制
带宽限制场景下完整节点的平均和最大网络传输量
ALT
超级节点在带宽上限下有充足的余量，但完整节点始终受上行链路的限制。一旦完整节点的聚合最大上传量达到 25 Mbps 的上限，区块时间就会急剧上升，这表明上行链路是及时数据传播的瓶颈。先前的分析表明，这些峰值是聚合的，而不是单个节点的异常值（Sunnyside Devnet 更新 - 07/14 - 通过检查单个节点，我们没有发现任何单个“不良行为者”节点导致所有流量，而是发现了…）；下面的列侧车 gossip 使用情况表明，在无限制的运行中，列 gossip 占据了峰值的主导地位。我们推测完整节点峰值与提议者职责相吻合，但尚未有确凿的证据。鉴于 EIP‑7870 的 25/50 Mbps（证明者）和 50/100 Mbps（提议者）指导，如果峰值不限于提议者，并且证明者受到 25 Mbps 上行链路的重大影响，则可能需要重新考虑最低验证器带宽要求。
在 Blobs w/ 大型 Txs 场景中，完整节点的平均和最大列 gossip 上传使用量
ALT
2.2. EL Interop
在 Blobs w/ 大型 Txs 场景中，执行层完整节点的平均网络使用量
ALT
出现了一种一致的 EL 模式：Geth 的平均上传量超过了其下载量，而 Besu 和 Erigon 则显示出相反的情况；Reth 和 Nethermind 更接近于对等。此行为似乎对对等节点计数不敏感。这意味着 Geth 节点充当了强大的传播器，这与 4. GetBlobsV2 指标 中的 GetBlobsV2 可用性和命中率结果一致。
3. 共识
当我们分层施加压力时，传播会退化。在最高负载下，区块传播在仅 blob 基线中平均约为 1.5 s (σ≈1.5 s)，添加大型交易时平均约为 3 s (σ≈2 s)，在带宽限制下平均约为 7 s (σ≈3–4 s)（p. 7）。我们丢失了在带宽限制窗口中进行列侧车传播的 Xatu 计时，但区块级别的指标表明类似的速度下降。1. Blob 吞吐量 中观察到的在受限带宽下，传播延迟是区块时间升高的最可能驱动因素。
带宽限制场景下的区块传播
ALT
带宽限制场景下的区块传播扩散
ALT
证明不一致随着负载的增加而增加 - 仅大型 tx 中几乎没有，blob 基线中更多（尤其是在较高的 blob 计数下），并且在组合 blob + 大型 tx 时更多。在带宽限制下，我们还看到了 reorgs：第一次限制运行中有 78 个，第二次运行中有 120 个。简而言之，受限带宽似乎进一步减慢了数据扩散的速度，足以导致非共识，这表现为证明不一致和 reorgs。
带宽限制场景下的链重组（左） 带宽限制场景下的证明一致性比率（上）
ALT
4. GetBlobsV2 指标
我们对 EL 侧的 GetBlobsV2 指标进行了检测；Erigon 在测试时未公开这些指标。在组合的 blobs + 大型 tx 场景中（blob 吞吐量随时间增加），Geth 向 CL 交付了最高的 blob 可用性和命中率，这与其在 2.2. EL Interop 中较高的相对上传量一致。Besu 在高 blob 负载下性能下降最严重。Nethermind 和 Reth 之间出现了一个有趣的对比：Nethermind 的 blob 池平均可用性更高，但其实际命中率较低 - 这表明它更经常缺少每个区块的完整 blob 集（仅当存在该区块的所有 blob 时，API 才会返回命中）。与 Besu、Geth 和 Nethermind 相比，Reth 的平均对等节点数减少了一半或更少，这可能解释了其较低的 blob 可用性。在带宽限制下，所有客户端的绝对可用性和命中率都下降了，但相对模式保持不变。下面的图说明了这些趋势。
在 Blobs w/ 大型 Txs 场景中，blob 池中的 blob 速率
ALT
在 Blobs w/ 大型 Txs 场景中，GetBlobsV2 命中率
ALT
5. CPU & RAM 使用情况
所有 Reth 实例的内存使用情况
ALT
整个集群的 CPU 通常都很舒适，很少有节点出现峰值。
Reth 的内存令人担忧：我们观察到其所有节点都存在泄漏，即使在没有 blob 流量的阶段，也导致重复的 OOM 式重启；这个问题已经在前一周报告过了。一些 Erigon 和 Besu 节点的使用率很高，达到了 80% 以上，但没有达到限制。
结论 & 讨论
本次运行表明，即使在带宽上限下，也可以实现高 blob 吞吐量 - 峰值交付 72 个 blob 并维持 >60 个 blob 的 10 分钟平均值。但是，当我们添加压力时，系统会受到传播的限制：在仅 blob 的基线中，区块时间在超过约 60 个 blob 时变得不稳定，在具有约 30 M gas 交易的情况下在超过约 45 个 blob 时不稳定，以及在应用带宽上限时在超过约 30 个 blob 时不稳定。带宽上限主要影响完整节点的上传，这与观察到的平均区块传播从约 1.5 s 到约 7 s 的逐步增加（在最高负载下）以及受限运行中证明不一致和 reorgs 的激增相吻合。在执行方面，客户端行为不统一：Geth 传播更多数据并表现出更高的 GetBlobsV2 命中率，Besu 在高 blob 负载下表现不佳，并且相对于 Reth 而言，Nethermind 的更高平均可用性并不总是转化为 GetBlobsV2 的完整集命中。最后，除了 Reth 内存泄漏（需要进行跟进）外，资源余量在很大程度上是足够的。
展望 fusaka‑devnet‑4 在类似带宽限制下更高的 blob 目标 (48/72) 和增加的 gas (100 M)，我们预计将存在吞吐量余量，但传播的限制会越来越大。如果验证器上行链路对于很大一部分节点仍然保持在 25 Mbps，我们应该预期区块时间的不稳定性会更早出现，并且共识流失会在比无限制运行中更低的 blob 计数下升高。
下一步
本周我们一直在与 EthPandaOps 一起运行和分析 fusaka-devnet-4 节点。我们还将继续与 EthPandaOps 和 Ethereum P2P 团队合作进行其他测试用例，以加强 Fusaka 的实施。待定的部分测试用例包括：
Perfect PeerDAS
P2P 团队测试用例
Chaos 工具
- 原文链接： testinprod.notion.site/2...
- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
