Actualités du développement Safe 🇫🇷 30 juin 2022

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

Les aînés utilisent la génération de clé distribuée (DKG) pour décider entre deux plans d’action alternatifs possibles. Chaque aîné génère une part de clé et l’envoie avec son vote, et si une majorité qualifiée (5 sur 7) de ces parts de clé est reçue, elles sont agrégées pour créer la clé complète requise pour valider la décision. Nous avons développé notre propre système pour ce faire en utilisant la cryptographie BLS, qui fonctionne bien la plupart du temps - mais pas tout le temps. Malheureusement, en cas d’échec, le réseau peut s’arrêter. Cette semaine, @anselme fournit un guide pour débutants sur DKG, et lui et @davidrusu expliquent comment nous cherchons à rendre notre implémentation DKG plus robuste.

Progrès général

@davidrusu et @joshuef ont creusé davantage pour rendre sn_node monothread autant que possible pour se débarrasser du problème causé par le verrouillage. Cela nécessitera un peu de refactorisation, en déplaçant Comm - le code qui gère la messagerie entre les nœuds - hors de sn_node afin qu’il puisse mieux se suffire à lui-même et avoir potentiellement son propre thread.

Pendant ce temps, @bochaco a travaillé sur la frappe de la genèse initiale DBC par le premier nœud du réseau, la gestion des livres dépensés afin que les nœuds ne besoin de conférer avec d’autres sections pour voir si une transaction est valide, et d’autres étapes de l’intégration DBC.

@bzee est coincé dans des algorithmes de dispersion d’informations (IDA), qui, comme vous vous en souvenez peut-être, est la façon dont nous réduisons le stockage et les exigences de bande passante du réseau, et @roland travaille sur des tests de module d’écriture pour DKG et assiste @Anselme avec la nouvelle caisse sn_sdkg (s signifie ici synchrone).

Vers un DKG for Safe plus stable

La génération de clé distribuée (DKG) est nécessaire pour que le réseau sécurisé garantisse que chaque aîné d’une section dispose d’un fragment unique de la clé de section : le partage de clé. Il permet au réseau de générer une clé secrète pour chaque section, sans jamais qu’un seul nœud connaisse la clé de section entière. Cela rend le réseau sécurisé plus résistant aux nœuds byzantins car il n’a pas besoin de faire confiance à tous les anciens.

L’implémentation actuelle de DKG a un défaut qui nous embête depuis de nombreux mois : l’utilisation de minuteries. DKG exige la pleine participation de tous les nœuds qui souhaitent pouvoir signer. En période de forte activité du réseau, les nœuds peuvent être sauvegardés et ne pas participer aux sessions DKG en temps opportun.

Avec notre implémentation actuelle, si les nœuds mettent trop de temps à contribuer à DKG, la session DKG échouera. Nous avons tenu à supprimer tous les comportements liés au temps dans Safe Network, en adoptant les flux simultanés et asynchrones par défaut.

Nous recherchons depuis un certain temps une alternative au DKG basé sur la minuterie et nous pensons avoir enfin trouvé quelque chose qui fonctionnera en nous appuyant sur le travail d’adhésion et de transfert que nous avons effectué.

DKG pour le reste d’entre nous

Bien que DKG puisse sembler être une chose très technique et complexe, j’ai l’impression que son utilité et ses mécanismes de base peuvent être expliqués à un enfant de 6 ans.

Imaginez un royaume avec un roi. Le roi a un timbre en ivoire que personne ne peut falsifier. Toute lettre portant le sceau d’approbation du roi est considérée par tout le royaume comme digne de confiance.

tampon ivoire == clé secrète
sceau d'approbation sur une lettre == lettre avec la signature du roi

Un jour, le roi se rend compte qu’il est vieux. Le roi a quatre héritiers, et il veut être juste, alors il demande à son maître artisan de briser son timbre d’ivoire en quatre morceaux égaux qui peuvent chacun imprimer une partie du sceau du roi. Il distribue ensuite un de ces minuscules timbres à ses quatre enfants. Maintenant, afin de recréer le sceau d’approbation du roi, les enfants doivent utiliser leurs minuscules tampons en ivoire et imprimer chacun leurs parties de sceau les unes à côté des autres jusqu’à ce que l’on puisse revoir le sceau complet.

4 morceaux de tampon ivoire == multisig
petit tampon == partage de clé

Au bout d’un moment, les héritiers se rendent compte que ce mécanisme ralentit le royaume car exiger toutes les pièces de sceau à chaque fois est une opération fastidieuse, certains d’entre eux sont absents et voyagent parfois, donc obtenir toutes les pièces de sceau peut devenir assez compliqué. Ils ont donc une idée : ils conviennent que tant qu’on peut voir plus de la moitié du sceau du roi sur une lettre (3/4+ sceau), le sceau est considéré comme valide et porte l’autorité du royaume.

Sceau 3/4+ == cryptographie à seuil

Un jour, les héritiers se rendent compte que le maître artisan était malhonnête et a conservé une copie du timbre d’ivoire original du roi et qu’il les vendait dans tout le royaume à des malfaiteurs. Les héritiers décident alors de créer un nouveau timbre pour leur royaume. Mais afin d’éviter l’erreur de la dernière fois, ils engagent chacun un artisan pour créer une seule nouvelle pièce d’un nouveau timbre. Chaque héritier a son propre sceau qu’il a créé de son côté. En les réunissant, ley obtenir un nouveau sceau royal unique et qu’aucun timbre ne peut falsifier. Ils décrètent que l’union de plus de la moitié de ces sceaux représente l’autorité du royaume. Puisque personne n’a jamais vu le timbre complet, ils peuvent être sûrs que personne ne trichera cette fois.

