Ceci est une traduction automatique. L’original en anglais est ici: Update 27 October, 2022
Les dernières semaines ont beaucoup épluché les couches du réseau et veillé à ce que ce qui se trouve en dessous soit stable. Cette semaine, nous parlerons de la manière dont nous espérons intégrer ce travail et de ce que cela devrait signifier pour nous à l’avenir.
Progrès général
Mostafa est profondément ancré dans les mécanismes de consensus et dans la manière dont nous pourrions les appliquer à certains fonctionnements de Safe Network, y compris les problèmes d’adhésion que nous abordons ci-dessous.
@davidrusu et @dirvine sont également très attentifs à ce sujet, travaillant sur les cas extrêmes et s’assurant qu’ils se résolvent avec nos mécanismes prévus.
@bochaco travaille toujours sur l’implémentation de la messagerie et les bogues de connectivité, avec @joshuef et @qi_ma. La branche de travail que nous avons maintenue avant main a l’air bien.
Ensuite, il y a la question de savoir ce qui se passe précisément lorsqu’une requête GET est faite. Qu’est-ce qui doit être signé et quelles informations minimales doivent être envoyées avec le bloc pour que l’adulte puisse être identifié, surveillé et puni en cas d’échec ? @ansleme et @oetyng regardent principalement cela maintenant.
Et sur le front des tests, @chriso réorganise le runner auto-hébergé pour GitHub Actions CI/CD afin de simplifier le fork que nous utilisions.
Prochaines étapes sur la stabilité
Récemment, nous nous sommes efforcés de stabiliser les couches inférieures du réseau (comme nous l’avons vu la semaine dernière). Nous avons simplifié la gestion des connexions et supprimé plusieurs couches de code « retry » des couches sn_client et sn_node, qui masquaient les bogues peu fréquents (qui sont devenus plus fréquents au cours d’un testnet plus long et de nombreux tests). Nous avons travaillé là-dessus dans les couches de gestion des connexions et de stockage des nœuds, ainsi que dans l’adhésion.
Comme nous nous sommes concentrés sur cette instabilité, nous avons opté pour une configuration CI plus simple. Cela a des tests fonctionnant en séquence, mais beaucoup plus cohérents, mais pour quelques problèmes qui surgissent sur main. Mais c’est avec une configuration de gestion de connexion beaucoup plus simple et une grande partie de la couche « réessayer » supprimée.
Nous n’avons pas encore mis cela dans l’essoreuse de testnet, car nous essayons toujours de résoudre les problèmes restants : les blocages d’adhésion… (un correctif est en cours de test pour cela) ; tests d’API parfois lents - qui semblent être liés à la désynchronisation des adhésions ; et des échecs de test DBC très occasionnels.
Nous espérons fusionner notre branche de travail avec main très bientôt. Une fois que nous aurons cela, nous chercherons à verrouiller ces gains de stabilité avec d’autres améliorations de l’IC.
Plus de tests
Nous ajouterons des tests pour vérifier tous les parcours des adultes et des personnes âgées (réactivation des tests fractionnés, équilibrage des données sur le taux de désabonnement, etc.) et vérification de chaque adulte qui doit stocker des données does stockent des données. Cela devrait éventuellement nous permettre de passer à une configuration de chemin heureux plus simple pour les communications client (c’est-à-dire communiquer avec un seul aîné… en attendant un ACK avant de tenter une vérification), ce qui réduira davantage la charge du réseau.
Une fois que nous aurons cela en place, nous chercherons à forcer tous les RP à suivre un flux de travail CI ajusté. Nous rationaliserons les tests pour qu’ils ne s’exécutent initialement que sur les machines Linux (car celles-ci sont les plus rapides). Avec la suite complète en cours d’exécution uniquement lorsque le PR a été examiné (via BORS, notre robot CI).
Cela devrait, espérons-le, accélérer la boucle de rétroaction sur nos PR, avec BORS fournissant la viande CI et les tests sur toutes les plateformes une fois que le PR a été examiné.
Et même si cela seul n’est pas à un million de kilomètres de ce que nous avons maintenant… L’IC devrait être plus stable, plus utile (BORS gère les PR en attente et se rebase automatiquement ; comme nous en avons peut-être déjà parlé ici)… Et… Nous ajouterons ensuite un réseau de test de gouttelettes complet au flux BORS, ce qui signifie que main contiendra uniquement du code qui a réussi tous les tests que nous avons, sur chaque plate-forme, dans toutes les conditions de mise en réseau !
Et avec « main » fiable, testé et publiable, nous serons bien mieux placés pour travailler sur des améliorations, des benchmarks et de nouvelles fonctionnalités sans glisser sur le front de la stabilité.
Liens utiles
- Site Web du réseau sécurisé
- Safe Network Primer
- Principes de base du réseau
- Feuille de route
- Glossaire
N’hésitez pas à répondre ci-dessous avec des liens vers les traductions de cette mise à jour de développement et les modérateurs les ajouteront ici.
En tant que projet open source, nous sommes toujours à la recherche de commentaires, de commentaires et de contributions de la communauté. Ne soyez donc pas timide, rejoignez-nous et créons ensemble le réseau sécurisé!