Introduction
Le terme « zero knowledge » (connaissance nulle) est devenu super courant dans le monde de la blockchain, surtout quand on parle des ZK-rollups. En fait, l'idée de la connaissance nulle existait déjà bien avant la blockchain, avec des recherches de base publiées en 1989.
Cette enquête explore la vraie signification de la connaissance zéro, regarde si les ZK-rollups ont vraiment des caractéristiques de connaissance zéro et explore le lien entre cette technologie et la confidentialité.
Comprendre les principes de la connaissance zéro
La technologie zéro connaissance est apparue bien avant la création de la première blockchain. L'article révolutionnaire « The knowledge complexity of interactive proof systems » (La complexité des connaissances des systèmes de preuve interactifs) a présenté ces idées en 1989, bien avant que la communauté Ethereum ne reconnaisse l'importance de ZK pour les solutions de rollup vers 2018.
Pour bien comprendre le concept de « zero knowledge », il faut savoir distinguer les différents types de preuves et leurs caractéristiques uniques.
Le concept de « zero knowledge » (connaissance nulle) est une caractéristique des systèmes de preuve. Dans les discussions sur la blockchain, on parle souvent des ZKPs, ou preuves à connaissance nulle, mais ce terme peut désigner à la fois la preuve de déclaration et la preuve de connaissance, chacune ayant des fonctions et des caractéristiques uniques.
Vérifier si ce qu'on dit est vrai ou si on a bien compris
La preuve d'une affirmation montre que l'affirmation est valide sans donner de détails sur l'affirmation elle-même. Les exemples incluent :
- •montrer qu'un nombre est un carré modulo n
- •ces deux graphes ne sont pas isomorphes
- •qu'un grand nombre a exactement trois facteurs premiers
La preuve de connaissance, par contre, montre que la personne qui fait une affirmation a des connaissances particulières sur le sujet. En utilisant des exemples analogues, ça voudrait dire :
- •montrer que tu sais que z est égal à x au carré modulo n pour une valeur x donnée
- •Comprendre l'isomorphisme entre deux graphes
- •avoir les éléments réels d'un nombre important
Chaque démonstration de connaissances sert intrinsèquement à démontrer une affirmation, mais l'inverse n'est pas vrai. Lorsqu'une personne démontre sa connaissance d'une valeur x qui satisfait une relation mathématique, cela confirme intrinsèquement l'existence de cette relation, fusionnant les deux formes de preuve en une seule illustration.
L'isomorphisme des graphes comme exemple concret
Le problème de l'isomorphisme des graphes illustre parfaitement ces idées. Deux graphes sont isomorphes s'ils sont fondamentalement identiques, à l'exception du réarrangement de leurs étiquettes. Une fonction bijective doit être établie entre les sommets afin que les arêtes soient présentes entre les sommets d'un graphe si et seulement si les arêtes correspondantes sont présentes dans l'autre graphe.
Pour prouver l'affirmation par le biais du non-isomorphisme des graphes, la procédure consiste à sélectionner au hasard une permutation et l'un des deux graphes, puis à calculer une variante permutée. Si les graphes étaient véritablement isomorphes, il serait impossible d'identifier le graphe d'origine, ce qui réduirait la précision à un simple hasard avec une probabilité de 50 %.
Pour prouver ses connaissances par le biais de l'isomorphisme de graphes, le vérificateur montre l'isomorphisme entre deux graphes. Le protocole utilise des permutations aléatoires et des défis pour confirmer ces connaissances sans dévoiler l'isomorphisme réel, ce qui permet de préserver la confidentialité tout en démontrant ses capacités.
Toute preuve de connaissance est aussi une preuve d'affirmation, mais pas l'inverse.
L'attribut à connaissance nulle
La connaissance zéro, c'est quand un vérificateur ne peut pas avoir plus d'infos d'un prouveur que ce qui est déjà dans la preuve. Dans le cas de l'isomorphisme de graphes, la preuve de connaissance garde les attributs de connaissance zéro avec des vérificateurs honnêtes, car le prouveur ne donne que des engagements sans dévoiler les détails de l'isomorphisme ou de la permutation.
Mais bon, les preuves de non-isomorphisme des graphes n'ont pas d'attributs à connaissance nulle, car les vérificateurs adversaires peuvent avoir des infos supplémentaires en ne respectant pas le protocole. Ils pourraient présenter des graphes au hasard et trouver des liens avec les graphes d'origine en suivant le protocole.
Pour transformer des preuves non zéro-connaissance en preuves zéro-connaissance, il suffit que les vérificateurs montrent qu'ils respectent les règles du protocole. La plupart des protocoles pratiques garantissent surtout une preuve zéro-connaissance honnête, ce qui est suffisant pour les applications non interactives grâce à des méthodes comme l'heuristique Fiat-Shamir.
Les ZK-Rollups et leurs vraies caractéristiques
Les ZK-rollups fonctionnent comme le problème de non-isomorphisme des graphes, en vérifiant les affirmations sur les transitions d'état valides au lieu de montrer des connaissances. Ces systèmes effectuent des transactions hors chaîne et fournissent des preuves aux réseaux de couche 1 comme Ethereum, confirmant que les calculs hors chaîne ont été faits correctement.
Les vérificateurs doivent pouvoir accéder à :
- •épreuves
- •nouveaux états
- •états antérieurs
- •valeurs saisies
Cette clarté va à l'encontre des vraies caractéristiques de la connaissance zéro.
Entrées publiques vs privées
Les rollups ZK font la différence entre les entrées publiques et privées, même si « privé » ici ne veut pas dire confidentiel. Les entrées privées sont utilisées uniquement par les prouveurs pour générer des preuves, tandis que les entrées publiques sont utilisées à la fois par les prouveurs et les vérificateurs.
Les contributions publiques doivent être envoyées à la couche 1, ce qui coûte cher et oblige à être bref.
Les contributions publiques comprennent généralement :
- •indiquez les racines
- •signatures
- •adresses
- •paramètres de fonction
- •infos sur le contrat
- •Modifications du stockage
- •événements déclenchés
Ça montre des détails importants aux gens qui regardent. Les infos privées comprennent les preuves d'adhésion Merkle et les traces d'exécution nécessaires pour vérifier que tout est correct.
La structure rollup demande que les vérificateurs connaissent les états précédents et les valeurs d'entrée pour créer des preuves de validité.
Types d'entrée dans les ZK-Rollups
| Type de saisie | Utilisé par | Contient | Coût |
|---|---|---|---|
| Public | Vérificateurs et validateurs | Indique les racines, les signatures et les adresses. | Élevé (envoyé à L1) |
| Privé | Prouveurs uniquement | Preuves Merkle, traces d'exécution | Faible (reste hors chaîne) |
La vérité sur la confidentialité dans les ZK-Rollups
Les rollups ZK standard n'offrent aucune garantie de confidentialité. Quand Alice envoie un ETH à Bob via un rollup ZK, les détails de la transaction sont visibles à la fois par le prouveur et le vérificateur.
Le système montre que les transactions sont valides comme preuve de déclaration sans attributs à connaissance nulle, car toutes les données restent accessibles ou disponibles publiquement.
Ces systèmes mettent l'accent sur l'évolutivité via une vérification rapide plutôt que sur la protection de la vie privée.
Marketing vs réalité
Le label « ZK » dans les rollups ZK sert surtout pour le marketing et ne veut pas dire qu'il y a vraiment des fonctionnalités à connaissance nulle.
Confidentialité authentique grâce à la vérification côté client
Une vraie confidentialité demande différentes méthodes architecturales, comme on le voit dans les systèmes qui gèrent les données privées sur les appareils des utilisateurs avant de créer des preuves à envoyer au réseau. Cette génération de preuves côté client permet de faire de vraies preuves à connaissance nulle des déclarations, ce qui aide les opérateurs de réseau à vérifier la validité des preuves sans avoir besoin d'accéder aux détails de l'exécution.
Les systèmes axés sur la confidentialité gèrent les transactions en toute discrétion sur les appareils des utilisateurs, générant des résultats qui masquent les effets secondaires tels que les hachages de notes et les annulateurs. Ces composants fusionnent dans l'état global tout en préservant la confidentialité des informations, qui ne sont divulguées qu'aux personnes impliquées dans la transaction et aux destinataires désignés.
Ces systèmes créent des preuves à connaissance nulle côté client pour les actions confidentielles, générant ensuite des preuves de blocs similaires aux rollups traditionnels pour l'accord réseau. Cette méthode à deux niveaux permet à la fois la confidentialité et l'évolutivité.
Créer la confidentialité dès le départ
La confidentialité ne peut pas être ajoutée aux systèmes transparents actuels. Les rollups axés sur la confidentialité doivent intégrer ces facteurs dès le départ, ce qui nécessite :
- •clarifiez les définitions relatives à la confidentialité
- •Formulez vos déclarations avec soin pour éviter toute fuite d'informations involontaire.
Des systèmes de confidentialité sophistiqués devraient gérer un état hybride public-privé, permettant aux applications de conserver certains composants privés tout en rendant d'autres publics pour l'engagement externe. Cette complexité facilite les applications avancées telles que :
- •Gestion programmable des identités
- •options privées DeFi
Ces systèmes représentent des avancées architecturales majeures plutôt que des améliorations progressives des réseaux transparents actuels.
L'environnement actuel a un nombre limité de solutions de couche 2 authentiques axées sur la confidentialité qui permettent un traitement côté client pour une vraie protection de la vie privée.
Utilisations pratiques et tendances à venir
Les réseaux qui protègent la vie privée offrent des opportunités incroyables pour la confidentialité financière et l'implication des institutions. Les utilisateurs peuvent :
- •Utilise les protocoles DeFi tout en gardant tes stratégies confidentielles.
- •Contribuez aux causes de manière anonyme.
- •participe à la gouvernance par le biais d'un vote privé
- •Montre que c'est légitime sans être trop transparent.
Le développement de ponts inter-chaînes relie les réseaux privés aux écosystèmes actuels, ce qui permet un accès privé à des pools de liquidités et à des applications bien établis. Au lieu de désagréger la liquidité, ces ponts améliorent l'infrastructure financière existante avec des couches de confidentialité.
L'avenir de la DeFi privée
Le passage à la DeFi privée marque un changement important dans les priorités de l'architecture blockchain. Les utilisateurs n'ont plus à choisir entre la confidentialité et l'accès aux protocoles établis ; ils bénéficient désormais de la confidentialité comme fonctionnalité optionnelle pour toute application, ce qui leur permet de conserver l'accès à la liquidité et aux communautés actuelles tout en protégeant leurs données sensibles.
Cette avancée technologique demande une attention particulière aux points suivants :
- •détails de mise en œuvre
- •conception de l'expérience utilisateur
- •Respectez les normes réglementaires tout en gardant les protections essentielles de la vie privée.
Ces considérations rendent ces systèmes avantageux tant pour les utilisateurs individuels que pour les organisations.
