Un audit d'un portefeuille de crypto-monnaie est l'occasion pour un tiers (l '«auditeur») de voir les transactions de ce portefeuille et de calculer son solde actuel correct sans droit de dépenser de l'argent.

L'article décrit différentes façons d'assurer cette fonctionnalité dans le protocole de crypto-monnaie CryptoNote 2.0 [ 1 ], où l'audit n'est que partiellement implémenté: à l'aide d'une clé de suivi, vous pouvez reconnaître les transactions entrantes, mais pour reconnaître les transactions sortantes, vous avez besoin d'un jeu complet de clés.

Le matériel est destiné aux lecteurs qui connaissent le sujet de la blockchain et des crypto-monnaies «classiques», ainsi que les bases de la cryptographie sur les courbes elliptiques.

Contenu

1.
2.
3. CryptoNote
4. 1/3. Bytecoin Auditable Coins
  4.1. tx.version < amethyst, legacy address
  4.2. tx.version ≥ amethyst
  4.3. tx.version ≥ amethyst, legacy address
  4.4. tx.version ≥ amethyst, amethyst address
  4.5. CryptoNote Bytecoin Amethyst
5. 2/3. CryptoNote Anton Sokolov
6. 3/3.
7.

1.

CryptoNote?

Curieusement, la plupart des personnes intéressées par la technologie de la blockchain n'ont rien entendu sur CryptoNote, et ce malgré le fait que cette technologie soit devenue la base de plus de 300 fourches, dont la plus célèbre est Monero.

En 2014, des mentions sont apparues dans l'environnement de crypto-monnaie [ 2] à propos d'un projet appelé Bytecoin. Le projet n'était pas un fork de Bitcoin ou un autre projet open source et avait une base de code complètement nouvelle, ce qui était extrêmement inhabituel pour l'époque. Son concept principal était de mettre en œuvre une technologie de confidentialité appelée CryptoNote. La confidentialité était assurée par deux mécanismes: les adresses furtives et le mélange des entrées à l'aide d'une signature en anneau (il était également appelé à l'époque «mélangeur sur la blockchain»). Puisqu'à cette époque, Zcash n'existait qu'en théorie, la technologie s'est avérée très compétitive et a provoqué une grande résonance dans la communauté des crypto-monnaies.

Bientôt, un groupe de passionnés qui ont montré de l'intérêt pour l'une des premières fourches de cette technologie, puis ont pris l'initiative dans cette fourchette, avec leurs actions énergiques ont réussi à attirer la plus grande attention sur la technologie à la fois dans la communauté et parmi les investisseurs. Cette fourchette s'appelait BitMonero [ 3 , 4 ], mais très vite elle fut renommée Monero.

À l'avenir, les deux projets - Bytecoin et Monero - se sont développés de manière technologiquement différente: si Bytecoin est resté un projet anonyme fermé, alors Monero s'est transformé en un grand projet communautaire avec un très grand nombre de participants et de développeurs. Cependant, ils sont tous deux un développement de la technologie CryptoNote.

Le concept d'audit et son application

Contrairement à la blockchain «pseudonyme» classique telle que Bitcoin, dans laquelle n'importe qui, en scannant la blockchain, peut calculer trivialement les soldes de n'importe quelle adresse, dans une blockchain privée, en particulier dans CryptoNote, cette tâche est difficilement réalisable sans connaissances supplémentaires. Tout d'abord, grâce à la technologie des adresses furtives, il n'y a aucune référence à des adresses dans la blockchain (cette propriété est généralement appelée anonymat ). Deuxièmement, en raison du fait que, grâce à la signature en anneau, l'entrée de transaction n'indique pas une sortie spécifique de la transaction parent, mais indique, dans le cas général, l'ensemble des sorties probables, il n'est également pas possible de suivre le mouvement des fonds (cette propriété est appelée indisponibilité ).

Dans la compréhension traditionnelle de la crypto-monnaie privée, ces propriétés sont nécessaires, mais il existe des cas particuliers où le propriétaire du portefeuille peut vouloir divulguer l'historique de ses transactions et le solde actuel du portefeuille à un tiers, tout en garantissant l'impossibilité de dépenser de l'argent par un tiers. Cela peut être nécessaire, par exemple, pour les échanges, pour l'interaction avec les régulateurs ou les autorités de contrôle. De plus, cela peut être important pour divers fonds qui souhaitent pouvoir être transparents pour un groupe spécifique d'individus ou être pleinement publics.

S'exprimant formellement, un audit des portefeuilles signifie une opportunité pour un tiers (l '«auditeur») de voir les transactions de ce portefeuille et de calculer son solde actuel correct sans transférer le droit de dépenser de l'argent. Dans la version originale de CryptoNote, l'audit n'était que partiellement implémenté: à l'aide d'une clé de suivi, vous pouvez reconnaître les transactions entrantes, mais pour reconnaître les transactions sortantes, vous avez besoin d'un jeu complet de clés.

À propos de l'auteur et du but de la publication

L'auteur de ce matériel est l'un des principaux développeurs du projet Zano - un projet basé sur CryptoNote, qui se développe depuis plusieurs années avec les mêmes mains qui ont écrit le code technologique original.

Notre équipe envisage maintenant d'ajouter un audit de portefeuille au projet et de mener des recherches sur ce sujet afin de choisir la meilleure option. L'auteur souhaite présenter les résultats de certaines de ces études aux lecteurs dans cet article.

2. Informations de base sur la cryptographie sur les courbes elliptiques

Le protocole CryptoNote utilise une courbe elliptique du schéma de signature numérique à clé publique ed25519 [ 5 ].

Rappelez les principaux paramètres de cette courbe et donnez des définitions supplémentaires.

1. Correction d'un grand nombre premier $$$q = 2^{255}-19$.
   $$$F_q$ $$$q$.
2. $$$F_q$, $$$E/F_q$:
   $$$−x^2+y^2= 1 +dx^2y^2$
   $$$d = −121665/121666$ ( $$$F_q$ ).
   $$$x$ $$$y$.
3. , : $$$F(A, B) = C$, «», , , ( [6]). , , , , $$$E(F_q)$.
   ( ): $$$\# E(F_q)=2^cl$, $$$= 3$ () $$$l=2^{252}+27742317777372353535851937790883648493$.
4. $$$(x, y)$. , , $$$y$, 256- .
   $$$x$-, (. ), , , $$$y$-.
5. $$$G = (x, −4/5)$. $$$y$-, x .
6. (. . 3) $$$G$ $$$n$ ($$$*$, ) , $$$\mathbf{G}$, , $$$E(F_q)$:
   $$$\#\mathbf{G} < \#E(F_q)$,
   
   $$$\#\mathbf{G}=l=2^{252}+27742317777372353535851937790883648493$.
7. $$$X$ — , $$$\mathbf{G}$:
   $$$X \in \mathbf{G}$
8. $$$x$, , $$$X$ — , :
   $$$X = x*G, x \in [1; l-1]$
   , (. ), 256- .
9. - $$$H$ ( cn_fast_hash). 32- :$$$H:\{0, 1\}^* \to [0,2^{256}-1]$
10. - $$$H_s$ ($$$s$ scalar) , , .. :
    $$$H_s:\{0,1\}^* \to [1; l-1]$
    $$$H_s$ $$$H$:
    $$$H_s(x)= H(x) \mod (l-1) + 1$
11. - $$$H_p$ ($$$p$ point — ) $$$\mathbf{G}$, , :
    $$$H_p:\{0,1\}^* \to \mathbf{G}$
    - , -, 256 (. . 4), -, $$$\mathbf{G}$ (. . 6).
    $$$H_p$ $$$H(H(...H(x)...))$ , $$$X \in \mathbf{G}$.
    CryptoNote , ge_fromfe_frombytes_vartime, [7].
    , 256 $$$\mathbf{G}$ :
    $$$to\_point : [0,2^{256}-1] \to \mathbf{G}$
    CryptoNote - $$$H_p$ :
    $$$H_p(x) = to\_point( H(x) )$

3. CryptoNote

Rappelez-vous comment les fonds sont envoyés et le solde est calculé dans la version originale du protocole.

Alice, en envoyant de l'argent à Bob, forme les résultats de sa transaction comme suit (Fig. 3.1).

1. Bob a une paire de clés privées $$$(v, s)$. Il calcule son adresse comme une paire de clés publiques correspondantes$$$(V, S)$ et le publie ou l'envoie à Alice.
2. Alice choisit une clé de transaction secrète aléatoire $$$r$ et calcule la clé publique $$$R = r G$qui écrit dans le domaine spécial des transactions supplémentaires.
3. Pour chaque sortie, Alice calcule l'adresse furtive (clé de destination unique):
   $$$P_i = H_s(rV, i)G + S$où $$$i$ - numéro de série de la sortie.
4. Alice signe et envoie la transaction.

Observateur tiers analysant les adresses furtives $$$P_i$, ne peut pas dire si une sortie particulière est destinée à Bob, et ne peut même pas déterminer si différentes sorties avec touches sont destinées $$$P_i$ et $$$P_j$à un destinataire.

Pour accepter l'argent, Bob analyse toutes les transactions sur la blockchain comme suit (Fig. 3.2).
5. Utilisation de votre clé privée $$$v$Bob calcule pour chaque sortie $$$P’_i = H_s(vR, i)G + S$ (Où $$$i$ - numéro de série de la sortie, $$$S$- Clé de dépenses publiques de Bob).
Si$$$P’_i = P_i$, cela signifie qu'il est le destinataire de cette sortie et qu'il peut la dépenser en calculant la clé secrète correspondante. Par conséquent, Bob augmente le solde de son portefeuille de la valeur de cette sortie.

Pour dépenser la sortie, Bob est le destinataire et envoie des pièces Carol, il agit comme suit.

6. Bob utilisant ses clés secrètes $$$(v, s)$calcule la clé privée $$$x_i = H_s(vR, i) + s$ à l'adresse furtive $$$P_i$, c'est-à-dire tels que $$$P_i = x_i G$.

7. Bob calcule l'image clé:$$$I = x_i H_p(P_i)$et l'écrit, la valeur nominale et un lien vers la sortie correspondante dans l'entrée de sa transaction pour Carol.
Il convient de noter que, premièrement, seul le propriétaire de la clé de dépense secrète peut calculer l'image de la clé$$$s$ (l'exactitude de cela sera certifiée par une signature en anneau), et deuxièmement, un tiers ne pourra pas lier l'image clé $$$I$ et l'adresse furtive correspondante $$$P_i$.

