Actualités du développement Safe 🇫🇷 13 octobre 2022

Développement
1

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

1
1830×430 59.6 KB

Nous parlons depuis un moment maintenant du processus remanié pour l’élection des nouveaux anciens de section et la gestion des scissions. Cette semaine, @anselme approfondit la réflexion derrière l’approche de la ceinture et des bretelles.

Progrès général

@Chriso refactorise les processus de signature des blocs et des registres et teste le stockage et les doubles dépenses DBC.

@roland travaille sur des tests pour l’AE sn_sdkg et la fonctionnalité d’adhésion décrite ci-dessous.

Mostafa a recherché des mécanismes de consensus décentralisés et revoit notre configuration actuelle.
@davidrusu retravaille le processus de jointure pour inclure la mise à jour des connaissances du réseau avant la jointure.

Et @anselme et @dirvine refactorisent le processus d’autorité comme décrit la semaine dernière.

@bzee, @bochaco et @joshuef travaillent sur le débogage de la stabilité de niveau inférieur. Nous avons constaté une combinaison de lenteur de la gestion des messages et de bogues dans la gestion des connexions causant parfois des problèmes. Nous allons donc plonger profondément ici. Nous avons fait des progrès, en simplifiant la gestion des messages et nous continuons sur ce front, car il semble que ce sera un refactor assez prometteur, à la fois en termes de simplicité de code, mais aussi de stabilité.

Tout sur sn_sdkg

DKG avec sn_sdkg

  • Basé sur la génération de clé de poanetwork dans hbbft
  • Supprime les minuteries
  • Présente les potins
  • Embrasse le DKG simultané
  • Une course entre DKGs pour Handover

Nous venons d’intégrer sn_sdkg (génération de clé distribuée synchrone de Safe Network), remplaçant la version précédente où nous avons vu des échecs et des délais d’attente lorsque les réseaux étaient lents. La cause principale est probablement que nous utilisons des minuteries. Ce nouveau processus DKG n’utilise pas de minuteries, en fait, nous ne voulons pas de minuteries sur Safe, n’importe où, du tout.

DKG n’est pas actif, c’est juste quelque chose que les nœuds font en arrière-plan lorsqu’ils reçoivent des messages système, et ils peuvent exécuter plusieurs sessions simultanément.

En plus d’utiliser l’anti-entropie (AE), sn_sdkg introduit également des commérages, pour s’assurer que les nœuds reçoivent tous les messages qui pourraient leur manquer, afin que tout le monde soit finalement cohérent.

Parcourons-le.

Les anciens envoient DkgStart

  • division de section
  • remise de section

La première étape du processus est que les anciens envoient un message « DkgStart ». Cela se produit lorsque l’une des deux situations se présente. Le premier est lorsqu’un nœud arrive dans une section qui est plus ancienne qu’un ou plusieurs des anciens actuels. Dans ce cas, nous devons passer la main - le nouveau nœud est promu et les connaissances de la section sont transmises. Le deuxième scénario est lorsque la section devient trop grande et se divise.

pub structure DkgSessionId {
    /// Préfixe de la session pour laquelle nous sommes candidats aînés
    préfixe pub : préfixe,
    /// D'autres Aînés dans cette session dkg
    anciens de pub : BTreeMap<XorName, SocketAddr>,
    /// La longueur de la branche principale de la chaîne de section.
    pub section_chain_len : u64,
    /// Les membres bootstrap pour la prochaine instance Membership.
    pub bootstrap_members : BTreeSet<NodeState>,
    /// La génération d'adhésion à laquelle ce SAP a été instancié
    pub membership_gen : génération,
}

Lorsqu’il y a un événement DkgStart, les anciens génèrent des informations dans une structure appelée DkgSessionId (le format est appelé ‹ struct › dans Rust). Ils signent cette structure avec leur part de clé BLS et l’échangent avec les autres anciens. Chaque DkgSessionId fournit des informations de base sur l’état actuel des choses et est unique à un cycle DKG.

Le préfixe est le préfixe de la section actuelle. Dans le cas d’un transfert, cela ne change pas. Dans le cas d’une scission, c’est le cas, et nous ajoutons un un ou un zéro à notre préfixe actuel selon que nous sommes du côté 0 ou 1 de la scission.

Le champ anciens contient tous les nouveaux anciens candidats pour cette session DKG, nœuds avec un âge de nœud égal ou supérieur à celui d’un ancien actuel.

section_chain_length (à renommer) est la distance entre la clé de section actuelle et Genesis. On peut la considérer comme la « génération de section ».

membership_gen affiche également la génération d’adhésion. Elle est différente de la génération de section. Chaque section a de nombreuses générations de membres et la longueur de la chaîne ne change pas.

bootstrap_members sont les anciens actuels de la section.

Une fois que les nœuds reçoivent les DkgSessionId de tous les anciens actuels, ils peuvent démarrer une session DKG.

Allons-y!

Étapes Dkg

organigramme LR ;
A[DkgStart] --> B[Clé éphémère]

Tous les anciens actuels et candidats reçoivent un message « DkgStart » qui leur est adressé et dans lequel ils sont inclus en tant qu’« anciens » dans la structure « DkgSessionId ».

Chacun de ces nœuds génère ensuite une clé BLS éphémère à usage unique qui n’est utilisée que pour ce cycle DKG. Cette clé éphémère est signée avec leur clé ed25519, qui leur sert d’identité, afin que les autres nœuds puissent vérifier si elle est valide.

