Accueil
Articles
L’amĂ©lioration de la transparence des cryptomonnaies grĂące Ă  la preuve zero-knowledge

L’amĂ©lioration de la transparence des cryptomonnaies grĂące Ă  la preuve zero-knowledge

Intermédiaire
Publié le Feb 10, 2023Mis à jour le Jan 5, 2024
10m

Résumé

Une Preuve Zero-Knowledge permet Ă  une partie (un vĂ©rificateur) de dĂ©terminer la validitĂ© d’une affirmation donnĂ©e par une autre partie (le prouveur), sans avoir connaissance du contenu de l’affirmation. Binance peut par exemple vouloir prouver l’adossement de l’intĂ©gralitĂ© des fonds de ses utilisateurs et utilisatrices Ă  des rĂ©serves, sans avoir Ă  rĂ©vĂ©ler les soldes individuels de ceux-ci.

Une « Preuve de RĂ©serves » pourrait ĂȘtre construite avec un arbre de Merkle qui empĂȘche la falsification de ses donnĂ©es internes. Dans ce cas, les soldes nets totaux des clients, qui sont les passifs de l’exchange vis-Ă -vis de ses utilisateurs. Cela peut ensuite ĂȘtre combinĂ© avec une zk-SNARK (un protocole de Preuves Zero-Knowledge) qui assure aux utilisateurs qu’ils peuvent vĂ©rifier que leur solde fait bien partie du solde total net des actifs des utilisateurs, sans connaĂźtre les soldes des autres utilisateurs.

Introduction

Au vu des rĂ©cents Ă©vĂšnements du marchĂ©, la sĂ©curitĂ© des crypto-actifs en garde (custody) est devenue un sujet critique. Les utilisateurs de la blockchain apprĂ©cient la transparence et l’ouverture, mais sont Ă©galement des dĂ©fenseurs de la confidentialitĂ© et de la vie privĂ©e. Cela crĂ©e un dilemme lors de l’apport de preuves des rĂ©serves dĂ©tenus par les dĂ©positaires (custodians). Il existe d’ailleurs souvent un compromis entre transparence, confiance et confidentialitĂ© des donnĂ©es.

Mais, cela n’a pas besoin d’ĂȘtre le cas. En combinant des protocoles de Preuves Zero-Knowledge comme les zk-SNARKs avec les arbres de Merkle, nous pouvons trouver une solution rĂ©pondant aux attentes de toutes les parties.

Qu’est-ce qu’une Preuve Zero-Knowledge ?

Une Preuve Zero-Knowledge permet Ă  une partie (un vĂ©rificateur) de dĂ©terminer la validitĂ© d’une affirmation faite par une autre partie (le prouveur), sans avoir connaissance du contenu de l’affirmation. Prenons un exemple simple.

Vous avez un coffre-fort verrouillĂ© dont vous ĂȘtes le seul Ă  connaĂźtre la combinaison. Ce coffre-fort ne peut pas ĂȘtre crochetĂ©, forcĂ© ou ouvert d’une autre maniĂšre qu’en connaissant sa combinaison. Ce fait est Ă©galement Ă©tabli, vĂ©rifiĂ© et connu de votre ami participant Ă  l’expĂ©rience.

Vous affirmez Ă  votre ami que vous connaissez la combinaison, mais vous ne voulez pas la divulguer ou ouvrir le coffre en sa prĂ©sence. Sur le dessus du coffre se trouve un trou dans lequel votre ami peut glisser une note. Pour en faire une Preuve Zero-Knowledge, votre ami ne devrait pas avoir d’information supplĂ©mentaire sur le processus et devra se contenter de votre dĂ©claration.

Vous pouvez prouver à votre ami que vous connaissez la combinaison en ouvrant le coffre, puis en lui disant ce qui était écrit sur la note, avant de le refermer. Bien évidemment, vous ne révÚlerez pas la combinaison.

Pour un exemple plus avancĂ©, consultez notre article Qu’est-ce qu’une Preuve Zero-Knowledge et quel effet a-t-elle sur la blockchain ?.