8. Bob réduit le solde de son portefeuille de la valeur nominale de la sortie utilisée au paragraphe 6.

9. Bob forme les sorties de la transaction pour Carol conformément aux paragraphes. 2-3. Signe ensuite la transaction et l'envoie.

En supposant que Bob a perdu toute l'histoire de ses opérations, mais possède toujours ses clés secrètes$$$(v, s)$, il pourra alors restaurer l'historique des transactions et calculer son solde actuel comme suit (Fig. 3.4).

10. Bob scanne l'intégralité de la blockchain et analyse toutes les transactions pour la présence de sorties qui lui sont adressées (voir paragraphe 5).

11. Lors de la recherche d'une telle sortie$$$P_i$, Bob augmente l'équilibre de son portefeuille de la valeur de la valeur faciale.
Ensuite, en utilisant votre clé de dépense secrète$$$s$ calcule la clé de sortie secrète correspondante $$$x_i$ (p. 6) et image clé $$$I$(paragraphe 7). Écrit ensuite l'image clé,$$$P_i$et d'autres données de paiement dans un tableau.

12. Si lors de la poursuite de l'analyse de la blockchain, Bob trouve dans l'entrée d'une transaction l'image clé du tableau, cela signifiera que cette transaction a été formée par Bob. Par conséquent, il réduira le solde de son portefeuille de la valeur de la valeur d'entrée.

Ce faisant, Bob rétablira l'équilibre actuel de son portefeuille.

Veuillez noter que si l'auditeur tiers Dan reçoit une clé secrète de Bob$$$v$, alors il sera capable de reconnaître les transactions entrantes de Bob sur la blockchain, cependant, sans clé secrète $$$s$, il ne pourra pas reconnaître les transactions sortantes de Bob, ce qui signifie qu'il calculera également le solde correct. Comme nous le verrons plus loin, dans le cas de dépenses directes de sortie par Bob sans mélange, Den pourra identifier une telle transaction comme le transfert sortant de Bob, mais dans le cas général cela ne peut pas être fait.

Ainsi, pour calculer le solde du portefeuille de Bob, vous devez connaître les deux clés secrètes$$$(v, s)$.

Si Bob donne ses deux clés privées à l'auditeur Dan$$$(v, s)$, cela équivaudra à transférer les fonds eux-mêmes, puisque Den, possédant $$$s$pourra les dépenser. Par conséquent, un audit complet des portefeuilles sous le protocole CryptoNote d'origine n'est pas possible.

Dans les sections suivantes, nous considérerons les options de modification du protocole qui ont cette capacité.

Notez que la clé secrète de la transaction$$$r$Il est logique de sauver Alice (ce qui se produit dans certaines implémentations du protocole). Quiconque sait$$$r$ pour certaines transactions, peut vérifier si la sortie est pertinente $$$i$ cette transaction à l'adresse indiquée $$$(V, S)$en répétant simplement les calculs de l'article 3:

$$$P’_i = H_s(rV, i)G + S$

et comparer le résultat avec $$$P_i$.

Alice peut, par exemple, utiliser ce fait pour prouver qu'elle a transféré l'argent à Bob.

Calculer l'adresse de destination$$$(V, S)$ à la sortie, même en sachant $$$r$, vous ne pouvez pas.

4. Option 1/3. Pièces vérifiables Bytecoin

Au moment de son apparition, Bytecoin était la première et la seule implémentation du protocole CryptoNote, il était donc caractérisé par toutes les fonctionnalités et limitations discutées dans la section précédente.

Le 7 février 2019, les développeurs ont publié ([ 20 ]) la version 3.4.0 d'Amethyst, qui contient un certain nombre d'améliorations et de changements à CryptoNote, que nous allons maintenant considérer. La plupart des informations de cette section ont été obtenues en analysant le code source de Bytecoin, car aucune documentation officielle n'a été fournie.

Dans le cadre de cet article, le changement le plus intéressant a été la possibilité pour les portefeuilles ordinaires de créer des copies spéciales - portefeuille vérifiable (AW), qui ont deux propriétés:

1. AW ne peut pas dépenser des fonds du portefeuille principal;
2. L'équilibre AW coïncide toujours avec l'équilibre du portefeuille principal. Il n'est pas possible de modifier l'équilibre du portefeuille principal afin qu'il n'affecte pas l'équilibre de AW.

