Ceci est une traduction automatique. L’original en anglais est ici: Update 06 July, 2023
L’un des changements sur lesquels nous travaillons cette semaine concerne la version mise à jour de libp2p, qui apporte des améliorations bienvenues à AutoNAT - détectant et permettant aux nœuds qui se trouvent derrière un pare-feu ou un routeur de se joindre. Nous serons bientôt en mesure de faire la distinction entre les adresses IP globales et privées, ce qui était un problème auparavant.
Inévitablement, cependant, cela apporte également de nouveaux bugs pour nous garder sur nos gardes. Donc, la plupart de notre travail cette semaine a été sous le capot, bricolant avec des poussoirs plutôt que de polir l’avant.
Cela dit, @ChrisO a maintenant mis à jour l’interface de journalisation, offrant des options de stockage et de formatage aux personnes exécutant un nœud. Les utilisateurs peuvent spécifier le répertoire de sortie du journal ou la sortie standard s’ils le souhaitent, mais par défaut, ce sont désormais :
Linux : $HOME/.local/share/safe/node/<peer-id>/logs
macOS : $HOME/Library/Application Support/safe/node/<peer-id>/logs
Windows : C:\Users\<nom d'utilisateur>\AppData\Roaming\safe\node\<peer-id>\logs
Les journaux des clients sont stockés par défaut dans les répertoires équivalents ...client/logs.
Il y a aussi un choix de formats. JSON peut être spécifié via la CLI si vous le souhaitez.
Comme vous le savez, il y a trois maximes que nous suivons lorsque nous intégrons notre travail avec libp2p. L’un est de laisser Kad dans la mesure du possible, car il y a beaucoup plus d’yeux sur le code libp2p et nous voulons standardiser cela autant que possible. La seconde est de laisser le soin au client - moins les nœuds ont à faire, mieux c’est. Le troisième est de maximiser la sécurité - tout doit être signé et les données doivent être cryptées. Nous constatons que ceux-ci sont actuellement contradictoires. @Anselme a examiné les registres qui ne sont pas sécurisés par défaut lors de la création de Kademlia Records, ce qui les rend vulnérables aux mauvais nœuds. Les nouveaux records ne sont pas non plus CRDT sur Kad, donc des conditions de course sont possibles. Les écritures suivantes sont CRDT donc pas de problème là-bas. Anselme pense avoir trouvé une solution à ces deux problèmes.
@Qi_ma et @joshuef travaillent sur un autre problème concernant la façon dont, lorsqu’un client stocke des morceaux, il trouve les nœuds les plus proches et achemine ses données. Nous estimons que le client devrait faire plus de travail. Nous voulons qu’ils demandent à plusieurs reprises au réseau les nœuds les plus proches et lorsqu’ils obtiennent un correctif, ils mettent le morceau, plutôt qu’un processus de découverte complet.
Notre approche préférée actuelle est celle-ci feat: Using put record for upload by maqi · Pull Request #482 · maidsafe/safe_network · GitHub , qui nous ramène à l’utilisation de l’implémentation Kademlia put, bien que nous l’ayons maintenant vérifiée au moment de la mise. Cela évite aux mauvais nœuds de faire des choses sournoises et simplifie également un peu le code autour de PUT.
Jusqu’à présent, les téléchargements sont un peu plus lents, mais nous sommes sûrs qu’ils peuvent être optimisés en cas de besoin.
Le traitement des paiements est un autre problème que nous examinons, y compris via des DBC appartenant au réseau, ce qui signifierait que nous n’avons pas à vérifier que les paiements sont allés à des nœuds valides à l’époque (puisqu’on n’a plus section-tree + history là-bas) cela simplifie beaucoup les choses. Et en fin de compte, nous pourrons verser des récompenses à partir du réseau lui-même.
Et nous avons examiné la question des redémarrages et des mises à jour. Un nœud défaillant ne doit pas conserver la même clé, mais un nœud valide qui tombe en panne lors d’une mise à niveau, par exemple, doit pouvoir recréer un ID et des clés valides à partir d’une clé précédente.
Progrès général
@Bochaco travaille à travers la logique des DBC et des paiements au réseau.
@aed900 travaille sur une option bin personnalisée pour l’outil testnet GitHub Actions (CI), et @roland a travaillé sur la mise en œuvre d’un réseau fictif qui nous permet de tester plus en profondeur les fonctionnalités des nœuds.
Avec la mise à jour Libp2p, @Benno recherche les bogues et teste les capacités d’AutoNat.
En plus de corriger la sécurité du registre, @anselme a mis à niveau la fonctionnalité du robinet.
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é!