Ceci est une traduction automatique. L’original en anglais est ici: Safe Network Dev Update - January 21, 2021
Sommaire
Voici quelques-unes des principales choses à souligner depuis la dernière mise à jour du développement:
- Nous avons trouvé et fusionné une solution de contournement pour un problème de
lagqui avait fait de son mieux pour rester non résolu. - Un projet de PR pour le flux de récompenses a été levé et est en voie d’achèvement.
- Certains tests de réseau client cassés, qui nous ont empêchés de progresser dans le test du correctif pour un problème de messagerie
KeySectionetDataSection(le dernier problème bloquant un réseau de test public), devraient maintenant être résolus et les tests vont maintenant reprendre. - Nous avons fusionné les PR CI / CD dans chacune de nos caisses BRB, ce qui a abouti à une couverture de test automatisée, à la gestion des versions et à nos premières versions des BRB crates on crates.io.
- @JimCollinson fournit une autre mise à jour captivante sur les progrès de l’application Safe Network et de l’UX.
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ésolution des problèmes de décalage
Il y a eu beaucoup de plongée profonde la semaine dernière pour tenter de trouver la source du retard important que nous avons connu lors de l’exécution de réseaux de test internes. Et bien que nous ne soyons pas entièrement «corrigés», nous avons une bien meilleure idée ici, et une solution assez simple solution de contournement a maintenant été fusionnée.
Le nœud de ce problème était quelque chose bloquait la gestion des demandes des clients par un nœud. Cela peut être lié à une concurrence de nœud sous-optimale (que nous cherchons également à corriger), mais la racine semble provenir de connexions abandonnées bloquant la capacité des nœuds à répondre, et ils ont donc effectivement attendu la connexion. être complètement abandonné par les couches inférieures - cette attente est le décalage que nous constatons.
Il semble qu’un simple ajustement du délai d’inactivité d’un nœud (le réduire de 30 à ~ 5 s … nous expérimentons pour trouver les nombres optimaux maintenant) débloquera suffisamment les nœuds pour que nous puissions à nouveau faire fonctionner correctement les tests client. Ainsi, pendant que nous cherchons à voir s’il y a un problème dans le pool de connexions de qp2p, et que nous refactorisons quelque peu sn_node, nous pouvons maintenant avancer en testant à nouveau tout.
Flux de récompenses
Nous avons déjà mentionné le travail en cours sur le flux des récompenses. Les récompenses sont payées par les Anciens dans une section, par eux en utilisant un acteur AT2 distribué - (c’est-à-dire l '«acteur de la section») et des signatures agrégées. Chaque fois qu’il y a un changement dans la constellation Elder, la clé de section change et l’acteur distribué passe à la nouvelle clé en lui transférant tous les jetons. Il y a un chemin initial différent sur le flux de transfert pour l’acteur de section (et tout acteur multi-propriétaire), par rapport aux acteurs à propriétaire unique, où la validation d’un transfert est proposée par une majorité, avant qu’il n’y ait une validation au niveau des répliques.
La transition depuis le nœud de genèse ainsi que les tests pour cela sont terminés et confirmés, nous travaillons maintenant sur les transitions ultérieures.
En travaillant sur ce qui précède, nous avons constaté que l’état Elder n’était pas cohérent entre les opérations dépendantes dans une telle transition, et ainsi cette semaine nous avons affiné la représentation et le traitement de cet état. Un projet de PR pour le flux de récompenses a été soulevé, contenant tout le travail mentionné ci-dessus, car il est maintenant presque terminé.
Problème de messagerie KeySection et DataSection
Dans une mise à jour précédente du développeur, nous avons mentionné que nous recherchions la suppression du possible travail d’agrégation de signatures dupliqué effectué par sn_node lors de l’échange de messages entre KeySection et DataSection. Il existe un WIP PR agrégat de signature de suppression généré à cet effet. Ce PR passe les tests unitaires sn_node, et nous avons utilisé des tests réseau sn_client pour effectuer une vérification supplémentaire. Cependant, en raison d’autres travaux de refactoring dans sn_node et sn_client, effectués en parallèle, les tests de réseau sn_client ont été interrompus pour d’autres raisons, donc le travail de vérification a dû être suspendu pendant un court moment.
Nous pensons que ce travail de suppression de duplication résoudra un problème de messagerie KeySection et DataSection que nous avons observé lors de notre testnet interne à la fin de l’année dernière, ce que nous devrions être en mesure de vérifier via le test réseau sn_client. Il s’agit actuellement du dernier bloqueur attendu pour pouvoir héberger un réseau de test public, nous n’avons donc pas pu progresser avec les tests internes ici entre-temps.
Cependant, avec la fusion récente de certains travaux de refactoring en both sn_node et sn_client, nous sommes maintenant de retour sur cela en priorité, et nous espérons pouvoir travailler sur les cas de test sans complications.
API et CLI
Après l’introduction de la caisse sn_messaging, où tous les types de message client sont maintenant définis, nous travaillions sur les changements nécessaires dans sn_api et CLI pour être à nouveau compatibles avec la messagerie sn_node et sn_routing. Ceci est maintenant terminé et tous les changements ont été fusionnés dans les branches principales de toutes ces caisses. Nous avons également fait des progrès en essayant de déplacer les définitions de message sn_routing vers la caisse sn_messaging, bien que ce soit toujours une tâche en cours avec une priorité inférieure à la plupart des autres choses sur lesquelles nous travaillons.
Nous avons également fusionné quelques améliorations d’API faites par @Scorch sur la caisse qjsonrpc qui rend les paramètres de chemin génériques. Nous tenons donc à le remercier pour sa contribution. : mains levées:
BRB - Diffusion fiable byzantine
Mardi a marqué un autre jalon avec la fusion des PR CI / CD qui ont abouti à une couverture de test automatisée, à la gestion des versions et à nos premières versions des brb crates on crates.io.
Une amélioration majeure depuis la mise à jour de la semaine dernière qui en a fait cette version est la prise en charge des types d’acteurs génériques via des traits de rouille. Cela signifie que le code est maintenant suffisamment flexible pour prendre en charge la plupart / n’importe quel algorithme ou bibliothèque de cryptographie à clé publique sans autre modification des bibliothèques principales. La prise en charge d’ed25519 est déjà incluse, mais nous envisagerons d’ajouter la prise en charge BLS. Même des dispositifs de signature matériels pourraient être ajoutés à l’avenir.
Les améliorations supplémentaires incluent:
- L’interface de ligne de commande brb_node_qp2p a quelques correctifs d’affichage et une nouvelle commande de nouvelle tentative en cas de perte de paquets.
- journalisation. Tous les appels println ont été remplacés par des fonctions de journalisation appropriées.
Travaux en cours:
- les cas de test sont en cours d’amélioration pour renvoyer des résultats et supprimer tous les appels qui paniqueraient ()
- des commentaires doc sont ajoutés pour rendre le code plus utilisable par d’autres développeurs
Enfin, encore de bonnes nouvelles! Notre spécialiste CRDT, et les grands cerveaux derrière les caisses brb, a accepté de prolonger son contrat de 3 mois supplémentaires pour aider à d’autres travaux de fonctionnalités et d’intégration. : tada:
Routage
Cette semaine, nous avons fusionné un autre lot de correctifs pour les problèmes découverts avec l’outil de test de résistance. Avec ces derniers, nous semblons être dans un bien meilleur endroit. Nous avons encore des problèmes avec les fourches (divergences dans la chaîne de sections) qui se produisent parfois lors de très fortes churn. Ce problème sera résolu par l’intégration du nouvel algorithme d’appartenance, travail qui est déjà au stade de la planification.
Nous avons également fusionné quelques modifications mineures. Tout d’abord, nous nous sommes assurés que les nœuds ne créent jamais de connexions aux clients - à la place, lorsqu’un nœud doit envoyer quelque chose à un client, il réutilise la connexion que le client a créée précédemment. Si une telle connexion n’existe pas, il signale une erreur. Cela en soi ne corrige vraiment rien, mais cela fait que certains échecs se manifestent de manière plus évidente, ce qui simplifie le débogage. Dans le même ordre d’idées, nous avons amélioré la gestion des erreurs (PR en cours de révision) afin que les erreurs soient désormais plus spécifiques et contiennent plus d’informations, encore une fois pour simplifier le débogage.
Enfin, nous avons corrigé un problème de longue date avec notre pipeline d’intégration continue où une tâche échouait constamment. Même si ce n’était pas critique, cela nous empêchait toujours de voir cette coche verte satisfaisante: heavy_check_mark: avant de fusionner un PR. Il s’avère que nous étions juste un peu trop stricts dans la façon dont nous traitons les avertissements du compilateur. Ce correctif a également été déployé sur plusieurs de nos autres caisses.
Application et UX Safe Network
Feature Tracker / Écrans et flux
Si vous vous souvenez de la mise à jour UX de novembre, nous vous avons présenté les mises à jour du lexique Safe Network proposées, introduisant une nouvelle métaphore d’un compte Safe to replace, des jetons plutôt que Safecoin, et déconseiller l’utilisation du terme Vault.
Eh bien, ces changements ont commencé à se faire sentir dans les conceptions d’interface utilisateur candidates où ils peuvent commencer à faire leurs preuves dans les pixels de l’expérience utilisateur, plutôt que sur papier.
Si vous sautez dans le fichier Figma pour les conceptions d’applications Safe Network, vous allez commencer à les voir en action, ainsi que quelques autres améliorations.
C’est un gros fichier avec une centainedes écrans et des flux différents, il n’est donc pas toujours facile de prendre en compte tout ce qui se passe. Voici donc quelques faits saillants:
Déverrouiller votre coffre-fort
Ici, nous voyons la métaphore d’un coffre-fort pour les données de l’utilisateur en cours d’introduction - le verrouiller et le déverrouiller - avec quelques indices visuels qui, espérons-le, renforcent cela également.
Vous noterez également que le menu Action a été promu dans la barre d’application supérieure, via un hamburger traditionnel. Et qu’il est maintenant accessible dans l’état locked, aussi. Mais plus là-dessus plus tard.
Travailler avec des jetons
En plus d’introduire la fin du terme de Safecoin, les modifications apportées à l’écran du portefeuille incluent une section Tokens globale, un peu de raffinement de l’interface utilisateur et un bouton d’action Nouvelle transaction plus multifonction. C’est un moyen de lancer une nouvelle transaction - en évitant une partie du flux légèrement plus long que nous avions précédemment - et aussi un autre point d’entrée pour commencer à gagner des jetons.
Gagner des jetons
Avec l’abandon du terme Vault, nous pouvons voir ici une exploration de la façon dont nous pouvons favoriser un verbe tel que Earn pour démarrer des flux pour offrir des ressources au réseau en échange de jetons de réseau sûr.
Ce flux peut être démarré à partir d’un certain nombre de points, y compris à partir de l’onglet Gains de l’écran Token, de l’écran d’accueil ou des applications et de l’utilitaire lui-même (ainsi que du menu Action ou d’une commande saisie.)
Quelques étapes pour configurer les choses, et nous sommes partis.
Le menu Action
Vous avez déjà vu cela en aperçu, mais voici le Action Menu, ainsi nommé car vous pouvez l’utiliser pour rechercher et accéder à toutes les fonctions de l’application, ainsi que pour lancer directement les commandes.
Il est maintenant accessible en haut à gauche de l’application, et ici vous pouvez le voir dans les deux états verrouillé et déverrouillé.
Un petit rappel de la façon dont les commandes peuvent être recherchées et lancées aussi. Pratique.
N’hésitez pas à fouiller dans le fichier Figma pour voir tous les détails à ce sujet, avec une multitude de flux individuels explorés et documentés.
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é. Alors ne soyez pas timide, rejoignez-nous et créons ensemble le réseau sécurisé!