Cependant, seules les adresses de portefeuille des nouvelles versions, les adresses dites améthystes, ont une telle fonctionnalité. La compatibilité descendante est fournie avec les adresses et les comptes existants; ils sont désormais appelés adresses héritées. L'implémentation de la nouvelle fonctionnalité n'est devenue possible que dans les transactions de la nouvelle version, car les développeurs ont changé le format des sorties.Par conséquent, les réseaux bytecoin diffusent actuellement à la fois les transactions de l'ancien format et les nouvelles. Les transactions du nouveau format prennent également en charge deux types d'adresses: l'améthyste et l'héritage, nous avons donc finalement trois options pour les schémas cryptographiques:

1. tx.version <améthyste, ancienne adresse;
2. tx.version ≥ améthyste, ancienne adresse;
3. tx.version ≥ améthyste, adresse améthyste.

Examinons-les plus en détail.

4.1. tx.version <améthyste, ancienne adresse

Il s'agit du schéma CryptoNote d'origine, mais avec une génération déterministe. $$$r$.

Compte portefeuille représenté par une clé secrète.$$$s$ et le hachage $$$v_s$. Touche de vue secrète$$$v$ généré de façon déterministe en fonction de $$$v_s$.

La clé secrète$$$r$ les transactions sont désormais sélectionnées non pas par hasard, mais calculées à l'aide de $$$v_s$:

$$$r = H_s(h_t, v_s)$où $$$h_t = H(tx.inputs, tx.version)$

Cela élimine le besoin de clés privées. $$$r$ dans le stockage local pour les besoins futurs, car pour toute transaction envoyée à la blockchain, une telle clé peut être calculée à l'aide de $$$v_s$.

Le solde du portefeuille est calculé de manière similaire à la CryptoNote d'origine (voir la section 3), c'est-à-dire qu'une clé de dépense secrète est requise pour tenir compte des paiements sortants.$$$s$.

Si toutes les adresses qui ont déjà été transférées vers le portefeuille sont stockées dans le portefeuille local , il est possible de calculer le solde correct sans impliquer une clé de dépense secrète$$$s$ de la manière suivante:

1. Alice scanne les transactions sur la blockchain et suit les paiements entrants à l'aide d'une clé de vue secrète $$$v$, comme décrit dans la section 3, et augmente l'équilibre.
2. Aussi, pour chaque sortie de chaque transaction, Alice passe par toutes les adresses $$$(V, S)$ vers lesquels des transferts ont déjà été effectués et calcule:
   $$$P’_i = H_s(rV, i)G + S$
   Si $$$P’_i = P_i$, alors cette sortie est le paiement sortant d'Alice à l'adresse $$$(V, S)$ et cela réduit l'équilibre.

Alice calculera donc le solde en utilisant uniquement $$$v_s$ et $$$v$.

De toute évidence, cette méthode n'est pas fiable et n'est pas pratique, car l'absence dans le stockage local indiqué de l'adresse à laquelle le transfert a été effectivement effectué entraînera une surestimation du solde. Il s'agit donc plutôt d'un intérêt théorique.

4.2. tx.version ≥ améthyste

Comme indiqué ci-dessus, depuis la version 3.4.0 d'Amethyst, Bytecoin a changé le format des transactions. Si tx.version ≥ amethyst, alors les sorties de transaction ont un format différent.

Désormais, chaque sortie, en plus du montant et de la clé publique P _i , contient également une clé publique supplémentaire Q _i (indiquée dans le code comme encrypted_secret) et un octet supplémentaire contenant le type d'adresse chiffrée, améthyste ou hérité (référencé dans le code encrypted_address_type). Ces structures sont représentées schématiquement sur la Fig. 4.2.

Ainsi, la taille de chaque sortie a augmenté de 33 octets.

Pour chaque sortie i, le type d'adresse est codé et décodé comme suit: où:

encrypted_address_type(i) = (H(oi) & 255) xor address_tag



$$$o_i = H(h_t, v_s, i)$(indiqué dans le code comme output_seed),

address_tag est 0 pour les adresses héritées et 1 pour les adresses amétystes.

4.3. tx.version ≥ améthyste, ancienne adresse

Le compte portefeuille est également représenté par une clé secrète. $$$s$ et le hachage $$$v_s$sur la base de laquelle une clé de vue secrète est générée de manière déterministe $$$v$.

Alice envoie de l'argent à Bob à son adresse$$$(V, S)$forme les sorties de sa transaction comme suit:

  1. Calcule$$$h_t = H(tx.inputs, tx.version)$, puis pour chaque sortie $$$i$:
  2.$$$D_i = H_s(h_t, v_s, i)G$(indiqué dans le code comme output_shared_secret)
  3.$$$P_i = S + H_s(D_i, h_t, i)G$
  4. $$$Q_i = H_s(h_t, v_s, i)V$ (où $$$Q_i = v D_i$cependant voir la clé $$$v$destinataire inconnu)
  5. Pair$$$(P_i, Q_i)$ - clés de sortie publiques $$$i$.

Pour accepter l'argent, Bob analyse toutes les transactions comme suit.

  6. Pour chaque transaction, calcule$$$h_t = H(tx.inputs, tx.version)$, puis pour chaque sortie $$$i$:
  7.$$$D_i = v^{-1} Q_i$
  8. $$$S’ = P_i — H_s(D_i, h_t, i) G$
  9. Si $$$S’$ correspond à la clé publique $$$S$Bob, alors cette sortie lui est destinée et il augmente le solde de son portefeuille de la valeur faciale correspondante.

Pour dépenser la sortie, Bob est le destinataire et envoie des pièces Carol, il agit comme suit.

  10. Utilisation de vos clés secrètes$$$v$ et $$$s$calcule la partie secrète $$$P_i$:
    $$$D_i = v^{-1} Q_i$
    $$$x_i = s + H_s(D_i, h_t, i)$, il est facile de voir que $$$P_i = x_i G$(voir paragraphe 3).
  11. Bob calcule l'image clé:$$$I = x_i H_p(P_i)$et l'écrit, la valeur nominale et un lien vers la sortie correspondante dans l'entrée de sa transaction pour Carol.
  12. Bob réduit le solde de son portefeuille de la valeur de la sortie utilisée.
  13. Bob forme les résultats de la transaction pour Carol conformément à 1-5. Signe ensuite la transaction et l'envoie.

Une caractéristique de ce schéma, contrairement à CryptoNote, est que toute personne à qui Alice transférera son hachage secret$$$v_s$, pourra calculer l'adresse du destinataire $$$(V, S)$pour toute transaction Alice:

  14.$$$D_i = H_s(h_t, v_s, i) G$
  quinze. $$$S = P_i — H_s(D_i, h_t, i) G$
  seize. $$$V = H_s(h_t, v_s, i)^{-1} Q_i$

Cependant, le problème dans ce cas est la tâche de déterminer quelles transactions Alice a générées et envoyées. Sans ces informations dans p.p. 14-16 pour les transactions arbitraires seront obtenues des données inutiles arbitraires indiscernables des adresses réelles$$$(V, S)$. L'algorithme de codage peut fournir une aide à cet encrypted_address_typeégard, car pour les transactions d'Alice, ce champ après décodage n'aura que des valeurs valides$$$\{0, 1\}$. Mais, malheureusement, des valeurs acceptables peuvent également être obtenues arbitrairement, et un tel cas ne peut être distingué.

Étant donné que dans ce schéma, le calcul de l'image clé nécessite également la connaissance de la clé de dépense secrète$$$s$, le problème d'audit, c'est-à-dire le calcul du solde exact du portefeuille sans transférer les droits de dépenser de l'argent, n'est pas résolu.

4.4. tx.version ≥ améthyste, adresse d'améthyste

Constante h

