Ceci est une traduction automatique. L’original en anglais est ici: Update 29nd July, 2021
Cette semaine, nous examinerons de plus près les DBC, qui ont le potentiel de révolutionner les paiements en ligne et de simplifier de nombreux aspects de l’économie du réseau sécurisé. Ils sont vraiment très importants, mais dans leur forme standard, ils présentent quelques inconvénients lorsqu’il s’agit de transactions privées.
L’un des problèmes est qu’une monnaie peut voir les transactions qui la transitent et pourrait, en cas de compromission, publier ces transactions. Cette semaine, nous examinerons un moyen de masquer les transactions d’une monnaie - les engagements de Pedersen - et également un moyen d’empêcher les engagements de Pedersen d’être joués par de mauvais acteurs - les preuves de gamme.
Progrès général
@danda et David Rusu dirigent la conception de transactions confidentielles et adaptent les DBC pour appliquer des clés à usage unique. @danda l’explique plus en détail dans ce message.
Du côté client, @yogesh a martelé le code pour permettre aux clients de parler directement aux sections où résident des morceaux, ce qui est beaucoup plus efficace que de tout acheminer via une section.
Routage : @lionel.faber a été en contact avec l’équipe quinn qui a proposé des suggestions sur la cause des problèmes de délai d’attente / de réinitialisation que les utilisateurs de testnet auront rencontrés. Nous déplaçons également certains aspects de la fonctionnalité de routage vers qp2p pour réduire la complexité.
La grande rationalisation de la messagerie se poursuit à un rythme soutenu, avec une élimination impitoyable des types de messagerie peu utilisés, ce qui réduira les erreurs et se traduira par un code plus propre. Comme mentionné dans la mise à jour de la semaine dernière, la messagerie doit être réduite au minimum pour plus d’efficacité, et il en va de même pour le contenu des messages. L’utilisation des CRDT et le regroupement des signatures des clients nous permettent d’éliminer une grande partie de la saleté et de réduire le travail d’âne effectué par le réseau.
L’un des plus récents MaidSafers qui est à la hauteur de la refonte du message est @Chris.Connelly. Voici une introduction de Chris :
Je suis un ingénieur logiciel basé à Édimbourg avec une expérience dans le développement de back-ends de services Web et d’automatisation d’infrastructure cloud, mais je cherche maintenant à élargir mes horizons aux systèmes distribués et décentralisés. Je suis passionné par l’ingénierie holistique (considérant l’ensemble du système et évitant les rôles de spécialiste) et écrivant des logiciels fiables à l’aide de Rust (et parfois d’Elm à côté), et je suis impatient de le faire ici chez MaidSafe !
Engagements Pedersen et preuves de gamme
Les engagements de Pedersen sont une forme de preuve à connaissance nulle conçue pour masquer les valeurs des transactions. Ils permettent au destinataire de vérifier que la somme de tous les nombres saisis dans l’engagement est égale à la somme de tous les nombres sortis dans la transaction, sans révéler les nombres eux-mêmes.
Donc, si j’ai 30 jetons, vous en payez 20 et quelqu’un d’autre 10, cette transaction peut être vérifiée par un tiers (les valeurs d’entrée et de sortie s’additionnent-elles, « vrai » ou « faux » ?) sans qu’il connaisse les valeurs impliquées.
Pour que les DBC soient dépensés, ils doivent être autorisés par une monnaie. Les engagements de Pedersen permettent à la menthe de vérifier que les valeurs d’entrée et de sortie du DBC s’additionnent (c’est-à-dire qu’il est valide) et de signer la transaction sans avoir aucune connaissance des montants traités.
Une faiblesse des engagements de Pedersen lorsqu’ils sont utilisés pour valider des transactions est qu’ils peuvent être trompés par des nombres négatifs. Une transaction avec une entrée de 20 et des sorties de 30 et -10 serait valide, mais comme « l’argent négatif » ne peut pas exister en tant que jeton, le payeur a effectivement transformé 20 jetons en 30 jetons. La magie! (Mais pas pour l’économie.)
Les preuves de plage rendent cryptographiquement impossible qu’une valeur de sortie soit en dehors d’une certaine plage, disons 0 - 2^32. Nous appliquons cela en disant qu’une transaction n’est valide que si chaque sortie contient également une preuve de plage.
Donc, si j’ai un DBC pour 30 jetons et que je veux payer Alice 20 et Bob 10, le processus se déroule comme ceci :
Je soumets mon DBC à la monnaie avec un engagement Pedersen avec l’entrée (cryptée) comme « 30 » et les sorties (cryptées) comme « 20 + une preuve de plage » et « 10 + une preuve de plage ». La monnaie vérifie que les valeurs d’entrée et de sortie s’additionnent et que chaque sortie a une preuve de plage valide, signe la transaction et réémet les DBC aux clés publiques (obscurcies) d’Alice et de Bob.
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é!