Actualités du développement Safe 🇫🇷 29 septembre 2022

Dimitar · Octobre 4, 2022, 4:00

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

Nous avons simplifié le code et éliminé de nombreux problèmes en supprimant tous les processus multithreads asynchrones inutiles dans le code du nœud. Dans le même temps, certains problèmes de lenteur des communications subsistent, qui, selon nous, peuvent être causés par Quic lui-même, nous creusons donc cela.

En dehors du bug bashing, le nouveau code synchrone sn_sdkg est maintenant prêt pour l’intégration. @anselme nous explique cela cette semaine.

Progrès général

Qi_ma examine comment les anciens vérifient le « node_age » d’un nœud lorsqu’ils décident lequel déplacer vers une nouvelle section, car nous y observons des comportements anormaux, y compris des nœuds « zombies » pouvant rejoindre le réseau.

@ChrisO expérimente Quinn, qui est une implémentation Rust du protocole Quic pour établir et maintenir des connexions entre pairs. Malheureusement, Quic est une sorte de boîte noire, et nous pensons que certains des problèmes de connectivité que nous rencontrons peuvent être dus à son fonctionnement, en particulier au fait que les communications sont souvent lentes, ce qui entraîne des problèmes lorsque les processus expirent. Chris a configuré un bac à sable Quinn et voit ce qui se passe lorsque nous lui envoyons différents types de messages. Dans le même temps, @bzee examine la structure des communications qp2p pour confirmer que nous utilisons Quinn aussi efficacement que possible. Le problème clé est de recevoir des flux simultanés de manière asynchrone tout en autorisant les attentes sur les réponses (renvoi d’un observateur, pour surveiller les messages de réponse sur le même canal).

@roland travaille sur des tests fuzz pour la nouvelle caisse sn_sdkg, que @anselme décrit en détail ci-dessous.

Intégration sn_sdkg

La génération de clé distribuée (alias DKG) est la façon dont les anciens de la section génèrent la clé de section de manière sécurisée qui garde la clé de section secrète. À la fin de DKG, chaque aîné ne connaît que son propre partage de clé secrète, de cette façon personne ne voit jamais la clé secrète de la section entière. Il s’agit d’un mécanisme pour atténuer le champ d’action des anciens potentiellement mauvais : c’est ainsi que Safe Network peut garantir que tant que nous avons moins de 5/7 mauvais anciens, ils ne peuvent rien signer avec l’autorité de la section. L’autorité de la section est requise pour modifier les données, promouvoir ou désigner des nœuds et créer des jetons, c’est donc très important.

Récemment, nous avons travaillé sur un nouveau DKG qui est plus résistant à la perte de paquets et qui n’utilise pas de minuteries, de sorte qu’il ne peut pas échouer en raison du trafic réseau lent et des délais d’attente. Cet article décrit le fonctionnement de ce nouveau DKG. Pour cette implémentation, nous utilisons la caisse génération de clé distribuée synchrone sn_sdkg, qui est basée sur l’algorithme de génération de clé synchrone de poanetwork dans leur caisse hbbft.

Comment fonctionne DKG

DKG est déclenché par les anciens lorsqu’ils remarquent que les membres les plus âgés ne sont pas les anciens, ou lorsqu’une section se divise et qu’ils doivent choisir des candidats plus âgés. Lorsqu’ils remarquent cela, les anciens actuels demandent aux candidats de démarrer une nouvelle session DKG avec un message « DkgStart », afin qu’ils puissent générer la clé de section suivante.

La première étape de notre DKG consiste à générer des clés BLS temporaires, qui sont utilisées pour le chiffrement dans le processus DKG. Chaque nœud du réseau sécurisé possède une clé ed25519, mais bien que ces clés soient idéales pour les signatures, nous ne pouvons pas effectuer de chiffrement en toute sécurité avec elles. Nous avons besoin d’un autre moyen.

