Ceci est une traduction automatique. L’original en anglais est ici: Safe Network Dev Update - January 28, 2021
Sommaire
Voici quelques-unes des principales choses à souligner depuis la dernière mise à jour du développement:
-
Aujourd’hui, c’est la Journée de la protection des données (également connue sous le nom de Journée de la protection des données dans certaines parties). Nous encourageons tous les membres de notre communauté, ainsi que toutes les personnes associées à d’autres projets ayant des objectifs similaires, à faire plus d’efforts que jamais pour atteindre ces objectifs communs. Chaque jour, nous nous rapprochons tous d’un pas de plus.
- Le PR récompenses est maintenant en cours d’examen par les pairs et de tests - regarder les pièces gagnées est très proche!
- Nous avons finalement cloué et corrigé le bug de blocage des connexions qui nous échappait depuis quelques semaines.
- Le débogage du problème de blocage des connexions a mis en évidence certains domaines à améliorer pour en faire un processus beaucoup plus simple si quelque chose de similaire se reproduit et des travaux sont donc en cours pour mettre à jour qp2p et simplifier son API.
- Avec ce PR maintenant fusionné, la CLI est maintenant capable de vérifier le solde de sa propre SafeKey.
- De nouvelles versions de sn_authd (v0.0.15), CLI (v0.17.2) et sn_node (v0.25.39) ont été publiées, avec la CLI et authd maintenant construites en utilisant MUSL pour Linux.
Pas de réseau de test public pour l’instant …
Nous étions vraiment sur la clôture aujourd’hui alors que nous examinions s’il fallait continuer à corriger les messages, les récompenses et apporter quelques améliorations à qp2p (toutes décrites plus en détail ci-dessous), ou mettre en place un réseau de test public avec tout ce que nous avions jusqu’à présent. Nous avons décidé que la bonne décision était de continuer avec les corrections et les améliorations que nous sommes actuellement en train de faire, et donc de suspendre un réseau de test public pendant ce que nous pensons être encore quelques jours. Nous avons décidé qu’il y aurait trop de distractions pour l’équipe dans la configuration et le support du testnet, plus les versions « * pourraient * » auraient été moins stables et plus difficiles à déboguer que nous le souhaiterions si les correctifs et améliorations de la messagerie et de qp2p manquaient. Le retarder nous donne également une chance de terminer et d’inclure le travail de flux de récompenses détaillé ci-dessous (gagner des pièces 
) dans n’importe quel réseau de test public.
Nous travaillons sur un chemin de correction / amélioration ici et cela fonctionne bien avec l’équipe dans un état d’esprit à une piste, donc remettre la version pour le moment et prendre quelques jours de plus pour ranger d’autres parties semble juste. Il y a de grands engagements et la participation de la communauté et tout cela aide, il y a une volonté définitive dans la bonne direction.
Quelques nouvelles générales supplémentaires cette semaine - nous avons engagé un stagiaire des Instituts indiens de technologie qui se concentre sur la cryptographie. L’intention est qu’il commencera la semaine prochaine et commencera immédiatement à auditer, pousser et généralement vérifier la sécurité autant que possible dans la base de code. Nous augmenterons considérablement cet effort au cours des prochains jours à mesure que nous passerons en mode de lancement complet.
Safe Client, Nodes et qp2p
Plan de projet des transferts sécurisés sur le réseau
Plan de projet Safe Client
Plan de projet du nœud de réseau sécurisé
Récompenses
Le travail avec les récompenses s’est poursuivi avec une simplification du démarrage de la section dans sn_node, qui nécessite désormais que le nombre minimum d’aînés existe dans la section, avant d’instancier l’acteur distribué - alias l’acteur de section - responsable des fonds de la section.
Avec cela en place, nous avons maintenant atteint le début des paiements de récompense. Le projet de PR a été converti en un PR approprié et est en cours de test auprès d’un client P.O.V. avant de fusionner ce travail dans master une fois les tests réussis.
Le suivi sera l’achèvement du paiement de la récompense, à quel point la fonction agricole est plus ou moins prête à être incluse dans un testnet.
RP communautaires
Nous avons fusionné quelques PR cette semaine, @mav a envoyé un qui ajoute des fonctionnalités client manquantes, et une autre amélioration de l’efficacité du Appel sequence.in_range.
La connexion se bloque
Nous avons continué à déboguer notre connexion se bloque la semaine dernière, et avons finalement trouvé la cause principale là-bas. Qp2p abandonnait par erreur des connexions qui avaient renvoyé une erreur. Dans ce cas, l’erreur était valide et ne justifiait pas la suppression de la connexion du pool. Avec ce correctif maintenant fusionné, nous ne voyons plus de longs délais dus à des connexions perdues, ce qui est génial: soulagé:. La rumeur veut que @joshuef ait les cheveux pleins avant que ce bug ne survienne!
Le nœud maître / client est beaucoup plus stable maintenant. Nous creusons un peu plusbogues occasionnels survenant dans le cadre du stockage des objets blob, où il semble que nous ne parvenions pas à stocker l’objet blob et / ou les métadonnées liées à l’objet blob.
API qp2p plus simple
Le récent problème avec la connexion se bloque dans qp2p nous a révélé que l’utilisateur de l’API a assumé beaucoup de responsabilités telles que le maintien des connexions et le maintien des écouteurs et des flux sur lesquels les messages sont entrants. Cela a rendu le débogage relativement complexe car la gestion des connexions faisait partie du routage et des caisses client qui sont riches en fonctionnalités à leur manière. En déplaçant la maintenance des composants réseau vers la caisse qp2p, nous pouvons isoler et tester plusieurs scénarios et nous assurer que toutes les connexions et la gestion des messages sont effectuées correctement. Cela simplifie également l’API qp2p, donc c’est gagnant-gagnant. Nous avons commencé ce refactor dans qp2p comme une preuve de concept pour fournir une API asynchrone simple que le routage et les clients peuvent utiliser pour les communications p2p.
API et CLI
Le repo sn_api a vu beaucoup d’activité de la part des membres de la communauté cette semaine, ce qui est une excellente nouvelle, en particulier parce que ces applications sont toutes orientées utilisateur et donc plus nous obtenons d’entrées des vrais utilisateurs finaux, mieux nous pouvons les améliorer, encore mieux si l’entrée est du code réel!
@Latch travaille sur une nouvelle fonctionnalité pour introduire une commande reset dans la CLI, qui peut nous permettre de nettoyer toutes les données et les fichiers de configuration que les applications CLI, sn_authd et sn_node stockent localement, en conservant les binaires d’application réels intacte. Toute personne intéressée à aider, veuillez rejoindre les discussions et consulter sur: https://forum.safedev.org/t/wip-feat-cli-implements-safe-reset-subcommand/2939/6.
Certaines améliorations soumises par @mav à notre API ont également été fusionnées, il y avait quelques fautes de frappe dans les messages d’erreur qui ont été corrigées, ainsi que l’ajout validations pour que les noms NRS rejettent les barres obliques.
Quelques exemples d’applications qjsonrpc sont en cours de développement par @scorch (https://github.com/maidsafe/sn_api/pull/690) qui aideront les utilisateurs à comprendre comment l’API qjsonrpc peut être utilisée et comment les applications nécessitant JSON-RPC sur le protocole QUIC peut être créé. Certaines informations contextuelles et contextuelles sont très bien détaillées dans cet article pour quiconque souhaite en savoir plus sur cet effort .
Avec ce PR désormais fusionné, la CLI est désormais également capable de vérifier le solde de sa propre SafeKey, c’est-à-dire le solde qui lui a été transféré une fois autorisé avec authd, qui est celui que la CLI utilise pour payer les coûts de toutes les opérations effectuées par / avec elle. Ainsi, en invoquant «$ safe keys balance» sans fournir de clé secrète, il vérifie maintenant par défaut le solde actuel de la paire de clés / SafeKey de la CLI.
De nouvelles versions de sn_authd (v0.0.15), CLI (v0.17.2) et sn_node (v0.25.39) ont été publiées, pour ceux qui ont joué avec eux localement. Puisque la CLI et les binaires authd sont maintenant construits en utilisant MUSL pour les plates-formes Linux, si vous êtes sous Linux assurez-vous de les installer plutôt que d’essayer de les mettre à jour en utilisant le CLI, vous pouvez trouver des instructions complètes pour les installer dans le Guide de l’utilisateur CLI.
BRB - Diffusion fiable byzantine
Cette semaine, nous avons peaufiné les erreurs de validation renvoyées par BRB DataTypes et avons également ajouté des commentaires de documentation approfondis à toutes les caisses BRB. Ces modifications devraient faciliter l’utilisation des bibliothèques pour quiconque souhaite utiliser les bibliothèques.
Il y a eu pas mal de discussions sur la conception de l’intégration de BLS Distributed Key Generation (DKG) dans BRB. L’espoir était que DKG pourrait en quelque sorte se greffer sur les opérations dynamiques d’adhésion (rejoindre / quitter) de la BRB. Cependant, en fin de compte, nous avons déterminé que cela ne fonctionnait pas car DKG nécessite une participation de 100% et doit se dérouler comme un processus distinct après la création du groupe de vote BRB.
Routage
Cette semaine a été plutôt calme en termes de changements de code réels dans le routage, car une partie de l’équipe était occupée à discuter des algorithmes BRB / DKG et l’autre aidait à détecter les problèmes de blocage de la connexion client. Nous avons également suspendu les travaux d’amélioration de la gestion des erreurs, car nous avons décidé qu’il y avait des problèmes plus urgents à résoudre en premier.
Nous avons cependant fusionné un petit PR qui améliore la gestion des événements. Nous avons eu des événements séparés pour le moment où les anciens de la section changent et pour le moment où le nœud actuel est promu ou rétrogradé. Il s’avère que ces choses se produisent en même temps et que la gestion des événements séparément a causé une certaine confusion dans les couches supérieures quant à l’ordre dans lequel elles devraient être traitées. Nous l’avons résolu en fusionnant ces événements en un seul événement, éliminant ainsi la confusion.
WNous avons également commencé [travailler pour unifier la gestion du bootstrap] (https://github.com/maidsafe/sn_routing/pull/2298) à travers les nœuds et les clients. Il s’avère que la logique pour les amorcer est exactement la même, mais elle a été implémentée de deux manières légèrement différentes à deux endroits différents. Ce travail supprimera cette duplication résultant en un code plus simple. Nous prévoyons de le terminer au début de la semaine prochaine.
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 ne soyez pas timide, rejoignez-nous et créons ensemble le réseau sécurisé!