Nous nous intéressons depuis longtemps au sujet de l'anonymat dans les crypto-monnaies et essayons de suivre le développement des technologies dans ce domaine. Dans nos articles, nous avons déjà examiné en détail les principes de fonctionnement des
transactions confidentielles dans Monero, et également effectué une
revue comparative des technologies qui existent dans ce domaine. Cependant, toutes les crypto-monnaies anonymes sont aujourd'hui construites sur le modèle de données proposé par Bitcoin - Sortie de transaction non dépensée (ci-après UTXO). Pour les chaînes de blocs basées sur des comptes comme Ethereum, les solutions existantes pour la mise en œuvre de l'anonymat et de la confidentialité (par exemple,
Mobius ou
Aztec ) ont essayé de répéter le modèle UTXO dans les contrats intelligents.
En février 2019, un groupe de chercheurs de l'Université de Stanford et de Visa Research
a publié la
préimpression «Zether: vers la confidentialité dans le monde des contrats intelligents». Les auteurs ont d'abord proposé une approche pour garantir l'anonymat dans les chaînes de blocs basées sur les comptes et ont présenté deux options pour un contrat intelligent: pour les transactions confidentielles (masquage des soldes et des montants de transfert) et anonymes (masquage des destinataires et des expéditeurs). Nous trouvons la technologie proposée intéressante et aimerions partager son appareil, ainsi que discuter pourquoi le problème d'anonymat dans les blockchains basées sur les comptes est considéré comme très complexe et si les auteurs ont réussi à le résoudre dans son intégralité.
À propos de l'appareil de ces modèles de données
Dans le modèle UTXO, une transaction comprend des «entrées» et des «sorties». Un analogue direct des «sorties» est le billet de banque dans votre portefeuille: chaque «sortie» a une certaine dénomination. Lorsque vous payez avec quelqu'un (formez une transaction), vous dépensez une ou plusieurs «sorties», alors qu'elles deviennent des «entrées» de la transaction, et la blockchain les marque comme dépensées. Dans le même temps, le destinataire de votre paiement (ou vous-même, si vous avez besoin d'un changement) reçoit les «sorties» nouvellement générées. Schématiquement, cela peut être représenté comme suit:
Les blockchains basées sur un compte sont structurées comme votre compte bancaire. Ils n'opèrent que sur le montant de votre compte et le montant du virement. Lorsque vous transférez un certain montant depuis votre compte, vous ne gravez aucune «sortie», le réseau n'a pas besoin de se rappeler quelles pièces sont dépensées et lesquelles ne le sont pas. Dans le cas le plus simple, la vérification d'une transaction se réduit à vérifier la signature de l'expéditeur et le montant de son bilan:
Analyse technologique
Ensuite, nous parlerons de la façon dont Zether masque le montant des transactions, le destinataire et l'expéditeur. Au cours de la description des principes de son travail, nous noterons les différences de version confidentielle et anonyme. Étant donné que garantir la confidentialité dans les chaînes de blocs basées sur les comptes est beaucoup plus simple, certaines des restrictions imposées par l'anonymisation ne seront pas pertinentes pour une version confidentielle de la technologie.
Dissimulation des soldes et des montants de transfert
Zether utilise le schéma de cryptage
El Gamal pour crypter les soldes et les montants de transfert. Cela fonctionne comme suit. Quand Alice veut envoyer des pièces Bob
b à l'adresse (sa clé publique)
Y , elle choisit un nombre aléatoire
r et chiffre le montant:
où
C est la somme chiffrée,
D est la valeur auxiliaire nécessaire pour déchiffrer cette somme,
G est le point fixe sur la courbe elliptique, lorsque la clé secrète est multipliée par laquelle la clé publique est obtenue.
Lorsque Bob reçoit ces valeurs, il les ajoute simplement à son solde, chiffré de la même manière, ce qui est pratique pour ce schéma.
De même, Alice soustrait les mêmes valeurs de son bilan, utilise uniquement
Y comme clé publique.
Dissimulation du destinataire et de l'expéditeur
Le mélange des «sorties» dans UTXO est apparu à l'aube des crypto-monnaies et permet de cacher l'expéditeur. Pour ce faire, l'expéditeur, lors d'un transfert, recueille des «sorties» aléatoires dans la blockchain et les pétrit avec les siennes. Il signe ensuite les «sorties» avec une signature en anneau - un mécanisme cryptographique qui lui permet de convaincre le vérificateur que parmi les «sorties» impliquées, il y a des pièces émettrices. Les pièces impliquées elles-mêmes, bien sûr, ne sont pas gaspillées.
Cependant, pour cacher le destinataire, nous ne serons pas en mesure de générer de fausses «sorties». Par conséquent, dans UTXO, chaque «sortie» a sa propre adresse unique, et elle est associée cryptographiquement à l'adresse du destinataire de ces pièces. Pour le moment, il n'y a aucun moyen d'identifier la relation entre l'adresse unique de «sortie» et l'adresse du destinataire sans connaître ses clés secrètes.
Dans un modèle basé sur un compte, nous ne pouvons pas utiliser d'adresses uniques (sinon ce sera déjà un modèle de "sorties"). Par conséquent, le destinataire et l'expéditeur doivent être pétris parmi d'autres comptes dans la blockchain. Dans le même temps, les pièces cryptées 0 sont débitées des comptes malaxés (ou 0 est ajouté - dans le cas d'un destinataire malaxé), sans pour autant modifier réellement leur solde réel.
Étant donné que l'expéditeur et le destinataire ont toujours une adresse permanente, il devient alors nécessaire d'utiliser les mêmes groupes pour mélanger aux mêmes adresses. Il est plus facile de considérer cela avec un exemple.
Supposons qu'Alice décide de contribuer à la charité de Bob, mais préfère que le transfert reste anonyme pour un observateur extérieur. Ensuite, afin de se déguiser dans le champ de l'expéditeur, elle entre également dans les comptes Adam et Adele. Et pour cacher Bob - dans le champ destinataire en plus des comptes Ben et Bill. En faisant le prochain versement, Alice a décidé d'entrer Alex et Amanda à côté d'elle, et Bruce et Bengen à côté de Bob. Dans ce cas, lors de l'analyse de la chaîne de blocs dans ces deux transactions, il n'y a qu'une seule paire de participants qui se croisent - Alice et Bob, qui désanonymise ces transactions.
Transaction Racing
Comme nous l'avons déjà mentionné, afin de masquer son solde dans les systèmes basés sur les comptes, l'utilisateur chiffre son solde et le montant du virement. De plus, il doit prouver que le solde de son compte reste non négatif. Le problème est que lors de la formation d'une transaction, l'utilisateur crée des preuves concernant son état actuel du compte. Et que se passe-t-il si Bob envoie une transaction à Alice et qu'elle sera acceptée plus tôt que celle envoyée par Alice? La transaction d'Alice sera alors considérée comme non valide, car la preuve de l'équilibre a été établie avant l'adoption de la transaction Bob.
La première solution qui se présente dans une telle situation est de geler votre compte avant la transaction. Mais cette approche n'est pas appropriée, car en plus de la complexité de résoudre un tel problème dans un système distribué, dans un schéma anonyme, il ne sera pas clair de savoir à qui bloquer.
Pour résoudre ce problème, la technologie sépare les transactions entrantes et sortantes: dépenser de l'argent a un effet immédiat sur le bilan et les revenus sont différés. Pour cela, le concept d '«ère» est introduit - un groupe de blocs de taille fixe. L '«ère» actuelle est déterminée en divisant la hauteur du bloc par la taille du groupe. En traitant la transaction, le réseau met immédiatement à jour le solde de l'expéditeur et ajoute les fonds du destinataire au lecteur. Les fonds accumulés ne sont disponibles pour le bénéficiaire que lorsqu'une nouvelle «ère» s'installe.
En conséquence, l'utilisateur peut envoyer des transactions quelle que soit la fréquence à laquelle il reçoit des fonds (dans la mesure où son solde le permet, bien sûr). La taille d'une époque est déterminée en fonction de la rapidité avec laquelle les blocs se propagent sur le réseau et de la rapidité avec laquelle la transaction tombe dans le bloc.
Cette solution fonctionne bien dans le cas de transferts confidentiels, mais avec des transactions anonymes, comme nous le verrons plus loin, cela crée de sérieux problèmes.
Rejouer la protection contre les attaques
Dans les chaînes de blocs basées sur les comptes, chaque transaction est signée par la clé privée de l'expéditeur, qui convainc le vérificateur que la transaction n'a pas été modifiée et a été créée par le propriétaire de cette clé. Mais que se passe-t-il si l'attaquant qui écoutait le canal de transmission intercepte ce message et envoie exactement la même seconde? Le vérificateur vérifiera la signature de la transaction et sera convaincu de sa paternité, et le réseau débitera à nouveau le même montant du solde de l'expéditeur.
Cette attaque est appelée attaque de rejeu. Dans le modèle UTXO, de telles attaques ne sont pas pertinentes, car l'attaquant tentera d'utiliser les sorties dépensées, ce qui en soi n'est pas valide et est rejeté par le réseau.
Pour éviter que cela ne se produise, un champ de données aléatoires est inséré dans la transaction, qui est appelé nonce ou simplement «sel». Lors de la nouvelle soumission d'une transaction avec un sel, le réviseur vérifie si ce nonce a déjà été utilisé et, dans le cas contraire, considère que cette transaction est valide. Afin de ne pas stocker tout l'historique des utilisateurs nonce sur la blockchain, il est généralement considéré comme nul lors de la toute première transaction, puis augmenté d'une unité. Le réseau ne peut que vérifier que le nonce de la nouvelle transaction diffère du passé d'une unité.
Dans un schéma de traduction anonyme, le problème de la validation des transactions nonce se pose. Nous ne pouvons pas lier explicitement nonce à l'adresse de l'expéditeur, car, évidemment, cela désanonymise la traduction. Nous ne pouvons pas non plus en ajouter un au nonce de tous les comptes participants, car cela peut entrer en conflit avec d'autres traductions en cours de traitement.
Les auteurs de Zether proposent de générer du nonce cryptographiquement - en fonction de "l'ère". Par exemple:
Ici
x est la clé secrète de l'expéditeur, et
G epoch est un générateur supplémentaire pour l'époque, obtenu en hachant une chaîne de la forme «Zether +». Maintenant, le problème, semble-t-il, est en train d'être résolu - nous ne divulguons pas le nonce de l'expéditeur et n'interférons pas avec le nonce des participants non impliqués. Mais cette approche impose une sérieuse limitation: un compte ne peut envoyer plus d'une transaction à «l'ère». Ce problème, malheureusement, n'est toujours pas résolu et rend actuellement une version anonyme de Zether, à notre avis, difficilement utilisable.
Preuve de confiance zéro
En UTXO, l'expéditeur doit prouver au réseau qu'il ne dépense pas un montant négatif, sinon il devient possible de générer de nouvelles pièces de l'air (pourquoi cela était possible, nous l'avons écrit dans l'un des
articles précédents). Et signez également les «entrées» avec une signature en anneau pour prouver que parmi les pièces à pétrir, il y a des fonds qui lui appartiennent.
Dans la version anonyme de la blockchain basée sur les comptes, les expressions de preuve sont beaucoup plus compliquées. L'expéditeur prouve que:
- Le montant envoyé est positif;
- Le solde reste non négatif;
- L'expéditeur a correctement chiffré le montant des transferts (y compris zéro);
- Le solde du solde est modifié uniquement par l'expéditeur et le destinataire;
- L'expéditeur possède la clé secrète de son compte et il est vraiment dans la liste des expéditeurs (parmi ceux impliqués);
- Le nonce utilisé dans la transaction est correctement composé.
Pour une preuve aussi complexe, les auteurs utilisent un mélange de
Bulletproof (l'un des auteurs a d'ailleurs participé à sa création) et du
protocole Sigma , qui s'appelle Sigma-bullets. La preuve formelle d'une telle déclaration est une tâche assez difficile, et elle limite considérablement le nombre de personnes qui souhaitent se lancer dans la mise en œuvre de la technologie.
Quel est le résultat?
À notre avis, la partie de Zether, qui ajoute de la confidentialité aux chaînes de blocs basées sur les comptes, pourrait bien être utilisée maintenant. Mais pour le moment, une version anonyme de la technologie impose de sérieuses restrictions à son utilisation et à sa complexité de mise en œuvre. Cependant, n'oubliez pas que les auteurs l'ont publié il y a seulement quelques mois, et peut-être que quelqu'un d'autre trouvera une solution aux problèmes aujourd'hui. En effet, c'est ainsi que la science se fait.