Sunnysideの7/14 PeerDAS Devnetレポートがこちら! PeerDAS の現状を詳しく見てみましょう - どのくらいの BLOB を処理できるのか、そしてボトルネックは何なのか?

これらの取り組みの中で、Sunnysideの役割は、さまざまな構成で毎週開発ネットワークを実行し、その結果得られた洞察をコア開発者に提供することです。 •現在のPeerDAS制限がある場所 •ボトルネックを引き起こすコンポーネントを正確に •スーパーノードやGetBlobV2などの最適化が実際にどの程度うまく機能するか

私たちの主な目的は、@ethPandaOpsのような他のチームがfusaka-deventsで行っていることを補完する方法で迅速かつ柔軟にテストし、PeerDASの継続的な実装をサポートするタイムリーなフィードバックを提供することです。

今週は、@ethPandaOpsの最新のfusaka-devnet-2イメージを使用して、12のdevnetを運用し、3つのテストスイートを実行しました。 1.BLOBスループット(ブロックあたりの最大BLOB) 2. ネットワーク帯域幅(持続負荷テスト) 3. 帯域幅の制約(30 / 20 / 10 Mbpsの上限)

1 – BLOB スループット テスト テスト結果によると、ほとんどのCLクライアントはブロックあたり84個以上のBLOBを処理でき、少なくとも40個のBLOBで安定していることが示されました。一部のクライアントは、以前の devnet と比較して比較的低い最大 BLOB 数を記録しましたが、これは、この devnet のノードあたりのバリデーター数が 100 から 8 に減少し、各ノードのサブネット参加率が低下したためである可能性があります。

2 – ネットワーク帯域幅テスト ブロブ数が多いとネットワークが不安定になることが多かった以前のデブネットとは異なり、今回はブロックあたり 60 または 72 のブロブであっても、すべてのデブネットが長期間 (~16 時間) 安定して実行されました。これは生産レベルの安定性を保証するものではありませんが、少なくともいくつかのCL-ELの組み合わせが最適化🚀によってはるかに高いレベルの堅牢性を達成していることを示しています

3 – 帯域幅制約テスト PeerDASがアクティブになった後、実際のホームステーカーがスムーズに参加できるかどうかを確認するために、このテストではネットワーク制限を適用し、さまざまな制約のあるシナリオでどの要因がボトルネックになるかを調べました。 複数のテストで、ノードの帯域幅使用量が定期的に急増し、特に BLOB がゴシップされるスロットの開始近くで急増し、これらの急増がネットワーク全体のパフォーマンスを制限することがわかりました。バーストトラフィックは、特定のCLまたはELクライアントによって引き起こされるのではなく、ノード間で均一に発生し、バーストが始まると、ネットワークはBLOBのスループットをそれ以上向上させることができませんでした。 言い換えれば、バーストトラフィックは帯域幅に制約のある環境における最大のボトルネックであり、それを軽減する方法を見つける必要があります。

さらに、さまざまなクライアントチームとコミュニケーションを取り、同期やピア関連の問題の強化を奨励しました。

Sunnyside devnetはまだ稼働🏗️しています。複数のクライアントの組み合わせによる相互運用開発ネットワーク、より詳細な帯域幅テスト、通常のトランザクションを含むスパムテスト、バックフィル/同期テストを実施して、メインネットの状態により近い環境のボトルネックを特定します。