Le fonctionnement de ce schéma cryptographique nécessite l'introduction d'une nouvelle constante - le point $$$H$élément de groupe $$$\mathbf{G}$et l'ordre du point $$$H$inconnue. En d'autres termes, il s'agit d'une clé publique fixe, dont la partie secrète est garantie inconnue et la probabilité de sa découverte est négligeable:

$$$H = yG$où $$$y$Est un nombre inconnu.

Par exemple, vous pouvez définir$$$H$comme proposé dans [ 8 ]:

$$$H = H_p(G) = to\_point( cn\_fast\_hash(G) )$

Les développeurs de Bytecoin ne calculent pas la constante, mais la définissent numériquement, sans aucune indication de la nature de son origine:

bytecoin / src / crypto / crypto_helpers.hpp, ligne 67

constexpr P3 H{ge_p3{{7329926, -15101362, 31411471, 7614783, 27996851, -3197071, -11157635, -6878293, 466949, -7986503},    {5858699, 5096796, 21321203, -7536921, -5553480, -11439507, -5627669, 15045946, 19977121, 5275251},    {1, 0, 0, 0, 0, 0, 0, 0, 0, 0},    {23443568, -5110398, -8776029, -4345135, 6889568, -14710814, 7474843, 3279062, 14550766, -7453428}}};

Cependant, une recherche de cette séquence numérique a montré ([ 9 ]) qu'ils utilisent la même constante que dans Monero pour RingCT, dont la méthode de calcul et sa justification ont été examinées dans [ 8 ].

Parce que le$$$H$ appartient au groupe $$$\mathbf{G}$, alors on peut dire que $$$H$ donne également naissance à un groupe $$$\mathbf{G}$comme point de base $$$G$.

Cela signifie que$$$\forall x \in [1,p-1], xH \in \mathbf{G}$

Plusieurs adresses non liées

Dans la CryptoNote d'origine, chaque portefeuille (c'est-à-dire un ensemble de clés secrètes) était associé à une adresse publique, qui était utilisée pour y transférer des fonds.

Le schéma envisagé permet de générer un nombre illimité d'adresses publiques sur le même ensemble de clés secrètes. Où:

1. les adresses sont générées de manière déterministe à partir de l'ensemble initial de secrets;
2. ces adresses ne peuvent pas être interconnectées, c'est-à-dire un observateur extérieur ne pourra pas calculer qu'il appartient au même compte;
3. vérification des transactions entrantes et comptabilisation $$$N$ plusieurs adresses seront plus faciles à calculer que la vérification $$$N$ comptes dans le schéma habituel.

Compte portefeuille représenté par une clé secrète. $$$s$ et le hachage $$$v_s$, ainsi que dans le schéma précédent. Cependant, sur la base du hachage$$$v_s$ maintenant non seulement une clé de vue secrète est générée de manière déterministe $$$v$, mais aussi une clé d'audit secrète supplémentaire $$$a$.

Le processus de génération de la i-ème adresse est le suivant (Fig. 4.4.2).
  1. Calculé $$$\delta = H_s(A + sH, i)$ et $$$\Delta = \delta G$
  2. $$$S = A + sH + Δ$
  3. $$$V = vS = v(A + sH + Δ) = v(A + sH) + δV$
  4. paire $$$(V, S) = (v S, S)$ est un $$$i$L'adresse publique de ce compte.

Notez que pour le calcul il suffit de connaître les valeurs suivantes:
  •$$$A$
  • $$$V$
  • $$$s H$
  • $$$v (A + s H)$

Quantités $$$s H$ et $$$v (A + s H)$ sont calculés lors de la création d'un compte et sont considérés comme sûrs dans le sens où les connaître, vous ne pouvez pas calculer $$$s$ ou $$$v$.

Les adresses générées sont stockées localement dans un conteneur optimisé pour la recherche sur le terrain.$$$S$.

Formation de sorties lors de l'envoi de fonds

Alice envoie de l'argent à Bob à son adresse $$$(V, S)$ forme les résultats de sa transaction comme suit (Fig. 4.4.3).
  1. Calcule $$$h_t = H(tx.inputs, tx.version)$, puis pour chaque sortie $$$i$:
  2.$$$P_i = H_s( H_p(h_t, v_s, i), h_t, i )^{-1} S$
  3. $$$Q_i = H_s( H_p(h_t, v_s, i), h_t, i )^{-1} V + H_p(h_t, v_s, i)$
  4. Couple $$$(P_i, Q_i)$ - clés de sortie publiques $$$i$.

Comptabilisation des paiements entrants

Pour accepter l'argent, Bob analyse toutes les transactions comme suit (Fig. 4.4.4.).

1. Pour chaque sortie $$$i$à l'aide d'une clé de vue secrète $$$v$Bob calcule:$$$K = H_p(h_t, v_s, i) = Q_i — v P_i$( output_shared_secreten code)
2. $$$S’ = H_s(K, h_t, i) P_i$
3. Après quoi il essaie de trouver $$$S’$dans votre liste d'adresses. S'il le trouve, cela signifie que cette sortie transfère de l'argent à Bob. Il augmente le solde de l'adresse correspondante.

Cela signifie que pour prendre correctement en compte les paiements entrants, dans ce schéma, en plus de la liste des adresses ou des clés pour les générer, vous devez connaître la clé de vue secrète $$$v$.

Formation des paiements sortants

Passer une sortie $$$i$dont Bob est le destinataire, et envoyer les pièces à Carol, il agit comme suit.

1. $$$K = H_p(h_t, v_s, i) = Q_i — v P_i$( output_shared_secreten code)
2. $$$x_i = H_s(K, h_t, i)^{-1} (a + \delta)$
3. $$$X_i = x_i G + H_s(K, h_t, i)^{-1} s H$
4. Calcule l'image clé $$$I = x_i * H_p(X_i)$
5. Bob réduit le solde lié à son adresse $$$S = H_s(K, h_t, i) P_i$ par la valeur nominale de la sortie correspondante.
6. Bob génère des sorties de transaction, le signe et l'envoie.

On voit que pour calculer l'image clé, il faut connaître non seulement la clé de vue secrète $$$v$, mais aussi $$$a$.

Une caractéristique importante de ce schéma est la possibilité de calculer une image clé (et, par conséquent, de prendre en compte ses paiements sortants, donc le calcul du solde) sans utiliser de clé de dépense secrète$$$s$.

Divulgation de l'adresse du destinataire de l'audit

Tout comme le précédent, ce schéma cryptographique vous permet d'extraire les adresses des destinataires des sorties de transaction si le hachage secret de l'expéditeur est connu. $$$v_s$.

Cela se produit comme suit (Fig. 4.4.5).
Supposons qu'Alice soit décédée $$$v_s$ et $$$s H$Carol. Puis Carol:

1. Récupérer des clés secrètes $$$v$ et $$$a$, restaurera la liste d'adresses d'Alice.
2. Scannera la blockchain pour chaque sortie. $$$i$ chaque transaction déterminera s'il s'agit d'un paiement entrant, en essayant de trouver
   $$$S’ = H_s(Q_i — v P_i, h_t, i) P_i$
   parmi les adresses d'Alice.
3. S'il le trouve, Carol augmentera le solde de l'adresse correspondante et, avec $$$a$ et $$$v$, calcule l'image clé (voir ci-dessus) et l'enregistre localement.
4. Si l'image clé d'Alice est trouvée parmi les entrées de transaction, cela signifie que cette transaction est le paiement sortant d'Alice. Carol récupérera les adresses des destinataires pour toutes les sorties de cette transaction:
   $$$S = P_i H_s(H_p(h_t, v_s, i), h_t, i)$
   $$$V = (Q_i — H_p(h_t, v_s, i)) H_s(H_p(h_t, v_s, i), h_t, i)$
   et réduire le solde de l'adresse Alice correspondante de la valeur de la valeur d'entrée.

