Transactions confidentielles dans Monero, ou comment transférer quelque chose d'inconnu vers un endroit inconnu

Nous continuons notre série sur le fonctionnement de la blockchain Monero, et l'article d'aujourd'hui sera consacré au protocole RingCT (Ring Confidential Transactions), qui introduit des transactions confidentielles et de nouvelles signatures en anneau. Malheureusement, il y a peu d'informations sur son fonctionnement sur Internet, et nous avons essayé de combler cette lacune.

Nous parlerons de la manière dont ce protocole dissimule les montants des transactions dans le réseau, pourquoi les signatures en anneau classiques utilisées dans les cryptonotes ont été abandonnées et comment cette technologie va évoluer à l'avenir.

Étant donné que ce protocole est l'une des technologies les plus complexes de Monero, le lecteur aura besoin de connaissances de base sur le fonctionnement de cette blockchain et d'une compréhension superficielle de la cryptographie sur courbes elliptiques (pour rafraîchir ces connaissances, vous pouvez lire les premiers chapitres de notre précédent article sur les signatures multiples).

Le protocole RingCT

Une des attaques possibles sur les cryptomonnaies cryptonote est l'analyse de la blockchain, basée sur la connaissance du montant et de l'heure de la transaction envoyée. Cela permet de réduire considérablement le champ de recherche des sorties qui intéressent l'attaquant. Pour se protéger contre une telle analyse, Monero a mis en place un protocole de transactions anonymes qui dissimule complètement les montants des transactions dans le réseau.

Il convient de noter que l'idée de dissimuler les montants n'est pas nouvelle. L'un des premiers à l'avoir décrite est le développeur de Bitcoin Core Greg Maxwell dans son article sur les Transactions Confidentielles. La réalisation actuelle de RingCT en est une modification, permettant l'utilisation de signatures en anneau (comment s'en passer), et elle a pris son nom — Ring Confidential Transactions.

En outre, le protocole aide à résoudre les problèmes liés à la confusion des sorties poussières — des sorties de faible montant (qui résultent généralement de monnaie rendue lors de transactions), qui posaient plus de problèmes qu'elles n'en valaient la peine.

En janvier 2017, un hard fork du réseau Monero a eu lieu, permettant d'utiliser des transactions confidentielles de manière optionnelle. Et en septembre de la même année, avec le hard fork de la version 6, ces transactions sont devenues les seules autorisées sur le réseau.

RingCT utilise plusieurs mécanismes : des signatures de groupe anonymes spontanées liées multilayered (Multilayered Linkable Spontaneous Anonymous Group Signature, ensuite — MLSAG), un schéma d'engagement (Pedersen Commitments) et des preuves de portée (ce terme n'a pas d'équivalent établi en français).

Le protocole RingCT introduit deux types de transactions anonymes : simple et full. La première est générée par le portefeuille lorsque la transaction utilise plus d'une entrée, les secondes dans le cas inverse. Elles diffèrent par la validation des montants des transactions et les données signées par la signature MLSAG (nous en parlerons plus en détail ci-dessous). De plus, les transactions de type full peuvent être générées avec n'importe quel nombre d'entrées, il n'y a aucune différence fondamentale. Dans le livre «Zero to Monero» , il est mentionné que la décision de limiter les transactions full à une entrée a été prise à la hâte et pourrait changer à l'avenir.

La signature MLSAG

Rappelons ce que représentent les entrées signées d'une transaction. Chaque transaction dépense des fonds et en génère. La génération de fonds se fait par la création d'ouvertures de transaction (analogie directe — billets), et l'ouverture que la transaction dépense (car dans la vie réelle, nous dépensons précisément des billets) devient une entrée (attention, il est très facile de se perdre ici).

Une entrée fait référence à plusieurs ouvertures, mais n'en dépense qu'une seule, ainsi créant un « écran de fumée » pour compliquer l'analyse de l'historique des transferts. Si une transaction a plus d'une entrée, cette structure peut être représentée sous forme de matrice, où les lignes sont des entrées et les colonnes — les ouvertures mélangées. Pour prouver au réseau que la transaction dépense bien ses propres ouvertures (connaissant leurs clés secrètes), les entrées sont signées par une signature en anneau. Cette signature garantit que le signataire connaissait les clés secrètes de tous les éléments d'une colonne.

Les transactions confidentielles n'utilisent plus les signatures en anneau classiques de cryptonote , elles ont été remplacées par les MLSAG — une version adaptée pour plusieurs entrées des signatures en anneau similaires unilocalisées, LSAG.