Pourquoi utilisons-nous des Preuves Zero-Knowledge ?

Les Preuves Zero-Knowledge sont parfaites pour prouver quelque chose sans rĂ©vĂ©ler d’informations ou de dĂ©tails sensibles. Cela pourrait convenir Ă  vos besoins si vous ne voulez pas divulguer vos informations financiĂšres ou personnelles, afin d’éviter qu’elles ne soient utilisĂ©es de maniĂšre inappropriĂ©e.

Dans le monde de la crypto, vous pourriez prouver que vous possĂ©dez une clĂ© privĂ©e sans la rĂ©vĂ©ler, ou sans devoir signer numĂ©riquement quelque chose. Un exchange de cryptomonnaie peut Ă©galement vouloir prouver l’état de ses rĂ©serves sans rĂ©vĂ©ler d’informations confidentielles sur ses utilisateurs, y compris le solde individuel de leurs comptes. 

Dans ces exemples (et dans beaucoup d’autres), une Preuve Zero-Knowledge utiliserait des algorithmes qui prennent des donnĂ©es en entrĂ©e et renvoient « vrai » ou « faux » en sortie. 

DĂ©finition des Preuves Zero-Knowledge en termes techniques

Une Preuve Zero-Knowledge, en termes techniques, suit une structure utilisant des critÚres précis. Nous avons déjà examiné les rÎles du prouveur et du vérificateur, mais une Preuve Zero-Knowledge doit également satisfaire trois autres critÚres :

  1. ComplĂ©tude. Si l’affirmation est vraie, un vĂ©rificateur sera convaincu par la preuve fournie, sans besoin d’autres informations ou d’autres vĂ©rifications.

  2. FiabilitĂ©. Si l’affirmation est fausse, un vĂ©rificateur ne sera pas convaincu de sa vĂ©racitĂ© par la preuve fournie.

  3. Zero-knowledge (sans connaissance). Si l’affirmation est vraie, le vĂ©rificateur n’apprend aucune information, hormis que l’affirmation est vraie.

Qu’est-ce qu’une Zk-Snarks ?

Une Zk-Snarks (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) est un protocole de preuve qui suit les principes de divulgation nulle de connaissance prĂ©cĂ©demment Ă©noncĂ©s. Avec une zk-SNARK, vous pourriez prouver que vous connaissez la valeur hachĂ©e originale (discutĂ©e plus bas) sans devoir la rĂ©vĂ©ler. Vous pouvez Ă©galement prouver la validitĂ© d’une transaction sans rĂ©vĂ©ler d’informations sur les montants, les valeurs ou les adresses concernĂ©s.

Les zk-SNARKs sont couramment utilisĂ©es et discutĂ©es dans le monde de la blockchain et des cryptomonnaies. Vous vous demandez peut-ĂȘtre pourquoi quelqu’un se donnerait la peine d’utiliser une zk-SNARK lorsqu’il pourrait utiliser une simple mĂ©thode de paire de clĂ©s publique/privĂ©e pour sĂ©curiser l’information. Avec cette paire de clĂ©s, nous ne serions pas en mesure de mettre en Ɠuvre la preuve mathĂ©matique garantissant qu’aucun solde nĂ©gatif n’est inclus dans la somme de l’arbre de Merkle. 

Dans le cas des rĂ©serves d’une plateforme d’exchange, nous voulons prouver un ratio 1 : 1 des soldes des clients, sans que les identifiants et les soldes des comptes de ceux-ci ne soient rendus publics. De plus, la technologie zk-SNARK rend encore moins probable la falsification des donnĂ©es.

Qu’est-ce qu’un arbre de Merkle ?

PrĂ©senter la somme des fonds des comptes des utilisateurs de Binance nĂ©cessite de travailler avec un grand nombre de donnĂ©es. Une façon de prĂ©senter cette grande quantitĂ© de donnĂ©es de maniĂšre cryptographique est d’utiliser un arbre de Merkle. Une grande quantitĂ© d’informations peut ĂȘtre stockĂ©e efficacement Ă  l’intĂ©rieur de celui-ci et sa nature cryptographique rend son intĂ©gritĂ© facilement vĂ©rifiable.