Ainsi, révélant une partie des données du compte, vous pouvez fournir à des tiers différents niveaux d'accès aux informations.

Pour générer une liste de vos adresses:
  •$$$A$
  • $$$V$
  • $$$s H$
  • $$$v (A + s H)$

Pour reconnaître uniquement les paiements entrants:
  •$$$A$
  • $$$v$
  • $$$s H$

Auditer, c'est-à-dire calculer le solde à vos adresses, sans divulguer les adresses des destinataires:
  •$$$a$
  • $$$v$
  • $$$s H$

Auditer, c'est-à-dire calculer le solde à vos adresses et divulguer les adresses des destinataires:
  •$$$v_s$
  • $$$s H$

4.5. Comparaison des signatures de transaction CryptoNote et Bytecoin Amethyst

Structures de données et tailles de signature

Comme indiqué ci-dessus, la mise en œuvre de la possibilité d'auditer les portefeuilles sans révéler de clé de dépense secrète a nécessité que les développeurs Bytecoin Amethyst augmentent la taille des données transmises dans chaque sortie de transaction: par rapport au protocole d'origine, une clé publique et 1 octet sont transférés pour identifier le type d'adresse. Total 33 octets par sortie.

Dans CryptoNote, chaque transaction est signée séparément pour une transaction. Pour chaque clé publique$$$P_i$ d'une sortie à laquelle se réfère cette entrée, une paire de scalaires est écrite dans la signature $$$(r,c)$taille totale de 64 octets. (Une entrée peut faire référence à plusieurs sorties, dont une seule est réelle, et les autres servent à anonymiser le transfert.)

Ainsi, si la transaction$$$N_{inputs}$ entrées, dont chacune fait référence à $$$N_{mixins}$ sorties, la taille totale de la signature en octets peut être exprimée comme suit:

$$$S = 32 * 2 * N_{mixins} * N_{inputs}$

La taille minimale de signature pour une transaction est de 64 octets (une entrée qui dépense directement une sortie).

Dans Bytecoin Amethyst, l'intégralité de la transaction est signée et la structure de données correspondante est compliquée (Fig. 4.5.1).
Pour chaque entrée de transaction, une période, deux scalaires et une autre $$$N_{mixins}$scalaires. Une autre signature est également ajoutée à la signature entière. Total, la taille totale de la signature en octets peut être exprimée comme suit:

$$$S = 32 * ((3 + N_{mixins}) * N_{inputs} + 1)$

La taille de signature minimale pour une transaction est de 160 octets (une entrée qui dépense directement une sortie).

On voit que les deux fonctions croissent proportionnellement au produit$$$N_{mixins} * N_{inputs}$

Pour comparer plus clairement la différence de taille des signatures de transaction, nous les calculons pour les valeurs les plus caractéristiques $$$N_{mixins}$ et $$$N_{inputs}$ et faites un tableau (Fig. 4.5.2).
Comme vous pouvez facilement le constater, dans une situation où il n'y a pas de mélange de résultats et où il y a un gaspillage direct de fonds ($$$N_{mixins} = 1$), ou lorsqu'une sortie est mélangée ($$$N_{mixins} = 2$), La taille de signature de Bytecoin est supérieure à CryptoNote jusqu'à 150%.

Lors du mixage de deux sorties ($$$N_{mixins} = 3$), les tailles des signatures dans l'un et l'autre schéma coïncident pratiquement.

Avec une nouvelle augmentation du nombre de sorties mixtes, la taille de la signature Bytecoin est plus petite.

Il est à noter que les développeurs Bytecoin avec la sortie de la version 3.4.0 Amethyst afin d'augmenter l'anonymat ont fixé le nombre minimum de sorties mixtes à 3 [ 10 ]. Dans de telles circonstances, la signature Bytecoin aura une taille plus petite.

La complexité de la vérification de signature

Outre la taille de la signature en anneau, qui affecte directement la taille de la blockchain, une autre caractéristique importante est la complexité de calcul de sa vérification. Il détermine des paramètres importants du système de crypto-monnaie comme, par exemple, la vitesse de synchronisation avec le réseau de nouveaux nœuds et la charge de calcul sur le réseau avec un grand flux de transactions.

La complexité de la vérification de signature pour CryptoNote et Bytecoin pourrait être facilement comparée pratiquement en écrivant simplement un test qui génère puis vérifie un grand nombre de signatures avec des données données.$$$N_{mixins}$ et $$$N_{inputs}$Cependant, puisque plus loin dans l'article, nous examinerons les schémas qui n'ont pas encore été mis en œuvre dans la pratique, mais seulement proposés en théorie, il sera logique de laborieux et d'évaluer ces schémas empiriquement, en fonction du nombre d'opérations cryptographiques utilisées.

CryptoNote et Bytecoin utilisent plusieurs primitives de base (voir la section 2). Dans le tableau de la fig. 4.5.3. l'exécution typique des primitives les plus couramment utilisées est donnée sur un ordinateur milieu de gamme moderne avec un processeur Core i5-6500 (à titre de comparaison, le code source d'origine compilé dans Microsoft Visual Studio 2017 avec toutes les optimisations de vitesse possibles a été utilisé).
Les résultats obtenus à partir des tests dans Bytecoin et CryptoNote sont en bon accord. Il est facile de voir que la plus grande contribution sera apportée par l'opération de multiplication du scalaire par un point et, dans une moindre mesure, par la procédure de calcul de la fonction de hachage$$$H_p$, tandis que les opérations d'ajout de deux points et de calcul d'une fonction de hachage $$$H_s$n'affectera pas de manière significative la complexité.

Considérez la procédure de vérification de la signature de l'anneau CryptoNote (Fig. 4.5.4, la procédure de génération de signature est discutée en détail dans [ 1 ] et ne sera pas considérée ici).
Comme déjà indiqué, dans CryptoNote, chaque entrée de transaction est signée séparément, respectivement, et chaque entrée est également vérifiée séparément. Par conséquent, le vérificateur pour chaque entrée de transaction vérifie la ligne correspondante (sur la figure) de la signature comme suit.

