Actualités du développement Safe 🇫🇷 4 mars 2021

Ceci est une traduction automatique. L’original en anglais est ici: Safe Network Dev Update - March 4, 2021

Résumé

Voici quelques-unes des principales choses à souligner depuis la dernière mise à jour du développement:

  • La communauté portes ouvertes de vendredi dernier, Safe Chat, a été un grand succès! Un grand merci à toutes les personnes impliquées, en particulier @sotros25 et @m3data pour leurs excellentes présentations. :clap:
  • @jimcollinson exécute une AMA over sur Reddit - impliquez-vous!
  • La plongée en profondeur et le débogage des réseaux multi-sections a été le thème principal de cette semaine, avec plusieurs nouvelles captures de gestion des erreurs introduites alors que nous éliminons les problèmes pouvant entraîner la défaillance des réseaux.
  • De nouvelles versions de sn_api (v0.20.0), sn_authd (v0.2.0) et de la CLI (v0.20.0) viennent d’être publiées, le rendant compatible avec le dernier sn_node.
  • Nous avons maintenant terminé le développement sur le MerkleReg mentionné la semaine dernière, et donc le travail a commencé pour l’intégrer dans sn_data_types.
  • Cette semaine a vu les premiers fichiers transmis d’un nœud SNFS à un autre via BRB. :tada:
  • Dans le routage, nous avons finalement fusionné le fork resolution PR.
  • Toujours dans le routage, nous avons fusionné trois PR distincts (# 2349, # 2351 et # 2336) implémentant des correctifs pour divers problèmes survenus pendant les tests de résistance. Le routage est maintenant considéré comme prêt pour un réseau de test stable.

Safe Client, Nodes et qp2p

Plan de projet de transferts sécurisés sur le réseau
Plan de projet Safe Client
Plan de projet du nœud de réseau sécurisé

De plus en plus près…

Nous avons continué à tester et à déboguer les réseaux multi-sections la semaine dernière. Nous sommes plus proches que jamais, de manière alléchante, mais pas encore là (c’est frustrant pour nous aussi!). C’est un endroit intéressant pour le débogage, il y a beaucoup de journaux et de messages, et ils arrivent dans toutes sortes d’ordres, donc nous testons vraiment les bords ici.

Plus de correctifs

Quelques petits bords rugueux ont été limés. Nous traitons maintenant certaines situations d’erreur qui peuvent provenir de transferts fractionnés par section, ou même de tout transfert, entrant et lançant des erreurs car ce n’est plus valide comme nous l’avons déjà vu et appliqué. Nous gérons maintenant également certaines erreurs sn_transfers qui peuvent se produire lorsqu’il n’y a pas d’historique - cela peut provenir de new anciens qui n’ont pas encore d’historique. Auparavant, cela provoquait une erreur et interrompait le flux.

Résoudre le problème racine

Mais le plus gros problème dans la progression des divisions de section au niveau sn_node, est de mettre les nouveaux anciens des sections respectives des frères et sœurs au courant des anciens de la section parente et de leur faire traiter les demandes comme s’ils étaient déjà des anciens. Sans cela, la transition serait fondamentalement dans une impasse. Maintenant, tant qu’ils n’ont pas tout ce qu’il faut pour être un ancien, certaines de ces demandes renverront une erreur - mais c’est fondamentalement bien.

Nous progressons avec deux tâches ici en parallèle; un où nous faisons quelques ajustements rapides qui permettent à ce qui est décrit ci-dessus de nous lancer pour le testnet, et un autre où nous faisons quelques ajustements également au niveau de sn_routing, pour que les transitions soient mieux coordonnées. Par cela, nous progressons également dans l’ambition d’impliquer tous les ingénieurs de bout en bout d’une manière ou d’une autre, ce qui, à notre avis, est nécessaire au bon fonctionnement d’un système de ce type.

Navigateur sécurisé

Cette semaine également, sur le navigateur sécurisé, nous avons passé un peu de temps à dépoussiérer le dépôt (cela faisait un moment!) À mettre à jour les dépendances afin que nous n’ayons pas une pile de problèmes de sécurité lorsque nous serons prêts à y aller. (@bzee semble avoir bien progressé avec sa conversion napi de sn_nodejs, ce qui est formidable à voir!). Ce n’est pas une nouvelle passionnante, mais c’est une chose de moins à aborder lorsque nous sommes satisfaits de la stabilité de testnet.

API et CLI

Une nouvelle version de sn_api (v0.20.0), sn_authd (v0.2.0) et de la CLI (v0.20.0) vient de sortir avec quelques améliorations sur la façon dont les fichiers et les conteneurs NRS sont également stockés sur le réseau. comme avec les nouvelles sous-commandes bin-version pour auth & node pour interroger leur version binaire. Comme d’habitude, vous pouvez utiliser la CLI pour mettre à niveau ($ safe update et $ safe auth update), ou installer la dernière CLI comme détaillé dans le Guide de l’utilisateur. Ces nouvelles versions sont compatibles avec la dernière version de sn_node v0.28.1.

Comme mentionné la semaine dernière, nous avons migré notre type de données Sequence pour qu’il contienne désormais une politique immuable qui supprime toutes les complexités qu’elle apporte à notre approche CRDT. Avec that maintenant en place, la semaine dernière, nous avons pu adapter tous nos API et types de messagerie à tous les niveaux pour supprimer la possibilité de faire muter les politiques.

En raison de la refactorisation et d’autres changements au cours des mois précédents dans la façon dont les messages sont envoyés par le client au réseau, nous avons dû désactiver temporairement nos tests E2E sn_api dans CI car ils doivent être adaptés à la nouvelle nature plus asynchrone de la messagerie. . Nous avons maintenant commencé à les adapter lentement pour les réintégrer dans notre système CI.

CRDT - Types de données répliquées sans conflit

Nous avons maintenant terminé le développement sur le MerkleReg mentionné la semaine dernière: rust-crdt # 111, et donc le travail a commencé pour l’intégrer dans sn_data_types. Pour rappel, le MerkleReg sera le nouveau CRDT de support au type Séquence. Il prend en charge un historique de branchement qui peut être parcouru (similaire à un historique de branchement git).

Cette semaine également, les CRDT GList / List ont rencontré un problème d’insertion entre les index utilisant le même identifiant, ce qui a été rapidement résolu dans rust-crdt # 112.

BRB - Diffusion fiable byzantine

L’intégration du Safe Network File System (SNFS) avec BRB s’est avérée très fructueuse pour découvrir certaines fonctionnalités manquantes dans BRB:

  1. Le client n’a pas été averti lorsqu’une opération a été appliquée. Les clients ont besoin de ces informations pour renvoyer les paquets potentiellement abandonnés. Cela a été résolu avec les paquets Livrés: brb # 27.
  2. Lorsqu’une opération était exécutée par BRB sur un client, il s’appuyait sur la pile réseau pour s’envoyer des paquets. Cela entraînerait des conditions de concurrence pour les clients hautement concurrents lorsque les opérations sont exécutées en succession rapide. Nous nous court-circuitons maintenant ces paquets et les traitons avant de les retourner au client: brb # 29.
  3. Pour gérer les paquets abandonnés, nous avons ajouté une API pour renvoyer les paquets pour lesquels nous n’avions pas encore reçu de réponse pour: brb # 29.

SNFS - Système de fichiers réseau sécurisé

Bonnes nouvelles! Cette semaine, les premiers fichiers ont été transmis d’un nœud SNFS à un autre via BRB. :tada:

Nous avons initialement effectué la transmission BRB de manière synchrone avec l’opération FUSE, mais cela s’est avéré trop lent. Une amélioration a été apportée à la file d’attente des opérations et au retour immédiat à FUSE. Un thread séparé envoie ensuite paresseusement les opérations aux pairs dans l’ordre source et s’assure que chacune est appliquée. Il s’agit d’une étape nécessaire vers un système de fichiers qui peut être utilisé hors ligne, puis synchronisé avec des pairs lorsque la connectivité est restaurée. Avec ce changement en place, le système de fichiers se sent en termes de vitesse comme l’utilisation d’un système de fichiers de système d’exploitation normal tel que ext4 sur Linux avec un SSD. Peut-être pas encore aussi vite, mais du même ordre de grandeur.

Lors des tests d’hier, nous avons découvert que deux threads utilisent plus de CPU qu’ils ne le devraient après que des communications lourdes se sont produites et terminées, et maintenant le processus est inactif. Les deux threads sont occupés à exécuter du code Quinn (réseau) pour des raisons inconnues. Une nouvelle version de Quinn a été publiée cette semaine et pourrait résoudre ce problème, nous allons donc tester cela dès que possible.

Routage

Plan de projet

Cette semaine, nous avons finalement fusionné la fork resolution PR. Le nœud du PR est une nouvelle implémentation de la structure de données SectionChain qui est maintenant un CRDT approprié. Cela signifie qu’il garantit une cohérence (éventuelle) quel que soit l’ordre dans lequel les opérations sont appliquées, comment elles sont regroupées, voire dupliquées. Même si plusieurs clés distinctes y sont insérées, tout le monde finira par se mettre d’accord sur celle qui est la plus récente et donc qui sont les anciens actuels (car chaque clé de section est uniquement associée à un seul groupe d’anciens). Et tout cela est réalisé sans impliquer de mécanisme de consensus compliqué. C’est précisément ce que nous voulions lorsque nous avons supprimé Parsec et maintenant c’est enfin là.

Cela a ensuite été suivi par trois PR distincts (# 2349, # 2351 et # 2336) implémentant des correctifs pour divers problèmes survenus lors des tests de résistance. Voici quelques-uns des plus notables:

  • Évitez la boucle infinie de demande-réponse pendant l’amorçage en ignorant les réponses de redirection en double - provoquant des fuites de mémoire massives.
  • Correction du rejet accidentel des réponses d’amorçage valides lors de la relocalisation - provoquait le blocage d’un nœud déplacé vers une autre section.
  • Correction de la signature d’invalidation accidentelle des messages Sync renvoyés et renvoyés - les nœuds n’étaient parfois pas correctement mis à jour sur l’état de leur section.
  • Aviser les anciens réinstallés qu’ils ont été exclus de leur section d’origine - ne pas le faire les a empêchés defaire progresser leur déménagement.
  • Assurez-vous que les informations de la section fraternelle sont fiables après la séparation - le fait de ne pas le faire a amené les nœuds à oublier qui étaient les nœuds de leur section sœur juste après la séparation et à ne pas les contacter. Cela a également provoqué le blocage de certains nœuds lors du démarrage.
  • Autoriser plusieurs résultats DKG en attente - ne pas le faire entraînait parfois les nœuds à oublier leurs partages de clé secrète et à devenir ainsi incapables de signer les messages de section.
  • Utilisez une clé unique pour les sessions DKG qui ont les mêmes participants - le fait de ne pas le faire entraînait parfois la corruption du résultat DKG et les nœuds ne pouvaient donc pas signer les messages de section.

Après ces correctifs, les réseaux internes que nous utilisons semblent beaucoup plus stables. Avec cela, nous considérons maintenant que le routage est prêt pour un testnet!

Communauté et marketing

Chat sécurisé

Le premier de nos journées portes ouvertes Safe Chats a eu lieu vendredi, et quel régal! Alors que l’ordre du jour était centré sur le thème du marketing communautaire du réseau, avec d’excellentes présentations de @ sotros25 et @ m3data, les discussions étaient plus larges que cela, comme vous pouvez l’imaginer.

Non seulement c’était génial de voir certains visages - bien que les caméras soient optionnelles! - mais cela semble devenir un environnement important pour la collaboration et la réalisation de grands projets!

Si vous ne l’avez pas déjà fait, vous pouvez suivre la conversation ici:

Nous allons sans aucun doute en exécuter plus, alors restez à l’écoute et nous vous ferons savoir quand garder votre agenda clair.

Je suis un UX Designer et j’aide à créer le nouvel Internet: demandez-moi n’importe quoi!

@jimcollinson exécute une AMA over sur Reddit et, enfin, tous les canaux sociaux vraiment.

Il répondra à autant de questions que possible et gardera certaines des questions les plus posées et les plus juteuses pour une session de questions-réponses sur YouTube afin de les rendre accessibles, faciles à partager et, espérons-le, rester un peu plus longtemps.

Rejoignez-nous!

Safe Network App UX

Comme nous avons amélioré le processus d’intégration pour les personnes qui créent un coffre-fort sur le réseau pour la première fois, nous vous avons donné un aperçu de il y a quelques mois, nous avons travaillé en utilisant encore plus cette approche plus conversationnelle pour les débutants dans plus de domaines de l’application. Pas beaucoup, mais là où cela pourrait aider à pousser les gens dans la bonne direction à partir des «états sans contenu».

Un tel endroit est l’utilitaire de création Invite, où les utilisateurs existants peuvent aider à trouver un ami sur le réseau sécurisé.

Travailler pour simplifier ce flux nous a également conduit à examiner le processus d’invitation dans son ensemble et à le façonner quelque peu.

Si vous vous souvenez bien, nous avions précédemment prévu de permettre aux clients de recharger automatiquement ou de débiter des invitations pour tenir compte de l’inflation / déflation des jetons. Cela présentait quelques inconvénients, l’un étant que cela ne fonctionnerait initialement que lorsque le client était ouvert, et l’autre étant que cela ajoutait également une certaine complexité aux flux dans des circonstances où la recharge automatique était activée, mais que le portefeuille était à court de fonds pour soutiens le.

En bref, ce qui était destiné à simplifier la vie pourrait bien fonctionner sur le chemin du bonheur, mais en être un peu encombrant.

Dans le même temps, nous avions également reporté une autre fonctionnalité d’invitation utile après MVE: la possibilité d’ajouter des fonds supplémentaires à une invitation lorsque vous l’offrez à un ami.

Mais plus maintenant! Nous pouvons rendre la compensation de l’inflation plus compréhensible et plus robuste, mais un peu plus manuelle, si nous allons juste de l’avant et construisons des recharges manuelles.

C’est donc un peu deux pour un. Vous obtiendrez une gestion des invitations plus compréhensible et vous pourrez ajouter autant de jetons que vous le souhaitez à un.

Aidez un ami à rejoindre le réseau et payez-le pour le déjeuner, le tout en une seule fois.

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é!