Étapes Dkg

organigramme LR ;
A[DkgStart] --> B[Clé éphémère] --> C[Vote]

Vient ensuite l’étape de vote dans laquelle chaque nœud peut générer ses propres clés pour voter. Nous utilisons un procédé emprunté à Poanetwork de génération de clé dans hbbft qui garantit que chaque nœud ne peut générer que sa propre clé et ne pas utiliser les informations d’autres nœuds pour générer une clé distincte pour le cycle DKG.

Les nœuds votent sur lequel parmi les candidats et les anciens existants devraient maintenant être les anciens de la section.

Étapes Dkg

organigramme LR ;
A[DkgStart] --> B[Clé éphémère] --> C[Voting] --> D{Génération de clé}

Une fois le vote terminé, le candidat génère une nouvelle clé qu’il envoie aux anciens actuels pour prouver qu’il est éligible pour devenir un ancien (car une supermajorité de nœuds l’a signée avec la nouvelle clé). DKG est donc une sorte de test pour un bon candidat. S’ils ne terminent pas DKG, ils ne sont pas assez bons.

Concurrence

organigramme LR ;
A[DkgStart1] --> B[Clé éphémère] --> C[Voting] --> D{Key1 Generation}

organigramme LR ;
A[DkgStart2] --> B[Clé éphémère] --> C[Voting] --> D{Key2 Generation}

Plusieurs sessions DKG peuvent avoir lieu en même temps. Chaque fois qu’il y a un nouveau membre dans la section, nous pouvons (si le nouveau nœud est plus ancien que l’un des anciens actuels) avoir une nouvelle session DKG, donc si pendant qu’une session est en cours, un nouveau nœud se joint, une autre session DKG peut démarrer. Certains se termineront, d’autres expireront et échoueront. C’est une course, et on choisit le premier qui finit. Plus tard, s’il s’avère qu’il existe un nœud plus ancien qui n’est pas un ancien, le processus recommence.

Résolu par transfert

stateDiagram-v2
Dkg1 --> Transfert
Remise --> Vainqueur : Dkg1
Dkg2 --> Transfert
Dkg3 --> Transfert

S’il y a égalité, nous ne voulons qu’un seul gagnant, c’est-à-dire un nouvel ancien. Le transfert est un processus qui utilise le consensus pour décider lequel doit gagner.

AE actif

stateDiagram-v2
DkgStart --> EphemeralKey
EphemeralKey --> EphemeralKey : Inclut DkgStart AE
EphemeralKey --> Vote
Vote --> Vote : Inclut EphemeralKeys AE
Vote --> Résiliation

Dans ces étapes mentionnées ci-dessus, recevoir un message DkgStart, créer une clé éphémère et voter, nous devons compenser les problèmes de réseau et les nœuds lents. Par exemple, nous avons besoin des clés de chacun pour commencer à voter, sinon nous restons bloqués. Nous incluons donc AE dans chaque message lié à la clé pour fournir des informations sur le fait qu’un nœud pourrait manquer. AE est léger et constitue un moyen efficace de s’assurer que tous les nœuds sont à jour.

enum SystemMsg {

    DkgStart(DkgSessionId),

    DkgEphemeralPubKey {
        /// L'identifiant de la session DKG à laquelle ce message est destiné.
        session_id : DkgSessionId,
        /// Autorité de section pour le message de démarrage DKG
        section_auth : AuthorityProof<SectionAuthProof>,
        /// La clé bls éphémère choisie par le candidat
        pub_key : BlsPublicKey,
        /// La signature ed25519 du candidat
        sig : Signature,
    },

    DkgVotes {
        /// L'identifiant de la session DKG à laquelle ce message est destiné.
        session_id : DkgSessionId,
        /// Les clés publiques bls éphémères utilisées pour ce round Dkg
        pub_keys : BTreeMap<XorName, (BlsPublicKey, Signature)>,
        /// Le message DKG.
        votes : Vec<DkgSignedVote>,
    },

    DkgAE(DkgSessionId),

    ...
}

Dans le code, un message système, qui est le type de message utilisé pour les processus susceptibles de modifier la structure du réseau, ressemble à ce qui précède. Cela englobe tous les processus dont nous avons parlé.

Résilience

  • AE actif
  • Vote AE
  • Potins
    • en attendant les votes
    • lors de la réception de votes périmés

Pour conclure, nous avons plusieurs mécanismes de résilience lors de la gestion des transferts et des scissions.

Active AE signifie que les nœuds reçoivent les informations de l’étape précédente au cas où ils les auraient manquées.

Nous avons aussi des potins comme back-up. Si vous êtes dans une session DKG, vous êtes prêt à recevoir des clés ou des votes éphémères de quelqu’un. S’ils ne se présentent pas, vous envoyez vos connaissances actuelles aux autres dans l’espoir qu’ils vous mettront à jour. De plus, si vous recevez des AE obsolètes de quelqu’un, vous pouvez les mettre à jour.

Les commérages ont donc deux objectifs. Pour nous assurer que nous sommes à jour afin que nous puissions aller de l’avant, et pour mettre à jour les autres, afin que nous puissions arriver à la résiliation.

Avec AE et permettant la concurrence entre les processus DKG, cela fournit un processus beaucoup plus robuste pour promouvoir de nouveaux anciens et gérer les scissions. Pendant les divisions, nous avons deux DKG en cours au lieu d’un.

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