timbres créés séparément qui constituent un sceau unique == DKG

Dans le Safe Network, DKG est utilisé par les anciens pour générer la clé de section qui porte l’autorité de section. Dans la terminologie SN, la clé de genèse (clé du premier nœud du réseau) est comme le timbre du roi. Une fois que plusieurs membres se joignent, le nœud de genèse et les nouveaux nœuds exécutent DKG pour créer une nouvelle clé de section. Ils créent chacun leur propre partage de clés (de minuscules tampons), mais ils n’ont jamais vu les clés de l’autre, donc personne n’a jamais la clé entière entre les mains. Chaque fois qu’il y a un changement d’anciens (les héritiers), les nœuds effectuent DKG pour créer une nouvelle clé de section. C’est assez sûr car il faudrait contrôler une super-majorité des nœuds les plus anciens pour avoir l’autorité de la section (plus de la moitié du sceau du royaume).

DKG de Poanetwork

hbbft (algorithme de consensus Honey Badger Byzantine Fault Tolerant) de Poanetwork a une implémentation assez simple de DKG qui n’utilise pas de minuteries. Leur code a été audité par des spécialistes de la cryptographie, c’est donc aussi un gros avantage par rapport au nôtre.

L’algorithme de génération de clé de HBBFT en bref :

  • Les participants génèrent chacun des Parts qu’ils diffusent aux autres
  • Les participants vérifient toutes les Parts et génèrent des Acks (accusés de réception) pour chacun d’eux, également diffusés aux autres
  • Enfin, ils peuvent chacun générer leur propre partage de clé à partir des Parts et Acks

Il y a quand même un hic ! Ils ont tous besoin de traiter les mêmes ensembles de Parts et Acks !

De leurs docs:

Si l’accusé de réception d’Alice était géré par Bob mais pas par Carol, Bob et Carol pourraient recevoir différents ensembles de clés publiques et des partages de clés secrètes qui ne correspondent pas.
Une façon de s’en assurer est de valider les messages dans un grand livre public avant de les traiter.

Bien qu’il n’y ait pas de temporisateurs impliqués, cet algorithme nécessite que les nœuds s’attendent les uns les autres.

Intégration avec Safe

Nous devons nous assurer que tous les participants ont accès aux mêmes ensembles de Parts et Acks. Les documents de Poanetwork suggèrent d’utiliser un registre distribué comme une blockchain pour s’assurer que tous les participants ont les mêmes ensembles. Nous n’avons pas de blockchain dans Safe - mais ça va. Notre équipe a eu une idée avec des messages signés diffusés qui ne nécessitent pas un consensus complet ! Cela fonctionne comme suit :

  • Envoyer Parts dans un message signé
  • Attendez que les 7 Parts arrivent, diffusez le set signé
  • Attendez que les 7 ensembles signés identiques de « Parts » arrivent
  • Envoyer des accusés de réception
  • Attendez que les 7 Acks arrivent, diffusez le set signé
  • Attendez jusqu’à ce que les 7 ensembles signés identiques de Acks arrivent
  • Une fois qu’un nœud reçoit 7 ensembles signés avec les mêmes « accusés de réception », il peut générer le partage de clé à partir des « parties » et des « accusés de réception » convenus.

Le fait que nous ayons ce tour supplémentaire de diffusion tout-à-tous pour que tous les nœuds voient que tous les nœuds ont vu les mêmes « Parts » et « Acks » rend cet algorithme résistant à un certain nombre de nœuds byzantins. Il est également facile de prouver qu’un nœud a triché en affichant deux messages différents et contradictoires qu’il a signés.

Bien que cet algorithme simple s’assure que les nœuds s’accordent sur les mêmes Parts et Acks, il ne garantit pas l’arrêt en cas de perte d’un certain nombre de messages. C’est bien, nous l’embrassons et ne le voyons pas comme un échec.

Si suffisamment de messages sont perdus, nous supposons que cet ensemble de candidats n’était pas apte à devenir des anciens en premier lieu. À chaque événement de désabonnement (nœud rejoignant ou quittant une section), les anciens vérifient si les 7 membres les plus âgés de la section sont les anciens actuels. Si ce n’est pas le cas, ils demandent aux membres les plus âgés de démarrer DKG. Ce processus s’appelle Handover.

Les événements de désabonnement peuvent se produire à un rythme assez rapide, de sorte que plusieurs DKG simultanés sont possibles. C’est une course entre plusieurs DKG, et celui qui termine en premier remporte le droit de passer par le processus de transfert. De nombreux DKG peuvent être laissés pour compte, soit pas encore terminés, soit bloqués en raison de la perte de messages, mais ce n’est pas grave, cela fait partie du jeu. Chaque nœud conserve ses statuts DKG actuels dans un ensemble temporaire qui est réinitialisé à chaque transfert.

Cet algorithme fait de DKG un processus passif : il s’agit uniquement de traitement de messages. Il n’y a pas de temporisateurs, pas de récupération de données sur d’autres nœuds, juste un ensemble temporaire de DKG en cours attendant d’être terminés ou supprimés après le prochain transfert.

Si, pour une raison quelconque, plusieurs messages sont supprimés et qu’un DKG ne peut pas être terminé, cela est facilement géré. Nous pouvons laisser le soin à Dysfunction de rechercher éventuellement les nœuds inactifs/lents et de les rejeter. Cela déclenche à son tour churn, et ce désabonnement déclenche un nouveau tour DKG.

Liens


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