Un protocole à divulgation nulle est une méthode par laquelle une partie (le prouveur) peut prouver à une autre partie (le vérificateur) que quelque chose est vrai, sans révéler aucune information autre que le fait que cette déclaration spécifique est vraie.

Les preuves de zéro connaissance ont progressé au fil des ans et sont maintenant utilisées dans plusieurs applications du monde réel.

Pourquoi avons-nous besoin de preuves de zéro-connaissance?

Les preuves de connaissance nulle ont représenté une percée en cryptographie appliquée, car elles promettaient d'améliorer la sécurité de l'information pour les individus. Considérez comment vous pourriez prouver une revendication (par exemple, "Je suis citoyen du pays X") à une autre partie (par exemple, un fournisseur de services). Vous auriez besoin de fournir une "preuve" pour étayer votre revendication, telle qu'un passeport national ou un permis de conduire.

Mais il y a des problèmes avec cette approche, principalement le manque de confidentialité. Les informations personnellement identifiables (PII) partagées avec des services tiers sont stockées dans des bases de données centrales, qui sont vulnérables aux piratages. Avec le vol d'identité devenant un problème critique, des appels sont lancés en faveur de moyens plus protecteurs de la vie privée pour partager des informations sensibles.

Les preuves de zéro-connaissance résolvent ce problème en éliminant le besoin de révéler des informations pour prouver la validité des revendications. Le protocole de zéro-connaissance utilise l'énoncé (appelé un 'témoin') comme entrée pour générer une preuve succincte de sa validité. Cette preuve fournit des garanties solides qu'un énoncé est vrai sans exposer les informations utilisées pour le créer.

Revenons à notre exemple précédent, la seule preuve dont vous avez besoin pour prouver votre revendication de citoyenneté est une preuve de connaissance nulle. Le vérificateur n'a qu'à vérifier si certaines propriétés de la preuve sont vraies pour être convaincu que l'affirmation sous-jacente est également vraie.

Comment fonctionnent les preuves de connaissance nulle ?

Une preuve de connaissance nulle vous permet de prouver la vérité d'une déclaration sans partager le contenu de la déclaration ou révéler comment vous avez découvert la vérité. Pour rendre cela possible, les protocoles de connaissance nulle s'appuient sur des algorithmes qui prennent certaines données en entrée et renvoient 'vrai' ou 'faux' en sortie.

Un protocole de zéro-connaissance doit satisfaire les critères suivants :

1. Complétude: Si l'entrée est valide, le protocole de preuve à divulgation nulle renvoie toujours 'true'. Ainsi, si l'énoncé sous-jacent est vrai et que le prouveur et le vérificateur agissent honnêtement, la preuve peut être acceptée.
2. Solidité : Si l'entrée est invalide, il est théoriquement impossible de tromper le protocole de preuve de zéro-connaissance pour renvoyer 'vrai'. Ainsi, un prouveur menteur ne peut pas tromper un vérificateur honnête en lui faisant croire qu'une déclaration invalide est valide (sauf avec une marge de probabilité minime).
3. Zéro-connaissance : Le vérificateur n'apprend rien sur une déclaration au-delà de sa validité ou de sa fausseté (il a "zéro connaissance" de la déclaration). Cette exigence empêche également le vérificateur de déduire l'entrée d'origine (le contenu de la déclaration) de la preuve.

Dans sa forme de base, une preuve de zero-knowledge est composée de trois éléments : témoin, défi et réponse.

• Témoin : Avec une preuve de connaissance nulle, le prouveur souhaite prouver la connaissance de certaines informations cachées. Les informations secrètes sont le "témoin" de la preuve, et la connaissance présumée du témoin par le prouveur établit un ensemble de questions qui ne peuvent être répondues que par une partie ayant connaissance des informations. Ainsi, le prouveur commence le processus de preuve en choisissant aléatoirement une question, en calculant la réponse, et en l'envoyant au vérificateur.
• Défi : Le vérificateur choisit au hasard une autre question de l'ensemble et demande au prouveur d'y répondre.
• Réponse: Le prouveur accepte la question, calcule la réponse et la renvoie au vérificateur. La réponse du prouveur permet au vérificateur de vérifier si ce dernier a réellement accès au témoin. Pour s'assurer que le prouveur ne devine pas à l'aveuglette et n'obtient pas les bonnes réponses par hasard, le vérificateur pose plus de questions à poser. En répétant cette interaction de nombreuses fois, la possibilité pour le prouveur de simuler une connaissance du témoin diminue considérablement jusqu'à ce que le vérificateur soit satisfait.

