Nous nous intéressons depuis longtemps au thème de l’anonymat dans les crypto-monnaies et essayons de suivre l’évolution des technologies dans ce domaine. Dans nos articles, nous avons déjà discuté en détail des principes de fonctionnement dans Monero, et a également réalisé technologies existantes dans ce domaine. Cependant, toutes les crypto-monnaies anonymes sont aujourd'hui construites sur le modèle de données proposé par Bitcoin - Unspent Transaction Output (ci-après 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, ou ) a tenté de reproduire 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 libéré "Zether : Vers la confidentialité dans le monde des contrats intelligents." Les auteurs ont été les premiers à proposer une approche pour garantir l'anonymat dans les blockchains basées sur les comptes et ont présenté deux versions d'un contrat intelligent : pour les transactions confidentielles (masquant les soldes et les montants des transferts) et anonymes (masquant le destinataire et l'expéditeur). Nous trouvons la technologie proposée intéressante et aimerions partager sa conception, ainsi que expliquer pourquoi le problème de l'anonymat dans les blockchains basées sur les comptes est considéré comme très difficile et si les auteurs ont réussi à le résoudre complètement.
À propos de la structure de ces modèles de données
Dans le modèle UTXO, une transaction se compose d'« entrées » et de « sorties ». Un analogue direct des « sorties » sont les billets dans votre portefeuille : chaque « sortie » a une dénomination. Lorsque vous payez quelqu'un (dans le cadre d'une transaction), vous dépensez un ou plusieurs « produits », auquel cas ils deviennent des « entrées » de la transaction, et la blockchain les marque comme dépensés. Dans ce cas, le destinataire de votre paiement (ou vous-même, si vous avez besoin de monnaie) reçoit les « sorties » nouvellement générées. Cela peut être représenté schématiquement comme ceci :
Les blockchains basées sur les comptes sont structurées un peu comme votre compte bancaire. Ils ne traitent que le montant de votre compte et le montant du transfert. Lorsque vous transférez un montant depuis 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 d’une transaction revient à vérifier la signature de l’expéditeur et le montant de son solde :
Analyse de la technologie
Nous verrons ensuite comment Zether masque le montant de la transaction, 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 les versions confidentielles et anonymes. Puisqu’il est beaucoup plus facile d’assurer la confidentialité dans les blockchains basées sur les comptes, certaines des restrictions imposées par l’anonymisation ne seront pas pertinentes pour la version confidentielle de la technologie.
Masquer les soldes et les montants des transferts
Un système de cryptage est utilisé pour crypter les soldes et transférer les montants dans Zether . Cela fonctionne comme suit. Quand Alice veut envoyer Bob b pièces par adresse (sa clé publique) Y, elle choisit un nombre au hasard r et crypte le montant :
où C - montant crypté, D - valeur auxiliaire nécessaire au déchiffrement de ce montant, G - un point fixe sur la courbe elliptique, multiplié par la clé secrète, on obtient la clé publique.
Lorsque Bob reçoit ces valeurs, il les ajoute simplement à son solde crypté de la même manière, c'est pourquoi ce schéma est pratique.
De même, Alice soustrait les mêmes valeurs de son solde, uniquement lorsque Y utilise votre clé publique.
Masquer le destinataire et l'expéditeur
Le brassage des « sorties » dans UTXO remonte aux débuts des crypto-monnaies et permet de cacher l’expéditeur. Pour ce faire, l'expéditeur lui-même, lors d'un transfert, collecte des « sorties » aléatoires dans la blockchain et les mélange avec les siennes. Ensuite, il signe les « sorties » avec une signature en anneau, un mécanisme cryptographique qui lui permet de convaincre le vérificateur que les pièces de l'expéditeur sont présentes parmi les « sorties » impliquées. Bien entendu, les pièces mélangées elles-mêmes ne sont pas dépensées.
Cependant, nous ne pourrons pas générer de fausses sorties pour masquer le destinataire. Par conséquent, dans UTXO, chaque « sortie » a sa propre adresse unique, et elle est liée cryptographiquement à l’adresse du destinataire de ces pièces. À l'heure actuelle, il n'existe aucun moyen d'identifier la relation entre l'adresse de sortie unique et l'adresse du destinataire sans connaître ses clés secrètes.
Dans le modèle basé sur les comptes, 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 mélangés avec d’autres comptes dans la blockchain. Dans ce cas, des pièces cryptées à 0 sont débitées des comptes mixtes (ou des 0 sont ajoutés si le destinataire est mixte), sans pour autant modifier leur solde réel.
Étant donné que l'expéditeur et le destinataire ont toujours une adresse permanente, il devient nécessaire d'utiliser les mêmes groupes pour le mixage lors du transfert vers les mêmes adresses. Il est plus facile de voir cela avec un exemple.
Disons qu'Alice décide d'apporter une contribution à l'association caritative de Bob, mais préfère que le transfert reste anonyme pour un observateur extérieur. Puis, afin de se déguiser dans le champ de l'expéditeur, elle entre également dans les comptes d'Adam et d'Adèle. Et pour masquer Bob, ajoutez les comptes de Ben et Bill dans le champ destinataire. Faisant la prochaine contribution, Alice a décidé d'écrire Alex et Amanda à côté d'elle, et Bruce et Benjen à côté de Bob. Dans ce cas, lors de l'analyse de la blockchain, dans ces deux transactions, il n'y a qu'une seule paire de participants qui se croisent - Alice et Bob, ce qui désanonymise ces transactions.
Courses aux transactions
Comme nous l'avons déjà mentionné, pour masquer votre solde dans les systèmes basés sur un compte, l'utilisateur crypte son solde et le montant du transfert. Parallèlement, il doit prouver que le solde de son compte reste non négatif. Le problème est que lors de la création 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 ? La transaction d'Alice sera alors considérée comme invalide, puisque la preuve de solde a été construite avant que la transaction de Bob ne soit acceptée.
La première décision à prendre dans une telle situation est de geler le compte jusqu'à ce que la transaction soit effectuée. Mais cette approche ne convient pas, car outre la complexité de résoudre un tel problème dans un système distribué, dans un schéma anonyme, il ne sera pas clair quel compte bloquer.
Pour résoudre ce problème, la technologie sépare les transactions entrantes et sortantes : les dépenses ont un effet immédiat sur le bilan, tandis que les recettes ont un effet différé. Pour ce faire, le concept d '«époque» est introduit - un groupe de blocs de taille fixe. L'« époque » actuelle est déterminée en divisant 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 et stocke les fonds du destinataire dans un réservoir de stockage. Les fonds accumulés ne sont mis à la disposition du bénéficiaire que lorsqu’une nouvelle « ère » commence.
En conséquence, l'utilisateur peut envoyer des transactions quelle que soit la fréquence de réception 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 propagent à travers le réseau et de la rapidité avec laquelle une transaction entre dans un bloc.
Cette solution fonctionne bien pour les transferts confidentiels, mais avec les transactions anonymes, comme nous le verrons plus tard, elle crée de sérieux problèmes.
Protection contre les attaques par relecture
Dans les blockchains basées sur un compte, 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 a été créée par le propriétaire de cette clé. Mais que se passe-t-il si un attaquant qui écoutait le canal de transmission interceptait ce message et envoyait exactement le même second ? Le vérificateur vérifiera la signature de la transaction et sera convaincu de sa paternité, et le réseau déduira à nouveau le même montant du solde de l'expéditeur.
Cette attaque est appelée attaque par rejeu. Dans le modèle UTXO, de telles attaques ne sont pas pertinentes, puisque l'attaquant tentera d'utiliser des sorties dépensées, qui en elles-mêmes ne sont pas valides et sont rejetées par le réseau.
Pour éviter que cela ne se produise, un champ contenant des données aléatoires est intégré à la transaction, appelé nonce ou simplement « sel ». Lors de la soumission à nouveau d'une transaction avec un sel, le vérificateur regarde si le nom occasionnel a déjà été utilisé et, sinon, considère la transaction valide. Afin de ne pas stocker l'intégralité de l'historique des noms occasionnels des utilisateurs dans la blockchain, il est généralement défini à zéro lors de la toute première transaction, puis augmenté de un. Le réseau peut seulement vérifier que le nonce de la nouvelle transaction diffère de la précédente.
Dans le schéma de transfert anonyme, le problème de la validation des transactions occasionnelles se pose. Nous ne pouvons pas lier explicitement le nonce à l'adresse de l'expéditeur, car cela désanonymise évidemment le transfert. Nous ne pouvons pas non plus en ajouter un aux noms occasionnels de tous les comptes participants, car cela pourrait entrer en conflit avec d'autres transferts en cours de traitement.
Les auteurs de Zether proposent de générer le nonce de manière cryptographique, en fonction de « l'époque ». Par exemple:
il est x est la clé secrète de l'expéditeur, et Gépoch — un générateur supplémentaire pour l'époque, obtenu en hachant une chaîne de la forme 'Zether +'. Maintenant, le problème semble être résolu - nous ne révélons 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 par « époque ». Ce problème reste malheureusement non résolu et rend actuellement la version anonyme de Zether, à notre avis, difficilement utilisable.
La complexité des preuves de connaissances nulles
Dans 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 à partir de rien (pourquoi cela est possible, avons-nous écrit dans l'un des précédents ). Et signez également les « entrées » avec une signature en 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 de preuve sont beaucoup plus complexes. L'expéditeur prouve que :
- Le montant envoyé est positif ;
- Le solde reste non négatif ;
- L'expéditeur a correctement crypté les montants du virement (y compris le zéro) ;
- Le solde du solde ne change que pour l'expéditeur et le destinataire ;
- L'expéditeur possède la clé privée de son compte et il figure effectivement sur la liste des expéditeurs (parmi ceux impliqués) ;
- Le Nonce utilisé dans la transaction est composé correctement.
Pour une preuve aussi complexe, les auteurs utilisent un mélange (l'un des auteurs a d'ailleurs participé à sa création) et , appelées balles Sigma. La preuve formelle d’une telle déclaration est une tâche assez difficile et limite considérablement le nombre de personnes disposées à mettre en œuvre la technologie.
Le résultat?
À notre avis, la partie de Zether qui apporte la confidentialité aux blockchains basées sur les comptes peut être utilisée dès maintenant. Mais pour le moment, la version anonyme de la technologie impose de sérieuses restrictions sur son utilisation et sa complexité sur sa mise en œuvre. Cependant, il ne faut pas ignorer 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 qui existent aujourd'hui. Après tout, c’est ainsi que se déroule la science.
Source: habr.com