Ceci est une traduction automatique. L’original en anglais est ici: Safe Network Dev Update - November 26, 2020
Sommaire
Voici quelques-unes des principales choses à souligner depuis la dernière mise à jour du développement:
- sn_node et sn_client travaillent pour s’aligner sur les derniers sn_data_types et d’autres changements se poursuivent à un rythme soutenu, CI passant maintenant entièrement dans sn_node.
- Le routage a maintenant été mis à jour en indicateur lorsqu’un nouveau nœud doit être accepté sur le réseau, avec des travaux en cours dans sn_node pour en profiter.
- Le travail de routage pour améliorer la détection des pairs perdus a été approuvé et fusionné cette semaine.
- Le changement de lexique du réseau sécurisé discuté il y a 2 semaines ont commencé à filtrer jusqu’aux conceptions UX. Aperçu de Sneek ci-dessous!
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é
Après avoir ajouté la semaine dernière la Signature des opérations de séquence CRDT, cette semaine nous avons intégré ceci dans la pile, avec quelques changements dans sn_node ici et sn_client ici et ici pour que toutes les opérations soient signées avant d’être transmises au réseau. Cela a mis en évidence d’autres problèmes liés à la mise en cache locale des séquences (quand utiliser local ou réseau, etc.). Nous avons choisi de supprimer ce cache pour le moment via ce PR pour plus de simplicité. Cela a aidé à consolider la suite de tests, nous permettant de voir plus clairement certains flux de type CRDT en action, par exemple, les changements de poussée ne sont pas * immédiatement * retirés du réseau, nous devons donc attendre les changements attendus là-bas.
Avec les modifications ci-dessus, nous avons également débogué de nouveaux problèmes de démarrage de section qui ont été soulevés à l’arrière de ceux-ci, avec quelques petits ajustements client ajoutés ici pour éviter l’échec si un ancien n’est pas disponible (mais il en reste suffisamment d’autres). Avec cela, nous pouvons maintenant voir un sous-ensemble de tests sn_client passer contre une section de onze membres sur CI.
Le reste des échecs que nous constatons sont principalement dus à quelques bogues cachés lors du choix des destinations et à la récupération de bloc dans la réplication de bloc de données blob que nous avons activée la semaine dernière. Rassurez-vous, nous sommes bien engagés avec des correctifs pour eux et cochons le dernier des tests échoués de la suite de tests client e2e. La recherche de ces erreurs a également mis en évidence que certains éléments de la messagerie étaient toujours manquants et qu’il était désormais nécessaire de rapprocher le flux de contrôle / la gestion des erreurs de ce que nous appelons la «messagerie paresseuse». Des travaux sont en cours pour résoudre ce problème.
La Lazy Messaging est l’endroit où nous recevons un message que nous ne pouvons pas gérer pour quelque raison que ce soit (désynchronisé, numéro de séquence futur, etc.) et nous renvoyons ce message à l’expéditeur avec notre dernier historique connu. L’expéditeur sait alors qu’il doit nous fournir le lien manquant (nous pouvons également faire l’inverse (pas d’erreur cependant) et mettre à jour l’expéditeur si ce sont eux qui sont en retard). Cela nous évite de retenir les messages jusqu’à leur commande, ce qui pourrait être exploité pour attaquer le réseau, et ce serait du code plus complexe. La messagerie paresseuse est beaucoup plus proche d’un modèle d’acteur de transmission de messages, et nous l’avons étendu pour gérer les événements partiellement ordonnés.
Avec un changement dans la nouvelle dynamique de jonction des nœuds dans le routage, voir PR # 2234, nous avons également commencé à mettre à jour sn_node de sorte que les nœuds prennent la responsabilité de permettant à de nouveaux nœuds de rejoindre le réseau. En effet, les anciens du réseau suivront désormais l’offre / la demande de ressources dans leur section et demanderont en conséquence un routage pour permettre aux nouveaux nœuds, qui font la queue, de rejoindre leur section.
Nous avons également commencé à adapter authd et la CLI à la nouvelle terminologie UI / UX, par exemple, en passant de" Comptes « à » Coffres-forts « , ainsi qu’en apportant les modifications nécessaires pour que authd stocke les applications 'paires de clés sur le réseau en utilisant une Map comme type de données de stockage pour le » Safe ". Nous poursuivrons cette tâche pour aligner toutes les commandes CLI et fonctionnalités d’authentification sur ces nouvelles terminologies ainsi qu’avec la nouvelle API sn_client.
Une fois les mises à jour, les correctifs et les bogues qu’ils génèrent ci-dessus terminés, nous serons tous prêts à relancer nos réseaux de test internes à plein régime, à ranger les différents modules, à vérifier leur stabilité, à résoudre les problèmes. et j’espère vous offrir un cadeau de Noël tôt! :clin d’œil:
BRB - Byzantine ReDiffusion responsable
Cette semaine, notre consultant a avancé l’idée de l’horloge de génération mentionnée la semaine dernière et a présenté un algorithme de pseudo-code à l’équipe pour commentaires. Cette approche hybride impose un ordre total sur les opérations de jointure et de sortie peu fréquentes, mais seulement un ordre partiel sur les opérations de données beaucoup plus fréquentes. En clair, cela signifie que join / Leave doit être borné (c’est-à-dire que nous ne pouvons pas autoriser les nœuds non réactifs à exister) et utiliser une forme de commande totale, mais nous pouvons gérer plusieurs feuilles à la fois, etc., alors que des opérations de données régulières peuvent se produire avec des niveaux élevés de concurrence, tant que chacun provient d’une source différente (Acteur dans le langage CRDT). Jusqu’à présent, la proposition semble solide et la prochaine étape est de l’implémenter dans le code et d’écrire quelques tests. Plus à ce sujet la semaine prochaine.
Routage
Comme indiqué dans les semaines précédentes, le travail pour améliorer la détection des pairs perdus a été approuvé et fusionné cette semaine. Cela tire parti de la fonctionnalité de regroupement de connexions dans qp2p. Ce changement signifie que la base de code de routage a été simplifiée et permet désormais d’ajouter des tests d’intégration plus complexes pour vérifier les fonctionnalités du code de production.
Certaines fonctionnalités de l’API fonctionnent - Indication pour le démarrage de la section et le getter d’âge et
notifier quand la clé a été modifiée lors de la réinstallation - a également été terminé cette semaine. Une fois ceux-ci en place, les nœuds seront désormais mieux informés de l’état du routage lors du démarrage et de la paire de clés mise à jour utilisée.
Pendant les tests, nous avons observé un problème où lors du bootstrap, lorsque le message NodeApproval était immédiatement suivi d’un autre message, disons Relocate, le bootstrap était terminé * après * le traitement de NodeApproval. Cela laissait tout message suivant, tel que Relocate, dans le tampon du canal intermédiaire pour ne jamais être retiré et traité, c’est-à-dire que nous perdions ce message. Nous avons fusionné un PR correctif Correction de la perte de messages pendant le bootstrap pour résoudre ce problème. Il supprime le canal intermédiaire, le remplaçant par un simple wrapper autour du récepteur ConnectionEvent. Ainsi, le modèle « push / pull » est transformé en un modèle « pull » simple. De cette façon, un message n’est jamais récupéré du canal s’il n’est pas prêt à le traiter.
Le travail pour permettre aux nœuds de dire au routage d’accepter ou non de nouveaux nœuds mentionné dans la mise à jour de la semaine dernière a également été achevé et fusionné cette semaine. Le routage suppose que les nœuds aînés suivront tous les nœuds adultes de la section et lorsqu’ils détectent que la capacité de stockage moyenne (ou une autre ressource) devient trop faible, ils retourneront le drapeau pour que la section commence à accepter de nouveaux nœuds. Tous les nœuds aînés devraient détecter cela plus ou moins en même temps, afin qu’un consensus puisse être atteint. En plus de retourner le drapeau, si la section a déjà des nourrissons, l’un d’entre eux sera promu avec son âge augmenté d’un, ce qui le fera déménager et le rejoindra immédiatement en tant qu’adulte.
Application Safe Network et UX
Feature Tracker / Écrans et flux / Prototype d’intégration
Merci pour tous vos commentaires sur les modifications du lexique Safe proposées. Nous avons commencé à filtrer ces changements à travers les flux UX et les prototypes de l’application Safe Network, et vous devriez les voir apparaître dans les différents fichiers Figma au fur et à mesure que nous travaillons à travers tout cela.
Bien qu’il ne soit pas directement lié aux changements de langue, un petit projet secondaire intéressant qui est sorti du travail était une revisite de certains des flux d’intégration, par exemple, lorsqu’un utilisateur est prêt à créer son propre coffre-fort.
Si vous vous en souvenez, la version existante énonçait toutes les options dont un utilisateur disposait pour créer un coffre-fort (ou un compte tel qu’il était à l’époque), et leur permettait de sélectionner l’itinéraire approprié, avec des instructions étape par étape.
Cela ressemblait à ceci:
Mais pourrions-nous le rendre plus fluide? Pourrions-nous peut-être le rendre moins intimidant et aider un utilisateur à mettre rapidement en marche son Safe sans aucune assistance extérieure, puis à le faire suivre pour gagner des jetons Safe Network pour démarrer.
Voici un petit prototype cliquable de la nouvelle approche (happy path uniquement) pour vous donner une idée.
Ce ne sera pas le seul moyen d’obtenir un coffre-fort, il y aura d’autres flux alternatifs avec un peu moins de main, mais pour le premier utilisateur, il sera intéressant de voir comment cela se compare à l’approche existante.
C’est également un modèle qui peut être appliqué à d’autres domaines de l’application, comme gagner des jetons la première fois, créer un SafeID ou choisir des informations d’identification solides.
C’est un peu plus de travail pour nous du point de vue de la conception et de la logique de flux, mais si c’est plus fluide et moins intimidant pour l’utilisateur, et que plus de coffres-forts et de nœuds sont installés sur le réseau, cela sera payant.
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é. Ne soyez donc pas timide, rejoignez-nous et créons ensemble le réseau sécurisé!