Ceci est une traduction automatique. L’original en anglais est ici: Update 18 November 2021
Alors cette semaine on passe la parole à Gab
Comme vous le savez, il n’est pas du genre à se vanter
Mais il a tranquillement réglé un problème de messagerie
En stockant les SectionChains dans un DAG
OK, c’est pas une Lambo ou même une Jag
Mais pour les opérations de réseau, c’est vraiment fabuleux
Jetez un oeil si c’est votre sac
Progrès général
@danda a créé des diagrammes UML pour toutes les caisses Safe Network, ce qui permet de voir facilement comment ils s’emboîtent tous. Pour les non-techniciens, la possibilité de parcourir les noms des blocs de code et leur lien donne un aperçu du fonctionnement du réseau. Comme pour voir tous les rouages d’une montre, vous ne comprendrez peut-être pas tous les détails du pas et du nombre de dents, mais il peut être bon de voir les rouages derrière la lunette pour mieux comprendre son fonctionnement. Vous pouvez voir des versions nues, compactes et complètes de chaque caisse, avec des niveaux de détail croissants, avec des blocs verts représentant les traits, les structures bleues et les énumérations jaunes. Le site est mieux visualisé dans Chrome.
Une représentation SVG « nue » de la caisse sn_dbc
Pendant ce temps, @qi_ma et @lionel.faber se concentrent sur la mise en œuvre du modèle Anti-Entropy dans le processus de génération de clés distribuées.
OK à Gabriel (@bochaco).
Gestion des connaissances du réseau
La connaissance du réseau décrit les processus par lesquels les Aînés gardent une trace de la topologie du réseau. Parce que Safe est asynchrone et change constamment, cela se fait sur la base du besoin de savoir, de sorte que lorsqu’un nœud contacte un autre nœud, il obtient d’abord sa synchronisation en échangeant des messages Anti-Entropy (AE).
Afin de réduire la messagerie, nous avons maintenant un DAG pour garder une trace de toutes les SectionChains et un PrefixMap pour stocker les SAP de la section actuelle. Ce qui suit explique comment cela affecte la vérification AE et SAP lorsqu’un message initial est rejeté.
Chaîne de sections
Une SectionChain est l’un des outils les plus importants disponibles pour un nœud, car elle lui permet de vérifier si une donnée ou un message est valide (a l’autorité réseau).
Une SectionChain est une liste chaînée de clés de section, où la clé de chaque bloc de la chaîne est signée par la clé du bloc précédent, jusqu’à la clé de genèse.
Chaque bloc de la chaîne contient la clé de section que les Aînés utilisaient - à ce moment particulier - pour signer toutes les procédures d’accord. Chaque fois que les Anciens changent (désabonnement), une nouvelle clé de section est générée et un nouveau bloc est ajouté à la SectionChain.
Comment est-il utilisé pour vérifier les messages et les données ? Eh bien, tout élément de contenu ou d’information signé par une clé de section peut être vérifié en examinant la SectionChain. Si la clé s’y trouve, cela signifie que l’élément de contenu/d’information a été signé par la section dans le passé et qu’il a donc l’autorité sur le réseau.
Réessayer et rediriger l’anti-entropie
Le réseau utilise un ensemble de messages anti-entropie (AE) pour que les nœuds se synchronisent sur la topologie du réseau et la section à laquelle ils appartiennent. Chaque message envoyé à un nœud ou à une autre section doit inclure la clé de section actuelle de la destination pour que le message soit accepté par le destinataire. Si ce n’est pas le cas, le destinataire rejettera le message et le renverra à l’expéditeur dans un message « AE-Retry ». Le message « AE-Retry » contient des informations à jour sur sa section, c’est-à-dire le fournisseur d’autorité de section actuel (SAP), qui répertorie les anciens de la section actuelle, et la clé de la section actuelle (voir le chapitre AE dans l’introduction).
Un flux d’événements similaire est déclenché lorsqu’un message est envoyé à une section incorrecte, ce qui peut être dû au fait que l’expéditeur ne dispose pas des dernières informations sur la topologie du réseau. Le destinataire rejettera également le message en le renvoyant à l’expéditeur dans un message « AE-Redirect ». Dans ce cas, le message « AE-Redirect » contient le SAP de la section à laquelle le message doit être renvoyé.
Lorsque l’expéditeur reçoit un nouveau SAP via un message « AE-Retry » ou « AE-Redirect », il doit d’abord vérifier qu’il s’agit d’un SAP valide et de confiance, c’est-à-dire vérifier que le SAP correspond au réseau auquel l’expéditeur fait confiance.
Pour ce faire, le nœud doit vérifier que la clé de section trouvée dans le SAP reçu est vérifiable par chiffrement avec la SectionChain jusqu’à la clé de genèse, sinon un nœud malveillant pourrait la rediriger vers un autre (non sûr) réseau ou à des pairs ou des sections malveillants. C’est pourquoi chaque message Anti-Entropy porte également une ProofChain afin que l’expéditeur d’origine puisse vérifier et faire confiance au nouveau SAP.
Une ProofChain est constituée des quelques blocs les plus récents de la SectionChain - nous n’avons pas besoin d’envoyer la SectionChain complète si nous avons récemment été en contact avec une autre section, juste le delta.
Qu’est-ce qui a changé ?
Jusqu’à présent, chaque nœud conservait une copie de sa propre SectionChain et SAP.Cela a été utilisé pour valider tout message entrant ou nouveau SAP reçu dans les messages AE, et également pour créer une ProofChain lors de l’envoi de messages AE à d’autres pairs.
Ce qui était bien pour les sections que nous connaissons, mais pour les sections éloignées et inconnues, cela a créé un peu de travail supplémentaire.
Disons que nous envoyons un message et qu’il est renvoyé disant que nous devons le rediriger vers une section que nous n’avons pas contactée auparavant, et incluant le SAP de cette section inconnue. Nous connaissons la section par son préfixe d’adresse XOR, mais nous n’en savons rien d’autre, ni nous. Nous n’avons jamais vu son SAP auparavant et nous n’avons pas de ProofChain. Ainsi, avant de pouvoir renvoyer le message à la nouvelle section, nous devons envoyer des messages supplémentaires pour échanger des SectionChains, ce qui est complexe et sujet aux erreurs.
C’est pourquoi nous avons récemment travaillé pour que tous les nœuds gardent une trace de toutes les SectionChains des autres sections. Cela permet à chaque nœud de fournir une ProofChain aux pairs non seulement lors de leur mise à jour avec le SAP de leur propre section, mais également lorsqu’un message « AE-Redirect » leur dit de le faire pour une section distante.
Cela supprime une partie du trafic et de la complexité AE, et permet également aux nœuds de s’assurer qu’ils n’interagissent qu’avec des pairs auxquels ils font confiance pour appartenir au même réseau, en vérifiant cryptographiquement toute clé de section qu’ils reçoivent jusqu’à la clé de genèse.
Mais comment stocker ces informations de manière sécurisée et efficace, afin que les nœuds puissent y accéder quand ils en ont besoin et qu’elles soient mises à jour en cas de fractionnement et de désabonnement ?
Nous avons maintenant implémenté un DAG (graphique acyclique dirigé) pour garder une trace de toutes les SectionChains et un PrefixMap (un registre mappant le préfixe d’une section à son SAP) pour stocker les SAP actuels de toutes les sections.
Le DAG
Le réseau commence par une clé de genèse, qui est le tout premier bloc de la SectionChain de la section de genèse, et la toute première clé de nœud est signée par la clé de genèse pour créer le deuxième bloc de cette SectionChain. Au fur et à mesure que les nœuds commencent à rejoindre cette toute première section, c’est-à-dire la section de genèse, la SectionChain continue de croître.
À un moment donné, lorsque la section de genèse a grandi avec suffisamment de membres pour se diviser en deux sections distinctes, les deux groupes de pairs qui deviendront des anciens se mettront d’accord sur ce qui deviendra leur propre clé de section (via le processus DKG). Une fois qu’ils auront tous fini de se mettre d’accord sur les deux nouvelles clés de section, l’ensemble actuel d’Anciens parviendra à un accord pour diviser la section, en signant les deux nouvelles clés de section avec la clé de section actuelle et en créant deux branches dans la SectionChain de la section Genesis.
Ce processus est répété dans chacune des deux nouvelles branches, indépendamment l’une de l’autre. Ils se divisent en plusieurs sections, créant plus de branches dans leurs SectionChains respectives. Cela forme naturellement un DAG, chacun des sommets contenant une clé de section et la signature faite avec la clé de section du sommet précédent.
Étant donné n’importe quelle clé de section, sa ProofChain peut être construite à partir du DAG en collectant tous les sommets (clés de section et signatures) qui se trouvent sur le chemin de la clé de genèse à cette clé de section. Notez que puisque les sections ne fusionnent jamais mais seulement se séparent, il existe toujours un chemin unique de la clé de genèse à toute autre clé de section dans le DAG, en d’autres termes, il existe une chaîne de preuve unique à partir de la clé de genèse pour toute clé de section donnée.
Ce développement est détaillé dans ce PR.
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é. Ne soyez donc pas timide, rejoignez-nous et créons ensemble le réseau sécurisé!