Sunnyside Devnet更新 - 08/13

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…

测试场景

结果

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。

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 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～