Actualités du développement Safe 🇫🇷 23 septembre 2021

Dimitar · Octobre 11, 2021, 3:48

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

Aujourd’hui, nous examinerons plus en détail les DBC et la propriété. Le réseau central et les DBC/Mints ont avancé en parallèle, mais nous nous rapprochons de pouvoir les assembler . Il se passe tellement de choses en ce moment - la plupart sont malheureusement impossibles à décrire dans un aperçu comme celui-ci - mais en résumé, cela a été une bonne semaine pour résoudre des problèmes de longue date et épineux avec la stabilité, les connexions et les tests.

Progrès général

@oetyng a étudié la meilleure façon de traiter les petits fichiers qui ne seront pas auto-cryptés en raison de leur taille, appelés Spots pour les distinguer des plus gros Blobs (> 3072 octets) qui passent par SE. Les spots incluront de nombreux fichiers de données en texte brut, y compris les DataMaps, et doivent donc toujours être chiffrés, à moins qu’il ne s’agisse de données publiques publiées.

@yogesh et @joshuef ont corrigé un bogue qui envoyait un message à tous les anciens d’une section plutôt que la sélection requise après un message de mise à jour AE. Cela augmentait considérablement les messages de va-et-vient sur le réseau provoquant une amplification des messages (plus de messages aux aînés signifiaient plus pour les adultes, puis plus en arrière). Avec le correctif fusionné dans PR#473, l’efficacité et le débit du réseau ont augmenté, ce qui signifie que nos tests E2E réussissent de manière beaucoup plus cohérente.

L’introduction de certains messages temporaires de sondage AE est également en cours. Il sera utilisé par les sections pour sonder périodiquement d’autres sections du réseau, à la recherche de mises à jour en déclenchant des flux AE, et aidera les sections à rester à jour, donnant plus de stabilité au réseau. (Cela devrait éventuellement être déprécié une fois que le trafic DBC sera acheminé sur tout le réseau).

@Yogesh a également résolu un problème avec les tests AE, où la boucle provoquait une amplification de la messagerie.

@ChrisO travaille sur la CLI et l’API, les mettant à jour pour être compatibles avec les dernières versions du réseau, et certaines commandes fonctionnent maintenant à l’aide de la clé Genesis, bien que ce travail n’ait pas encore été intégré à main, il devrait arriver ‹ bientôt ›.

@Chris.Connelly et @lionel.faber ont expérimenté la suppression du pool de connexions de qp2p. Le pool de connexions maintient les connexions ouvertes après un premier contact, mais c’est un instrument contondant et une sorte de boîte noire. Nous voulons plus de contrôle afin d’optimiser l’utilisation des ressources, et cherchons donc à implémenter quelque chose de mieux dans la base de code safe_network.

Les problèmes de mémoire précédents ont maintenant été pour la plupart résolus (nous sommes tombés sur la plupart des nœuds inactifs d’environ 80 Mo et allant jusqu’à environ 250 Mo sous charge), mais il y a un cas limite en suspens trouvé par @qi_ma où le fichier journal d’un nœud nouvellement déplacé est gonfler en taille, probablement parce que les messages ne sont pas reçus.

Propriété DBC

Lors de la conception d’un système DBC, une décision que vous devez prendre est de savoir si les DBC auront ou non des propriétaires. Avec les DBC sans propriétaire, quiconque met la main sur un DBC peut le dépenser, ce qui se rapproche assez bien des pièces d’or, mais il a ses propres problèmes.

Étant donné que toute personne possédant une copie du DBC peut le dépenser, il est de pratique courante de réémettre immédiatement un DBC une fois que vous l’avez reçu pour vous assurer que quelqu’un d’autre ne le dépense pas en premier.