. Elles sont appelées multischichtées car elles signent plusieurs entrées à la fois, chacune étant mélangée avec plusieurs autres, c'est-à-dire qu'une matrice est signée et non une seule ligne. Comme nous le verrons plus loin, cela aide à économiser de la taille de la signature.

Examinons comment une signature en anneau est formée, à l'exemple d'une transaction qui dépense 2 ouvertures réelles et utilise pour le mélange m — 1 aléatoires de la blockchain. Désignons les clés publiques des ouvertures que nous dépensons comme
, et les images de clé pour elles respectivement : Ainsi, nous avons une matrice de taille 2 x m. Pour commencer, nous devons calculer les soi-disant challenges pour chaque paire de sorties :

Nous commençons les calculs avec les sorties que nous dépensons, en utilisant leurs clés publiques :et des nombres aléatoiresAu final, nous obtenons les valeurs :
, que nous utilisons pour calculer le challenge
de la prochaine paire de sorties (pour faciliter la compréhension de ce que nous remplaçons, nous avons mis ces valeurs en couleurs différentes). Toutes les valeurs suivantes sont calculées en rond selon les formules présentées dans la première illustration. Le challenge pour la paire réelle de sorties est calculé en dernier.

Comme nous le voyons, dans toutes les colonnes, sauf celle contenant les sorties réelles, des nombres générés aléatoirement sont utilisés. Pour π-ième colonne, ils nous seront également nécessaires. Transformonsen s :
La signature elle-même est un tuple de toutes ces valeurs :

Ensuite, ces données sont enregistrées dans la transaction.

Comme nous le voyons, le MLSAG contient un seul challenge c0, ce qui permet d'économiser sur la taille de la signature (qui demande déjà beaucoup d'espace). Ensuite, tout vérificateur, en utilisant les données, restaure les valeurs c1,…, cm et vérifie que. Ainsi, notre anneau s'est bouclé et la signature a passé la vérification.

Pour les transactions RingCT de type full, une ligne supplémentaire est ajoutée à la matrice avec les sorties mélangées, mais nous en parlerons plus tard.

Engagements de Pedersen

Schémas d'engagements (le terme anglais — commitments — est le plus souvent utilisé) sont utilisés pour qu'une partie puisse prouver qu'elle connaît un certain secret (nombre) sans le révéler réellement. Par exemple, vous lancez un certain nombre sur des dés, calculez l'engagement et le transmettez à la partie vérificatrice. Ainsi, au moment de dévoiler le nombre secret, le vérificateur calcule lui-même l'engagement, s'assurant ainsi que vous ne l'avez pas trompé.

Dans Monero, les engagements sont utilisés pour masquer les montants des transferts et appliquent la variante la plus courante — les engagements de Pedersen. D'ailleurs, un fait intéressant — au départ, les développeurs proposaient de masquer les montants par un simple mélange, c'est-à-dire d'ajouter des sorties à des montants aléatoires pour introduire de l'incertitude, mais ont ensuite opté pour des engagements (il n'est pas certain que cela ait permis d'économiser sur la taille de la transaction, comme nous le verrons plus bas).
Dans l'ensemble, un engagement se présente comme suit :
Où C — la valeur de l'engagement lui-même, a — le montant masqué, H — un point fixe sur une courbe elliptique (générateur additionnel), x — un masque arbitraire, un facteur caché, généré aléatoirement. Ce masque est nécessaire pour que la troisième partie ne puisse pas deviner la valeur d'engagement simplement par essais et erreurs.

Lors de la génération d'une nouvelle sortie, le portefeuille calcule une valeur d'engagement, et en cas de dépense, il utilise soit la valeur calculée lors de la génération, soit la recalcule — selon le type de transaction.

RingCT simple

Dans le cas de transactions RingCT simples, pour garantir que la transaction ait créé des sorties dont le montant est égal à la somme des entrées (et n'ait pas généré de l'argent à partir de rien), il est nécessaire que les sommes des engagements des premières et deuxièmes sorties soient identiques, c'est-à-dire :

L'engagement des frais est calculé un peu différemment — sans masque :
, où a — le montant des frais, qui est publiquement accessible.

Cette approche permet de prouver à la partie vérificatrice que nous utilisons des sommes identiques, sans les révéler.

Pour rendre cela plus clair, prenons un exemple. Supposons qu'une transaction dépense deux sorties (c'est-à-dire qu'elles deviennent des entrées) de 10 et 5 XMR et génère trois sorties d'un montant total de 12 XMR : 3, 4 et 5 XMR. Dans ce cas, elle paie des frais de 3 XMR. Ainsi, la somme d'argent dépensée plus la somme générée et les frais égalent 15 XMR. Essayons de calculer les engagements et observons la différence de leurs sommes (rappelons un peu de mathématiques) :

