Ceci est une traduction automatique. L’original en anglais est ici: Update 16 September, 2021
Cette semaine, nous abordons un peu plus en détail les menthes distribuées/partagées, comment elles s’intègrent aux DBC et à la confidentialité, et ce qu’elles signifient à la fois pour le réseau et l’expérience utilisateur.
Progrès général
David Rusu et @danda ont expérimenté l’ajout de clés à usage unique forcées à leur travail sur les signatures aveugles, et ont également obligé le client à écrire dans le livre dépensé. Un travail encore en cours, mais qui semble bon jusqu’à présent.
Beaucoup de corrections de bugs cette semaine. Nous sommes aux prises avec un autre problème de mémoire de nœud autour des mises de fichiers. Ces pics de mémoire étaient dus à un problème d’amplification des messages causé par les flux AE sur le client, ainsi que par les adultes back vers les clients. Les correctifs pour ceux-ci ont été fusionnés et l’utilisation de la mémoire a considérablement diminué.
Avec cela, nous avons commencé à chercher à obtenir plus de résumés concernant la messagerie sur le réseau, avec des nœuds configurés pour imprimer ces statistiques en même temps que leur utilisation des ressources dans les journaux. Une fois cela en place, nous commencerons à utiliser toutes ces informations dans nos systèmes de test pour nous assurer qu’aucun autre bogue d’amplification ne peut s’infiltrer.
En lien avec cela, @chris.connelly a creusé dans qp2p, supprimant certaines des fonctionnalités de regroupement de connexions qui ne sont plus nécessaires.
@oetyng met en œuvre la gestion de la contre-pression (résistance ou force s’opposant au flux de données souhaité via le logiciel). L’idée est qu’un nœud vérifie sa charge CPU lors de la prise de requêtes. S’il est au-dessus d’un certain niveau, il renverra un message contenant la charge CPU. Le nœud récepteur peut alors réguler ses communications en fonction de ces informations. Après un certain temps, ils reviennent aux paramètres par défaut.
Il n’est pas nécessaire de synchroniser ces informations ou de parvenir à un accord. La gestion de la contre-pression est comme les directives de circulation. Lorsque la plupart des conducteurs suivent les directives de trafic, le trafic est plus fluide, même s’il y a des conducteurs fous 
Ce qui signifie que bien qu’un mauvais nœud puisse choisir de ne pas suivre les directives, puisque la plupart des nœuds du réseau fonctionneront correctement et suivront les directives, le trafic sera amélioré par rapport au fait de ne pas avoir ces directives.
C’est du moins l’idée, et nous allons l’essayer pendant un certain temps maintenant. C’est une nouvelle dimension de la communication réseau, un peu comme l’a été AE, et il faudra du temps pour s’y installer.
Le bogue de choix de @Anselme a été le processus d’auto-chiffrement qui a envoyé des erreurs déroutantes qui ont fait planter certains tests unitaires. Il cherche maintenant à refactoriser le NRS pour le simplifier.
Pendant ce temps, @Lionel.faber a amélioré la façon dont GitHub Actions fonctionne pour automatiser les déploiements de réseaux de test sur Digital Ocean, ce qui s’est très bien passé avec l’équipe, et @Qi_Ma a découvert un comportement anormal avec AE. Avec chaque bogue éliminé, nous nous rapprochons un peu plus.
Oh et nous étions très heureux de recevoir un PR de @davidpbrown. Super d’avoir des membres de la communauté impliqués. Si quelqu’un veut contribuer, vous devez d’abord créer le dépôt - plus ici.
Menthes DBC
Les DBC Mints existent depuis les années 90, mais elles ne sont jamais devenues très populaires.
Un problème sérieux empêchant l’adoption est qu’ils ont généralement été centralisés et nécessitent donc que les utilisateurs du système (détenteurs de jetons) fassent entièrement confiance à l’opérateur de la monnaie. Un opérateur de monnaie avide pourrait gonfler la masse monétaire sans que personne d’autre ne le sache, volant ainsi de la valeur à tous les utilisateurs. De plus, l’opérateur de monnaie pourrait simplement disparaître et tous les jetons perdraient de la valeur du jour au lendemain. Il faut donc faire confiance à l’exploitant de la monnaie non seulement aujourd’hui, mais aussi demain, et aussi qu’aucun tiers, pirate informatique, initié ou gouvernement ne peut avoir d’impact sur son fonctionnement.
La décentralisation par sections (sharding) est une caractéristique centrale de la conception du Safe Network. La conception SN DBC exploite et s’appuie sur cela pour créer une Monnaie à la fois décentralisée et évolutive. À ce jour, aucune crypto-monnaie déployée[1] n’a incorporé de monnaies DBC décentralisées à notre connaissance, il s’agit donc d’un nouveau développement. Notre objectif est de nous adapter à une utilisation mondiale avec des règlements de transaction instantanés (et privés).
La fonctionnalité de décentralisation peut être divisée en quelques domaines principaux :
- MintNode est homologue au sein d’une section.
- Partage : chaque section est responsable d’un sous-ensemble de DBC.
- Agrégation des clients
- Spentbook distribué écrit par le client
Regardons chacun d’eux.
MintNode est homologue au sein d’une section.
Dans une section, chaque Aîné est également désigné comme MintNode. Ainsi, il y a 7 nœuds, les autres étant prêts et attendant de remplacer tout nœud défaillant. Lorsque la section est formée ou que l’appartenance change, les nœuds effectuent une série de génération de clé distribuée (DKG) pour créer une clé BLS partagée. Il s’agit d’une clé multi-signature, telle que 5 des 7 nœuds (super-majorité) doivent signer une donnée pour qu’elle soit considérée comme valide. Dans le cas des DBC, les données signées sont appelées ReissueShare. CesLes ReissueShares doivent être collectés à partir d’une super-majorité de nœuds dans une section pour terminer la réémission des DBC gérés par cette section.
Disons que l’un des nœuds est malveillant. Peut-être qu’un client s’est entendu avec un nœud pour doubler l’un de ses DBC. Le nœud malveillant pourrait répondre avec un ReissueShare frauduleux pour la double dépense, mais ce partage à lui seul est inutile, un client doit convaincre une super-majorité de nœuds avant de pouvoir collecter suffisamment de ReissueShares pour certifier une réémission à double dépense.
De plus, il est difficile en termes de temps et de ressources de devenir un Mint Node (section Elder) en premier lieu. Le Safe Network a un concept de Node Age par lequel les nœuds Adultes doivent prouver qu’ils sont fiables et honnêtes au fil du temps. Seul l’adulte le plus âgé est choisi comme Aîné chaque fois qu’un Aîné existant disparaît. De plus, un nœud ne peut pas choisir dans quelle section il se trouvera. Toutes ces stratégies rendent difficile pour un attaquant d’atteindre plusieurs nœuds malveillants dans une section pertinente à son activité DBC.
Sharding : chaque section est responsable d’un sous-ensemble de DBC.
Le partitionnement est un terme général qui signifie briser les données afin que différents serveurs gèrent des sous-ensembles de données.
Notre approche de sharding est en fait assez simple. La clé de dépense des DBC (une clé unique universellement unique) détermine quelle section est responsable de sa gestion. Le logiciel client est chargé d’envoyer une ReissueRequest identique à tous les nœuds mint dans toutes les sections correspondant aux entrées DBC dans la ReissueRequest.
Dans l’exemple suivant, nous avons 3 entrées, chacune étant gérée par des sections différentes, chaque section répond avec une super-majorité (5 sur 7) d’actions de réémission.
Lorsqu’un MintNode parcourt les DBC d’entrée, il vérifie pour chacun s’il a la responsabilité ou non. Si un MintNode est responsable d’un DBC, le Spentbook est consulté pour savoir si ce DBC a déjà été dépensé. Ainsi, un MintNode ReissueShare ne fournit SignatureShare que pour les DBC pour lesquels une section particulière a autorité.
Agrégation de clients
Lorsqu’un utilisateur souhaite réémettre un DBC, le logiciel client de l’utilisateur contacte chacun des 7 MintNodes pour la ou les sections responsables du ou des DBC d’entrée et soumet une ReissueRequest. Chaque nœud valide la demande, et si tout est correct, il répond avec un ReissueShare qui contient un BLS SignatureShare.
Le logiciel client collecte les réponses ReissueShare de tous les MintNodes qu’il a contactés et les inspecte. Si au moins 5 nœuds dans une section donnée ont répondu correctement, le client peut combiner leur SignatureShare afin de former une Signature Mint finale pour chaque DBC de sortie. Avec la signature en main, le client construit ensuite le ou les DBC réels qui peuvent ensuite être envoyés en entrée à une autre réédition.
Spentbook distribué écrit par le client
Il s’agit d’une fonctionnalité en développement. L’idée de base est que le client s’engage sur une ReissueTransaction donnée et publie cet engagement, identifié par la clé de dépense du DBC (ou un hachage de la clé), sur le réseau sécurisé avant de faire une ReissueRequest. Chaque MintNode n’a alors qu’à lire l’entrée Spentbook pour chaque DBC et valider que l’entrée est correctement signée par le propriétaire du DBC. Cela simplifie les opérations pour le MintNode, qui n’a plus besoin d’écrire de données, et garde l’API de réédition du MintNode idempotente. En d’autres termes, le Client peut appeler reissue plusieurs fois avec la même ReissueRequest et obtenir toujours la même réponse.
Nous prévoyons d’entrer plus en détail sur le Spentbook dans une mise à jour ultérieure.
[1] Un livre blanc a été publié en 2019 décrivant un système DBC Mint décentralisé appelé Scrit. La conception de Scrit est substantiellement différente de la nôtre, et elle ne semble pas avoir été déployée publiquement au moment de la rédaction de cet article.
Liens utiles
- Site Web du réseau sécurisé
- Safe Network Primer
- Principes de base du réseau
- Feuille de route
- Glossaire
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é!