Les transactions Mimblewimble expliquées

• Aperçu de haut niveau
• Transactions expliquées
  • Transaction de base
  • Facteurs aveuglants
  • Alice prépare une transaction
  • Bob prépare sa réponse
  • Alice finalise et diffuse la transaction
• Vérification et propagation des transactions
• Mettre fin à la fraude
• récapitulatif des transactions
• Bibliographie
• Contributeurs

Aperçu de haut niveau

Mimblewimble est une technologie de crypto-monnaie axée sur la confidentialité. Il diffère du Bitcoin dans certains domaines clés :

• Aucune adresse. Le concept d’adresses Mimblewimble n’existe pas.
• Complètement privé. Chaque transaction est confidentielle.
• Blockchain compacte. Mimblewimble utilise un ensemble de garanties de sécurité différent de celui de Bitcoin, ce qui conduit à une blockchain beaucoup plus compacte.

Transactions expliquées

Opérations confidentielles [1] ont été inventés par le Dr Adam Back et sont utilisés dans plusieurs projets de crypto-monnaie, notamment Monero et Tari – via Mimblewimble.

Les destinataires de Tari créent les clés privées pour recevoir des pièces à la volée. Ils doivent donc être impliqués dans la construction d’une transaction Tari.

Cela ne signifie pas nécessairement que les destinataires doivent être en ligne. Cependant, ils doivent être capables de communiquer, que ce soit par courrier électronique, par messagerie instantanée (IM) ou par pigeon voyageur.

Transaction de base

Nous expliquerons comment Alice peut envoyer Tari à Bob en utilisant un protocole bipartite pour Mimblewimble. Les transactions multipartites sont similaires, mais le flux d'informations est un peu différent et s'effectue via des cycles de communication supplémentaires.

Disons qu'Alice a 300 µT et qu'elle souhaite envoyer 200 µT à Bob.

Voici la transaction de base :

Si nous écrivons cela sous la forme d'une équation mathématique, où les sorties sont positives et les entrées négatives, nous devrions être en mesure d'équilibrer les choses afin qu'il n'y ait pas de création de pièces à partir de rien :

$$ -300 + 200 + 90 + 10 = 0 ​$$

Il s’agit essentiellement des informations contenues dans la blockchain Bitcoin. N'importe qui peut auditer les transactions de quelqu'un d'autre simplement en inspectant l'historique des transactions du grand livre global. Ce n'est pas idéal pour la vie privée.

C'est ici qu'interviennent les transactions confidentielles. Nous pouvons commencer par multiplier les deux côtés de l'équation précédente par un point générateur H sur la courbe elliptique (pour une introduction aux mathématiques sur la courbe elliptique, reportez-vous à cette présentation):

$$ 300.H = 200.H + 90.H + 10.H ​$$

Depuis que H est une constante, le calcul ci-dessus est toujours valable, nous pouvons donc valider qu'Alice ne vole pas en vérifiant que

$$(3.H) - (2.H) - (1.H) - (fH) \equiv 0.H = 0 $$

Remarquez que nous voir uniquement les clés publiques et donc les valeurs sont cachées. Cool!

En bref, Oui. Nous n’avons donc pas encore terminé.

Facteurs aveuglants

Pour éviter qu'une attaque pré-image ne révèle toutes les valeurs des transactions Tari, nous devons ajouter du caractère aléatoire à chaque entrée et sortie. L'idée de base est de le faire en ajoutant une deuxième clé publique à chaque sortie de transaction.

Donc si on réécrit les entrées et sorties comme suit :

$$ C_i = n_i.H + k_i.G $$

De G est un autre générateur sur la même courbe, ceci complètement stores les entrées et sorties afin qu’aucune attaque pré-image ne soit possible. Cette formulation est appelée un L'engagement de Pedersen [3].

Alice prépare une transaction

Alice peut maintenant commencer à créer une transaction.

Les valeurs \( k_i \), \(k_1, k_2\) sont les clés de dépenses pour ces résultats.