Cette réédition implique l’envoi du DBC à un Mint pour le convertir en un nouveau DBC de la même valeur, ce désabonnement DBC est un gaspillage à la fois pour le client et le réseau, et pire encore, il affaiblit notre sécurité car l’envoi du DBC à un Mint pourrait entraîner le DBC volé par un nœud Mint malveillant (rappelez-vous, toute personne possédant une copie du DBC peut la dépenser et Mints a besoin d’une copie pour exécuter une réémission).

Les DBC détenus résolvent ces problèmes en ajoutant la clé publique des propriétaires de DBC au DBC, un Mint exigera une preuve de propriété avant de réémettre un DBC détenu. Cette preuve implique généralement que le propriétaire signe la transaction de réémission.

Avec les DBC que nous possédons, nous pouvons stocker les DBC publiquement sans crainte de vol, car nous seuls avons les clés secrètes pour dépenser nos DBC.

REMARQUE : Nous pouvons en fait modéliser des DBC sans propriétaire avec des DBC appartenant en empaquetant la clé secrète avec un DBC lors d’un paiement.

Confidentialité et DBC détenus

Pour illustrer cette section, imaginez que Sam aimerait recevoir des dons en SafeCoin, Sam diffuse la clé publique de son don en ligne pour que tous puissent la voir et sollicite ses abonnés pour toutes les pièces de rechange.

Toute personne souhaitant faire un don à Sam réémettrait certains de ses DBC à Sam en utilisant la clé de don de Sam en tant que propriétaire du DBC et en envoyant les DBC résultants à Sam.

Maintenant, malheureusement, toute personne auditant les journaux de réédition de Mints serait en mesure de trouver les transactions de Sam en recherchant les transactions impliquant la clé de don de Sam. Ce n’est pas ce que nous voulons d’un système monétaire soucieux de la vie privée.

Nous avons longuement discuté de ce scénario, mais avec la cryptographie existante, nous n’avons pas pu trouver de moyen de combiner une clé de don statique et des DBC avec des propriétaires de clé à usage unique.

Heureusement, à la même époque, nousexploraient ces questions, @mav avait creusé dans les mathématiques derrière les techniques de dérivation de clé BLS et a proposé une technique vraiment intelligente qui nous permet de faire une dérivation de clé côté clé publique. La technique permet à n’importe qui de dériver une clé enfant d’une clé publique bien connue.

Par exemple, dans le cas de Sam ci-dessus, supposons que Janet souhaite faire un don de 10 $ à Sam. Janet déduirait d’abord une nouvelle clé de propriétaire en utilisant un index aléatoire

owner_index = random_256bits()
owner_pk = sams_donation_pk.derive_child(owner_index)

Ensuite, Janet réémettrait un DBC de 10 $ avec le propriétaire défini sur owner_pk . Ce DBC de 10 $ est ensuite envoyé à Sam avec le owner_index . Lorsque Sam va dépenser ce don, il utilise le owner_index pour dériver la clé secrète du propriétaire de la clé secrète du don :

owner_sk = sams_donation_sk.derive_child(owner_index)

Donc, pour récapituler, nous avons obscurci la clé publique du don à l’aide d’un indice de dérivation aléatoire. Cet index est envoyé à Sam avec le DBC donné afin que Sam puisse obtenir la clé du propriétaire lorsqu’il souhaite la dépenser. Étant donné que l’index de dérivation n’est jamais envoyé à la Monnaie, les journaux d’audit ne pourront trouver aucune référence à la clé de don de Sam.

Le Spentbook et les clés de dépense

La réémission d’un DBC implique toujours une écriture dans le Spentbook. Le Spentbook est un journal de tous les DBC qui ont été dépensés et de la transaction de réémission dans laquelle le DBC a été dépensé, il peut être considéré comme une grande table distribuée qui mappe un DBC à une transaction. Chaque fois qu’un DBC est dépensé, il est ajouté au Spentbook. Lorsque quelqu’un essaie de dépenser à nouveau le même DBC, les Monnaies remarqueront qu’il a déjà une entrée dans le Spentbook et refuseront de signer la réédition.

