La puissance des preuves à connaissance nulle : une innovation axée sur la confidentialité dans un monde décentralisé
TechFlow SélectionTechFlow Sélection
La puissance des preuves à connaissance nulle : une innovation axée sur la confidentialité dans un monde décentralisé
Nous n'avons vu qu'un infime aperçu du potentiel de la technologie ZK, dont les véritables capacités sont loin d'être pleinement exploitées.
Dédié à des analyses Web3 approfondiesRédaction : Salus
1. Introduction
La technologie du zero-knowledge proof (preuve à divulgation nulle de connaissance, ou ZK) peut résoudre les problèmes de confidentialité et de sécurité dans un monde décentralisé. Cet article illustre le rôle clé joué par la technologie ZK à travers quatre cas concrets : DEX, Oracle, vote et enchères. La technologie ZK permet de garantir que les transactions sur un DEX peuvent être vérifiées tout en protégeant la vie privée des utilisateurs, en masquant leur identité ou d'autres détails transactionnels. Grâce à la technologie ZK, il est possible d'assurer l'exactitude des données provenant des oracles, empêchant toute altération pendant la transmission ou le calcul. Dans les projets de vote sur blockchain, les électeurs éligibles peuvent voter de manière anonyme, tandis que les informations de vote sont protégées contre toute manipulation préalable – un problème que la technologie ZK est capable de résoudre. Cette même technologie peut également protéger l'anonymat des participants lors d'enchères blockchain, tout en évitant les offres frauduleuses.
2. Les risques liés à la confidentialité dans un monde décentralisé
La blockchain ne comporte aucun secret ; toutes les informations sont publiques, ce qui implique une faiblesse en matière de protection de la vie privée. En outre, bon nombre de contrats intelligents dépendent fortement de données hors chaîne, ce qui introduit des risques supplémentaires en termes de sécurité. Nous allons examiner en détail ci-dessous les problèmes de sécurité et les risques potentiels découlant de ces deux caractéristiques.
Problèmes de sécurité découlant de la transparence de la blockchain
La transparence de la blockchain assure la traçabilité des transactions, mais entraîne également des problèmes de sécurité. Par exemple, les risques de fuite de données personnelles et de transactions anticipées (front-running) dans le domaine DeFi.
Fuite de données personnelles : Des méthodes telles que le marquage des adresses, la correspondance des adresses IP aux transactions ou encore l'analyse des nœuds de diffusion permettent facilement d’associer une adresse blockchain à l'identité réelle d’un utilisateur. Ces techniques d’analyse peuvent non seulement révéler l’identité d’un utilisateur, mais aussi ses comportements, ses stratégies d’investissement, etc. Par exemple, les transactions fréquentes ou spécifiques d’une adresse peuvent indiquer les préférences ou habitudes d’investissement d’un utilisateur. Ces informations sont souvent exploitées abusivement pour obtenir un avantage concurrentiel.
Transactions anticipées (Front-running) : Un attaquant peut tirer parti de la transparence de la blockchain pour surveiller la file d’attente des transactions en attente de confirmation. En analysant ces transactions non encore confirmées, il peut proposer des frais plus élevés afin d’inciter les mineurs à prioriser son exécution. Ainsi, l’attaquant peut effectuer sa transaction avant les autres utilisateurs, profitant ainsi d’un avantage stratégique au détriment des autres. Ce type de comportement fausse l’équité du processus transactionnel et peut conduire à des manipulations de marché.
Par conséquent, la conception et la mise en œuvre des protocoles DeFi doivent tenir compte de ces menaces potentielles. Il convient d’envisager l’introduction de mesures supplémentaires de protection de la vie privée afin de protéger les utilisateurs contre les fuites de données et les analyses comportementales.
Risques de sécurité liés à l'accès aux données hors chaîne
Dans la blockchain, les contrats intelligents ne peuvent pas directement accéder aux données hors chaîne ; ils ne peuvent consulter que les données transactionnelles présentes sur la blockchain ou l’état d’autres contrats. Un contrat intelligent est un programme s’exécutant automatiquement sur la blockchain dont le résultat doit être cohérent sur tous les nœuds, c’est-à-dire que des entrées identiques doivent produire des résultats strictement identiques. Étant donné que les données hors chaîne peuvent varier, si un contrat intelligent y accède directement, différents nœuds pourraient aboutir à des résultats divergents lors de l’exécution du même contrat, compromettant ainsi la cohérence du système blockchain.
Toutefois, dans de nombreux cas, les contrats intelligents ont besoin de données externes. Par exemple, un DEX a besoin du prix le plus récent d'une action ou d'une cryptomonnaie. Ces données de prix proviennent généralement de marchés financiers ou d’autres bourses hors chaîne. Le système blockchain utilise généralement des oracles pour récupérer ces données externes. Lorsqu’un contrat intelligent nécessite des données hors chaîne, il peut envoyer une requête à un oracle, qui récupère alors les données et les renvoie au contrat. L’oracle peut également transférer certaines données de la chaîne vers l’extérieur.
Cependant, l'introduction d'oracles crée de nouveaux risques de sécurité : dans certains cas, un oracle peut fournir des données inexactes, volontairement ou par erreur. Par conséquent, la conception et la mise en œuvre des oracles doivent accorder une attention particulière à la sécurité.
Les projets blockchain impliquant des votes ou des enchères doivent également prendre des mesures spécifiques de protection de la sécurité. La technologie blockchain offre aux plateformes de vote transparence et immuabilité. Toutefois, cela soulève de nouveaux défis : identifier les électeurs éligibles, assurer l’anonymat du vote, et empêcher toute falsification préalable des résultats. Pour les enchères sur chaîne, les principaux problèmes sont les offres frauduleuses et la visibilité des comptes adverses. Si vous pouvez connaître les fonds disponibles de votre opposant, vous obtenez un avantage stratégique décisif.
3. Innovation pilotée par la confidentialité
3.1 ZK Private DEX
La transparence de la blockchain pose des défis importants en matière de confidentialité pour de nombreux projets DeFi. Face à ce défi, Salus prend ici l'exemple des DEX pour explorer le rôle crucial de la technologie ZK dans le renforcement de la protection de la vie privée.
Imaginons un DEX privé doté de fonctionnalités de protection de la vie privée. Grâce à la technologie ZK, il peut masquer certaines parties des informations transactionnelles tout en permettant de valider leur légitimité. Sur ce DEX, seules certaines informations sont publiques, comme la liste des utilisateurs inscrits, leurs comptes bancaires, ainsi que les actifs déposés ou retirés, avec leurs montants respectifs (voir Figure 1). Chaque utilisateur connaît l’intégralité de ses propres transactions, mais ne peut pas voir celles des autres. Illustrons ceci à travers cinq événements transactionnels spécifiques :
Figure 1 : DEX privé ne révélant que des informations partielles, source : https://arxiv.org/pdf/2309.01667.pdf
Supposons que cinq transactions ont lieu sur cette plateforme DEX privée, avec les événements suivants :
-
Alice dépose 1000 USD sur la plateforme.
-
Bob dépose 10 BTC sur la plateforme, lorsque le prix du BTC est de 1000 USD.
-
Alice effectue une transaction sur la plateforme, échangeant 800 USD contre 0,5 BTC, au moment où le prix du BTC atteint 1600 USD.
-
Alice retire 0,3 BTC de la plateforme, lorsque le prix du BTC est de 2000 USD.
-
La plateforme enregistre les dépenses totales et les revenus totaux d’Alice, respectivement 480 USD et 600 USD.
Cette plateforme DEX privée repose sur la technologie ZK pour assurer la confidentialité. Les informations complètes des transactions ne sont visibles que par les utilisateurs concernés. La plateforme n'affiche pas publiquement les détails complets des événements transactionnels, mais fournit plutôt des informations anonymisées. Précisons maintenant ce que signifient ces « informations confidentielles » et comment elles sont validées :
-
Lorsque Alice dépose 1000 USD, son compte bancaire affiche son identité. Elle reçoit ensuite un justificatif d’actif ou une signature générée par la plateforme. Pour éviter les doubles dépenses et respecter les exigences réglementaires, le message signé doit inclure des attributs supplémentaires allant au-delà des simples détails de l’actif. Ces attributs comprennent notamment un identifiant unique de l’actif, correspondant à l’identifiant utilisateur d’Alice. Ces informations doivent rester cachées pour préserver l’anonymat de l’utilisateur. Alice doit prouver, via la technologie ZK, que son identifiant utilisateur masqué (« blinded user identifier ») correspond bien à ses informations d’inscription (« registration credential »). Pour répondre aux obligations fiscales et de conformité client, les bénéfices réalisés sur la vente d’actifs et les retraits doivent être calculés. Cela nécessite d’inclure dans le justificatif d’actif le prix exact d’achat initial. C’est pourquoi nous intégrons ce prix d’achat comme attribut supplémentaire dans le justificatif.
-
Lorsque Bob dépose 10 BTC, la plateforme ne connaît pas son identité, car il ne s’agit pas d’un dépôt en monnaie fiduciaire.
-
Lorsqu’Alice échange 800 USD contre 0,5 BTC, elle utilise son justificatif de 1000 USD pour demander deux nouveaux justificatifs : l’un pour les 200 USD restants et l’autre pour 0,5 BTC, tout en gardant ses informations masquées. La plateforme approuve sa demande sous certaines conditions, notamment la preuve via ZK qu’elle dispose suffisamment de dollars, que les justificatifs partagent le même identifiant utilisateur, que le solde restant en dollars soit non négatif, que le prix du BTC corresponde au dernier justificatif disponible, et que la valeur totale de la transaction soit équivalente.
-
Lors du retrait de 0,3 BTC, le mécanisme est similaire à une opération de trading, à l’exception du type d’actif échangé. Alice valide également sur la blockchain le reçu de retrait des BTC.
-
Lorsque les dépenses totales s’élèvent à 480 et les revenus à 600, Alice présente un justificatif d’inscription valide contenant son identité, puis demande un nouveau justificatif d’inscription mis à jour avec un nouvel index, remettant les valeurs de dépense et de revenu à zéro, et obtenant un document justificatif destiné aux autorités réglementaires. Ce document contient l’identité réelle d’Alice, les chiffres corrects (dépense : 480, revenu : 600), ainsi que des informations auxiliaires utiles à la régulation. Comme les montants de dépense et de revenu sont masqués par la plateforme pour éviter les fuites d’informations, Alice doit prouver que les valeurs engagées correspondent à celles figurant dans son justificatif d’inscription. La plateforme procède alors à une signature aveugle (« sign blindly »). Alice démasque ensuite la signature et soumet le couple message-signature aux autorités pour la déclaration fiscale.
3.2 zkOracle
Supposons l’existence d’un contrat intelligent d’assurance agricole basé sur la blockchain, qui décide de verser une indemnisation aux agriculteurs assurés selon les données météorologiques fournies par un oracle. Par exemple, si une région subit une sécheresse grave, les agriculteurs de cette zone peuvent recevoir une compensation via ce contrat.
Cependant, si l’oracle communique incorrectement les conditions météorologiques — par exemple, s’il indique une pluviométrie normale alors que la région souffre en réalité d’une sécheresse extrême — cette information erronée conduira le contrat intelligent à une mauvaise décision, refusant ainsi des indemnisations à des agriculteurs véritablement touchés.
Cet exemple montre clairement combien il est crucial de garantir l’exactitude des données fournies par les oracles. zkOracle est un oracle sécurisé et sans confiance, basé sur la technologie ZK. Nous allons maintenant expliquer les différences principales entre les oracles traditionnels et zkOracle, et préciser pourquoi la technologie ZK joue un rôle essentiel.
Les oracles traditionnels peuvent être divisés en trois catégories différentes. Nous allons les comparer selon quatre dimensions :
Dans cet article, nous nous concentrons sur les oracles de type Output Oracle et I/O Oracle. Les données de ces deux types proviennent de la blockchain, ce qui signifie qu’elles ont déjà été validées et protégées par celle-ci. Nous mettons l’accent sur la question suivante : comment garantir la sécurité des calculs et du transfert des données ?
Pour créer un oracle sécurisé, nous pouvons appliquer une transformation ZK aux output oracle et I/O oracle, créant ainsi des output zkOracle et I/O zkOracle. La section suivante compare les flux de travail des oracles traditionnels, des output zkOracle et des I/O zkOracle, et explique en quoi ces derniers ont été modifiés grâce à la technologie ZK.
1. Oracle traditionnel
Le flux de travail d’un oracle traditionnel est illustré à la Figure 2 :
Étape ① : Récupération des données depuis la source
Étape ② : Calcul des données dans le module « computation »
Étape ③ : Diffusion du résultat du calcul
Figure 2 : Oracle traditionnel
La technologie ZK peut être appliquée aux étapes ② et ③ du flux de travail d’un oracle traditionnel, tandis que l’étape ① reste inchangée :
2. Output zkOracle
Transformation ZK étape ② : Calcul et génération de la preuve ZK
Le module « computation » utilise la technologie ZK pour traiter les données provenant de la source — typiquement tri, agrégation, filtrage — et génère une preuve ZK comme résultat. Cela rend le calcul et la sortie vérifiables.
Transformation ZK étape ③ : Vérification de la preuve ZK
La preuve ZK générée à l’étape ② peut être vérifiée dans un contrat intelligent ou tout autre environnement. Cette vérification permet de confirmer la validité du calcul réalisé à l’étape ②.
Figure 3 : Output zkOracle
3. I/O zkOracle
Transformation ZK étape ② : Calcul et génération de la preuve ZK
Le module de calcul de l’I/O zkOracle comprend à la fois un output zkOracle et un input zkOracle. Comparé à l’output zkOracle, l’I/O zkOracle ajoute une couche de calcul supplémentaire : l’input zkOracle consiste à utiliser le résultat du calcul hors chaîne comme calldata pour invoquer un contrat intelligent. Cette combinaison permet d’automatiser des opérations complexes sur chaîne grâce à des calculs sophistiqués hors chaîne.
Transformation ZK étape ③ : Vérification de la preuve ZK
La sortie du calcul à l’étape ② comprend des données sur chaîne (comme calldata pour appeler le contrat) et une preuve ZK vérifiable. Cette preuve peut être vérifiée dans un contrat intelligent ou tout autre environnement, permettant de confirmer la validité du calcul.
Figure 4 : I/O zkOracle
3.3 Vote anonyme
Dans un scrutin blockchain, toutes les informations sont publiques, ce qui expose potentiellement les données personnelles des votants à des attaquants. Les projets de vote sur blockchain font face à deux grands défis :
-
Confidentialité de l’identité du votant : garantir l’anonymat en utilisant une identité cachée.
-
Vérifiabilité du résultat : empêcher la falsification des votes, en concevant un mécanisme permettant de vérifier l’authenticité des résultats.
Sur une plateforme de vote blockchain, concilier protection de l’anonymat et vérifiabilité des résultats constitue un défi délicat à gérer. La technologie ZK permet d’atteindre efficacement cet équilibre.
Dans les projets devote anonyme sur blockchain, on combine technologie ZK et arbre de Merkle pour permettre le vote anonyme et sa vérification. Le processus de vote se décompose en trois phases principales :
1. Génération d'une identité anonyme via hachage et signature
Avant de voter, chaque électeur doit vérifier son éligibilité et son identité réelle. Une fois validé, il reçoit une identité anonyme (« anonymous identity ») dissociée de son identité réelle. Il pourra alors voter sous cette identité anonyme, protégeant ainsi ses données personnelles.
2. Vérification de l’identité anonyme via ZK et arbre de Merkle
Avant de pouvoir voter, un électeur doit faire vérifier son identité anonyme.
Unarbre de Merkleest utilisé pour stocker les identités anonymes de tous les électeurs, garantissant ainsi l’intégrité et l’immutabilité des données.
Les engagements d’identité anonyme des électeurs sont placés comme feuilles de l’arbre. Un circuit de vérification basé sur l’arbre de Merkle est utilisé pour authentifier les votants. Trois éléments sont nécessaires pour la vérification :
-
L’engagement d’identité du votant courant (« input target node »).
-
Le nœud racine (« root node ») de l’arbre de Merkle.
-
L’indice de chemin (« path index ») entre le nœud cible et la racine. Cet indice représente la position du nœud dans l’arbre (gauche = 0, droite = 1).
Pendant la reconstruction du nœud racine à partir du nœud cible et de l’indice de chemin, les engagements d’identité générés à partir des nœuds frères et des données utilisateur servent à confirmer l’identité. Pour garantir l’unicité du vote, on utilise comme preuve un identifiant haché combiné à un identifiant externe.
3. Vote et vérification
Cette phase se divise en six étapes, illustrées à la Figure 5 :
-
Calcul du problème : insertion de l’identité anonyme du votant dans l’arbre de Merkle, puis vérification.
-
Transformation équivalente : conversion du problème en circuit ZK de bas niveau (low-order circuit), puis en système de contraintes de rang 1 (R1CS), puis en programme arithmétique quadratique (QAP), dans le but de générer les clés de preuve et de vérification.
-
Génération des paramètres publics : pour assurer la sécurité du système ZK, une configuration de confiance est nécessaire afin de générer la chaîne publique utilisée pour produire et vérifier les preuves.
-
Génération de la preuve ZK : un circuit ZK permet de générer une preuve pour chaque votant. Pour cela, les informations d’identité anonyme et de vote sont utilisées comme entrées du circuit. Cette étape s’effectue généralement hors chaîne. La preuve ZK générée est ensuite envoyée sur la blockchain.
-
Vérification de la preuve ZK : sur chaîne, la preuve est vérifiée, c’est-à-dire que la validité du vote est confirmée — autrement dit, on vérifie si le vote satisfait les contraintes du circuit. Si la vérification réussit, le résultat est 1 ; sinon, 0.
-
Contrat de vote (« Voting contract ») : le contrat de vote utilise le contrat de vérification déployé et la clé de vérification pour valider les résultats. Pendant l’interaction utilisateur-contrat, la génération et la vérification des preuves reposent sur le circuit ZK, protégeant ainsi efficacement l’identité du votant.
Figure 5 : Processus de vérification du vote
Grâce à ce mécanisme, il devient possible de mettre en œuvre un projet de vote anonyme sur blockchain.
3.4 Enchères privées
Les enchères blockchain publiques présentent un inconvénient majeur. Puisque toutes les transactions sont publiques, n’importe qui peut observer les offres et la situation financière des participants. Si un enchérisseur connaît l’offre d’un autre, ou pire, s’il découvre son identité, il peut exploiter les informations publiques de la blockchain pour connaître les fonds disponibles sur ce compte. Il pourra alors ajuster stratégiquement son offre pour remporter l’enchère. Les enchères blockchain publiques sont donc confrontées à des risques d’exposition de l’identité et des fonds. Les enchères privées permettent d’éviter ces pratiques injustes.
Dans une enchère privée, les participants peuvent soumettre leurs offres sans révéler leur identité ni leurs fonds disponibles. Pour y parvenir, deux défis majeurs doivent être relevés :
-
Protection de l’identité de l’acheteur : l’identité du compte acheteur doit rester confidentielle, car sa révélation trahirait ses fonds disponibles pour l’enchère.
-
Protection des intérêts du vendeur : l’enchère doit empêcher tout participant malveillant de soumettre une offre supérieure à ses fonds réellement disponibles.
La technologie ZK permet de protéger l’anonymat des enchérisseurs tout en vérifiant qu’ils disposent bien des fonds nécessaires pour honorer leur offre.
Dans une enchère privée, chaque participant a besoin de deux adresses de compte :
-
Compte de mise publique (« Public staking account ») : utilisé pour transférer à l’avance les frais d’entrée à l’enchère.
-
Compte privé (« Private account ») : détient les fonds réels que l’enchérisseur utilisera pour payer le prix s’il remporte l’enchère.
Ces deux adresses sont totalement indépendantes ; personne ne peut relier le compte de mise à l’offre maximale du compte privé.
Le processus d’une enchère privée est le suivant :
1. Vérification de l’adresse du compte et des fonds disponibles via ZK
Chaque enchérisseur pré-soumet le hachage de son adresse de compte et celui de ses fonds disponibles dans un arbre de Merkle. La technologie ZK permet de vérifier qu’il possède bien ces données, c’est-à-dire que les originaux des hachages correspondent effectivement à l’adresse et aux fonds.
2. Vérification des comptes pour éviter les surenchères artificielles
Avant de soumettre une offre, le contrat d’enchère privée peut vérifier le compte du précédent enchérisseur. Pour éviter qu’un même utilisateur surenchérisse lui-même, le nouvel enchérisseur ne doit pas être le même que le précédent. Bien que cette règle ne puisse pas empêcher totalement une personne de contrôler deux comptes de mise et deux comptes privés, il faut noter que posséder deux comptes divise les fonds disponibles dans chacun. Cela réduit davantage les chances de remporter l’enchère, car une fois les fonds engagés dans l’arbre de Merkle, ils ne peuvent plus être transférés vers le compte privé.
3. Vérification via ZK que les fonds disponibles sont supérieurs à l’offre
On utilise un circuit comparateur (« comparator circuit ») pour vérifier que les fonds disponibles sont supérieurs ou égaux à l’offre, en validant notamment :
-
La comparaison entre les fonds disponibles et le montant offert. Si le circuit ZK retourne « vrai », l’offre est valide ; sinon, elle est rejetée.
-
Des vérifications intermédiaires sont intégrées pour empêcher toute falsification du fichier témoin (« witness file »).
-
On vérifie que les hachages de l’adresse et des fonds sont bien présents dans l’arbre de Merkle.
Grâce à ce mécanisme, il devient possible de mettre en œuvre un projet d’enchères privées sur blockchain.
4. Conclusion
Nous ne pouvons ignorer les défis de sécurité aux
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@salus_sec