Fonctions de hachage

Pour encoder succinctement une entrĂ©e, un arbre de Merkle utilise des fonctions de hachage. Pour faire simple, le hachage est le processus de gĂ©nĂ©ration d’une sortie de taille fixe Ă  partir d’une entrĂ©e de taille variable. En d’autres termes, lorsqu’une entrĂ©e de n’importe quelle longueur est hachĂ©e par un algorithme, elle produira une sortie chiffrĂ©e de longueur fixe.

Tant que l’entrĂ©e reste la mĂȘme, la sortie le sera aussi. Cela signifie que nous pouvons prendre d’énormes quantitĂ©s de donnĂ©es transactionnelles et les hacher en une sortie plus facile Ă  gĂ©rer. La sortie sera radicalement diffĂ©rente si une information est modifiĂ©e dans l’entrĂ©e.

Nous pourrions par exemple prendre le contenu de 100 livres et les entrer dans la fonction de hachage SHA-256. Celle-ci fournirait alors quelque chose comme ceci en sortie :

801a9be154c78caa032a37b4a4f0747f1e1addb397b64fa8581d749d704c12ea

Si nous modifions ne serait-ce qu’un seul caractĂšre de l’entrĂ©e (ces 100 livres), le hachage sera complĂštement diffĂ©rent :

abc5d230121d93a93a25bf7cf54ab71e8617114ccb57385a87ff12872bfda410

Cette propriĂ©tĂ© importante des fonctions de hachage permet une vĂ©rification facile de l’exactitude des donnĂ©es. Si quelqu’un reproduit le processus de hachage de ces mĂȘmes 100 livres en utilisant l’algorithme SHA-256, il obtiendra exactement le mĂȘme hachage en sortie. Si la sortie est diffĂ©rente, nous pouvons affirmer avec certitude que l’entrĂ©e a Ă©tĂ© modifiĂ©e. Cela signifie qu’il n’est pas nĂ©cessaire de vĂ©rifier individuellement ou manuellement les diffĂ©rences entre les entrĂ©es, ce qui peut ĂȘtre laborieux.

Les arbres de Merkle dans le monde des cryptomonnaies

Lors de la sauvegarde des donnĂ©es de transaction sur une blockchain, chaque nouvelle transaction est soumise Ă  travers une fonction de hachage, qui gĂ©nĂšre des valeurs de hachage uniques. Imaginez que nous ayons huit transactions (de A Ă  H) que nous hachons individuellement pour obtenir leurs sorties hachĂ©es. Ce sont ce que nous appelons les nƓuds feuilles de Merkle. Dans l’image ci-dessous, vous pouvez voir la valeur de hachage unique de chaque lettre : hA pour A, hB pour B, hC pour C, etc.

Nous pouvons ensuite prendre des paires de sorties hachĂ©es, les combiner et obtenir une nouvelle sortie hachĂ©e. Les hachages de hA et hB hachĂ©s ensemble, nous donneraient par exemple une nouvelle sortie hachĂ©e de hAB connue sous le nom de branche de Merkle. Veuillez remarquer qu’à chaque fois qu’une nouvelle sortie est gĂ©nĂ©rĂ©e, celle-ci dispose d’une une longueur et d’une taille fixe, qui dĂ©pend de la fonction de hachage utilisĂ©e.

Maintenant, nous avons les données de deux transactions (ex : A et B) combinées en un seul hachage (hAB). Veuillez remarquer que si nous changeons une quelconque information de A ou B et répétons le processus, notre sortie hachée hAB serait complÚtement différente.

