Actualités du développement Safe 🇫🇷 2 décembre 2021

Ceci est une traduction automatique. L’original en anglais est ici: Update 02 December, 2021

Nous sommes sur le point de pouvoir déployer la nouvelle CLI et l’API intégrées pour les tests communautaires, mais il existe encore quelques cas extrêmes qui posent encore des problèmes - et l’histoire nous dit que ce qui peut mal tourner va mal tourner. Nous travaillons donc à les aplanir avant d’intégrer correctement la CLI.

Dans la dernière mise à jour, nous avons mentionné que DKG causait des problèmes (non liés), avec des nœuds qui ne parvenaient parfois pas à être promus aux anciens et des scissions ne se produisaient parfois pas comme elles le devraient. Une partie du blâme réside dans le fait que les messages arrivent dans le désordre et ne sont pas traités correctement pendant les exécutions de DKG. @lionel.faber explique comment nous résolvons cela avec [spoiler]Anti-Entropy[/spoiler].

Progrès général

La plupart des commandes CLI fonctionnent désormais correctement, mais quelques-unes ne sont pas encore cohérentes. Nous devons également ajouter la CLI au nouveau processus de publication automatisé.

@Anselme a approfondi le NRS, y compris la mise en œuvre de la prise en charge des essais à sec pour le traitement par lots des opérations. Il a également aidé @danda et David Rusu dans leur travail sur les preuves de paiement et les transactions privées. Si vous avez suivi ces mises à jour, vous saurez qu’elles ont étudié les meilleurs moyens de mettre en œuvre les DBC de manière à ce que les transactions puissent être rapides et non traçables, tout en étant auditables et en prenant en charge plusieurs sorties DBC. Les gars ont suivi plusieurs voies, et jusqu’à présent, l’approche la plus prometteuse semble être une version de Ring Confidential Transactions (RingCT) utilisée par Monero, qui peut être utilisée pour fournir une preuve de paiement. David Rusu a fait une présentation à l’équipe à ce sujet, que nous reproduirons ici bientôt.

Résoudre les problèmes de DKG à l’aide d’Anti Entropy

La génération de clés distribuées (DKG) est la façon dont nous gérons le processus d’accord entre les nœuds. Une clé est requise pour qu’une action ait lieu. Cette clé est divisée en partages de clés, chaque nœud votant ayant un seul partage unique. Ce n’est qu’une fois qu’un certain nombre d’actions (disons 5 sur 7) a été reçu et agrégé que la clé de signature peut être générée.

Au cours des deux dernières semaines, nous nous sommes attaqués à quelques problèmes qui se sont produits pendant le DKG lors du processus de promotion des nœuds adultes les plus anciens. Lorsqu’une section décide qu’un adulte doit être promu, un tour DKG est organisé et les candidats plus âgés génèrent une clé de section et un partage de clé.

L’exécution du DKG est un processus par étapes avec six phases distinctes : initialisation, contribution, réclamation, justification, engagement et finalisation. Les clés doivent être générées, échangées, agrégées et acceptées. Avec des messages qui vont et viennent à chaque phase. Bien que l’ordre total des messages ne soit pas requis pour le DKG en général, un nœud ne peut traiter que les messages pertinents pour sa phase DKG actuelle.

Cependant, la nature asynchrone du réseau signifie que les messages peuvent arriver dans n’importe quel ordre, et dans un environnement distribué, il est naturel que certains messages arrivent beaucoup plus tard ou même pas du tout en raison de perturbations du réseau, par exemple.

Ces événements naturels ne devraient pas affecter la capacité DKG des nœuds, et tout comme les autres opérations réseau, la solution aux messages DKG non ordonnés est (si vous ne l’avez pas déjà deviné) l’Anti-Entropy. AE met activement à jour les acteurs avec les informations dont ils ont besoin et empêche les actions de se produire jusqu’à ce que les participants soient prêts.

Il existe deux situations distinctes dans lesquelles les messages AE pour DKG sont requis.

Les messages DKG arrivent en décalage

Lorsqu’un nœud reçoit un message DKG qui fait partie d’une phase qu’il n’a pas encore atteinte, il doit conserver ce message et continuer à l’appliquer jusqu’à ce qu’il ait finalement (et espérons-le) progressé jusqu’à un point où le message peut être appliqué.

Au lieu de laisser cela au hasard, nous pouvons demander à l’expéditeur du message DKG de nous envoyer la liste des messages qu’il a déjà traités. Nous pouvons vérifier ces messages en utilisant la signature de l’expéditeur, puis les appliquer localement pour nous amener à la même phase et puis appliquer le message auquel nous nous sommes accrochés. Cela permet aux nœuds qui se sont repliés dans le processus DKG de rattraper le reste du réseau.

Pour montrer pourquoi cela est plus efficace, considérez ce qui suit.

Supposons que l’ordre des messages requis est

1.1, 1.2, 1.3, 2.1, 2.2, 2.3...

où se trouve chaque message

<phase>.<message_no>

Par exemple, Initialisation.message1, Initialisation.message2, Contribution.message1 etc.

Disons que nous avons deux nœuds A et B. Le nœud A est en phase 2 et le nœud B est en phase 1.

Il y a deux options :

Essai et erreur

# Étape 1
B(phase 1) reçoit 2.1 -> Pas prêt -> mémoriser 2.1

# Étape 2
B(phase 1) reçoit 1.2 -> appliquer 1.2
B(phase 1) -> applique 2.1 à partir du stockage -> Pas prêt

# Étape 3
B(phase 1) reçoit 1,3 -> applique 1,3
B (phase 2) -> applique le stockage du formulaire 2.1 -> OK -> supprimer 2.1 du stockage

Ici, plus les 1.2 et 1.3 prennent de temps pour arriver, plus il y a d’essais et d’erreurs.

AE

# Étape 1
B(phase 1) reçoit 2.1 -> Pas prêt ->Demande à A pour tous les messages

B(phase 1) reçoit 1.1, 1.2, 1.3, 2.1 -> Les applique tous -> OK
B(phase 2)

Ainsi, AE est beaucoup plus efficace et réduira le nombre de flux de messages inattendus.

Messages DKG arrivant pour une session qui n’a pas encore commencé

Avant le début d’une session DKG, les nœuds participants doivent signer la liste des participants ainsi que la chaîne de sections pour s’assurer qu’ils participent tous à la même session DKG. La nouvelle clé est ajoutée à la chaîne de sections afin que tous les nœuds participants se mettent d’accord sur sa longueur.

Dans le cas où un nœud n’a pas reçu suffisamment de signatures pour démarrer la session DKG, mais que les messages DKG ont commencé à arriver (par exemple, si des problèmes de connexion sont survenus au cours de cette phase initiale), le nœud peut alors demander la signature agrégée du Message DkgStart qui peut être vérifié par rapport à la clé de section, après quoi la session DKG peut être initialisée et le(s) message(s) appliqué(s) comme ci-dessus.


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