Sur l'anonymat dans les blockchains basées sur des comptes

Nous nous intéressons depuis longtemps à la question de l'anonymat dans les cryptomonnaies et nous nous efforçons de suivre l'évolution des technologies dans ce domaine. Dans nos articles, nous avons déjà détaillé les principes de fonctionnement des transactions confidentielles dans Monero, et nous avons également examiné un aperçu comparatif les technologies existantes dans ce domaine. Cependant, toutes les cryptomonnaies anonymes actuellement reposent sur le modèle de données proposé par Bitcoin — Unspent Transaction Output (UTXO). Pour les blockchains basées sur des comptes comme Ethereum, les solutions existantes pour mettre en œuvre l'anonymat et la confidentialité (par exemple, Mobius ou Aztec) ont tenté de reproduire le modèle UTXO dans des contrats intelligents.

En février 2019, un groupe de chercheurs de l'Université de Stanford et de Visa Research publiés par a publié un préprint « Zether : Vers la confidentialité dans le monde des contrats intelligents ». Les auteurs ont proposé pour la première fois une approche pour garantir l'anonymat dans les blockchains basées sur des comptes et ont présenté deux variantes de contrats intelligents : pour des transactions confidentielles (cachant les soldes et les montants des transferts) et anonymes (cachant le destinataire et l'expéditeur). Nous trouvons cette technologie proposée intéressante et aimerions partager son fonctionnement, ainsi que discuter du fait que le problème de l'anonymat dans les blockchains basées sur des comptes est considéré comme très complexe et si les auteurs ont réussi à le résoudre complètement.

Sur le fonctionnement de ces modèles de données

Dans le modèle UTXO, une transaction se compose d'« entrées » et d'« sorties ». L'analogue direct des « sorties » — ce sont des billets dans votre portefeuille : chaque « sortie » a une certaine valeur. Lorsque vous payez quelqu'un (formez une transaction), vous dépensez une ou plusieurs « sorties », qui deviennent alors des « entrées » de la transaction, et la blockchain les marque comme dépensées. Pendant ce temps, le destinataire de votre paiement (ou vous-même, si vous avez besoin de monnaie en retour) reçoit de nouvelles « sorties » générées. Schématiquement, cela peut être représenté comme suit :

Les blockchains basées sur des comptes fonctionnent à peu près comme votre compte bancaire. Elles opèrent uniquement sur le montant de votre compte et le montant de transfert. Lorsque vous transférez une certaine somme de votre compte, vous ne brûlez aucune « sortie », le réseau n'a pas besoin de se souvenir quelles pièces ont été dépensées et lesquelles ne l'ont pas été. Dans le cas le plus simple, la vérification de la transaction se résume à vérifier la signature de l'expéditeur et le montant de son solde :

Analyse de la technologie

Ensuite, nous parlerons de la façon dont Zether cache le montant des transactions, le destinataire et l'expéditeur. Au fur et à mesure que nous décrivons les principes de son fonctionnement, nous noterons les différences entre la version confidentielle et la version anonyme. Étant donné qu'il est beaucoup plus simple de garantir la confidentialité dans les blockchains basées sur des comptes, certaines des limitations imposées par l'anonymisation ne seront pas pertinentes pour la version confidentielle de la technologie.

Masquage des soldes et des montants des transferts

Pour chiffrer les soldes et les montants des transferts dans Zether, un schéma de cryptage est utilisé d'ElGamal. Il fonctionne comme suit. Lorsque Alice souhaite envoyer à Bob b des pièces à l'adresse (sa clé publique) Y, elle choisit un nombre aléatoire r et chiffre le montant :

où C — montant chiffré, D — valeur auxiliaire nécessaire pour déchiffrer ce montant, G — point fixe sur la courbe elliptique, en multipliant la clé secrète par lequel on obtient la clé publique.

Lorsque Bob reçoit ces valeurs, il les additionne simplement à son solde chiffré de la même manière, ce qui rend ce schéma pratique.

De la même manière, Alice soustrait de son solde les mêmes valeurs, en utilisant son Y clé publique.

Masquage du destinataire et de l'expéditeur

Le mélange des « sorties » dans UTXO existe depuis les débuts des cryptomonnaies et aide à cacher l'expéditeur. Pour ce faire, l'expéditeur lui-même choisit des « sorties » aléatoires dans la blockchain lors de l'effectuation d'un transfert et les mélange avec les siennes. Ensuite, il signe les « sorties » avec une signature en anneau — un mécanisme cryptographique permettant de convaincre le vérificateur qu'il y a parmi les « sorties » mélangées des pièces de l'expéditeur. Les pièces mélangées ne sont, bien entendu, pas dépensées.

Cependant, pour cacher le destinataire, nous ne pourrons pas générer de fausses « sorties ». Par conséquent, dans l'UTXO, chaque « sortie » a sa propre adresse unique, et elle est cryptographiquement liée à l'adresse du destinataire de ces pièces. Actuellement, il n'existe aucune méthode pour identifier le lien entre l'adresse unique de la « sortie » et l'adresse du destinataire, sans connaître ses clés secrètes.

Dans un modèle basé sur les comptes, nous ne pouvons pas utiliser des adresses jetables (sinon cela deviendrait un modèle de « sorties »). Par conséquent, l'expéditeur et le destinataire doivent être mélangés avec d'autres comptes dans la blockchain. Dans ce cas, des 0 pièces chiffrées sont dépensées (ou ajoutées 0 — dans le cas du mélange du destinataire) depuis les comptes mélangés, sans changer leur véritable solde.

Puisque l'expéditeur et le destinataire ont toujours une adresse permanente, il est nécessaire lors des transferts vers les mêmes adresses d'utiliser les mêmes groupes pour le mélange. Il est plus simple d'examiner cela par un exemple.

Supposons qu'Alice a décidé de faire un don à la fondation caritative de Bob, mais préfère que ce transfert reste anonyme pour un observateur externe. Alors, pour se camoufler dans le champ de l'expéditeur, elle inscrit également les comptes d'Adam et d'Adèle. Pour cacher Bob — dans le champ du destinataire, elle ajoute les comptes de Ben et de Bill. Lors du prochain don, Alice a choisi d'inscrire Alex et Amanda à ses côtés, et Bruce et Benjen à côté de Bob. Dans ce cas, lors de l'analyse de la blockchain, il n'y aura qu'une seule paire d'intervenants qui se croisent dans ces deux transactions — Alice et Bob, ce qui dé-anonymise ces transactions.

Courses de transactions

Comme nous l'avons déjà mentionné, pour masquer son solde dans les systèmes basés sur les comptes, l'utilisateur chiffre son solde et la somme du transfert. Cependant, 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 construit une preuve concernant l'état actuel de son compte. Que se passe-t-il si Bob envoie une transaction à Alice, et qu'elle est acceptée avant celle envoyée par Alice ? Alors, la transaction d'Alice sera considérée comme invalide, car la preuve du solde a été construite avant l'acceptation de la transaction de Bob.

La première solution qui vient à l'esprit dans une telle situation est de geler le compte jusqu'à la réalisation de la transaction. Mais cette approche ne convient pas, car au-delà de la complexité de cette tâche dans un système distribué, dans un schéma anonyme, il sera difficile de savoir quel compte geler.

Pour résoudre ce problème, la technologie sépare les transactions entrantes et sortantes : les dépenses ont un effet immédiat sur l'état du solde, tandis que les recettes sont différées. Pour cela, le concept d'« époque » est introduit — un groupe de blocs de taille fixe. L'« époque » actuelle est déterminée par la division de la hauteur du bloc par la taille du groupe. Lors du traitement d'une transaction, le réseau met immédiatement à jour le solde de l'expéditeur, tandis que les fonds du destinataire sont accumulés. Les fonds accumulés ne sont disponibles pour le destinataire du paiement qu'à l'arrivée de la nouvelle « époque ».

En conséquence, l'utilisateur peut envoyer des transactions indépendamment de la fréquence à laquelle il reçoit des fonds (dans la mesure où son solde le permet, bien sûr). La taille de l'époque est déterminée en fonction de la rapidité avec laquelle les blocs se répandent dans le réseau et de la vitesse à laquelle une transaction est intégrée dans un bloc.

Cette solution fonctionne bien pour les transferts confidentiels, mais elle crée de sérieux problèmes avec les transactions anonymes, comme nous le verrons plus loin.

Protection contre les attaques de reproduction

Dans les blockchains basées sur des comptes, chaque transaction est signée par la clé privée de l'expéditeur, ce qui convainc le vérificateur que la transaction n'a pas été modifiée et qu'elle a été créée par le propriétaire de cette clé. Mais que se passe-t-il si un malfaiteur, ayant intercepté le canal de transmission, réintroduit exactement le même message ? Le vérificateur comparera la signature de la transaction et sera convaincu de son autorisation, et le réseau débitera à nouveau le même montant du solde de l'expéditeur.

Cette attaque est appelée une attaque de reproduction. Dans le modèle UTXO, ces attaques ne sont pas pertinentes, car le malfaiteur tentera d'utiliser des sorties dépensées, ce qui en soi n'est pas valide et est rejeté par le réseau.

Pour éviter cela, un champ de données aléatoires, appelé nonce ou simplement « sel », est intégré à la transaction. Lors de la renvoi d'une transaction avec le « sel », le vérificateur vérifie si ce nonce a été utilisé auparavant et, si ce n'est pas le cas, considère cette transaction comme valide. Pour ne pas stocker toute l'historique des nonces des utilisateurs dans la blockchain, on accepte généralement que le nonce de la toute première transaction soit égal à zéro, puis on l'augmente de un. Il ne reste plus qu'à vérifier que le nonce de la nouvelle transaction diffère de l'ancien de un.

Dans un schéma de transfert anonyme, le problème de validation des nonces des transactions se présente. Nous ne pouvons pas lier explicitement le nonce à l'adresse de l'expéditeur, car cela dé-anonymiserait clairement le transfert. Nous ne pouvons pas non plus incrémenter le nonce de tous les comptes impliqués, car cela pourrait entrer en conflit avec d'autres transferts en cours de traitement.

Les auteurs de Zether proposent de générer des nonces de manière cryptographique — en fonction de l'« époque ». Par exemple :

Ici x — la clé secrète de l'expéditeur, et Gepoch — un générateur supplémentaire pour l'époque, obtenu en hachant une chaîne de type 'Zether + '. Maintenant, le problème semble être résolu — nous ne révélons pas le nonce de l'expéditeur et ne nous mêlons pas aux nonces des participants non impliqués. Mais cette approche impose une limite sérieuse : un compte ne peut envoyer plus d'une transaction par « époque ». Malheureusement, ce problème reste non résolu et rend, à notre avis, la version anonyme de Zether à peine utilisable.

La complexité des preuves à divulgation nulle

Dans UTXO, l'expéditeur doit prouver au réseau qu'il ne dépense pas un montant négatif, sinon il deviendrait possible de générer de nouvelles pièces de toutes pièces (nous avons discuté de pourquoi cela est possible dans l'un de nos précédents articles). Il doit également signer les « entrées » avec une signature de type anneau pour prouver que parmi les pièces mélangées, il y a des fonds qui lui appartiennent.

Dans la version anonyme de la blockchain basée sur les comptes, les expressions pour la preuve deviennent beaucoup plus complexes. L'expéditeur prouve que :

1. Le montant envoyé est positif ;
2. Le solde reste non négatif ;
3. L'expéditeur a correctement chiffré les montants des transferts (y compris zéro) ;
4. Le solde change uniquement pour l'expéditeur et le destinataire ;
5. L'expéditeur possède la clé secrète de son compte et il est réellement présent sur la liste des expéditeurs (parmi les mélangés) ;
6. Le nonce utilisé dans la transaction est constitué correctement.

Pour une telle preuve complexe, les auteurs utilisent un mélange Imperméable (l'un des auteurs, soit dit en passant, a participé à sa création) et le protocole Sigma, que l'on appelle Sigma-bullets. La preuve formelle de cette affirmation est assez complexe, et elle limite fortement le nombre de personnes désireuses de se lancer dans la mise en œuvre de la technologie.

Quel est le résultat ?

À notre avis, la partie Zether, qui apporte de la confidentialité aux blockchains basées sur des comptes, peut déjà être utilisée. Mais pour le moment, la version anonyme de la technologie impose de sérieuses restrictions à son utilisation, et sa complexité complique sa mise en œuvre. Cependant, il ne faut pas oublier que les auteurs l'ont publiée il y a seulement quelques mois, et il se peut que quelqu'un d'autre trouve une solution aux problèmes existants aujourd'hui. C'est exactement ainsi que la science progresse.

Source : habr.com