Un autre rapport est sorti - le rapport Devnet 8/4 de PeerDAS par Sunnsyide Labs est ici ! Vous vous demandez comment les nœuds se comportent dans des conditions de production avec PeerDAS ? 🧵

Cette fois, Sunnyside Labs a exécuté 2 types de devnets basés sur l'image fusaka-devnet-2 de @ethPandaOps, pour vérifier la stabilité du réseau dans un environnement plus réaliste : 1. Devnet d'interopérabilité (clients CL/EL mélangés avec 50 % de supernode) 2. Devnet Perfect PeerDAS (chaque nœud détient exclusivement une colonne de données unique)

Pour chaque configuration de devnet, nous avons exécuté 3 nouveaux scénarios de test : 1. Blobs avec de Grandes Transactions Ceci vise à enquêter sur la manière dont les transactions régulières affectent la compétition de la propagation des blocs avec la propagation de la colonne de données à travers les nœuds. Nous avons maintenu chaque bloc au test pour atteindre 22 Mgas (taille de bloc de 2 Mo). 2. Limite de Bande Passante + Grandes Transactions Ce test vise à étudier le comportement du réseau dans des conditions de nœuds à bande passante limitée, tels que les stakers à domicile. La bande passante est fixée à 100/50Mbps pour les supernœuds et 50/25Mbps pour les nœuds complets, conformément aux recommandations de l'EIP-7870. 3. Test de Synchronisation Genesis La synchronisation Genesis est testée sur les devnets pour identifier d'éventuels blocages ou bugs dans le processus de synchronisation. Voici les informations que nous avons obtenues de ces tests :

1 - Les grandes transactions ont un faible impact sur le réseau, dans un réseau sans contraintes. Dans les deux Devnets Interop et Perfect PeerDAS, le réseau a supporté 60 blobs sans trop de problèmes, même avec des transactions supplémentaires autres que les blobs. Ce résultat est le même que le scénario de référence avec uniquement des blobs. Cela indique que les transactions ordinaires autres que les blobs ont un impact minimal sur la stabilité du réseau en l'absence de contraintes de ressources.

2 - La limite de bande passante affecte le réseau de diverses manières Avec des uplinks limités à 100/50Mbps pour les supernodes et 50/25Mbps pour les fullnodes, le débit de blobs s'est effondré à 20 blobs/block sur le devnet Interop et 30 blobs/block sur le devnet Perfect PeerDAS. Sous ces limites, une forte augmentation des messages IWANT sur le sujet beacon_block a montré que les blocs de balise avaient du mal à se propager. De plus, une fois que les nœuds ont atteint leurs plafonds de sortie, les mempools EL ont exposé beaucoup moins de blobs, comme en témoigne une forte baisse des taux de réussite de getBlobsV2. Les discussions internes pointent le plafond de 50 Mbps pour les uploads sur les supernodes comme le principal coupable : ce plafond à l'EIP-7870 est conçu pour les constructeurs de blocs locaux, et non pour les supernodes servant le réseau plus large. Ainsi, ces tests étaient plus sévères que les conditions réelles. Sunnyside Labs effectuera un test de suivi cette semaine avec une bande passante de supernode plus élevée pour évaluer l'impact exact de cette contrainte.

3 - La synchronisation Genesis fonctionne pour le devnet Interop, mais a échoué sur le devnet Perfect PeerDAS La synchronisation Genesis s'est déroulée sans accroc sur le devnet Interop, mais s'est bloquée juste après l'époque de mise à niveau Fulu sur Perfect PeerDAS. Si un nœud ne peut pas obtenir toutes les colonnes lors de la synchronisation Genesis, il devrait idéalement interroger des pairs supplémentaires pour combler les lacunes, ce qui n'est pas encore implémenté dans aucun client. La question de savoir si cette récupération de colonnes entre pairs deviendra une fonctionnalité requise avant le Fusaka est encore ouverte ; la décision est attendue lors de l'ACD de jeudi prochain.

4 - Récupération de la garde des validateurs réussie chez @Teku_Consensys La récupération de la garde des validateurs permet à un client de détecter les colonnes historiques manquantes et de les récupérer automatiquement auprès des pairs. Notre test dédié a confirmé que l'implémentation de Teku fonctionne parfaitement - elle a identifié les lacunes et a entièrement récupéré sans accroc dans des conditions normales. Un petit bug dans un cas limite où il y avait un grand vide dans la chaîne sans aucun blob a été identifié lors des tests, qui a été rapidement corrigé par l'équipe. D'autres clients travaillent maintenant sur cette fonctionnalité, et elle sera testée dans les futurs devnets Sunnyside à mesure que l'implémentation sera terminée.

Sunnyside Labs continuera à faire fonctionner des devnets cette semaine, en se concentrant sur les sujets suivants : - Interopérabilité des devnets avec des limites de bande passante de supernœuds plus élevées et des périodes plus longues - Plus d'analyses sur les tests de synchronisation de genesis sur le devnet Perfect PeerDAS - Plus de devnets axés sur la taille maximale des blocs (au format compressé snappy), les nœuds corrompus avec blobber, et la finalité sur un réseau divisé.