Étant donné que nos nœuds n’ont pas de clés BLS (les anciens ont un partage de clés BLS mais pas une simple clé BLS), nous générons une clé unique uniquement pour cette session DKG et la supprimons après utilisation. Cependant, nous avons besoin que les autres nœuds fassent confiance à cette clé BLS car elle est toute nouvelle, donc avant que quoi que ce soit d’autre ne se produise, chaque candidat diffuse sa clé publique BLS nouvellement générée dans un message qui contient sa signature (faite avec sa clé ed25519 de confiance) sur la nouvelle clé publique BLS à usage unique qu’ils utiliseront pour cette session DKG.

Une fois que les candidats ont toutes les clés publiques du BLS pour cette session DKG, ils peuvent commencer à voter. Le vote comporte 3 étapes :

Parts : chaque nœud soumet une Part qui sera utilisée pour la génération finale de la clé, elle contient des données cryptées qui seront utilisées pour générer leur partage de clé.
Acks : les nœuds vérifient les Parts et soumettent leurs Acks (accusés de réception) sur les Parts. Ces Ack seront également utilisés pour la génération de clé.
AllAcks : tout le monde s’assure qu’ils ont tous le même ensemble d’Acks et de Parts en envoyant leur version des ensembles. Cette dernière partie est là pour s’assurer que les candidats finissent par générer la même clé de section !

Une fois le vote terminé, les candidats peuvent générer leurs parts de clé secrète avec la clé publique de la nouvelle section à partir des « Parts » et des « Acks ».

Potins et résiliation éventuelle

Sur un réseau, des messages peuvent être perdus et cela peut conduire à des situations où certains candidats manquent des votes et certains attendent une réponse à des votes qui ne sont jamais arrivés. Pour contrer ce problème, nous avons des potins! De temps en temps, si un nœud n’a pas reçu de nouveaux messages DKG alors qu’il en attend, il enverra tous ses votes aux autres. Cela a deux objectifs :

l’un est d’informer les autres des votes, et de les obtenir up pour accélérer les votes qu’ils auraient pu manquer
l’autre est de montrer aux autres participants qu’il manque des votes à notre nœud, afin que les autres puissent répondre à leur tour avec leurs votes et nous aider à les rattraper

En effet, si un nœud reçoit un message gossip auquel manque une information, il répondra avec sa connaissance. Cela se produit même après la fin (fin du tour de scrutin), car parfois, lorsqu’un nœud se termine (et arrête donc de bavarder car il n’attend plus de votes), il recevra toujours des commérages d’autres nœuds qui n’y sont pas parvenus encore. Dans ce cas, le nœud bien informé répondra à ces commérages avec ses connaissances afin que les autres nœuds puissent également atteindre la terminaison. Finalement, à travers ce processus, chaque candidat atteint la résiliation.

DKG simultanés

Dans cette implémentation, nous adoptons des DKG simultanés. Parfois, juste après le déclenchement de DKG, un nouveau nœud rejoint la section et semble être un meilleur candidat aîné car son âge de nœud est très élevé. Dans ce cas, l’ensemble actuel des meilleurs candidats anciens change et les anciens actuels envoient un autre message « DkgStart » aux nouveaux candidats.

La précédente session DKG n’est pas arrêtée, c’est maintenant une course entre les deux ! Nous voulons que les aînés soient des nœuds très fiables. D’une certaine manière, le processus DKG intensif est un test pour vérifier que ces candidats sont bien aptes à être des aînés. Si plusieurs DKG se terminent en même temps, ça va, « Handover Consensus » s’assurera que les anciens actuels ne choisissent qu’un seul gagnant. Les sessions DKG qui n’ont pas gagné la course peuvent ou non se terminer, mais cela n’a pas vraiment d’importance, elles finiront par être supprimées lorsque les nœuds se rendront compte qu’ils ont perdu.

Conclusion

En bref, le nouveau DKG vise à être très résistant à la perte de messages, en supprimant le besoin de minuteries et en s’assurant que tout le monde finit par se terminer sans délais d’attente possibles. Il fait également des DKG simultanés une fonctionnalité permettant de sélectionner les meilleurs candidats dans une course à la résiliation entre les DKG.

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