Le processus continue alors que nous combinons de nouvelles paires de hachages pour les hacher Ă  nouveau (voir l’image ci-dessous). Nous hachons hAB avec hCD pour obtenir un hachage unique hABCD et faisons de mĂȘme avec hEF et hGH pour obtenir hEFGH. À la fin, nous recevons un seul hachage reprĂ©sentant les sorties hachĂ©es de tous les hachages des transactions prĂ©cĂ©dentes. En d’autres termes, la sortie hachĂ©e hABCDEFGH reprĂ©sente toutes les informations qui l’ont prĂ©cĂ©dĂ©e.

Le graphe affichĂ© ci-dessus est appelĂ© un arbre de Merkle. La sortie hachĂ©e hABCDEFGH est la racine de Merkle. Nous utilisons les racines de Merkle dans les en-tĂȘtes de blocs, car elles rĂ©sument succinctement cryptographiquement toutes les donnĂ©es de transaction dans un bloc. Nous pouvons Ă©galement vĂ©rifier rapidement si des donnĂ©es ont Ă©tĂ© falsifiĂ©es ou modifiĂ©es Ă  l’intĂ©rieur du bloc.

Les Limites des Arbres de Merkle

Revenons Ă  notre exemple de rĂ©serves d’un CEX. Un CEX veut prouver l’adossement 1 : 1 de tous les actifs de ses clients et construit un arbre de Merkle qui hache ensemble les UID de ses clients avec leurs avoirs nets en actifs (compensant les actifs et les passifs) au niveau d’un token. Une fois publiĂ© (et signĂ© pour prouver la propriĂ©tĂ© de la racine de Merkle fournie), un utilisateur individuel ne pourrait pas vĂ©rifier si l’arbre de Merkle est valide sans accĂ©der Ă  toutes ses entrĂ©es.

Un exchange aurait pu manquer d’inclure certaines entrĂ©es. Il pourrait Ă©galement crĂ©er de faux comptes avec des soldes nĂ©gatifs pour modifier le passif total. Par exemple, bien que les actifs des clients puissent totaliser 1 000 000 $, un faux compte pourrait ĂȘtre ajoutĂ© avec un solde de - 500 000 $. Cela crĂ©erait une cible de rĂ©serves de seulement 500 000 $.

Le cas de la preuve de rĂ©serves est diffĂ©rent de celui de la racine de Merkle d’un bloc, car les utilisateurs peuvent voir toutes les transactions qu’un bloc contient sur un explorateur de blockchain. Cependant, un CEX ne voudra pas divulguer chaque solde de compte pour des raisons de sĂ©curitĂ© et de confidentialitĂ© des donnĂ©es. Les clients ne seraient pas non plus heureux que le solde de leur compte soit rendu public. Dans ce cas, le CEX ne peut pas prouver que le total des soldes des utilisateurs est correct, sans rendre visibles les soldes des autres utilisateurs.

Une solution que les exchanges pourraient envisager d’employer consiste Ă  avoir recours un auditeur tiers de confiance. L’auditeur peut vĂ©rifier les comptes individuels et les rĂ©serves avant de certifier la validitĂ© de la racine de Merkle fournie. Cependant, pour les utilisateurs, cette mĂ©thode nĂ©cessite de faire confiance Ă  l’auditeur et aux donnĂ©es utilisĂ©es pour l’audit. Vous n’avez pas besoin de faire confiance Ă  un tiers lorsque vous pouvez faire confiance aux donnĂ©es.

Combinaison des zk-SNARKs avec les arbres de Merkle

Le problĂšme mentionnĂ© prĂ©cĂ©demment est un cas parfait pour l’utilisation des zk-SNARKs. Nous voulons prouver que les rĂ©serves couvrent entiĂšrement les passifs des utilisateurs et qu’elles ne sont pas falsifiĂ©es. Cependant, pour des raisons de confidentialitĂ© et de sĂ©curitĂ©, nous ne voulons pas montrer au vĂ©rificateur la composition exacte des soldes et des rĂ©serves des utilisateurs. 

