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