Ceci est une traduction automatique. L’original en anglais est ici: Safe Network Dev Update - February 18, 2021
Résumé
Voici quelques-unes des principales choses à souligner depuis la dernière mise à jour du développement:
- Un nouvel ensemble de messages d’infrastructure que
sn_routingpeut utiliser pour mieux gérer et renvoyer les erreurs lors des fractionnements de section et du désabonnement a été ajouté. - Le travail pour traiter les SignatureShares invalides par les mauvais acteurs dans les transferts a commencé, avec des sanctions pour ces mauvais acteurs en cours d’élaboration et d’accord.
- Le travail de flux de messagerie touche à sa fin, ce qui signifie beaucoup moins de code et de complexité pour analyser les messages entrants dans
sn_node, et ouvre la voie à l’intégration des récompenses. - De nouvelles versions de la CLI (v0.19.0) et de
authd(v0.1.1) ont été publiées, ce qui les rend compatibles avec le derniersn_node(v0.26.16), ainsi que plusieurs autres améliorations. - Le tout premier exemple d’application est maintenant disponible dans la caisse
sn_api, montrant comment télécharger un fichier sur le réseau, puis récupérez-le en utilisant son URL XOR. - Nous avons pris des mesures pour intégrer
sn_fsetBRBafin de créer un prototype de système de fichiers distribué P2P byzantin tolérant aux pannes. - Les modifications de la chaîne de sections
sn_routingpour résoudre les fourchettes sont pour la plupart en place maintenant, nos tests indiquant une certaine amélioration de la stabilité du réseau, en particulier autour des fractionnements. -
Encore plus de contributions de la communauté fantastiques à la base de code
Statut Testnet - en attente
Comme discuté la semaine dernière, nous avons décidé de changer tous nos efforts pour inclure des récompenses dans le prochain testnet. Les récompenses elles-mêmes ont été bloquées par un travail connexe pour ajuster les flux de messages après que nous ayons fait le changement pour ne faire que l’accumulation de messages dans sn_routing. Nous pensons que nous sommes actuellement dans les dernières étapes du travail de flux de messages, avec ce que nous pensons être quelques derniers problèmes en cours de résolution (plus de détails ci-dessous). Une fois cela fait, cela ouvre la voie à l’intégration complète des récompenses.
Comme pour tous les progrès révolutionnaires, nous prévoyons que des problèmes seront détectés pendant les étapes d’intégration et de test, nous ne voulons donc pas mettre un calendrier à ce sujet et exercer une pression supplémentaire sur l’équipe. Comme toujours, nous vous tiendrons au courant des progrès précis de ces mises à jour hebdomadaires.
Merci pour votre patience!
Safe Client, Nodes et qp2p
Plan de projet pour les transferts sécurisés sur le réseau
Plan de projet Safe Client
Plan de projet du nœud de réseau sécurisé
Messagerie paresseuse
Pour mieux gérer les problèmes lors de la division de section et pendant le désabonnement, nous avons ajouté un nouvel ensemble de messages d’infrastructure que sn_routing peut utiliser pour renvoyer des erreurs telles que DKGINprocess lorsque nous essayons d’envoyer des messages aux anciens pendant de telles périodes. Pour ce faire, les clients / nœuds fourniront la PublicKey actuelle pour une section, pour autant qu’ils le sachent, et nous pouvons prendre des mesures si celle-ci est, par exemple, obsolète. Ces changements ont été ajoutés dans sn_messaging, sn_client et sn_routing, et nous examinons quelques petits refactors pour simplifier les choses avec les nœuds.
En raison de cela, nous avons encore renforcé la gestion client de ces changements d’infrastructure, donc un changement dans le pipeline permettra aux clients de redémarrer autant de fois que nécessaire. Parallèlement à cela, nous éliminons également les bogues qui se produisent avec le refactor d’accumulation de messages effectué au cours des semaines précédentes.
Pénaliser les mauvais acteurs
La gestion des SignatureShares invalides par de mauvais acteurs dans les transferts est également en cours. Jusqu’à présent, nous avons approuvé un transfert chaque fois que des actions valides «seuil + 1» ont été agrégées avec succès, ignorant les partages défectueux qui ne sont pas nécessaires pour cette agrégation. Nous allons maintenant introduire des mécanismes pénalisants dans le réseau pour punir les nœuds en conséquence après vérification. Nous commençons notre refactor à partir de sn_transfers, car c’est là que les accumulations se produisent pour les transferts de paiement, puis nous progressons à travers les couches.
Flux de messagerie
Lors du passage à l’accumulation dans sn_routing uniquement, nous devions supprimer les informations uniques dans les messages, afin que les anciens signent le même message.
Avec cela, le modèle source et destination a dû être changé et pendant ce temps, nous l’avons simplifié, en amincissant l’interface de messagerie entre sn_node et sn_routing, et en utilisant les mêmes primitives sur la frontière.
Comme l’amorçage du client a maintenant lieu dans la couche sn_routing, ces primitives d’emplacement ont dû être étendues avec une variante client. Un registre de clients connectés a été implémenté dans sn_routing avec la fourniture de la clé publique et de la signature sur l’adresse de socket au démarrage du client. Il y a maintenant beaucoup moins de code et de complexité pour analyser les entréesmessages dans sn_node. Jusqu’à présent, environ 1 000 lignes au total ont été supprimées.
API et CLI
De nouvelles versions de la CLI (v0.19.0) et de authd (v0.1.1) ont été publiées cette semaine, qui incluent tous les correctifs, améliorations et nouvelles fonctionnalités implémentées depuis la version précédente. Comme d’habitude, ils peuvent être mis à jour avec $ safe update et $ safe auth update respectivement. Ces applications sont compatibles avec la dernière version de sn_node v0.26.16, donc pour ceux qui effectuent une mise à niveau, assurez-vous également de mettre à jour votre binaire sn_node ($ safe node install ou $ safe node update).
@scorch a repéré que la toute dernière version de clippy se plaignait sur Windows de la CLI et de la base de code authd, et a soumis un correctif pour cela. Cela nous a conduit à améliorer les contrôles clippy dans nos scripts CI pour s’exécuter non seulement sous Linux mais aussi sous Windows, ce qui devrait éviter que cela ne se reproduise.
Avec l’ajout (par @mav) d’une nouvelle API dans notre type de données CRDT Sequence pour récupérer une entrée spécifiant un seul index plutôt qu’une plage, @mav maintenant a changé notre sn_api pour utiliser cette nouvelle API pour récupérer une version spécifique d’une séquence.
Quelques améliorations ont également été apportées à cette nouvelle CLI (v0.19.0) qui permet à l’utilisateur de configurer des informations d’amorçage pour un réseau en utilisant une adresse IP (v4 ou v6) et un numéro de port, pour plus de détails sur cette nouvelle commande, veuillez vous référer à la section correspondante dans le Guide de l’utilisateur CLI.
Pour ceux qui sont curieux de voir comment l’API Rust évolue et à quoi cela ressemblera pour créer une application avec elle, un tout premier exemple d’application est maintenant disponible dans la caisse sn_api qui montre comment télécharger un fichier sur le réseau, puis le récupérer à l’aide de son URL XOR. Espérons que cela inspirera d’autres personnes à créer d’autres exemples d’applications simples pour notre API Rust Safe, à découvrir les opportunités d’améliorations au fur et à mesure que nous les utilisons, ainsi qu’à être une bonne ressource pour les nouveaux développeurs désireux d’écrire des applications sûres.
CRDT
David Rusu, auteur de rust-crdt ainsi que de notre implémentation BRB, a examiné le code LSeq après que @mav ait signalé des problèmes avec il lorsque de nombreuses insertions sont effectuées. Il a remplacé l’implémentation d’ID qui était basée sur le papier original «LSeq» par un nombre rationnel de la caisse «num». Cela rend le code LSeq beaucoup plus simple et entraîne également une meilleure distribution (plus uniforme), résolvant le problème et permettant l’insertion d’un nombre arbitraire d’éléments. «LSeq» a également été renommé «List». Pull Request.
BRB - Diffusion fiable byzantine
Rappelez-vous sn_fs, notre prototype de système de fichiers utilisant l’arborescence CRDT? Eh bien, cette semaine, nous avons pris des mesures pour intégrer sn_fs et BRB afin de créer un prototype de système de fichiers distribué P2P byzantin tolérant aux pannes.
Tout d’abord, nous avons forké brb_node_qp2p et créé brb_node_tree, ce qui montre l’envoi d’opérations crdt_tree via brb. Ensuite, nous avons modifié la caisse sn_fs et l’avons transformée en bibliothèque. Plus récemment, nous avons créé une caisse brb_node_snfs dans laquelle nous rassemblons tout. À partir d’aujourd’hui, nous avons pu mettre en place deux (ou plus) nœuds et lancer des opérations de répertoire telles que mkdir, rmdir. Les opérations sont reflétées dans le système de fichiers monté de chaque pair. Les opérations sur les fichiers ne fonctionnent pas encore, mais devraient l’être bientôt.
Il convient de souligner qu’il s’agit là d’un travail de démonstration de principe. Il y a beaucoup de détails à régler avant de pouvoir être mis en pratique.
Routage
Les modifications de la chaîne de sections afin de résoudre les fourchettes, comme discuté dans la mise à jour de la semaine dernière, sont pour la plupart en place maintenant. Nous exécutons actuellement des tests internes à l’aide de l’outil de test de résistance pour identifier les problèmes restants. Il semble que la stabilité du réseau s’est un peu améliorée, en particulier autour des scissions. Certains problèmes subsistent cependant et nous sommes occupés à les déboguer, mais dans l’ensemble, nous sommes optimistes quant à cette approche.
Nous avons également fusionné un PR pour corriger une explosion de message, cela se produisait lorsqu’un ancien se déconnectait mais les anciens restants tentaient toujours de leur envoyer le vote, qui, bien sûr, échouerait et déclencherait alors de nouveaux votes" hors ligne ".
Nous avons fusionné un autre PR pour répondre avec une erreur à une demande client s’il y a un DKG en cours. Un DKG (Distributed Key Generation) en cours signifie que la section est sur le point de passer à un nouvel ensemble d’anciens et que les choses pourraient ne pas être entièrement stables ou cohérentes pour le moment, il est donc préférable de le faire savoir au client afin qu’il recule et essaie again peu de temps après.
[UPDATE 22nd Feb] - Navigateur sécurisé
Quelque chose que nous avons oublié d’ajouter à cette mise à jour 
@bzee a créé un PR pour mettre à jour sn_nodejs avec les dernières modifications de l’API, qui est nécessaire pour que le navigateur sécurisé soit mis à jour vers être à nouveau compatible avec le reste du paysage sécurisé. Il s’est également penché sur les limites de la bibliothèque actuelle, et a vu des opportunités pour améliorer les choses!.
Merci @bzee! 
et excuses pour avoir initialement manqué vos contributions dans le PO.
Liens utiles
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é. Alors n’hésitez pas, rejoignez-nous et créons ensemble le réseau sécurisé!