Ici, nous voyons que, pour que l'équation soit correcte, les sommes des masques des entrées et des sorties doivent être identiques. Pour cela, le portefeuille génère aléatoirement x1, y1, y2 et y3, tandis que le reste x2 est calculé comme suit :

En utilisant ces masques, nous pouvons prouver à n'importe quel vérificateur que nous ne générons pas plus de fonds que nous ne dépensons, sans révéler les sommes. Original, n'est-ce pas ?

RingCT complet

Dans les transactions RingCT complètes, la vérification des montants des transferts se fait de manière un peu plus complexe. Dans ces transactions, le portefeuille ne recalcule pas les engagements pour les entrées, mais utilise ceux calculés lors de leur génération. Il faut alors supposer que la différence des sommes n'est plus égale à zéro, mais à la place :

Ici z — la différence des masques des entrées et des sorties. Si nous considérons zG comme une clé publique (ce qu'elle est de facto), alors z — c'est une clé privée. Ainsi, nous connaissons la clé publique et sa clé privée correspondante. Avec ces informations, nous pouvons les utiliser dans la signature en anneau MLSAG avec les clés publiques des sorties mélangées :

Ainsi, une signature en anneau valide garantira que nous connaissons toutes les clés privées d'une des colonnes, tandis que la clé privée de la dernière ligne ne peut être connue que si la transaction ne génère pas plus de fonds qu'elle n'en dépense. D'ailleurs, ici se trouve la réponse à la question « pourquoi la différence des sommes des commitments ne donne-t-elle pas zéro » — si zG = 0, alors nous dévoilerons la colonne avec les sorties réelles.

Mais comment le destinataire saura-t-il combien d'argent il a reçu ? C'est simple : l'expéditeur de la transaction et le destinataire échangent des clés selon le protocole de Diffie-Hellman, en utilisant la clé de la transaction et la clé de vue du destinataire pour calculer un secret commun. L'expéditeur enregistre dans des champs spéciaux de la transaction les montants des sorties, chiffrés avec cette clé commune.

Preuves d'intervalle

Que se passe-t-il si nous utilisons un nombre négatif comme montant dans les commitments ? Cela pourrait conduire à la génération de pièces supplémentaires ! Un tel résultat est inacceptable, donc nous avons besoin d'une garantie que les sommes que nous utilisons ne sont pas négatives (sans révéler ces sommes, bien sûr, sinon tout ce travail serait vain). En d'autres termes, nous devons prouver que la somme se situe dans l'intervalle [0, 2n — 1].

Pour cela, chaque montant de sortie est décomposé en bits binaires et un commitment est calculé pour chaque bit séparément. Comment cela se passe, il est préférable de l'observer avec un exemple.

Supposons que nos montants soient petits et tiennent dans 4 bits (en pratique, c'est 64 bits), et que nous créons une sortie pour un montant de 5 XMR. Calculons les commitments pour chaque bit et le commitment total pour l'ensemble du montant :
Ensuite, chaque commitment est mélangé avec un substitut (Ci-2iH) et signé par une signature en anneau de Borromeo (une autre signature en anneau), proposée par Greg Maxwell en 2015 (vous pouvez lire plus à son sujet ici):
Tout cela s'appelle preuve d'intervalle et permet de garantir que les sommes dans les commitments sont dans l'intervalle [0, 2n — 1].

Et après ?

Dans la mise en œuvre actuelle, les preuves de portée occupent beaucoup d'espace — 6176 octets par sortie. Cela entraîne des transactions de grande taille et, par conséquent, des frais plus élevés. Pour réduire la taille des transactions, les développeurs de Monero introduisent des bulletproofs — un mécanisme de preuve de portée sans engagements bit à bit, à la place des signatures de Borromeo. Selon certaines estimations, ils peuvent réduire la taille de la preuve de portée jusqu'à 94 %. À propos, à la mi-juillet, la technologie a été auditée par la société Kudelski Security, qui n'a identifié aucun défaut significatif dans la technologie elle-même ni dans sa mise en œuvre. La technologie est déjà utilisée sur le réseau de test et, avec le nouveau hard fork, pourrait probablement être intégrée dans le réseau principal.

Posez vos questions, proposez des sujets pour de nouveaux articles sur les technologies dans le domaine des cryptomonnaies, et abonnez-vous à notre groupe sur Facebook, afin de rester informé de nos événements et publications.

Source : habr.com