Dans les versions précédentes du système Safe DBC, les Monnaies elles-mêmes écrivaient les entrées du Spentbook à chaque réédition, mais récemment, nous sommes passés à un nouveau modèle où les clients sont censés écrire dans le Spentbook. Ce changement est une réduction significative de la charge sur nos nœuds Mint car l’écriture dans le livre dépensé et les vérifications des preuves de propriété requises étaient des parties coûteuses du flux de réémission.

Pour illustrer le changement, continuons à partir de l’exemple ci-dessus, Sam a reçu un don DBC de 10 $ et il aimerait maintenant le dépenser.

Tout d’abord, Sam construit la transaction qu’il souhaite exécuter, ici il divise ses 10 $ en un DBC à 8 $ et un DBC à 2 $.

let tx = ReissueTransaction {
  entrées : { $10DBC }
  sorties : { $8DBC, $2DBC }
}

Maintenant que Sam a spécifié la transaction, Sam doit engager le DBC de 10 $ dans cette transaction en l’enregistrant dans le Spentbook.

Écrire sur le Spentbook nécessite une preuve que vous êtes réellement le propriétaire du DBC, la façon dont nous le faisons est de forcer les clients à dériver une clé de dépense DBC et à prouver la propriété en signant la transaction.

Clé de dépense

Une clé de dépense est la façon dont les DBC sont appelés dans le Spentbook. Il est dérivé du propriétaire du DBC en utilisant le hachage du DBC.

laissez dbc = 10DBC ;
laissez passer_key = dbc.owner.derive_child(sha3_256(dbc))

Vous vous demandez peut-être pourquoi nous n’utilisons pas directement le propriétaire de DBC ? Pourquoi dériver une autre clé alors que le propriétaire est censé être une clé à usage unique ? Eh bien, la Monnaie ne voit pas l’index aléatoire utilisé pour dériver le propriétaire, nous n’avons donc aucune garantie qu’il s’agit en fait d’une clé unique.

Le Spentbook nous oblige à avoir une clé unique pour chaque DBC, nous utilisons donc le hachage du DBC pour dériver une clé de dépense qui est garantie d’être imprévisible. Donc en tout, nous avons trois clés à l’œuvre ici, dérivées en chaîne :

well_known_key <-- largement publié et associé à une entité réelle
owner_key <-- dérivé de la well_known_key à l'aide d'un index aléatoire
passe_clé <-- dérivé de la clé_propriétaire à l'aide du hachage DBC

S’engager dans une transaction

Sam a maintenant une transaction sur laquelle il aimerait s’engager et une clé de dépense.

laissez input_dbc = 10DBC ;
let tx = ReissueTransaction {
  entrées : { input_dbc }
  sorties : { $8DBC, $2DBC }
}

laissez passer_key = input_dbc.owner.derive_child(sha3_256(input_dbc))

Sam signe la transaction avec cette spend_key et envoie le tx , spend_key , et la signature au réseau à écrire dans le Spentbook.

Une fois le Spentbook rédigé, il ne reste plus qu’à obtenir une signature Mint certifiant que la transaction est valide. Pour ce faire, Sam envoie simplement la transaction tx à la Mint, chaque nœud Mint interrogera le Spentbook et s’assurera que chaque entrée de transaction est engagée dans cette même transaction. Si cela réussit, nous vérifions les contraintes de réédition standard, à savoir que la somme des entrées doit s’équilibrer avec la somme des sorties, et que chaque DBC d’entrée est valide.

Une fois tous les chèques passés, la Monnaie signe la réémission et renvoie la signature à Sam qui ensuite agrège et forme les DBC de sortie finaux. Terminé.

Ce nouveau flux de réédition se traduit par des nœuds Mint qui agissent simplement comme des validateurs avec une vue en lecture seule dans le Spentbook, cela devrait réduire les demandes de ressources sur les nœuds Elder et nous donner un réseau plus rapide.

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