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

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

Quelque chose d’une préquelle cette semaine alors que nous examinons comment les SectionChains et les SAP s’intègrent aux changements de PrefixMap annoncés la semaine dernière.

Progrès général

Pas de grandes révélations cette semaine, plus du travail régulier de test, d’optimisation et de débogage qui marque cette phase du développement.

@davidrusu a cherché des moyens de surveiller le réseau et d’administrer Node Age, y compris comment les adultes peuvent prouver aux aînés qu’ils sont vivants, même s’il n’y a pas beaucoup d’activité sur le réseau.

@bzee continue d’examiner OpenTelemetry l’outil de surveillance open source, avec certains refactors déjà en place pour permettre la journalisation via le protocole OTLP. Cela devrait, espérons-le, nous permettre de nous connecter au serveur élastique, où nous pourrons plus facilement avoir un aperçu de l’état des réseaux de test.

Et @joshuef continue de bricoler avec l’optimisation de la mémoire. Nous avons supprimé certaines tentatives trop zélées qui maintenaient potentiellement les connexions en vie et les messages en attente en mémoire pendant que l’envoi était réessayé et réessayé et réessayé (à la fois au niveau de la couche qp2p et dans le nœud). Il a également fait d’autres ajustements plus petits qui ont tous contribué à réduire considérablement la charge de la mémoire.

@yogesh a un RP en place pour permettre le retour des informations de traceroute au client. Cela répertorie tous les nœuds impliqués dans le flux de messagerie pour une requête/cmd donnée, ce qui devrait faciliter le débogage.

Chaînes de sections et SAP

Les chaînes de section fournissent un enregistrement des changements d’anciens au sein d’une section, agissant comme preuve que l’ensemble actuel d’anciens est valide. Nous ne pouvons croire sur parole d’un aîné qu’il est ce qu’il prétend être, ni faire confiance au groupe actuel - ce serait un vecteur d’attaque évident. Au lieu de cela, nous utilisons les merveilles de la cryptographie pour créer une SectionChain, une liste liée sécurisée qui prouve que les anciens sont bien ce qu’ils prétendent être, en reliant la clé de section actuelle jusqu’à la clé de genèse.

La clé « Genesis » peut être considérée comme une « preuve de réseau ». Il s’agit de la toute première clé créée par le tout premier nœud de la toute première section - la section avec le préfixe « 0 ». Dès que ce premier nœud solitaire est rejoint par un autre nœud (en essayant de résister à l’appeler Eve car cela deviendra rapidement déroutant), une nouvelle clé de section B est créée, qui est signée par la clé de genèse. Lorsqu’un nouveau nœud C se joint, une nouvelle clé de section est à nouveau créée, cette fois signée par « B », et ainsi de suite.

Les jours de signature de la clé « Genesis » sont terminés dès qu’elle signe la clé « B ». Cependant, il reste extrêmement utile comme preuve que la clé de section actuelle et toutes celles qui la précèdent sont valides, et non introduites par un attaquant, car il est cryptographiquement très facile de prouver que la clé actuelle de n’importe quelle section est finalement liée à Genesis, quelle que soit la durée de la SectionChain devient.

Signature

Mais qu’entend-on par signature ? Signer signifie simplement utiliser notre clé secrète pour ajouter des bits uniques à un message ou à un fichier. Toute personne disposant de notre clé publique peut vérifier que c’est bien nous qui l’avons signée (et dans la plupart des cas que le fichier n’a pas changé après la signature).

Pour utiliser l’exemple classique, Alice envoie un message à Bob et le signe avec sa clé secrète, ce qui signifie qu’elle crée une « signature » unique à partir d’une combinaison du contenu du message et de sa clé secrète. Bob peut être sûr qu’elle a été signée par Alice car il peut vérifier la signature avec sa clé publique. Eavesdropper Eve a également la clé publique d’Alice, mais elle est impuissante à tromper Bob en modifiant le message d’Alice car il ne porterait plus de signature valide.

Plutôt que des individus comme Alice et Bob, dans une section, nous traitons de décisions de groupe qui doivent être approuvées par une super majorité d’anciens. Pour être tolérant aux pannes byzantines (ce qui signifie qu’un tiers des nœuds peuvent être dysfonctionnels sans provoquer de panne), cinq anciens sur sept doivent signer un message. Plutôt que de demander à chaque aîné de suivre un processus comme Alice et Bob ci-dessus, un moyen beaucoup plus efficace de le faire consiste à utiliser la génération de clé distribuée (DKG), où chaque aîné contribue une part de clé. Dès que nous avons cinq de ces parts de clé - cinq quelconques - nous créons une clé de signature valide et la décision est validée. C’est l’équivalent de la section clé secrète signant le message, même si avec BLS une clé secrète n’existe pas.

Tout va bien tant que nous n’avons qu’une seule section, mais au fur et à mesure que le réseau se développe, la section se divisera pour créer de nouvelles sections « 01 » et « 11 » avec de nouveaux anciens et de nouvelles SectionKeys signées par celle de la section parente. Ces nouvelles sections connaîtront un taux de désabonnement plus ancien au fil du temps, créant à chaque fois une nouvelle DKG SectionKey. Finalement, une structure arborescente est formée avec la genèse comme racine et chaque branche engendrant deux nouvelles branches à mesure que le réseau se développe.

L’important est que chaque clé de section actuelle dans chaque section ait un chemin le long des branches vers la clé de genèse. Autrement dit, nous pouvons prouver que nous sommes sur le bon réseau et que le processus d’accueil de nouveaux nœuds a été valide à chaque étape, au moins jusqu’à la DKG est concerné. Mais dès qu’il y a plus d’une section, chaque section a un chemin différent vers la « Genèse », à quel point la chaîne de section devient un DAG (graphe acyclique dirigé) plutôt qu’une chaîne linéaire.

Le fournisseur d’autorité de section (SAP)

La chaîne de sections est un outil simple mais vital. Chaque nœud et client détient une SectionChain. En tant que client ou nœud, il nous indique que la section actuelle à laquelle nous parlons est cryptographiquement valide et que nous sommes dans le bon réseau (comme le prouve la clé Genesis), plutôt qu’un fork, mais c’est à peu près tout .

Lorsqu’un nœud ou un client rejoint le réseau, il reçoit la SectionChain et le SAP. Le SAP nous renseigne sur les anciens actuels. Il s’agit d’une liste des anciens actuels (chaque ancien a un identifiant unique, une adresse IP et un port) signé par l’une des clés de la SectionChain. Cela signifie que lorsque nous nous connectons à un nœud de cette liste, nous pouvons être sûrs qu’il est valide, car, encore une fois, la signature peut être retracée jusqu’à Genesis. Le SAP contient également la SectionKey actuelle.

Comme expliqué la semaine dernière, le SAP est inclus dans le PrefixMap, qui mappe chaque préfixe de section à toutes les clés de l’historique de cette section. En plus de pouvoir vérifier que toutes les données que nous traitons sont correctes (elles auront le même préfixe que la section), cela signifie également que lorsque nous nous déplaçons entre les sections, nous n’avons pas à saisir à nouveau la chaîne de section entière. Au lieu de cela, nous pouvons simplement descendre l’arbre aussi loin que nécessaire, jusqu’à atteindre une section qui existe déjà dans notre chaîne de sections et la prendre à partir de là, ce qui est évidemment plus efficace.

La semaine prochaine, en savoir plus sur la façon dont tout cela s’emboîte.


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