Actualités du développement Safe 🇫🇷 28 juillet 2022

Ceci est une traduction automatique. L’original en anglais est ici: Update 28 July, 2022

Cette semaine, nous terminons notre examen de la façon dont nous pouvons valider les sections et même le réseau lui-même en utilisant les clés de signature BLS pour créer un lien jusqu’à Genesis, avec l’adhésion actuelle liée au préfixe de section via le PrefixMap, et comment cela est régulièrement mis à jour par AntiEntropy (AE).

Progrès général

@Joshuef constate de bons progrès avec les problèmes de mémoire, dont certains peuvent être dus à des verrous provenant de traceroute. Avec quelques améliorations du test DBC de @bochaco, CI recommence à avoir l’air plus sain.

@Bochaco étudie également h3 et WASM et comment ils pourraient être intégrés au client. Il y a une bonne vidéo sur h3 (HTTP/3) ici - belle trouvaille @19eddiejohn75.

@Roland a écrit un PR pour déplacer SectionChain dans PrefixMap (voir ci-dessous). Il faudra d’abord quelques tests.

Et @oetyng a deux grands changements en cours : l’extraction du stockage des données et la simplification du flux de messages d’envoi.

Extraction de stockage de données
Passant à une structure node plus simple, nous avons précédemment extrait le module comms. Nous sommes maintenant sur le module data. C’était initialement dans le but de supprimer les verrous dans la structure du nœud, mais nous recherchons d’autres avantages. Le découplage permet de faire fonctionner ces composants de manière isolée, ce qui facilite et accélère leur test. De plus, nous pouvons mettre en place des versions plus petites d’un réseau, combinant certains modules et pas d’autres. Pour la structure node, nous en déplaçons la plupart des E/S, ce qui est un pas de plus vers une API potentielle de « fonction pure » du node. Cela vise à faciliter le raisonnement sur le code et les effets des changements, réduisant ainsi le risque de bogues.

Simplification de l’envoi de msg
Ce refactor supprime plus de 400 lignes de code et réduit le nombre d’endroits où nous appelons diverses fonctions d’envoi avec différents paramètres. Ces paramètres se sont avérés inutiles, et les différentes fonctions d’envoi n’étaient pas nécessaires non plus, en retravaillant un peu les choses. En outre, cela place la signature et l’instanciation de la structure WireMsg à un seul endroit.

Comment tout s’emboîte

En savoir plus sur BLS

Nous utilisons la génération de clé distribuée (DKG) comme moyen efficace de parvenir à un accord entre les aînés. Une fois que nous avons agrégé cinq partages sur sept, nous créons une nouvelle clé de section, qui est une clé publique, ainsi qu’une clé privée virtuelle qui n’existe pas réellement, car il s’agit d’un système sans propriétaire. Nous ne voulons pas que quiconque soit responsable lorsque nous parvenons à un accord.

Mais chaque aîné individuel - ou même n’importe quel nœud - peut également utiliser ses propres paires de clés BLS pour créer n’importe quel nombre de partages de clés, et ceux-ci peuvent être utilisés dans un mécanisme basé sur un concessionnaire. Dans ce système, il y a un propriétaire qui contrôle la clé secrète, et ce propriétaire est libre de créer et de distribuer des partages dans un système n-de-m. Par exemple, le propriétaire d’un site Web peut distribuer des partages de clés à trois employés de confiance et exiger qu’au moins deux d’entre eux approuvent toute modification apportée au site.

Nous n’utiliserions pas un mécanisme basé sur le concessionnaire pour un consensus décentralisé car nous ne voulons spécifiquement pas qu’il y ait un propriétaire de la clé secrète, mais nous pouvons l’utiliser pour mettre en œuvre le partage de données.

Plus sur PrefixMap, SectionChain et SAP

Le PrefixMap est simplement une structure qui mappe tous les préfixes de section (00, 01 …) à leurs fournisseurs d’autorité de section (SAP) actuels.

Le SAP est une liste des anciens de la section, avec leurs identifiants, adresses IP et ports, ainsi que la clé de section BLS actuelle. Ainsi, il fournit toutes les informations dont un nœud ou un client a besoin pour rejoindre le réseau.

Carte des préfixes

Préfixe                   SÈVE

00 → {[A(IP, port), B(IP, port), ….F(IP, port)], Sec_key}
01 → {[G(IP, port), H(IP, port), ….M(IP, port)], Sec_key}

….

Chaque nœud et client a une copie du PrefixMap - ils en reçoivent un dès qu’ils se connectent, ou ils peuvent en obtenir un d’amis, ou n’importe où. Mais le PrefixMap de tout le monde n’est pas à jour, donc le client ou le nœud qui entre en contact avec une section doit d’abord mettre à jour son PrefixMap avec le SAP actuel via AntiEntropy (AE). Ce n’est que lorsqu’elle dispose d’un SAP à jour qu’elle peut commencer à faire affaire avec la section.

Mais, bien sûr, il doit également savoir que le PrefixMap est authentique. Pour cela, il doit vérifier que le SAP est signé par une clé de section valide (la clé actuelle moins 1), et également que cette clé de section est valide, car elle a été signée par la précédente, etc. à la touche « Genesis ».

Ainsi, l’autre partie de PrefixMap est la SectionChain. Il s’agit d’une arborescence binaire qui relie toutes les clés de section BLS jusqu’à Genesis. Actuellement, il s’agit d’un élément distinct et nous nous synchronisons entre la clé dans le SAP et la chaîne, mais nous prévoyons de les réunir - à ce moment-là, nous devrons penser à de meilleurs noms !

À ce stade, le PrefixMap / SectionChain, ou tout ce que nous l’appellerons finalement, sera un DAG avec la clé Genesis à la racine et la chaîne de SectionKeys et tla clé actuelle et l’adhésion aux feuilles.

L’autre chose à mentionner est que si un client ou un nœud se reconnecte au réseau, il n’a pas besoin de mettre à jour à nouveau toute la SectionChain, juste la partie qui est nouvelle. Ainsi, la section à laquelle elle se connecte envoie ce nouveau morceau de la chaîne - appelé diversement une ProofChain ou une partie de la chaîne - au nœud de reconnexion afin qu’il puisse simplement l’ajouter à sa SectionChain existante.

Avec cette conception, même si quelqu’un réussissait à voler la clé « Genesis » et à se faire passer pour le réseau, cela aurait de moins en moins d’importance à mesure que le réseau s’agrandit et que le DAG a de plus en plus de branches, car nous devrons tracer le touches tout le chemin du retour à Genesis encore de moins en moins fréquemment.


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