🚨 Sunnyside devnetレポート(09/30)がドロップされたばかりで、devnet-5は~11%のメインネット規模(~1.7Kフルノード)で実行されました。 BLOB のスケーリングとネットワークの制限に関心がある場合は、これは必読の記事です。 スレッド 🧵

devnet-5 でのブロブ スループットは 22/33 ブロブを維持し、48/72 に拡張され、ガス使用量は ~45M 付近でピークに達しました。 最大の制限要因はネットワーク容量で、アップロード上限が 50Mbps のフルノードは、48/72 BLOB で常に上限に達しました。

以前の小規模な開発ネットワークとは異なり、フルノードの EL P2P スパイクはゴシップを完全に上回り、大規模な新たな不安定性を生み出しました。ネットワーキングのEL側は、現在、主要なボラティリティ源です。 列のゴシップアップロードの急増は緩和されましたが、これはおそらく、ELトラフィックがすでに帯域幅を飽和させており、ノードが列要求を共有するCLピアの数が増えていたためです。

可用性に関しては、GetBlobsV2 の信頼性は、負荷が高くなるとある程度の低下が明らかに示されました。 Geth と Nethermind はヒット率よりも高い BLOB の可用性を示し、部分的な BLOB のみを保持することが多いことを示唆しており、GetBlobs API からの部分的なリターンを許可することで、より多くの BLOB 数での CL パフォーマンスに役立つ可能性があることを示唆しています。 一方、Reth の GetBlobAPI パフォーマンスは大幅に向上し、ピア数が 2 倍 (~120 対 ~40-60) になり、最終的に過去の同期/OOM の問題が解消されました。

結論： Fusaka は L2 のより多くの BLOB のサポートを解除しますが、現在予定されている BPO はブロックあたり 14 個の BLOB (最大 21 個) の目標までスケールアップされます。この制限を超えるには、このレポートで強調されている重大なボトルネック、つまりアップロード帯域幅、P2P ネットワークの安定性、クライアント固有の外れ値に細心の注意を払う必要があります。 当面の優先事項は、帯域幅効率の向上と、GetBlobs API を介した部分返品の有効化など、クライアント BLOB の処理を改善することです。 Sunnyside Labs は、これらの分野の進歩に引き続き取り組んでおり、ブロブのスループットを限界まで押し上げるよう引き続き取り組んでいきますが、常にネットワークが安全かつ確実に動作することを保証する方法で行います。