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

Dimitar · Mars 12, 2021, 1:18

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

Résumé

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

Après avoir travaillé sur quelques refactors et correctifs mineurs, nous sommes maintenant en mesure de mettre à jour toutes nos caisses Rust vers Tokio v1.
Nous avons revisité sn_routing cette semaine pour changer la manière dont l’accord est conclu pour exiger maintenant une supermajorité (plus de 2/3) au lieu d’une majorité simple (plus de 1/2). Nous pensons que cela était nécessaire pour rendre le réseau résistant à certains types d’attaques.
Nous avons décidé d’implémenter Lazy Messaging dans sn_node, avec des travaux déjà en cours. Cela était initialement prévu pour post-testnet, mais nous avons jugé utile de le présenter.
@jimcollinson a lancé une AMA sur Reddit, et à droite ici sur le forum, la semaine dernière - il est encore temps de poser vos questions!
@jimcollinson a créé la première de ce que nous pensons être une série de réponses vidéo YouTube aux questions plus importantes reçues dans l’AMA - vous pouvez la regarder ici.
@dimitar a travaillé dans les coulisses pour aider à accroître la notoriété du Safe Network en Inde avec une campagne publicitaire Facebook et Twitter. :heart :
Surveillez régulièrement le fil de discussion Like This Tweet sur le forum pour obtenir d’excellents conseils sur la manière de promouvoir le réseau sécurisé, et composants environnants, avec un simple clic de bouton!

Safe Client, nœuds, routage 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é

La semaine dernière, une version tant attendue de Quinn est enfin arrivée avec une mise à jour importante: Tokio v1. Jusqu’à présent, l’utilisation d’une ancienne version de Tokio dans Quinn nous a empêché de mettre à jour toutes nos caisses vers Tokio v1 en raison de versions d’exécution incompatibles, nous sommes donc en train de mettre à niveau toutes nos caisses vers Tokio v1. Avec quelques remaniements et correctifs mineurs, nous avons pu faire passer tous les tests avec la nouvelle version de Tokio. Cette mise à jour nous a également aidés à identifier un problème qui laissait les flux ouverts jusqu’alors inconnu bloquant finalement les communications réseau une fois la limite supérieure atteinte. L’équipe Quinn nous a rapidement aidés et le problème est maintenant résolu dans qp2p. Les communications de sn_routing fonctionnent à nouveau parfaitement! Nous prévoyons que toutes nos caisses seront mises à jour dans les prochains jours.

Cette semaine, nous avons également ajouté plus d’exemples à la caisse qp2p pour mieux démontrer l’utilisation de l’API, et pour les tests de stress qp2p à la fois localement et sur l’océan numérique.

Dans sn_routing cette semaine, nous avons décidé de changer la façon dont l’accord est conclu pour exiger maintenant une supermajorité (plus de 2/3) au lieu d’une majorité simple (plus de 1/2). Cela était nécessaire pour rendre le réseau résistant à certains types d’attaques. Nous avons également augmenté le nombre d’anciens dans une section de 5 à 7, ce qui signifie qu’une section peut encore perdre jusqu’à deux anciens et continuer à fonctionner. Ces modifications sont actuellement en cours d’examen et de test, et nous prévoyons qu’elles seront bientôt fusionnées.

Avec la nécessité d’activer la messagerie paresseuse (voir la sous-section ci-dessous), nous avons cherché la meilleure façon d’y parvenir dans sn_node. Nous pourrons peut-être en insérer quelques petites parties, mais nous examinons également un refactor plus grand ici pour simplifier les choses. On dirait qu’avec une partie du code sn_node disparu (essentiellement en supprimant Duties) et en analysant directement les messages, nous finirons avec quelque chose dont nous pouvons facilement nous tromper, tout en supprimant probablement beaucoup de sn_node la complexité. Les premiers efforts dans ce domaine ont été assez positifs. Nous espérons que ce ne sera pas une tâche aussi lourde, car la logique sous-jacente devrait rester la même, mais quoi qu’il en soit, nous abordons cela en parallèle avec des solutions plus légères, nous espérons donc ne rien bloquer.

`sn_node` Messagerie différée

La messagerie paresseuse dans sn_node fonctionnerait en augmentant légèrement la taille des messages envoyés entre les nœuds afin qu’ils incluent des informations supplémentaires sur l’état actuel du réseau tel que vu par différents observateurs dans l’espace et dans le temps. L’alternative à cette approche serait de sonder continuellement les changements - nous croyons fermemente que le coût des données supplémentaires par message est plus que compensé par la réduction du trafic global par rapport à l’interrogation constante. Avec les sondages, même lorsque le Réseau traverse une période calme, les sondages devraient se poursuivre furieusement en arrière-plan. D’autres approches pour arrêter / mettre en pause des parties du réseau pour parvenir à un accord comportent de nombreux effets secondaires et un code complexe, donc ceux-ci sont hors de propos.

