Ceci est une traduction automatique. L’original en anglais est ici: Update 13 July, 2023
Cela devient un peu répétitif, mais encore une fois cette semaine, nous pouvons signaler que le testnet NodeDiscoveryNet est toujours opérationnel. Un peu rugueux sur les bords et nécessitant un raffinement, bien sûr, mais les fondations semblent très solides. Cette stabilité n’est plus une surprise, mais après de nombreuses années d’excitation alors que nous avons tenté de faire voler cette chose, c’est franchement le type d’ennui avec lequel nous pouvons vivre.
Parmi les ajustements résultant des résultats de testnet, nous améliorons la messagerie d’erreur aux utilisateurs lorsqu’un nœud ne parvient pas à se connecter correctement. Actuellement, lorsque cela se produit, il n’y a aucun signe évident pour l’utilisateur, qui doit creuser dans les journaux - bien que le manque de morceaux soit un cadeau.
La plupart des échecs de connexion résultent d’une tentative de connexion à des adresses homologues inaccessibles. Nous avons également vu beaucoup plus de connexions auxquelles vous pourriez vous attendre à des adresses valides (étant donné que libp2p offre le multiplexage). Plus d’une poignée par pair ne devrait pas exister à un moment donné, mais nous en avons vu des centaines ! Après quelques recherches, cela s’est avéré être une fonctionnalité (pas un bogue…) de libp2p, mais pas optimisée pour notre cas d’utilisation. @bzee a tendu la main et Max Inden de Protocol Labs a aimablement proposé un correctif qui a vu le nombre de connexions chuter de dizaines à seulement six ou sept. Merci Max!
Nous avons constaté que les nœuds effectuent une vérification « get_closest » chaque fois qu’un nouveau nœud est ajouté, alors qu’ils ne devraient le faire que lorsqu’ils se joignent pour la première fois, c’est donc un peu plus de temps que nous avons réduit. Il y aura plus.
De plus, nous avons approfondi la sécurité des registres, en considérant ce qui se passerait si un attaquant au lieu d’essayer de modifier les données d’un registre (pratiquement impossible sans l’autorisation correcte) remplaçait simplement l’intégralité du registre - ce qui n’est pas impossible avec notre configuration actuelle. Nous travaillons sur les meilleurs moyens de résoudre ce problème.
Progrès général
@joshuef a apporté quelques modifications au flux de réplication, dont une qui mélange les données en attente de réplication/récupération pour empêcher qu’une extrémité du groupe proche ne soit martelé en raison de la commande Xorspace. Outre les connexions excessives et la sur-messagerie, il s’agit d’une autre cause probable de nœuds qui jettent l’éponge.
@Roland a travaillé sur un test pour vérifier où se trouve une donnée particulière sur le réseau, et @Qi_ma est en train de mettre les registres dans le test de désabonnement , afin que nous puissions voir comment ceux-ci s’en sortent lorsque les choses se déchaînent. Après cela, nous chercherons à affiner nos tests de rétention de données et à porter notre attention sur les DBC.
Dans cet esprit, @bochaco a refactorisé la façon dont le client fragmente les fichiers lors de l’auto-cryptage et paie pour leur stockage. Auparavant, nous découpions les fichiers deux fois (d’abord pour créer l’arborescence de paiement Merkle, puis lors de leur téléchargement). Nous générons maintenant des morceaux et les stockons dans un dossier temporaire local lors du paiement, et lisons à partir de ce dossier temporaire par lots lors du téléchargement des morceaux payés. Cela devrait réduire l’empreinte mémoire du client, en particulier pour les fichiers volumineux, car ils n’ont plus besoin d’être stockés en mémoire.
@Anselme a amélioré le robinet. Le simple fichier autonome qui se trouvait sur la machine locale est maintenant un serveur HTTP qui envoie des jetons aux adresses de la demande. Donc, c’est en libre-service, et nous n’avons plus besoin d’avoir une personne qui réclame la clé Genesis, puis distribue les jetons manuellement lorsque les gens envoient leurs clés. Cela nous place en bonne position lorsque nous serons prêts à commencer à distribuer des jetons pour tester les DBC dans les futurs réseaux de test.
Cela se retrouvera bientôt ajouté à l’outil testnet, que @ aed900 a refactorisé avec @Chriso.
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é!