Par conséquent, pour cette transaction, le portefeuille d'Alice, qui suit toutes ses sorties Tari non dépensées, aurait fourni le facteur aveuglant et la valeur « 300 » pour compléter l'engagement. C1.

Notez que lorsque toutes les entrées et sorties sont additionnées (y compris les frais), toutes les valeurs s'annulent à zéro, comme elles le devraient. Notez également que le seul terme restant est multiplié par le point G. Tous les H les termes ont disparu. Nous appelons cette somme la excès public pour la part d'Alice dans la transaction.

Nous définissons le excès de la transaction à réaliser

$$ x_s = k_2 - k_1 $$

Un moyen simple pour Alice de calculer son excédent (et comment le logiciel de portefeuille Tari le fait) consiste à additionner ses facteurs aveuglants de sortie et moins la somme de ses facteurs aveuglants d'entrée.

Disons qu'Alice essayait de créer de l'argent pour elle-même et effectuait le changement de 100 µT au lieu de 90. Dans ce cas, la somme des sorties et des entrées ne s'annulerait pas sur H et nous aurions

$$X^* = 10.H + x_s.G$$

Nous verrons dans un instant comment le protocole Mimblewimble surprend Alice si elle essaie de commettre des manigances comme celle-ci.

Alice choisit aussi un Nonce,

$$ r_a $$

et calcule le nonce public correspondant,

$$ R_a = r_a.G $$

Alice envoie ensuite les informations suivantes à Bob :

Les métadonnées du message sont des informations supplémentaires relatives à la transaction (par exemple, quand le résultat peut être dépensé).

Bob prépare sa réponse

Bob reçoit ces informations et entreprend ensuite de terminer sa part de la transaction.

Premièrement, il peut vérifier qu'Alice a envoyé la bonne information en vérifiant que l'excès public, X, est correct en suivant la même procédure qu'Alice a utilisée pour le calculer ci-dessus. Cette étape n’est pas strictement nécessaire, car il ne dispose pas à ce stade de suffisamment d’informations pour détecter une fraude.

Il construit alors un engagement du amount champ qu'Alice lui envoie :

$$ C_b = 200.H + k_b.G $$

où \(k_b\) est la clé de dépense privée de Bob. Il calcule

$$P_b = k_b.G$$

et génère une preuve de portée pour l'engagement.

Bob doit alors signer qu'il est heureux que tout soit terminé à sa satisfaction. Il crée un partiel Signature Schnorr avec le défi,

$$ e = H(R_a + R_b \Vert X + P_b \Vert f \Vert m) $$

et la signature est donnée par

$$ s_b = r_b + ek_b $$

Bob renvoie

Alice finalise et diffuse la transaction

Après avoir entendu Bob, Alice peut conclure.

Premièrement, elle peut désormais utiliser le nom occasionnel public et la clé publique de Bob pour calculer indépendamment le même défi que celui signé par Bob :

$$ e = H(R_a + R_b \Vert X + P_b \Vert f \Vert m) $$

Alice crée ensuite sa propre signature partielle,

$$ s_a = r_a + e.x_s $$

et la signature globale combinée, $$ s = s_a + s_b, R = R_a + R_b $$.

Alice peut désormais diffuser cette transaction sur le réseau. La transaction finale se présente comme suit :

Vérification et propagation des transactions

Lorsqu'un nœud complet reçoit la transaction d'Alice, il doit vérifier qu'il est au niveau avant de l'envoyer à ses pairs. Le nœud souhaite vérifier les éléments suivants :

1. Toutes les entrées proviennent de l'ensemble UTXO actuel

   Tous les nœuds complets gardent une trace de l'ensemble des sorties non dépensées, le nœud vérifiera donc que C1 est dans cette liste.

2. Toutes les sorties ont une preuve de plage valide

   La preuve de gamme est vérifiée par rapport à son engagement correspondant.