En bref, avec la messagerie paresseuse, si un nœud reçoit un message et qu’il se rend compte que les détails de * l’état du réseau * dans le message entrant diffèrent de ce qu’il croyait être l’état, alors il communique davantage avec le nœud d’envoi pour se résoudre, ** ou l’expéditeur **, à jour avec * l’état du réseau * correct, alors le message d’origine peut être traité en conséquence.

La messagerie paresseuse a été implémentée dans sn_routing depuis un certain temps maintenant, se révélant efficace et fiable. Dans sn_node, nous avons rencontré quelques défis au cours des dernières semaines en essayant de mettre les nœuds à jour avec les derniers changements * d’état du réseau * (après le désabonnement, la promotion, la rétrogradation, etc.). Par exemple, lorsqu’une section se scinde, nous avons du mal à mettre à jour les nouveaux anciens des nouvelles sections respectives des frères et sœurs avec les aînés de la section parentale, tout en étant toujours en mesure de faire face au trafic et aux événements du réseau attendus typiques.

Nous avons eu un message paresseux marqué comme objectif final pendant un certain temps, mais jusqu’à présent, nous l’avons considéré comme une optimisation post-testnet. Cependant, cela ressemble à une lutte acharnée avec les défis auxquels nous avons été confrontés au cours des deux dernières semaines, et que nous mettons une quantité apparemment sans fin de plâtre temporaire sur des fissures dont nous savons qu’elles sont complètement résolues par des messages paresseux. Nous avons donc décidé de ne plus perdre de temps ici et de passer à l’utilisation de ce modèle dans sn_node pour mettre à jour * l’état du réseau * sur chaque nœud au fil du temps, au fur et à mesure des besoins.

Comme mentionné, il s’agit d’un travail supplémentaire qui, à notre avis, ne serait pas nécessaire avant le testnet, mais nous ne le considérons pas si important qu’il retarde un testnet de manière trop importante. Et c’est un autre élément coché sur notre liste de choses à faire sur la route de la version bêta et du lancement.

CRDT

Le travail a commencé sur un type de compteur borné qui nous permettra de plafonner les opérations sur un type de données. Il s’agit d’un composant précieux qui permet aux données modifiables de croître continuellement, tout en délimitant les données dans des compartiments. Cela signifie que nous pouvons payer pour télécharger le type de données, puis y ajouter librement jusqu’à un point délimité, moment auquel l’utilisateur paierait à nouveau et libérerait un autre ensemble d’espace d’opérations. Le fractionnement des données évolutives de cette manière répartit la charge sur le réseau. Il s’agit d’une optimisation, mais importante qui est requise pour le lancement, mais pas pour Fleming. C’est agréable de voir ces pincements et replis dans le pipeline maintenant.

Nous avons également apporté des modifications au type de données Sequence depuis que nous migrons pour utiliser le nouveau CRDT MerkleReg, qui nous permettra de conserver tout l’historique des ajouts, ainsi que d’autoriser des fourchettes de données si l’utilisateur final ou l’application les génère. volontairement ou non. Cela a un impact sur la façon dont notre API doit être présentée à l’utilisateur final, car selon le cas d’utilisation, il peut y avoir des fourches / branches d’ajouts que l’utilisateur peut vouloir non seulement traverser, mais également résoudre. Par conséquent, nous travaillons également à ajuster notre API côté client pour présenter toutes les fonctionnalités à l’utilisateur, sans la compliquer, et sans supprimer la flexibilité et la puissance que ce nouveau type de données CRDT apporte aux applications et aux développeurs.

Communauté et marketing

@jimcollinson a lancé une AMA sur Reddit, et à droite ici sur le forum, la semaine dernière.

L’objectif initial était de rassembler une paire de questions juteuses et d’y répondre lors d’une session de questions-réponses sur YouTube. Il y a eu une réponse splendide, les réponses à de nombreuses questions se sont avérées beaucoup plus détaillées qu’une seule session de questions-réponses ne pourrait en traiter. Voici donc la première réponse vidéo de ce qui deviendra probablement une série:

S’il vous plaît, aimez, partagez, dispersez, distribuez, diffusez, discutez et appréciez de la manière qui vous convient. Et n’hésitez pas à garder les questions à venir.

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