En utilisant une zk-SNARK, un exchange de cryptomonnaie peut prouver que tous les ensembles de soldes des nƓuds feuilles de l’arbre de Merkle (c’est-Ă -dire, les soldes des comptes utilisateurs) contribuent au total du solde d’actifs des utilisateurs revendiquĂ© par l’exchange. Chaque utilisateur peut facilement accĂ©der Ă  son nƓud feuille, celui-ci ayant Ă©tĂ© inclus dans le processus. Le zk-SNARK garantit Ă©galement qu’aucun arbre de Merkle gĂ©nĂ©rĂ© ne contient d’utilisateurs avec un solde net total d’actifs nĂ©gatif (ce qui impliquerait une falsification des donnĂ©es, car tous les prĂȘts sont sur-collatĂ©ralisĂ©s). Nous utilisons Ă©galement un calcul de l’état global de Binance, c’est-Ă -dire, une liste du solde net total de chaque actif dĂ©tenu par chaque client de Binance.

Examinons comment Binance aborde la situation. Pour commencer, Binance dĂ©finit les contraintes du calcul qu’il souhaite prouver et les dĂ©finit comme un circuit programmable. Voici l’ensemble des trois contraintes que Binance utilise dans son modĂšle. 

Pour chaque ensemble de soldes d’utilisateur (nƓud feuille de l’arbre de Merkle), notre circuit assure que :

  1. Les soldes d’actifs d’un utilisateur sont inclus dans le calcul de la somme des soldes nets totaux des utilisateurs de Binance.

  2. Le solde net total de l’utilisateur est supĂ©rieur ou Ă©gal Ă  zĂ©ro.

  3. Le changement de la racine de l’arbre de Merkle est valide (c’est-Ă -dire, n’utilise pas d’informations falsifiĂ©es) aprĂšs la mise Ă  jour des informations d’un utilisateur vers le hachage du nƓud feuille.

Binance peut ensuite gĂ©nĂ©rer une preuve zk-SNARK pour la construction de l’arbre de Merkle selon le circuit. Cela implique que l’exchange exĂ©cute le calcul lourd du hachage des identifiants et des soldes des utilisateurs, tout en s’assurant que la preuve respecte les contraintes.

Un vĂ©rificateur examinera la preuve (et son code source publiĂ© publiquement) pour ĂȘtre convaincu que le calcul est exĂ©cutĂ© avec toutes les contraintes respectĂ©es. Le calcul de vĂ©rification prend un temps extrĂȘmement court comparĂ© au temps de preuve.

À chaque publication de la Preuve de RĂ©serves, l’exchange publiera :

1. La preuve de Merkle pour chaque utilisateur.

2. La preuve zk-SNARK et l’entrĂ©e publique (un hachage de la liste du solde net total de chaque actif et de la racine de Merkle) du circuit pour tous les utilisateurs.

Les parties intĂ©ressĂ©es peuvent vĂ©rifier la preuve de Merkle, en s’assurant que leurs soldes individuels ont contribuĂ© Ă  la racine de l’arbre de Merkle. Elles peuvent Ă©galement vĂ©rifier la preuve zk-SNARK pour s’assurer que la construction de l’arbre de Merkle rĂ©pond aux contraintes dĂ©finies dans le circuit. Pour une explication plus dĂ©taillĂ©e de la solution zk-SNARK et de ses performances, consultez notre blog Comment les zk-SNARK amĂ©liorent-elles le systĂšme de preuve de rĂ©serves de Binance ?

Conclusion

Les zk-SNARK fournissent la technologie nĂ©cessaire pour assurer Ă  la fois l’intĂ©gritĂ© des donnĂ©es et la confidentialitĂ© en mĂȘme temps. Son application pour prouver les rĂ©serves et augmenter la transparence des CEX devrait aider Ă  renforcer la confiance dans l’industrie de la blockchain. Pour beaucoup, un dĂ©veloppement comme celui-ci a Ă©tĂ© longuement attendu et arrive Ă  un moment crucial pour les CEX.

Il s’agit de la premiĂšre version de notre zk-SNARK et nous avons hĂąte de recevoir les avis de la communautĂ© afin de pouvoir continuer Ă  amĂ©liorer notre systĂšme.

Plus d’informations