3. Les valeurs s'équilibrent

   Lors de cette vérification, le nœud veut s'assurer qu'aucune pièce n'est créée ou détruite lors de la transaction. Mais comment y parvenir si les valeurs sont aveuglées ?

   Rappelons que dans une transaction honnête, toutes les valeurs (qui sont multipliées par H) annulez, et vous vous retrouvez avec la somme des clés publiques des sorties moins les clés publiques des entrées. Ce n'est pas par hasard qu'il s'agit de la même valeur qui est stockée dans le noyau en tant qu'excédent public.

   Les occasions publiques résumées, R sont également stockés dans le noyau, ce qui permet au nœud de vérifier la signature en vérifiant ce qui suit, où le défi e est calculé comme précédemment :

$$ sG \stackrel{?}{=} R + e(X + P_b) $$

4. La signature dans le noyau est valide

   Ainsi, en validant la signature du noyau, nous nous prouvons également que la comptabilité des transactions est correcte.

5. Diverses autres vérifications de consensus

   Par exemple, si les frais sont supérieurs au minimum.

Si toutes ces vérifications réussissent, le nœud transmettra la transaction à ses pairs et elle sera finalement extraite et ajoutée à la blockchain.

Mettre fin à la fraude

Supposons maintenant qu'Alice ait essayé d'être sournoise et ait utilisé \( X^* \) comme excès ; celui où elle s'est donné 100 µT de changement au lieu de 90 µT. Désormais, les valeurs ne s'équilibreront plus. La somme des sorties, des entrées et des frais ressemblera à ceci :

$$ 10.H + (x_s + k_b).G ​$$

Alors maintenant, lorsqu'un nœud complet vérifie la signature :

$$ \begin{align} R + e(X^* + P_b) &\stackrel{?}{=} sG \\ R + e(10.H + x_s.G + P_b) &\stackrel{?}{ =} (r_a + r_b + e(x_s + k_b)).G \\ R + e(10.H + X + P_b) &\stackrel{?}{=} (r_a + r_b).G + e(x_s + k_b).G \\ \mathbf{10e.H} + R + e(X + P_b) &\stackrel{?}{=} R + e(X + P_b) \\ \end{align} $$

La signature ne vérifie pas ! Le nœud ne peut pas dire exactement ce qui ne va pas avec la transaction, mais il sait que quelque chose se passe, et il abandonnera donc simplement la transaction en silence et poursuivra sa vie.

récapitulatif des transactions

Pour résumer : une transaction Tari/MimbleWimble comprend les éléments suivants :

• À partir d'Alice, un ensemble d'entrées qui font référence et dépensent un ensemble de sorties précédentes.
• D'Alice et Bob, un ensemble de nouvelles sorties, notamment :
  • Une valeur et un facteur aveuglant (qui n'est qu'une nouvelle clé privée).
  • Une preuve de plage qui montre que la valeur n'est pas négative.
• Les frais de transaction, en texte clair,
• La démesure publique, qui est la somme de tous les facteurs aveuglants utilisés dans la transaction.
• Métadonnées des transactions.
• L'excès de valeur aveuglante utilisé comme clé privée pour signer un message attestant des métadonnées de la transaction, et l'excès public.

Bibliographie

[1] « Que sont les transactions confidentielles Bitcoin ? » [En ligne.] Disponible : https://www.mycryptopedia.com/what-are-confidential-transactions/ Date de consultation : 2019 04 09.

[2] "Nothing-Up-My_Sleeve Number" [en ligne].
Disponible: https://en.wikipedia.org/w/index.php?title=Nothing-up-my-sleeve_number&oldid=889582749. Date de consultation : 2019 04 09.

[3] Wikipédia : « Schéma d'engagement » [en ligne]. Disponible: https://en.wikipedia.org/wiki/Commitment_scheme. Date de consultation : 2019 04 09.

[4] "Kernel Offsets, dans Introduction à MimbleWimble et Grin" [en ligne]. Disponible: https://github.com/mimblewimble/grin/blob/master/doc/intro.md#kernel-offsets. Date de consultation : 2019 04 09.

[5] A. Gibson, « De zéro (connaissance) aux BulletProofs » [en ligne]. Disponible: https://joinmarket.me/static/FromZK2BPs_v1.pdf. Date de consultation : 2019‑04‑10.

Contributeurs

• https://github.com/CjS77
• https://github.com/anselld