1. Pour chaque paire de valeurs $$$r_j$ et $$$c_j$ utilisant la saisie d'images clés $$$I$ et clé publique $$$P_j$ de la sortie suivante à laquelle se réfère cette entrée, les valeurs sont calculées:$$$L_j = r_j G + c_j P_j$
   $$$R_j = r_j H_p(P_j) + c_j I$
   (dans ce cas, l'index j va de 0 à $$$N_{mixins}$)
2. Le montant est calculé $$$c$ de tout $$$c_j$.
3. Le hachage est calculé $$$c`=H_s(tx\_prefix\_hash, L_0 ... L_n, R_0 ... R_n$)
   où tx_prefix_hashest le hachage de la partie préfixe de la transaction (sans signature).
4. Égalité vérifiée $$$c` = c$. Si c'est le cas, la signature de l'anneau est considérée comme valide.

Estimons le nombre d'opérations de multiplication scalaire par un point et des calculs de hachage $$$H_p$.

Chaque calcul$$$L_j$ et $$$R_j$nécessite deux multiplications scalaires. Nombre de paires$$$L_j, R_j$ correspond au nombre de sorties à mélanger $$$N_{mixins}$pour chaque entrée. Par conséquent, nous avons:

$$$O(*) = N_{inputs} * 4 * N_{mixins}$

Dans ce cas, la fonction de hachage $$$H_p$ utilisé une fois par calcul $$$R_j$, Par conséquent:

$$$O(H_p) = N_{inputs} * N_{mixins}$

Maintenant, considérons l'algorithme de vérification de la signature en anneau dans Bytecoin Amethyst (Fig. 4.5.5).
La signature entière est entièrement vérifiée, pour toutes les entrées à la fois. Cela se passe comme ceci:

1. Le hachage de préfixe de la transaction est écrit dans le tampon de hachage (sans signature).
2. Pour chaque entrée $$$i$ (ligne de signature sur la figure):
3. Calculé $$$H_s$ selon toutes les données du tampon de hachage et le résultat est comparé à la valeur $$$c_0$Une signature est considérée comme valable si l'égalité est respectée.

Estimons le nombre d'opérations de multiplication scalaire par un point et des calculs de hachage $$$H_p$.

Chaque calcul$$$Y_j$ et $$$Z_j$ nécessite deux multiplications scalaires, plus le calcul $$$X$nécessite trois multiplications scalaires. Nombre de paires$$$Y_j, Z_j$ correspond au nombre de sorties à mélanger $$$N_{mixins}$pour chaque entrée. Par conséquent, nous avons:

$$$O(*) = N_{inputs} * (3 + 4 * N_{mixins})$

Dans ce cas, la fonction de hachage $$$H_p$ utilisé une fois par calcul $$$Z_j$ et une fois pour le calcul $$$B$ pour chacune des entrées, donc:

$$$O(H_p) = N_{inputs} * (N_{mixins} + 1)$

Pour comparer visuellement la complexité de calcul des deux algorithmes sur des données standard, nous introduisons la métrique suivante. Ajouter le nombre d'opérations de multiplication scalaire et d'opérations de calcul$$$H_p$ avec des poids proportionnels au temps caractéristique mis pour effectuer ces opérations:

$$$O(total) = 130 * O(*) + 15 * O(H_p)$

Comparez ensuite les résultats relatifs pour CryptoNote et Bytecoin en pourcentage (Fig. 4.5.6).
Comme vous pouvez le voir, la vérification de signature Bytecoin est une opération beaucoup plus longue.

Cependant, comme indiqué ci-dessus, dans Bytecoin de la version 3.4.0 Amethyst, afin d'augmenter l'anonymat, le nombre minimum de sorties mixtes est fixé à 3 [ 10 ], donc la pire valeur pratique ne dépassera pas 25% (en théorie).

Résumer:

1. La taille de chaque sortie est augmentée par la clé publique $$$Q$ - 32 octets.
2. La taille de la signature en anneau varie par rapport à la taille de la signature CryptoNote en fonction du nombre de sorties mélangées (avec un grand nombre, il s'avère être moins):
   $$$S = 32 * ((3 + N_{mixins}) * N_{inputs} + 1)$
3. La complexité de calcul est plus élevée que dans CryptoNote et dépend considérablement du nombre de sorties à mélanger:
   $$$O(*) = N_{inputs} * (3 + 4 * N_{mixins})$
   $$$O(H_p) = N_{inputs} * (N_{mixins} + 1)$

5. Option 2/3. Études d'audit chez CryptoNote par Anton Sokolov

À l'automne 2019, une série d'essais [ 11 , 12 , 13 , 14 , 15 , 18 ] sur le problème d'audit dans CryptoNote et les moyens possibles de le résoudre rédigés par Anton Sokolov a été publiée sur Medium.com . Il envisage théoriquement plusieurs options pour modifier le protocole d'origine de manière à résoudre la tâche d'audit pour un tiers.

Nous considérons le dernier d'entre eux [ 15 ] comme le plus optimisé. Nous allons l'abréger en "AS".

Remarque: par souci de cohérence, les clés de dépenses continueront d'être indiquées par des lettres$$$s$ et $$$S$, afficher les clés en lettres $$$v$ et $$$V$, malgré le fait que dans les œuvres originales sont utilisées $$$b$, $$$B$ et $$$a$, $$$A$ respectivement.

Formation de sortie

Le compte portefeuille est représenté par un ensemble de trois clés secrètes, pas deux, comme dans CryptoNote $$$\{v, s, d\}$: clés d'affichage, de dépenses et d'audit, respectivement.

Une collection de trois clés publiques$$$\{V, S, D\}$représente l'adresse publique de ce compte.

Alice, en envoyant de l'argent au bean, agit comme suit (Fig. 5.1).

1. Bob publie son adresse, donc Alice connaît ses clés publiques $$$V$, $$$S$ et $$$D$.
2. Comme CryptoNote, Alice choisit une clé de transaction secrète aléatoire $$$r$ et calcule la clé publique $$$R = r G$qui écrit dans le domaine spécial des transactions supplémentaires.
3. Pour chaque sortie, Alice calcule non pas une, mais deux adresses furtives $$$P$ et $$$T$. Le premier est calculé de manière similaire à CryptoNote:
   $$$P = H_s(r V) G + S$
   Le second est différent:
   $$$T = H_s(r D) D$
   Le numéro de série de la sortie n'est pas utilisé dans le travail d'origine, cependant, il est raisonnable de supposer que cela est fait pour la simplification et dans la pratique, ce sera l'un des arguments de la fonction $$$H_s$ similaire à CryptoNote (voir section 3).
4. Alice signe et envoie la transaction.

Un observateur extérieur ne pourra pas se lier $$$P$ et $$$T$ avec l'adresse de Bob.

Reconnaissance des paiements entrants et formation des intrants

Pour accepter et dépenser de l'argent, Bob agit comme suit (Fig. 5.2).

1. Utilisation de votre clé de vue privée $$$v$Adresse de Bob Stealth $$$P$ compare chaque sortie à un point:
   $$$P’ = H_s(vR)G+S$
   (cette étape est similaire à CryptoNote)
2. Si l'égalité est remplie, cela signifie que cette sortie est adressée à Bob. Il augmente son équilibre de la valeur de la production nominale.
3. Si nécessaire, transférez les fonds reçus Carol, Bob, en utilisant leurs clés secrètes de dépenses et d'audit $$$s$ et $$$d$calcule deux images clés:$$$I$ et $$$\ddot I$. Le premier est similaire à CryptoNote:
   $$$I = x * H_p(P)$
   et facultatif:
   $$$t = H_s(dR)d$
   $$$\ddot I = t H_p(P)$
   Puis il les écrit, la valeur nominale et un lien vers la sortie correspondante dans l'entrée de sa transaction pour Carol.
4. Ensuite, Bob forme les sorties de transaction pour Carol, réduit son solde proportionnellement aux sorties dépensées, signe la transaction et envoie.

Comme vous pouvez le voir, ici, comme dans CryptoNote, le tiers - l'auditeur - ne possédant qu'une clé de vue secrète $$$v$, ne peut reconnaître que les transferts entrants.

Audit

Si l'auditeur possède également une clé d'audit secrète $$$d$, il pourra alors reconnaître les paiements sortants de Bob et calculer son solde comme suit:

1. Pour chaque paiement entrant, l'auditeur calculera et mémorisera une image clé supplémentaire $$$\ddot I$ en stockage local:
   $$$t = H_s(d R) d$
   $$$\ddot I = t H_p(P)$
   
2. Si dans les entrées de l'une des transactions de la chaîne de blocs, une image clé supplémentaire $$$Ï$Si elle coïncide avec l'une des sauvegardées, cela signifie que cette transaction est le paiement sortant de Bob. L'auditeur réduira le solde de la valeur nominale de l'entrée correspondante.

Ainsi, l'auditeur, ayant un jeu de clés $$$\{v, S, d\}$pourra reconnaître les transferts entrants et sortants de Bob sur la blockchain et rétablir son équilibre correct. Dans le même temps, l'auditeur ne sera pas en mesure de dépenser de l'argent, car sans clé de dépense secrète$$$s$ il ne pourra pas calculer l'image clé principale $$$I$.

Le problème est résolu.

Signature de bague

Appliquant les idées de [ 16 ], l'auteur a réussi à réduire la taille de la signature par rapport à CryptoNote: désormais, pour chaque entrée, seule la signature est stockée$$$N_{mixins} + 1$ scalaire (Fig. 5.3).
Ainsi, la taille de la signature est presque divisée par deux.

Considérez la complexité de calcul de sa vérification. Le schéma de vérification de signature est illustré à la Fig. 5.4.
Cet algorithme est très similaire dans sa structure à celui utilisé dans CryptoNote (voir Fig. 4.5.4). Le contrôle est effectué séparément pour chaque entrée et consiste à calculer séquentiellement les valeurs$$$u_j$, $$$L_j$, $$$R_j$, $$$c_j$pour toutes les sorties utilisées pour le mixage dans cette entrée. En conséquence, le cycle de$$$c_j$ devrait fermer et la valeur $$$c_{n+1}$ doit correspondre $$$c_0$, dans ce cas, la signature est considérée comme valide.

La complexité de calcul de l'algorithme est déterminée par six opérations de multiplication scalaire et un calcul de la fonction de hachage$$$H_p$ à l'itération, le nombre qui est le produit $$$N_{inputs} * N_{mixins}$.

Comparaison avec CryptoNote par les données et la charge de calcul

1. La taille de l'adresse augmente de 50%, car l'adresse représente désormais un ensemble de trois clés publiques:$$$\{V, S, D\}$pas deux $$$\{V, S\}$.
   La représentation codée de l'adresse augmentera à peu près de la même manière: par exemple, une adresse Zano standard contenant deux clés publiques prend 97 caractères:
   

   ZxD5UBX5PM3RTsEtTRd9ATUFxXyocoQzDRk3baVBahuWQJRK8QHTUT9GQM7jk7GoedK5B2nP4HxSPDpuLHvizpwj2q99bmz7t

   
   Une adresse Zano similaire contenant trois clés publiques aura une longueur d'environ 141 caractères:
   

   ZxD5UBX5PM3RTsEtTRd9ATUFxXyocoQzDRk3baVBahuWQJRK8QHTUT9GQM7jk7GoedK5B2nP4HxSPDpuLHvizpwjcenhnGbhpJFLk8vkhJywHCcht4d9EKA7CHHav1H6QPpB1cLsTvPfj

2. La taille de chaque sortie est augmentée d'une adresse furtive supplémentaire $$$T$ - 32 octets.
3. La taille de chaque entrée est augmentée d'une image clé supplémentaire $$$\ddot I$ - 32 octets.
4. La taille de la signature de l'anneau est plus petite que dans CryptoNote:
   $$$S = 32 * (N_{mixins} + 1) N_{inputs}$
5. La complexité informatique est plus élevée que dans CryptoNote:
   $$$O(*) = N_{inputs} * 6 * N_{mixins}$
   $$$O(H_p) = N_{inputs} * N_{mixins}$

6. Option 3/3. Audit via la limite de mixage de sortie

Envisagez une autre façon d'implémenter l'audit dans CryptoNote.

Attribut de sortie Mix_attr

Dans le projet Zano, qui succède à CryptoNote, la sortie de transaction a un attribut mix_attr 8 bits supplémentaire et une règle de noyau limitant l'utilisation des sorties dans le mixage, en fonction de sa valeur.

La structure des sorties de CryptoNote et Bytecoin (Fig. 4.2) peut maintenant être complétée de cette manière (Fig. 6.1.).
La règle du noyau limitant le mixage selon mix_attr est la suivante:

1. mix_attr = 0, . . — -.
2. mix_attr = 1, , , .
3. mix_attr ≥ 2, , mix_attr.

La principale caractéristique de cette innovation est le paragraphe 3, qui permet d'augmenter l'intraçabilité (non-traçabilité des obligations) en éliminant les situations où la production déjà utilisée dans le mélange est dépensée directement par son propriétaire (cela a été décrit en détail dans [ 19 ]).

Cependant, dans le contexte de cet article, nous nous intéresserons au point 2, c'est-à-dire une situation où mix_attr = 1 et la sortie marquée de cette manière ne peuvent être dépensés que directement. Cette limitation est illustrée sur la fig. 6.2.
Étant donné que la sortie # 2 a mix_attr = 1, elle ne peut pas être mélangée avec d'autres sorties, quelles que soient leurs valeurs d'attribut mix_attr. Il ne peut être dépensé que directement, en tant que sortie # 0.

Cette fonctionnalité peut être utilisée pour organiser un audit.

Audit avec mix_attr = 1

Comme indiqué dans la section 3, si, en vertu du protocole CryptoNote d'origine, l'auditeur Dan reçoit une clé secrète de Bob $$$v$, il pourra reconnaître les transactions entrantes, mais il ne pourra pas reconnaître les transactions sortantes, de sorte qu'un calcul précis du solde est impossible.

Néanmoins, étant donné que Den disposera d'informations complètes sur les sorties inutilisées de Bob (UTXO), il pourra suivre le fait qu'une transaction dans ses entrées se réfère à l'UTXO de Bob. Lors de l' utilisation du mélange d'autres sorties, Den ne sera pas en mesure de déterminer si cette transaction est dépense la production de Bob, qui est réalisé par l'utilisation d'une signature de l' anneau. Cependant, s'il n'y a pas de mixage et que l'UTXO de Bob est dépensé directement, l'auditeur Dan peut être sûr que cette transaction est le paiement sortant de Bob. Telle est l'idée de ce schéma.

Supposons qu'Alice envoie une transaction à Bob et que Bob souhaite que l'auditeur Dan voie le fait qu'Alice a reçu l'argent et qu'il l'a dépensé lorsque Bob a décidé de le dépenser.

Le schéma de travail se présente comme suit (Fig. 6.3).

1. Bob dit à Alice son discours public $$$(V, S)$, et lui demande également de définir l'attribut mix_attr sur 1 dans toutes les sorties qui lui sont adressées (nous verrons ci-dessous comment cela peut être implémenté techniquement).
2. Bob donne au vérificateur Dan sa clé de vue secrète $$$v$.
3. Alice envoie à Bob une transaction en utilisant le schéma CryptoNote habituel. Dans les sorties adressées à Bob, elle définit mix_attr = 1.
4. Dan scanne toutes les transactions sur la blockchain et, en utilisant la clé de vue secrète de Bob, vérifie chaque sortie $$$P_i \stackrel{?}{=} P’_i = H_s(v R, i) G + S$ (Où $$$i$ - numéro de série de la sortie, $$$S$- Clé de dépenses publiques de Bob). Si l'égalité est respectée, cette sortie est adressée à Bob.
   Den s'assure que mix_attr == 1, ajoute cette sortie à la liste et augmente le solde de la valeur de la sortie.
5. Dan vérifie également toutes les entrées de toutes les transactions, et si l'une des entrées fait référence à l'UTXO de Bob dans la liste, cela signifie que cette transaction est le paiement sortant de Bob. En raison de la restriction mix_attr = 1, l'entrée ne peut pas mélanger d'autres sorties, ce qui signifie qu'elle dépense directement la sortie de Bob, et Den peut être sûr qu'il s'agit du paiement sortant de Bob. Den réduit le solde de la valeur de l'entrée.

Ainsi, Den pourra calculer le solde correct du portefeuille de Bob sans avoir accès à sa clé de dépense secrète $$$s$.

Caractéristiques du circuit

Fonctionnalité 1. Il est important que la partie émettrice (Alice) définisse mix_attr sur 1 lors de l'envoi d'une transaction. Si Alice ne le fait pas, alors les fonds viendront à Bob, mais à l'avenir, Den ne pourra pas dire clairement si Bob les a dépensés ou non, car tout autre utilisateur pourra utiliser cette sortie pour le mixage.

Une solution consiste à introduire un type spécial d'adresse contenant les deux mêmes clés publiques$$$(V, S)$mais emballé d'une manière différente de la norme. Alice, en envoyant des fonds à une adresse de ce type, connaîtra la nécessité de définir mix_attr = 1 pour les sorties correspondantes.

Fonctionnalité 2. L'utilisation d'adresses d'un type spécial n'oblige pas Alice à définir la valeur d'attribut souhaitée pour les sorties. Elle peut envoyer des fonds sans faire cela, cependant, cela sera immédiatement révélé par Bob et l'auditeur Dan.

Caractéristique 3. Dans ce schéma, la capacité d'audit est obtenue au prix de la plus grande réduction de l'intraçabilité. Cela ne présente pas de problème particulier si l'opportunité d'audit est offerte à un nombre illimité de personnes. Par exemple, un fonds de bienfaisance peut publier une adresse de don ainsi qu'une clé de vue secrète, afin que n'importe qui puisse agir en tant qu'auditeur et calculer le solde actuel de son portefeuille. Il est important que, dans ce cas, l'anonymat des transferts entrants reste standard pour CryptoNote (un grand nombre de$$$N_{mixins}$) Cependant, l'anonymat des paiements sortants sera limité par l'incapacité de mélanger des sorties arbitraires.

Il convient de noter que dans le cas où l'opportunité d'audit est offerte à un cercle restreint de personnes, contrairement à l'exemple ci-dessus, une diminution de l'intracabilité peut être un effet indésirable.

Les grands avantages de cette option sont la facilité de mise en œuvre et l'absence de charge supplémentaire sur les calculs et les données.

7. Conclusion

Nous avons examiné trois options pour ajouter la possibilité de mener un audit au protocole CryptoNote: Bytecoin Amethyst, le schéma AS théorique d'Anton Sokolov et l'utilisation de mix_attr (noté MA).

Le changement relatif de la taille de la signature en anneau pour toutes les options sauf Bytecoin (BCN) est indépendant de$$$N_{inputs}$considérez donc $$$N_{inputs} = 1$ (minimum) et $$$N_{inputs} = 3$ (Fig. 7.1).
Remarque. $$$N_{inputs}$ - le nombre d'entrées dans la transaction, $$$N_{mixins}$- le nombre de sorties associées à chaque entrée de transaction. Si$$$N_{mixins} > 1$cela signifie que pour augmenter la traçabilité, chaque entrée fait référence à plusieurs sorties d'une autre transaction, et il est impossible d'établir laquelle est réelle.

Le meilleur résultat est indiqué par le circuit AS, ce qui donne une réduction de la taille de la signature en anneau dans une large gamme du nombre de sorties à mélanger ($$$N_{mixins}$) Bytecoin donne également de bons résultats lorsque$$$N_{mixins} \ge 3$ (comme déjà noté, une limite de nombre minimum a été introduite dans Bytecoin Amethyst pour augmenter l'intracabilité $$$N_{mixins}$égal à 3).

Le schéma MA n'offre aucune amélioration de la taille de la signature de l'anneau.

Comparons maintenant la lourdeur de la procédure de vérification de la signature en anneau. Pour ce faire, nous utiliserons la métrique mentionnée ci-dessus, à savoir, nous prenons la somme des opérations du produit scalaire et le calcul de la fonction de hachage$$$H_p$ avec des poids proportionnels à leur temps d'exécution sur un processeur moderne typique:

$$$O(total) = 130 * O(*) + 15 * O(H_p)$

Nous avons l'image suivante (Fig. 7.2).
Avec des dépenses directes de fonds ($$$N_{mixins} = 1$) Les schémas AS et Bytecoin nécessitent beaucoup plus de calculs pour vérifier la signature.

Lors du mixage des sorties ($$$N_{mixins} > 1$) Le schéma Bytecoin Amethyst semble préférable à AS, cependant, la dernière option MA considérée reste inégalée.

Résumons le résultat final en tenant compte de facteurs tels qu'une augmentation de la taille de l'adresse, des entrées et des sorties des transactions (Fig. 7.3).
Bytecoin maintient la longueur de l'adresse pratique pour l'utilisateur final, tandis que le schéma Anton Sokolov l'augmente de 50%. Cela n'affecte pas directement la taille de la chaîne de blocs (bien que l'adresse de l'expéditeur sous forme cryptée puisse être transmise dans des transactions supplémentaires si celui-ci le souhaite, par exemple) et la complexité de calcul, cependant, cela n'affecte pas de manière significative la convivialité. Dans le schéma MA, la taille de l'adresse reste égale à 64 octets; cependant, un moyen est nécessaire pour distinguer les adresses d'audit des adresses normales.

Les options d'audit pour Bytecoin et AS incluent l'ajout d'un point (32 octets) à chaque sortie de transaction, cependant, la taille d'entrée reste inchangée uniquement pour Bytecoin.

Il convient également de noter que le schéma Bytecoin Amethyst est implémenté dans le code depuis longtemps et, à en juger par le manque de messages sur les problèmes qui sont passés depuis sa mise en œuvre, il est bien testé dans la pratique. Cependant, il n'a pas été possible de trouver sa description publique sous une forme stricte, par conséquent, il n'existe aucune preuve formelle de son exactitude.

Le schéma AS, au contraire, est strictement décrit et proposé pour discussion dans la communauté cryptographique [ 17 ].

Le schéma d'AMM n'a pas de preuve formelle strictement décrite; cependant, en raison de son extrême simplicité, il semble inutile.

Littérature

1. Nicolas van Saberhagen, CryptoNote v 2.0
2. Annonce de Bytecoin sur le forum bitcointalk.org
3. Annonce Bitmonero sur bitcointalk.org
4. Dépôt Bitmonero sur Github
5. Bernstein et al. "Ed25519: signatures haute sécurité haute vitesse"
6. Patient zéro, « »
7. Shen Noether, «Understanding ge_fromfe_frombytes_vartime»
8. Shen Noether, MRL, «Ring confidential transactions»
9. , H Monero
10. Bytecoin blog — Auditable coins
11. Anton Sokolov, «Cryptonote auditability. How to append a wallet balance audit.»
12. Anton Sokolov, «Discussion for the auditable wallets Variant 1 and 2»
13. Anton Sokolov, «The unlinkable auditable Variant 3»
14. Anton Sokolov, «The auditable variant 4. Memory efficiency and security question.»
15. Anton Sokolov, «Multi-signature with LSAG. One more memory efficient approach to auditable wallets.»
16. Abe, Ohkubo, Suzuki, «1-out-of-n Signatures from a Variety of Keys» (AOS)
17. Anton Sokolov, «Cryptonote auditability and efficient scheme for anonymous key vector proof»
18. Anton Sokolov, «Approche pratique pour ajouter des portefeuilles vérifiables au Cryptonote»
19. "Boolberry résout les problèmes de CryptoNote"
20. «Description technique étendue de Bytecoin Amethyst Stable Release»