Ce qui précède décrit la structure d'une 'preuve de connaissance zéro interactive'. Les premiers protocoles de connaissance zéro utilisaient une preuve interactive, où vérifier la validité d'une déclaration nécessitait une communication aller-retour entre les prouveurs et les vérificateurs.

Un bon exemple qui illustre comment fonctionnent les preuves interactives est le célèbre Jean-Jacques Quisquater.Histoire de la caverne d'Ali Baba

(opens in a new tab)

. Dans l'histoire, Peggy (le prover) veut prouver à Victor (le vérificateur) qu'elle connaît la phrase secrète pour ouvrir une porte magique sans révéler la phrase.

Preuves de connaissance nulle non interactives

Bien que révolutionnaire, la preuve interactive avait une utilité limitée car elle nécessitait que les deux parties soient disponibles et interagissent à plusieurs reprises. Même si un vérificateur était convaincu de l'honnêteté d'un prouveur, la preuve serait inaccessible pour une vérification indépendante (le calcul d'une nouvelle preuve nécessitait un nouvel ensemble de messages entre le prouveur et le vérificateur).

Pour résoudre ce problème, Manuel Blum, Paul Feldman et Silvio Micali ont proposé le premier preuves de connaissance nulle non interactives

(s'ouvre dans un nouvel onglet)

où le prouveur et le vérificateur ont une clé partagée. Cela permet au prouveur de démontrer sa connaissance de certaines informations (c'est-à-dire, le témoin) sans fournir les informations elles-mêmes.

Contrairement aux preuves interactives, les preuves non interactives ne nécessitent qu'un seul tour de communication entre les participants (le prouveur et le vérificateur). Le prouveur transmet les informations secrètes à un algorithme spécial pour calculer une preuve de zéro-connaissance. Cette preuve est envoyée au vérificateur, qui vérifie que le prouveur connaît les informations secrètes à l'aide d'un autre algorithme.

La preuve non interactive réduit la communication entre le prouveur et le vérificateur, rendant les preuves ZK plus efficaces. De plus, une fois qu'une preuve est générée, elle est disponible pour toute autre personne (avec accès à la clé partagée et à l'algorithme de vérification) pour vérification.

Les preuves non interactives ont représenté une avancée majeure pour la technologie de la connaissance nulle et ont stimulé le développement des systèmes de preuve utilisés aujourd'hui. Nous discutons ci-dessous de ces types de preuves :

Types de preuves de connaissances nulles

ZK-SNARKs

ZK-SNARK est un acronyme pour Zero-Knowledge Succinct Non-Interactive Argument of Knowledge. Le protocole ZK-SNARK a les qualités suivantes :

• Zéro-connaissance : Un vérificateur peut valider l'intégrité d'une déclaration sans rien savoir d'autre sur la déclaration. La seule connaissance que le vérificateur a de la déclaration est si elle est vraie ou fausse.
• Succinct: La preuve de connaissance nulle est plus petite que le témoin et peut être vérifiée rapidement.
• Non interactif : La preuve est « non interactive » car le prouveur et le vérificateur n'interagissent qu'une seule fois, contrairement aux preuves interactives qui nécessitent plusieurs rounds de communication.
• Argument : La preuve satisfait l'exigence de 'sonorité', donc tricher est extrêmement improbable.
• (De) Connaissance: La preuve de connaissance nulle ne peut être construite sans accès aux informations secrètes (témoin). Il est difficile, voire impossible, pour un prouveur qui n'a pas le témoin de calculer une preuve de connaissance nulle valide.

La « clé partagée » mentionnée précédemment fait référence aux paramètres publics sur lesquels le prouveur et le vérificateur conviennent d'utiliser pour générer et vérifier les preuves. Générer les paramètres publics (connus collectivement sous le nom de chaîne de référence commune (CRS)) est une opération délicate en raison de son importance dans la sécurité du protocole. Si l'entropie (aléatoire) utilisée pour générer le CRS tombe entre les mains d'un prouveur malhonnête, il peut calculer de fausses preuves.

Calcul multipartite (MPC)

(s'ouvre dans un nouvel onglet)

est un moyen de réduire les risques liés à la génération de paramètres publics. Plusieurs parties participent à un cérémonie de configuration de confiance

(s'ouvre dans un nouvel onglet)

, où chaque personne contribue à des valeurs aléatoires pour générer le CRS. Tant qu'une partie honnête détruit sa part d'entropie, le protocole ZK-SNARK conserve la validité computationnelle.

Les installations de confiance nécessitent que les utilisateurs fassent confiance aux participants à la génération de paramètres. Cependant, le développement des ZK-STARKs a permis de mettre en place des protocoles de preuve qui fonctionnent avec une configuration non fiable.

ZK-STARKs

ZK-STARK est un acronyme pour Zero-Knowledge Scalable Transparent Argument of Knowledge. Les ZK-STARKs sont similaires aux ZK-SNARKs, sauf qu'ils sont :

• Évolutif : ZK-STARK est plus rapide que ZK-SNARK pour générer et vérifier des preuves lorsque la taille du témoin est plus grande. Avec les preuves STARK, les temps de prouvé et de vérification augmentent seulement légèrement à mesure que le témoin augmente (les temps de prouvé et de vérification SNARK augmentent linéairement avec la taille du témoin).
• Transparent : ZK-STARK s'appuie sur une aléatoire vérifiable publiquement pour générer des paramètres publics pour la preuve et la vérification au lieu d'une configuration de confiance. Ainsi, ils sont plus transparents par rapport aux ZK-SNARKs.

Les ZK-STARK produisent des preuves plus grandes que les ZK-SNARK, ce qui signifie qu'ils ont généralement des frais de vérification plus élevés. Cependant, il existe des cas (comme prouver de grands ensembles de données) où les ZK-STARK peuvent être plus rentables que les ZK-SNARK.

Cas d'utilisation des preuves de connaissance nulle

Paiements anonymes

Les paiements par carte de crédit sont souvent visibles pour plusieurs parties, y compris le fournisseur de paiement, les banques et d'autres parties intéressées (par exemple, les autorités gouvernementales). Bien que la surveillance financière présente des avantages pour identifier les activités illégales, elle compromet également la vie privée des citoyens ordinaires.

Les cryptomonnaies ont été conçues pour offrir aux utilisateurs un moyen de mener des transactions privées de pair à pair. Mais la plupart des transactions de cryptomonnaie sont ouvertement visibles sur les blockchains publiques. Les identités des utilisateurs sont souvent pseudonymes et peuvent être intentionnellement liées à des identités du monde réel (par exemple, en incluant des adresses ETH sur les profils Twitter ou GitHub) ou peuvent être associées à des identités du monde réel en utilisant des analyses de données de base sur et hors chaîne.

Il existe des "privacy coins" spécifiques conçues pour des transactions complètement anonymes. Les blockchains axées sur la confidentialité, telles que Zcash et Monero, protègent les détails des transactions, y compris les adresses de l'expéditeur/du destinataire, le type d'actif, la quantité et le calendrier des transactions.

En intégrant la technologie du zéro connaissance dans le protocole, les réseaux blockchain axés sur la confidentialité permettent aux nœuds de valider les transactions sans avoir besoin d'accéder aux données de transaction.

Les preuves de connaissance nulle sont également appliquées à l'anonymisation des transactions sur les blockchains publiques. Un exemple est Tornado Cash, un service décentralisé et non dépositaire qui permet aux utilisateurs d'effectuer des transactions privées sur Ethereum. Tornado Cash utilise des preuves de connaissance nulle pour obscurcir les détails des transactions et garantir la confidentialité financière. Malheureusement, parce qu'il s'agit d'outils de confidentialité "opt-in", ils sont associés à des activités illicites. Pour surmonter cela, la confidentialité doit finalement devenir la norme sur les blockchains publiques.

Protection de l'identité

Les systèmes actuels de gestion de l'identité exposent les informations personnelles à des risques. Les preuves de connaissance nulle peuvent aider les individus à valider leur identité tout en protégeant les détails sensibles.

Les preuves de connaissance nulle sont particulièrement utiles dans le contexte de identité décentraliséeL'identité décentralisée (également décrite comme une 'identité souveraine') donne à l'individu la capacité de contrôler l'accès aux identifiants personnels. Prouver votre citoyenneté sans révéler vos détails d'identifiant fiscal ou de passeport est un bon exemple de la manière dont la technologie du savoir zéro permet l'identité décentralisée.

Authentification

L'utilisation de services en ligne nécessite de prouver votre identité et votre droit d'accéder à ces plateformes. Cela nécessite souvent de fournir des informations personnelles, telles que des noms, des adresses e-mail, des dates de naissance, et ainsi de suite. Vous devrez également mémoriser de longs mots de passe ou risquer de perdre l'accès.

Les preuves de zéro connaissance, cependant, peuvent simplifier l'authentification pour les plateformes et les utilisateurs. Une fois qu'une preuve de ZK a été générée en utilisant des entrées publiques (par exemple, des données attestant de l'appartenance de l'utilisateur à la plateforme) et des entrées privées (par exemple, les détails de l'utilisateur), l'utilisateur peut simplement la présenter pour authentifier son identité lorsqu'il a besoin d'accéder au service. Cela améliore l'expérience des utilisateurs et libère les organisations de la nécessité de stocker d'énormes quantités d'informations utilisateur.

Calcul vérifiable

Calcul vérifiable est une autre application de la technologie de la preuve à divulgation nulle pour améliorer les conceptions de blockchain. L'informatique vérifiable nous permet d'externaliser le calcul à une autre entité tout en maintenant des résultats vérifiables. L'entité soumet le résultat avec une preuve vérifiant que le programme a été exécuté correctement.

La computation vérifiable est essentielle pour améliorer les vitesses de traitement sur les blockchains sans compromettre la sécurité. Comprendre cela nécessite de connaître les différences dans les solutions proposées pour mettre à l'échelle Ethereum.

Solutions de mise à l'échelle sur chaîne, comme le sharding, nécessitent une modification approfondie de la couche de base de la blockchain. Cependant, cette approche est très complexe et des erreurs dans la mise en œuvre peuvent compromettre le modèle de sécurité d'Ethereum.

Solutions de mise à l'échelle hors chaînene nécessitent pas de refonte du protocole de base d'Ethereum. Au lieu de cela, ils reposent sur un modèle de calcul externalisé pour améliorer le débit sur la couche de base d'Ethereum.

Voici comment cela fonctionne en pratique :

• Au lieu de traiter chaque transaction, Ethereum délègue l'exécution à une chaîne séparée.
• Après le traitement des transactions, l'autre chaîne renvoie les résultats à appliquer à l'état d'Ethereum.

L'avantage ici est qu'Ethereum n'a pas à effectuer d'exécution et n'a besoin que d'appliquer les résultats de la computation externalisée à son état. Cela réduit la congestion du réseau et améliore également les vitesses de transaction (les protocoles hors chaîne optimisent l'exécution plus rapide).

La chaîne a besoin d'un moyen de valider les transactions hors chaîne sans les ré-exécuter, sinon la valeur de l'exécution hors chaîne est perdue.

C'est là que la computation vérifiable entre en jeu. Lorsqu'un nœud exécute une transaction en dehors d'Ethereum, il soumet une preuve de connaissance nulle pour prouver la justesse de l'exécution hors chaîne. Cette preuve (appelée

garantit que la preuve de validité) d'une transaction est valide, permettant à Ethereum d'appliquer le résultat à son état—sans attendre que quelqu'un le conteste.

Rouleaux à connaissance nulleetvalidiumssont deux solutions de mise à l'échelle hors chaîne qui utilisent des preuves de validité pour offrir une scalabilité sécurisée. Ces protocoles exécutent des milliers de transactions hors chaîne et soumettent des preuves pour vérification sur Ethereum. Ces résultats peuvent être appliqués immédiatement une fois la preuve vérifiée, permettant à Ethereum de traiter plus de transactions sans augmenter le calcul sur la couche de base.

Réduire la corruption et la collusion lors des votes sur chaîne

Les schémas de vote sur la blockchain ont de nombreuses caractéristiques favorables : ils sont entièrement auditables, sécurisés contre les attaques, résistants à la censure et exempts de contraintes géographiques. Mais même les schémas de vote sur la chaîne ne sont pas immunisés contre le problème de collusion.

Défini comme "coordonner pour limiter la concurrence ouverte en trompant, fraudant et trompant les autres", la collusion peut prendre la forme d'un acteur malveillant influençant le vote en offrant des pots-de-vin. Par exemple, Alice pourrait recevoir un pot-de-vin de Bob pour voter pour l'option B sur un bulletin, même si elle préfère l'option A.

La corruption et la collusion limitent l'efficacité de tout processus utilisant le vote comme mécanisme de signalisation (en particulier lorsque les utilisateurs peuvent prouver comment ils ont voté). Cela peut avoir des conséquences significatives, en particulier lorsque les votes sont responsables de l'allocation de ressources rares.

Par exemple, mécanismes de financement quadratique

(opens in a new tab)

reposez-vous sur des dons pour mesurer la préférence pour certaines options parmi différents projets de biens publics. Chaque don compte comme un "vote" pour un projet spécifique, les projets qui reçoivent plus de votes recevant plus de fonds du pool de correspondance.

L'utilisation du vote sur chaîne rend le financement quadratique susceptible à la collusion : les transactions blockchain sont publiques, donc les corrupteurs peuvent inspecter l'activité sur chaîne d'un corrompu pour voir comment il a "voté". Ainsi, le financement quadratique cesse d'être un moyen efficace d'allouer des fonds en fonction des préférences agrégées de la communauté.

Heureusement, de nouvelles solutions telles que MACI (Minimum Anti-Collusion Infrastructure) utilisent des preuves de connaissance nulle pour rendre les votes sur chaîne (par exemple, les mécanismes de financement quadratique) résistants à la corruption et à la collusion. MACI est un ensemble de contrats intelligents et de scripts qui permettent à un administrateur central (appelé un “coordinateur”) d'agréger les votes et de calculer les résultats sans révéler les détails sur la manière dont chaque individu a voté. Néanmoins, il est toujours possible de vérifier que les votes ont été correctement comptés, ou de confirmer qu'un individu particulier a participé au tour de vote.

Comment MACI fonctionne-t-il avec des preuves de connaissance nulle ?

Au début, le coordinateur déploie le contrat MACI sur Ethereum, après quoi les utilisateurs peuvent s'inscrire pour voter (en enregistrant leur clé publique dans le contrat intelligent). Les utilisateurs votent en envoyant des messages chiffrés avec leur clé publique au contrat intelligent (un vote valide doit être signé avec la clé publique la plus récente associée à l'identité de l'utilisateur, entre autres critères). Ensuite, le coordinateur traite tous les messages une fois la période de vote terminée, totalise les votes et vérifie les résultats on-chain.

Dans MACI, des preuves de connaissance nulle sont utilisées pour garantir la correction du calcul en rendant impossible pour le coordinateur de traiter incorrectement les votes et de totaliser les résultats. Cela est obtenu en exigeant que le coordinateur génère des preuves de ZK-SNARK vérifiant que a) tous les messages ont été traités correctement b) le résultat final correspond à la somme de tous les votes valides.

Ainsi, même sans partager un décompte des votes par utilisateur (comme c'est généralement le cas), MACI garantit l'intégrité des résultats calculés lors du processus de décompte. Cette fonctionnalité est utile pour réduire l'efficacité des schémas de collusion de base. Nous pouvons explorer cette possibilité en utilisant l'exemple précédent de Bob soudoyant Alice pour voter pour une option :

• Alice s'inscrit pour voter en envoyant sa clé publique à un contrat intelligent.
• Alice accepte de voter pour l'option B en échange d'un pot-de-vin de Bob.
• Alice vote pour l'option B.
• Alice envoie secrètement une transaction chiffrée pour changer la clé publique associée à son identité.
• Alice envoie un autre message (crypté) au contrat intelligent votant pour l'option A en utilisant la nouvelle clé publique.
• Alice montre à Bob une transaction qui montre qu'elle a voté pour l'option B (ce qui est invalide car la clé publique n'est plus associée à l'identité d'Alice dans le système)
• Lors du traitement des messages, le coordinateur saute le vote d'Alice pour l'option B et ne compte que le vote pour l'option A. Ainsi, la tentative de Bob de comploter avec Alice et de manipuler le vote on-chain échoue.

Utiliser MACI nécessite de faire confiance au coordinateur pour ne pas colluder avec les corrupteurs ou essayer de corrompre les électeurs eux-mêmes. Le coordinateur peut décrypter les messages des utilisateurs (nécessaire pour créer la preuve), afin de vérifier avec précision comment chaque personne a voté.

Mais dans les cas où le coordinateur reste honnête, MACI représente un outil puissant pour garantir la sanctité du vote on-chain. Cela explique sa popularité parmi les applications de financement quadratique (par exemple,clr.fund

(s'ouvre dans un nouvel onglet)

) qui reposent fortement sur l'intégrité des choix de vote de chaque individu.

En savoir plus sur MACI

(opens in a new tab)

.

Inconvénients de l'utilisation des preuves de zéro-connaissance

Coûts matériels

La génération de preuves de zéro connaissance implique des calculs très complexes, mieux réalisés sur des machines spécialisées. Comme ces machines sont coûteuses, elles sont souvent hors de portée des particuliers ordinaires. De plus, les applications qui souhaitent utiliser la technologie de zéro connaissance doivent prendre en compte les coûts matériels, ce qui peut augmenter les coûts pour les utilisateurs finaux.

Coûts de vérification de la preuve

La vérification des preuves nécessite également des calculs complexes et augmente les coûts de mise en œuvre de la technologie de connaissance nulle dans les applications. Ce coût est particulièrement pertinent dans le contexte de la vérification des calculs. Par exemple, les ZK-rollups paient environ 500 000 gaz pour vérifier une seule preuve ZK-SNARK sur Ethereum, les ZK-STARKs nécessitant même des frais plus élevés.

Hypothèses de confiance

Dans ZK-SNARK, la chaîne de référence commune (paramètres publics) est générée une fois et disponible pour être réutilisée par les parties souhaitant participer au protocole de preuve de connaissance nulle. Les paramètres publics sont créés via une cérémonie de configuration de confiance, où l'on suppose que les participants sont honnêtes.

Mais il n'y a vraiment aucun moyen pour les utilisateurs d'évaluer l'honnêteté des participants et les utilisateurs doivent prendre les développeurs au mot. Les ZK-STARKs sont exempts d'hypothèses de confiance car la randomité utilisée pour générer la chaîne est publiquement vérifiable. Pendant ce temps, les chercheurs travaillent sur des configurations non fiables pour les ZK-SNARKs afin d'augmenter la sécurité des mécanismes de preuve.

Menaces de l'informatique quantique

ZK-SNARK utilise la cryptographie à courbes elliptiques

ECDSA) pour le cryptage. Bien que l'algorithme ECDSA soit sécurisé pour l'instant, le développement d'ordinateurs quantiques pourrait compromettre son modèle de sécurité à l'avenir.

ZK-STARK est considéré comme immunisé contre la menace de l'informatique quantique, car il utilise des hachages résistants aux collisions pour le chiffrement. Contrairement aux appariements de clés publique-privée utilisés dans la cryptographie à courbes elliptiques, le hachage résistant aux collisions est plus difficile à casser pour les algorithmes d'informatique quantique.

Avertissement：

1. Cet article est repris de [ Ethereum]. Tous les droits d'auteur appartiennent à l'auteur original [Ethereum]. Si des objections sont formulées à cette réimpression, veuillez contacter le Gate Learnéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.