Ceci est une traduction automatique. L’original en anglais est ici: Update 19 October, 2023
C’est formidable d’être arrivé au point où, côté client, nous pouvons au moins consulter le forum, demander des journaux lorsque quelque chose ne fonctionne pas et le réparer à la volée. Par exemple, le problème des morceaux manquants lors du téléchargement de fichiers volumineux. Dans ce cas, il s’agissait de regrouper des morceaux lors du téléchargement.
En fait, la semaine a été bonne pour les correctifs, dont beaucoup sont liés à nos tests internes et à notre intégration, mais certains sont également plus visibles. Celui qui vient d’être publié traite d’un problème où les clients payaient trop cher pour les téléchargements. Chaque fois qu’un remboursement était requis, le client rembourse (actuellement) tous les nœuds du groupe proche plutôt que seulement celui dont le taux est le plus élevé. Ainsi, même si nous devons améliorer cela (pour ne pas payer trop cher), les nœuds jetaient en fait simplement l’argent gratuit qui leur était envoyé s’ils détenaient déjà les données. Maintenant, ils prennent tous les jetons qui leur sont envoyés, avant de vérifier si c’est réellement suffisant (le transfert de jetons ne peut de toute façon pas être annulé).
En enquêtant sur un journal client de @Toivo, qui montrait le client en boucle sur les téléchargements de fragments, Qi a découvert que la cause était la perte de connexions réseau et de tables de routage. Dans ce cas, il peut être préférable de simplement mettre fin au client et de le faire recommencer.
Ce fut également une excellente semaine pour la collaboration externe. Nous avons eu une réunion productive avec Max Inden d’IPFS qui est l’un des principaux gars de Rust libp2p, expliquant comment nous utilisons Kademlia/Libp2p, ce qui est assez différent de la façon dont IPFS l’utilise. Dans IPFS, il s’agit de suivre qui stocke les données plutôt que de gérer les données elles-mêmes. En tant que tel, il est conçu pour les petits transferts de données, tandis que Safe est conçu pour les gros transferts, c’est pourquoi nous disposons de notre propre mécanisme de réplication. Quoi qu’il en soit, ce fut une bonne rencontre d’idées et nous sommes impatients de poursuivre notre collaboration et de voir comment nous pouvons contribuer en amont, AutoNat étant une cible privilégiée.
Merci à tous ceux qui ont repéré les anomalies et envoyé des journaux. Très appréciée. Parfois, il est difficile de reproduire les erreurs de notre côté, elles peuvent donc être très utiles. Josh, Qi et Roland les ont examinés et ils nous ont aidé à résoudre un certain nombre de problèmes cette semaine.
Nous avons identifié la cause première de la fuite de mémoire principale des nœuds qui « rappellent » lorsqu’ils remarquent que l’un d’entre eux est perdu, ou apparemment derrière un NAT. Ce processus ne meurt pas comme il le devrait, nous avons donc supprimé une partie du code autour de cela et constaté une baisse décente de la mémoire. Nous suivons actuellement l’effet de cette démarche et observons s’il y a d’autres domaines que nous pourrions améliorer ici.
HeapNet2 s’avère être une bête robuste. Nous avons apprécié le commentaire de @neik « le silence dans l’oreille est assourdissant signifie que nous avons de moins en moins de raisons de nous plaindre mdr »
Maintenant que les chargements et téléchargements de blocs semblent stables, nous pouvons nous concentrer sur les registres, payer la Fondation et optimiser la réplication.
Nous espérons que vous avez remarqué que les gars sont venus sur le forum cette semaine. Si vous voyez quelque chose qui ne va pas, envoyez-nous un ping. Le prochain testnet devrait concerner le paiement des redevances, nous travaillons simplement sur une nouvelle configuration pour vérifier les choses là-bas.
Progrès général
@anselme a rendu les paiements plus rapides et plus efficaces, en transformant CashNotes (lourds) en virements (légers) dès que possible dans le code pour éviter traiter de gros CashNotes qui doivent être lus à partir du disque. Cela se traduit par une empreinte mémoire plus petite car les transferts sont beaucoup plus légers que CashNotes et beaucoup moins d’E/S disque.
Il a également corrigé une faille potentielle possible double dépense, en faisant de tout fractionnement une erreur, à l’exception des registres pour lesquels, en tant que CRDT, les fractionnements sont gérés. côté client.
@roland a ouvert un PR pour autoriser les utilisateurs à configurer Open Metrics sur le port du serveur. Il étudie également l’auto-réparation via des requêtes et des angles de mise en cache potentiels.
@chriso a créé une nouvelle caisse appelée « sn_releases » pour exposer un référentiel permettant de télécharger et d’extraire nos binaires de version. Il a également fait un PR sur une caisse de rouille pour la gestion des services système. Ce travail ouvrira la porte à un outil de gestion des nœuds (pour permettre des mises à jour automatisées).
Fraîchement sorti de sa victoire en s’attaquant au mystère des morceaux manquants lors du téléchargement et en résolvant l’énigme de la boucle client, @qi_ma enquête maintenant sur une énigme similaire : le syndrome des nœuds sans morceaux. Il a des pistes intéressantes autour du biais « PeerId », qui pourraient bien expliquer certaines distributions inégales de nœuds/morceaux/récompenses. 
@bochaco a pratiquement terminé les paiements des redevances réseau, y compris la validation des montants payés par adresse de nœud. Ceci est prêt maintenant au moins comme première étape pour que le paiement des redevances nettes soit effectué par les clients, vérifié par les nœuds et que les notifications soient envoyées par les nœuds via GossipSub. Tous les nœuds sont par défaut abonnés au sujet GossipSub mais uniquement le paiement des royaltiesAucune notification n’est envoyée sur le sujet.
@joshuef a examiné combien de nœuds doivent être payés pour détenir un morceau. En théorie, il ne peut s’agir que d’un seul système, ce qui présente l’énorme avantage de la simplicité, mais pourrait s’avérer risqué si le nœud tombe en panne avant que la réplication puisse avoir lieu. @bzee exécute des tests sur ce scénario. Josh et @dirvine travaillent également sur la manière d’identifier et d’éjecter/ignorer les nœuds défectueux.
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é!