Ceci est une traduction automatique. L’original en anglais est ici: Update 02 September, 2021
Nous attendons depuis quelques semaines la perspective d’une mise à jour sur l’économie sûre et nous sommes ravis de pouvoir vous présenter un aperçu de notre réflexion actuelle sur les certificats au porteur numériques (DBC). Il y a encore quelques boules en l’air marquées « clés à usage unique » et « dénominations », mais nous sommes définitivement en train de converger vers une solution viable qui sera rapide, privée et sécurisée.
Comme pour de nombreuses autres innovations Safe, les objectifs des DBC sont la simplicité et faire en sorte que le client fasse le travail dans la mesure du possible - ce qui revient généralement au même. Nous voulons éviter d’avoir à stocker l’état (par exemple les soldes des comptes) sur le réseau, ou de recourir à la logique conditionnelle, qui engendrent la complexité. Au lieu de cela, nous déployons Anti-Entropy dans de nombreuses communications, où le flux est : try -> success (continuer) | fail (retry), tandis que le suivi de l’état est le travail du client.
Nous savons que vous avez tous hâte de vous salir les mains à nouveau avec un nouveau testnet, mais pour que cela en vaille la peine, nous voulons nous assurer que le réseau est stable avec plusieurs sections et que AE fonctionne correctement dans tous les domaines.
Progrès général
Nous essayons de résoudre un problème intermittent qui voit différents Aînés dans une section recevoir différents messages du même nœud (cela ne devrait pas arriver) et/ou choisir différents Adultes pour stocker le même morceau. De plus, les Aînés écrivent parfois des données, ce qui est le travail des Adultes. @Qi_Ma et @lionel.faber ont examiné ces anomalies de messagerie.
Nous nous sommes efforcés de terminer la mise en œuvre de l’AE sur le client, avec @bochaco et @yogesh en tête. Il y a encore quelques problèmes et @lionel.faber a aidé au débogage du client AE et a déjà identifié l’une des causes du comportement anormal en tant que Elders ayant des clés de section différentes.
@oetyng a terminé sa refonte de l’auto-chiffrement (qui a maintenant été fusionné dans main), et a également travaillé sur la refonte de la façon dont les morceaux sont traités.
Et @danda s’est penché sur la question des dénominations des DBC : dans le choix des dénominations pour notre monnaie, quelles valeurs devons-nous choisir et pourquoi ? Ce qui semble être une question assez simple implique en réalité des compromis intéressants entre l’efficacité du réseau et la convivialité humaine.
Un aperçu des DBC
Un DBC est un « bon numérique » unique qui a de la valeur du fait qu’il a été prouvablement émis par une monnaie de confiance dans le cadre d’un système économique. Pour dépenser un DBC, vous devez le faire rééditer par un menthe. La Monnaie peut prendre votre DBC et le réémettre en deux nouveaux DBC ou plus si vous le souhaitez (par exemple, paiement à un magasin, le reste en tant que monnaie pour vous), et plusieurs DBC peuvent être réémis en un seul DBC.
L’important pour nous est que les DBC fournissent un moyen rapide, sûr et flexible d’effectuer des paiements qui soit compatible avec la cryptographie de signature multisig/seuil et qui puisse être utilisé en ligne et hors ligne. Ils simplifient de nombreux aspects de l’économie du réseau sécurisé.
L’état actuel des choses
Actuellement, notre système DBC comprend les éléments suivants :
Sharding: La menthe est fragmentée entre les sections, de sorte que chaque section est responsable de la réémission de certains DBC uniquement, déterminés par le nom/l’ID du DBC.
Nœuds de la Monnaie décentralisés: Au sein d’une section, les nœuds de la Monnaie individuels (Anciens) fonctionnent de manière autonome, sans coordination. Un client effectuant une opération de réémission doit obtenir un « ReissueShare » d’une majorité qualifiée de nœuds mint (au moins 5 sur 7). Chaque « ReissueShare » contient un BLS « SignatureShare ». Le client combine ces « SignatureShare » pour obtenir une signature complète. Le Client ajoute cette Signature au contenu du DBC pour former un DBC complet, prêt à être dépensé.
Propriété DBC: Chaque DBC a un propriétaire, identifié par une « PublicKey ». Cela permet aux DBC d’être stockés et transférés en clair sans que personne ne les vole. La monnaie vérifie que le propriétaire a correctement signé chaque DBC d’entrée lorsqu’il est dépensé (réédité).
Masquage du montant: Les montants DBC sont masqués de manière à ce que seuls l’expéditeur et le destinataire puissent le savoir. Même les nœuds de menthe ne peuvent pas voir le montant. Pourtant, la Monnaie peut vérifier que la somme des DBC d’entrée correspond à la somme des DBC de sortie grâce à l’utilisation des engagements Pedersen et des rangeproof (pare-balles).
Spentbook: Chaque nœud Mint écrit dans un Spentbook. Lors de chaque réédition, le nœud mint vérifiera d’abord que tous les DBC d’entrée ne sont pas déjà dans le Spentbook (n’ont pas été dépensés) et que toutes les signatures et sorties sont correctes. Il enregistre ensuite chaque entrée comme dépensée dans le Spentbook. Idéalement, nous voulons déplacer cela vers le client, voir ci-dessous.
Améliorations futures
Nous cherchons toujours où nous pouvons apporter des améliorations au système DBC, et les éléments suivants sont tous à l’étude :
Clés à usage unique: Les nœuds mint imposeraient que chaque clé publique ne puisse être utilisée que dans une seule transaction de réémission. Cela peut aider à la confidentialité car cela empêche l’utilisation des clés dans plusieurs transactions.
Le client écrit dans Spentbook: Avec cette configuration, le client écrirait les entrées Spentbook avant de contacter lementhe. L’avantage de ceci est que l’appel de réémission devient idempotent, ce qui signifie qu’un client peut faire le même appel de réémission plusieurs fois et recevoir la même réponse à chaque fois.
Signatures aveugles: Cela nous apporterait un véritable certificat au « porteur » sans propriétaire. Une pure forme d’argent numérique introuvable, si vous voulez.
Public Spentbook: Rendre le Spentbook public est considéré comme souhaitable/nécessaire pour que le public puisse auditer la masse monétaire, c’est-à-dire pour vérifier que de l’argent supplémentaire n’a pas été créé par fraude/vol ou bugs/erreurs.
Pour toute personne intéressée à plonger plus profondément, notre code DBC se trouve dans la crate sn_dbc.
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é!