Le rapport Devnet de PeerDAS de Sunnyside du 7/14 est là ! Plongeons dans l'état actuel de PeerDAS - combien de blobs pouvons-nous gérer, et quel est le goulot d'étranglement ?

Parmi ces efforts, le rôle de Sunnyside est de faire fonctionner des devnets hebdomadaires dans de nombreuses configurations différentes et de fournir aux développeurs principaux les informations résultantes : • Où se situent les limites actuelles de PeerDAS • Quels composants créent exactement des goulets d'étranglement • À quel point des optimisations telles que Supernodes et GetBlobV2 fonctionnent en pratique

Notre objectif principal est de tester rapidement et de manière flexible de manière à compléter ce que d'autres équipes comme @ethPandaOps font lors des fusaka-devents, en fournissant des retours d'information opportuns qui soutiennent la mise en œuvre continue de PeerDAS.

Cette semaine, nous avons opéré 12 devnets et exécuté 3 suites de tests, en utilisant la dernière image fusaka-devnet-2 de @ethPandaOps : 1. Débit des blobs (nombre maximum de blobs par bloc) 2. Bande passante du réseau (test de charge soutenue) 3. Limitation de bande passante (plafonds de 30 / 20 / 10 Mbps)

1 – Test de Débit de Blob Les résultats des tests ont montré que la plupart des clients CL pouvaient gérer 84 blobs par bloc ou plus, et restaient stables avec au moins 40 blobs. Certains clients ont enregistré un nombre maximum de blobs relativement plus bas par rapport aux devnets précédents - mais cela peut être dû au fait que le nombre de validateurs par nœud dans ce devnet a été réduit de 100 à 8, ce qui a à son tour abaissé le taux de participation de chaque nœud au sous-réseau.

2 – Test de bande passante du réseau Contrairement aux anciens devnets où le réseau devenait souvent instable avec un nombre élevé de blobs, cette fois tous les devnets ont fonctionné de manière stable pendant une période prolongée (~16 heures) même avec 60 ou 72 blobs par bloc. Bien que cela ne garantisse pas une stabilité au niveau de la production, cela montre qu'au moins certaines combinaisons CL-EL ont atteint un niveau de robustesse beaucoup plus élevé grâce à l'optimisation 🚀

3 – Test de contrainte de bande passante Pour vérifier si de véritables stakers à domicile peuvent participer sans problème une fois que PeerDAS est actif, ce test a appliqué des limites réseau et examiné quels facteurs deviennent des goulets d'étranglement dans divers scénarios contraints. Au cours de plusieurs tests, nous avons découvert que l'utilisation de la bande passante des nœuds connaît des pics périodiques - surtout près du début d'un créneau lorsque les blobs sont diffusés - et que ces pics limitent la performance globale du réseau. Le trafic de pointe s'est produit uniformément à travers les nœuds plutôt que d'être causé par un client CL ou EL particulier, et une fois que les pics ont commencé, le réseau n'a pas pu augmenter davantage le débit des blobs. En d'autres termes, le trafic de pointe est le plus grand goulet d'étranglement dans des environnements à bande passante contrainte, et nous devons trouver des moyens de l'atténuer.

De plus, nous avons communiqué avec diverses équipes de clients et encouragé des améliorations pour les problèmes de synchronisation et liés aux pairs.

Le devnet de Sunnyside est toujours en cours 🏗️ ; il réalise des interop-devnets avec plusieurs combinaisons de clients, des tests de bande passante plus granulaires, des tests de spam incluant des transactions normales, et des tests de remplissage/synchronisation, afin d'identifier les goulets d'étranglement dans des environnements qui ressemblent davantage aux conditions de mainnet.