🚨 Le rapport devnet de Sunnyside (30/09) vient de sortir — concernant le devnet-5 qui a fonctionné à ~11% de l'échelle mainnet (~1,7K nœuds complets). Si vous vous intéressez à la mise à l'échelle des blobs et aux limites du réseau, c'est une lecture essentielle. Un fil 🧵
Test in Prod (Sunnyside Labs)
Test in Prod (Sunnyside Labs)16 sept. 2025
Sunnyside Labs, en collaboration avec @ethPandaOps, @Optimism et @base, a lancé un autre méga-devnet pour Fusaka, avec 56K validateurs et 1.7K nœuds complets - environ 11 % de l'échelle du mainnet - et prenant en charge jusqu'à 72 blobs.
Le débit des blobs sur devnet-5 a maintenu 22/33 blobs, et a été étendu à 48/72, avec une utilisation de gaz atteignant près de ~45M. Le plus grand limitateur était la capacité du réseau : les nœuds complets avec des limites de téléchargement de 50 Mbps atteignaient constamment le plafond à 48/72 blobs.
Contrairement à nos précédents petits devnets, les pics P2P EL pour les nœuds complets ont complètement dépassé le gossip, créant une nouvelle instabilité à grande échelle. Le côté EL du réseau est désormais la principale source de volatilité. Les pics de téléchargement de gossip de la colonne ont diminué, probablement parce que le trafic EL saturait déjà la bande passante et que les nœuds avaient plus de pairs CL pour partager les demandes de colonne.
Concernant la disponibilité, la fiabilité de GetBlobsV2 a clairement montré des dégradations avec une charge plus élevée. Geth et Nethermind ont montré une disponibilité de blob plus élevée que le taux de réussite, suggérant qu'ils détenaient souvent seulement des blobs partiels — ce qui laisse entendre que permettre des retours partiels de l'API GetBlobs pourrait aider les performances de CL avec un nombre de blobs plus élevé. Pendant ce temps, la performance de l'API GetBlob de Reth s'est beaucoup améliorée, doublant le nombre de pairs (~120 contre ~40–60) et se débarrassant enfin des problèmes de synchronisation/OOM passés.
Conclusion : Fusaka débloquera le support pour plus de blobs pour les L2, tandis que les BPO actuellement programmés passeront à un objectif de 14 blobs par bloc (avec un maximum de 21). Pour dépasser cette limite, une attention particulière est requise sur les goulets d'étranglement critiques soulignés dans ce rapport — à savoir la bande passante de téléchargement, la stabilité du réseau P2P et les cas particuliers spécifiques aux clients. La priorité immédiate devrait être d'améliorer l'efficacité de la bande passante et de peaufiner la gestion des blobs par les clients, comme permettre des retours partiels via l'API GetBlobs. Sunnyside Labs reste engagé à faire progresser ces domaines et continuera à travailler pour pousser le débit des blobs à ses limites — mais toujours d'une manière qui garantit que le réseau fonctionne de manière sûre et fiable.
2,83K