Ceci est une traduction automatique. L’original en anglais est ici: Safe Network Dev Update - February 11, 2021
Résumé
Voici quelques-unes des principales choses à souligner depuis la dernière mise à jour du développement:
- La version de testnet est toujours en attente alors que nous travaillons à la refactorisation du flux de messages, ce qui empêche les récompenses de progresser.
- Le travail de refactorisation du flux de messages progresse bien, avec un projet de PR en place. Cela se traduira par un flux de messages plus propre, plus simple et plus efficace.
- Nous avons migré nos scripts de déploiement / suppression de testnet pour utiliser terraform, ce qui a entraîné une amélioration drastique du temps nécessaire pour créer des réseaux de test de toute taille pour les tests internes / externes déploiement.
- Passer du temps à travailler avec une configuration `` sans récompenses ‹ › nous a permis d’attraper et d’écraser certains bogues qui seraient autrement restés cachés jusqu’à ce que les récompenses soient entièrement implémentées.
- Une nouvelle sous-commande
$ safe networks setest en cours d’implémentation dans la CLI qui permettra aux utilisateurs de se connecter plus facilement aux réseaux en utilisant simplement leur adresse IP d’amorçage: port, avec le PR correspondant en cours d’examen maintenant. - Nous pensons avoir trouvé une solution pour la création de chaînes de sections dans
sn_routing. Cette solution est actuellement en cours de mise en œuvre et nous pensons qu’elle contribuera à rendre les réseaux de test suffisamment stables pour faire face aux sondages de la communauté. -
Les contributions au code communautaire continuent d’arriver!
Statut Testnet - en attente
Encore une fois, nous visions à inclure des récompenses dans un réseau de test public cette semaine, mais certains travaux connexes pour ajuster les flux de messages après avoir fait le changement pour ne faire que l’accumulation de messages dans sn_routing, qui affecte toutes les parties de sn_node, ont tourné prendre plus de temps que prévu. Ce travail empêche actuellement les récompenses de progresser.
Plus tôt dans la semaine, nous avons décidé de concentrer notre énergie sur l’alternative d’avoir un testnet sans récompenses, c’est-à-dire de supprimer une partie du flux de récompenses, ce que nous avons commencé la semaine dernière. Nous avons fait de bons progrès ici, mais nous avons rencontré plusieurs problèmes de blocage en cours de route, que nous avons dû appliquer plusieurs « hacks » pour résoudre temporairement jusqu’à ce que les récompenses et les fonctionnalités associées soient en place. Les réseaux `` sans récompense ‹ › qui en résultent ont manqué de stabilité, de fiabilité et de cohérence, de sorte que dans l’état actuel des choses, nous ne pensons pas qu’il soit utile de mettre en place un réseau de test sans récompenses. Cette approche alternative a eu certains avantages cette semaine en ce qu’elle nous a permis de progresser quelque peu avec les tests multi-sections, ce qui nous a conduit à identifier et à résoudre quelques problèmes que nous n’aurions pas vu autrement jusqu’à ce que les récompenses et les fonctionnalités associées soient en place.
Nous prévoyons toujours d’héberger un réseau de test dès que possible, avec un recentrage pour avancer avec des récompenses à nouveau et publier un réseau de test fiable avec cela en place. Potentiellement, nous ferons un peu plus de tests en utilisant le travail «no-rewards» pour voir si nous pouvons découvrir autre chose qui se cache pour nous sur toute la ligne.
Préparation et test de Testnet
Vers la fin de la semaine dernière, nous essayions de publier de grands réseaux de test, et il est rapidement devenu évident que notre script bash pour cela n’était pas à la hauteur - prendre 30 minutes pour lancer environ 20 nœuds, et prendre beaucoup plus de temps. pour lancer 100 nœuds! En tant que tel, nous avons migré vers terraform pour gérer le déploiement / la destruction de gouttelettes et de nœuds, et c’est muuuch mieux. Nous pouvons maintenant lancer 40 nœuds impairs en quelques minutes. Nous l’avons beaucoup utilisé pour itérer, et l’avons configuré maintenant pour nous permettre de déployer également des builds de nœuds personnalisés. Ce qui s’est avéré très pratique sur le front des itérations. Le PR pour ce passage à terraform est en place et assez soigneusement testé maintenant, avec un travail de rangement prévu avant la fusion.
À un moment donné de la semaine, nous voyions assez régulièrement des réseaux de test internes voulant se diviser, mais sans le faire. Nous avons commencé à essayer de déboguer avec des sections plus petites (par exemple, 3 anciens, une taille de section de 5 nœuds) pour déclencher plus de fractionnements, mais cela n’a pas aidé. Il s’est avéré que nous ne voyions pas de fractionnement car notre code dépendait des sections Elders moving, mais ce n’est pas vraiment nécessaire (dans l’état actuel des choses). Comme pour toute probabilité, même ces événements improbables semblaient se produire assez souvent … et c’est ainsi que tous nos anciens tombaient dans la moitié de la section, formant ainsi une nouvelle section pour eux-mêmes, sans changement de clé nécessaire. , et aucun de notre code n’est touché.
Avec plus de correctifs de bogues en place là-bas, ainsi que la suppression de certaines fonctionnalités de récompenses qui sont en cours de retravail, nous avons résolu un problème qui se produisait au démarrage du réseau par lequel à chaque désabonnement dans la section genèse, l’ancien nouvellement promu proposerait une genèse une fois de plus, ce qui oblige le reste des aînés à attendreautre paiement de genèse qui était censé ne se produire qu’une seule fois au départ. Avec cela cloué, nous avons également corrigé un autre bogue lié où l’accumulation de la preuve de paiement de genèse ne se produisait pas (nous stockions tous les événements de paiement _ à l’exception_ de ceux de validation); qui a aidé à faire bouger les choses.
Après cela, nous sommes également tombés sur des boucles dans sn_routing, ce qui a été observé comme provoquant une utilisation élevée de la mémoire, provoquant potentiellement la mort des nœuds. Nous savons où se situe le problème et nous avons mis en place une mesure temporaire pour l’empêcher de se produire pour le moment. Un correctif plus permanent viendra en temps voulu.
Avec tout ce qui précède déployé avec la branche `` no-rewards`, nous sommes finalement arrivés au stade où nous pouvions voir la majorité des tests clients passer, les échecs mettant en évidence quelques autres problèmes tels que frapper occasionnellement du code que nous ne devrions pas être en mesure d’atteindre (une gestion des erreurs est nécessaire pour cela), et maintenant nous réduisons actuellement un problème avec les portefeuilles clients. Rendre la suite de tests client un peu plus verte en prévision du moment où le flux de récompenses sera à nouveau entièrement intégré.
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é
QP2P
Au cours de la dernière semaine, nous avons testé la nouvelle API qp2p avec toutes nos caisses. Il y avait des problèmes au départ, mais ils sont tous réglés maintenant et nous sommes dans la phase finale de révision et de fusion à tous les niveaux. Nous inclurons ces changements lors des tests de bout en bout et ils feront partie de la prochaine version de testnet.
Messages
Récemment, nous avons déménagé pour accumuler les messages dans sn_routing seulement, après avoir déjà fait cela dans sn_node. Pour terminer ce refactor, beaucoup de code a été touché, mais aussi environ 1350 lignes supprimées.
Le résultat est un flux de messages plus simple, plus propre et plus efficace.
Les travaux pour ce faire sont actuellement en cours, avec un projet de PR qui suit les progrès. Cela nous aidera à avancer avec les flux de messages en général, mais très important maintenant aussi les récompenses, qui ont été un peu retardées par ces mises à jour.
API et CLI
Une dette technique que nous avions dans notre caisse sn_api était de faire en sorte que notre type Error implémente le trait std :: error :: Error. C’est quelque chose que nous avons terminé et fusionné la semaine dernière avec l’aide de thiserror Caisse. Nous avons également modifié la base de code CLI pour utiliser de toute façon afin que toutes les fonctions retournent maintenant anyhow :: Result et la gestion des erreurs est beaucoup plus facile sans perdre d’informations ni de contexte sur la cause première de chacune des erreurs propagées.
Une nouvelle sous-commande $ safe networks set est en cours d’implémentation dans la CLI, ce qui permettra aux utilisateurs de se connecter plus facilement aux réseaux en utilisant simplement leur adresse IP d’amorçage: port. Le PR correspondant comprend une mise à jour du guide de l’utilisateur, donc pour toute personne intéressée à fournir des commentaires préliminaires sur cette commande, veuillez consulter la description ici.
Les contributions de la communauté ont continué à venir la semaine dernière. Il y a un effort de travail en cours de @bzee pour rendre le paquet nodejs compatible avec la dernière version de sn_api, ainsi qu’un correctif dans la CLI pour supprimer un nom d’indicateur qui provoquait un conflit entre deux commandes différentes (https://github.com/maidsafe/sn_api/pull/708). Un PR a également été levé et fusionné pour supprimer l’implémentation de journalisation de sn_client car cela devrait être laissé aux applications ou aux binaires qui utilisent la bibliothèque, ce qui certaines applications n’obtiennent pas de sortie inattendue sur stdout ou stderr.
Puisque la majorité des dépendances de nos caisses utilisent tiny-keccak v2.0.2, @mav a envoyé des PR pour mettre à jour toutes nos caisses afin qu’elles dépendent de cette même version. Nous apprécions tous les efforts de tous ceux qui s’impliquent de toutes les manières possibles: applaudir:
BRB - Diffusion fiable byzantine
Nous avons fait un travail supplémentaire sur brb_node_qp2p pour le faire fonctionner avec des flux bidirectionnels et la nouvelle API (à venir) qp2p. Cela permet à chaque nœud d’envoyer et de recevoir du même port, au lieu d’ouvrir de nouvelles connexions sur un port aléatoire distinct pour les paquets sortants. Dans le processus, nous avons contribué quelques petits PR à qp2p. Un en particulier facilite le partage d’un point de terminaison qp2p entre les threads, ce qui devrait être une victoire pour quiconque construit une application p2p avec la bibliothèque.
sn_data_types
Nous avons une conception pour simplifier la politique / l’autorisations logique régissant l’accès aux données du réseau, elle fait actuellement l’objet d’un examen interne. Nous avons également un PoC pour un nouveau Chain CRDT qui pourrait s’avérer être un meilleur CRDT sous-jacent pour notre type de données Sequence. sur le problème @mav soulevé concernant notre type de données Sequence.
Routage
Cette semaine, nous explorions une approche prometteuse de la résolution des fourches. Pour récapituler: nous avons quelque chose qui s’appelle une « chaîne de sections » qui est une liste de clés de section liées entre elles par des signatures. Il peut être utilisé pour prouver qu’une donnée a été signée par un groupe de nœuds qui étaient autrefois des membres valides d’une section, même après la disparition de ces nœuds. Actuellement, cette chaîne exige que la section convienne de la clé à y ajouter ensuite. En cas de désaccord à ce sujet, la chaîne peut se diviser en deux (ou plus) chaînes mutuellement incompatibles qui pourraient actuellement casser la section. Cela peut arriver, par exemple, à des moments de désabonnement intense. Nous espérions pouvoir nous en sortir sans nous attaquer un peu plus longtemps, c’est-à-dire jusqu’à ce que le testnet soit sorti, mais il s’avère que nous voyons parfois des fourchettes même dans des réseaux de test relativement petits.
Nous étions donc occupés à discuter de la meilleure manière de s’attaquer à ce problème et nous avons proposé quelques idées prometteuses. Une de ces idées est actuellement en cours de mise en œuvre et nous espérons qu’elle contribuera à rendre les réseaux de test suffisamment stables pour faire face aux sondages communautaires. Il existe encore des problèmes potentiels concernant la sécurité et les vecteurs d’attaque possibles, mais ceux-ci seront abordés plus tard. À l’heure actuelle, l’accent est mis sur la stabilité. Pas de bébé.
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é!