Analyse approfondie : pourquoi la preuve à divulgation nulle de connaissance (ZK) est-elle importante ?
TechFlow SélectionTechFlow Sélection
Analyse approfondie : pourquoi la preuve à divulgation nulle de connaissance (ZK) est-elle importante ?
L'avenir de ZK est prometteur, car il peut rendre possible certaines choses qui étaient auparavant impossibles.
Dédié à des analyses Web3 approfondiesAuteur : Glaze & l'équipe de recherche Fundamental Labs
Si vous avez apprécié ce rapport de recherche, n'hésitez pas à le liker, à l'enregistrer et à le partager avec des amis intéressés. Cela nous aide beaucoup.
TL;DR
L'avenir des preuves à connaissance nulle (ZK) est prometteur : elles rendent possibles des choses auparavant impossibles. Ces dernières années, le domaine ZK a connu plusieurs avancées majeures, notamment en performance, en capacité de mise à niveau et en élimination du besoin d'une configuration initiale de confiance. Ces améliorations ont conduit les ZK vers une phase d'application pratique. Ainsi, lorsqu’on examine un nouveau système de preuve ZK, on peut l’évaluer selon les critères suivants :
Temps de génération de la preuve pour une transaction et pour dix transactions
Temps de vérification de la preuve pour une transaction et pour dix transactions
Taille de la preuve après regroupement d’une transaction et de dix transactions
Configuration initiale de confiance
Longueur de la chaîne de référence
Prise en charge CRS
Prise en charge SRS
Prise en charge des preuves récursives
Résistance aux ordinateurs quantiques
Sécurité fondée sur des hypothèses cryptographiques
ZKEVM est la prochaine étape clé des ZKRU, avec trois phases :
Niveau consensus
Niveau bytecode
Niveau langage
Les ZKRU viennent tout juste d’entrer dans leur phase d’application, et leur écosystème reste imparfait. Les développeurs n’ont pas encore exploité tout le potentiel des ZK. De nouvelles idées continuent d’émerger à partir de ces théories de pointe. Voici quelques directions prometteuses à surveiller :
Applications exploitant pleinement un TPS élevé et des frais faibles
Protocoles/applications de communication entre Layer2
Agrégation de liquidités
Outils et frameworks de développement
Outils de développement basés sur le cloud
Applications transversales entre Layer2 et Layer1 offrant des fonctionnalités uniques
Différents ZKVM
Ponts ZK
Application des ZK sur d'autres blockchains
Layer2 dotés de fonctionnalités récursives
Utilisation des ZK dans la gouvernance DAO et communautaire
Algorithmes ZK commercialisés
Puces et informatique en nuage
Les applications ZK se concentrent principalement sur deux axes : Rollup et confidentialité. Rollup présente un avenir plus prometteur que la confidentialité. Cette dernière va quelque peu à l’encontre de l’esprit ouvert de la blockchain et peut poser des problèmes de conformité réglementaire. À l'ère Web2, aucune application centrée sur la confidentialité n'est devenue dominante. Bien que tous les logiciels renforcent progressivement leurs protections de confidentialité, les leaders du marché ne sont jamais ceux qui mettent la confidentialité en avant, mais bien ceux offrant la meilleure facilité d'utilisation. La confidentialité a un coût, souvent au détriment de l’ergonomie, qui est primordiale pour les utilisateurs.
Lorsqu'on analyse un projet de confidentialité utilisant les ZK, voici quelques points importants à considérer :
Le ZK n’est qu’un outil technique ; il faut privilégier la qualité du produit et l’équipe derrière
Le ZK est une technologie complexe qui ralentit le développement
Le ZK bénéficie à la gouvernance DAO et à l’authentification d’identité
Le ZK est une technologie indispensable pour l’intégration institutionnelle à la blockchain
Intuition
Définition simple de la preuve à connaissance nulle (Zero Knowledge Proof) : le prouveur (Prover) convainc le vérificateur (Verifier) qu’une affirmation est vraie, sans lui fournir aucune autre information que cette vérité elle-même.
Les ZK ont été conçus pour assurer l’anonymat. Imaginez pouvoir prouver que votre numéro de carte d’identité est valide, sans pour autant le divulguer au vérificateur. Dans un monde où les données personnelles sont excessivement collectées, cela revêt une importance cruciale.
Voici un exemple plus vivant. Xiao Ming et Xiao Hong jouent au sudoku. Xiao Hong veut prouver à Xiao Ming qu’elle connaît la solution, sans toutefois la lui révéler, car Xiao Ming n’a pas encore trouvé la réponse. Comment concevoir une telle preuve ?
On écrit chaque chiffre du sudoku sur une carte, puis on les place face cachée selon la solution. Xiao Ming choisit alors aléatoirement une ligne, une colonne ou un bloc. Xiao Hong prend les cartes correspondantes, les mélange, puis les retourne face visible. Si les chiffres sont tous distincts et forment 1 à 9, Xiao Ming sait qu’elle connaît partiellement la solution – peut-être par chance. En répétant ce processus plusieurs fois, la probabilité que ce soit une coïncidence devient négligeable. Xiao Ming est donc convaincu qu’elle connaît la solution complète, sans jamais savoir laquelle.
Si vous êtes encore perplexe, regardez cette vidéo. Un professeur d’informatique de l’UCLA explique les ZK selon cinq niveaux de difficulté croissante.
Grandes familles de preuves à connaissance nulle
Avant d’aborder les différentes familles de ZK, précisons que ZK-SNARK n’est pas un algorithme unique, mais une famille. ZK-STARK est le nom d’un algorithme spécifique de preuve à connaissance nulle.
La plus connue est probablement ZK-SNARK. SNARK signifie Succinct Non-interactive Argument of Knowledge. Ce qui caractérise surtout SNARK, c’est son « N » : la non-interactivité.
Succincte (Succinct) : les ressources nécessaires à la vérification sont bien inférieures à celles requises pour exécuter à nouveau le programme prouvé.
Non interactive (Non-interactive) : le prouveur et le vérificateur n’ont pas besoin d’interagir à chaque tour. Une configuration initiale de confiance suffit au départ, après quoi d’autres vérificateurs peuvent participer.
Argument : si le prouveur dispose d’une puissance de calcul illimitée, il pourrait générer une fausse preuve. Mais dans ce cas, même les systèmes de cryptographie classiques seraient compromis.
Connaissance (Knowledge) : le prouveur doit connaître un secret inconnu des autres pour produire la preuve.
Le principal défaut de ZK-SNARK est sa dépendance à une configuration initiale de confiance (Trust Setup). Celle-ci génère une chaîne de référence (Reference String). Si celle-ci fuit, n’importe qui peut créer de fausses preuves. Concevoir une configuration impliquant plusieurs participants est également très complexe. De plus, chaque chaîne ne sert qu’à un programme donné. Pour un autre programme, il faut refaire toute la procédure. Par conséquent, ZK-SNARK ne peut pas être utilisé pour le calcul généralisé. Enfin, la chaîne ne peut pas être mise à jour : si le programme évolue, il faut recommencer la configuration initiale.
Pour résoudre ces problèmes, deux grandes voies ont été explorées :
Configuration transparente (Transparent Setup) : génère une chaîne de référence commune (Common Reference String), publique et non confidentielle. Fractal, Halo, ZK-STARK et SuperSonic adoptent cette approche. Le problème est que les preuves générées occupent beaucoup d’espace (jusqu’à plusieurs ko), ce qui est coûteux pour une blockchain.
Configuration universelle (Universal Setup) : produit une chaîne de référence structurée (Structure Reference String), qui reste confidentielle. Le SRS permet d’utiliser la même configuration pour différents programmes, rendant possible le calcul généralisé. Marlink, SuperSonic-RSA et Plonk suivent cette voie.
Les algorithmes couramment utilisés incluent :
Groth16 : utilisé initialement par Zcash. Il sert de référence en matière de performances grâce à ses temps de preuve rapides et à la petite taille de ses preuves. Son inconvénient majeur est la nécessité d’une configuration initiale de confiance, propre à chaque programme. Il dispose toutefois de la chaîne d’outils la plus mature.
Sonic : supporte Universal Setup. La taille du SRS augmente linéairement avec celle du programme. La taille de la preuve est fixe, mais la vérification est gourmande en ressources. Sonic rend possible les preuves ZK pour le calcul généralisé.
Fractal : supporte la récursion. Génère des preuves volumineuses.
Halo : supporte la récursion, mais n’est pas « succinct » car le temps de preuve est non linéaire. Halo2 est actuellement le système de preuve le plus utilisé.
SuperSonic : premier ZK-SNARK transparent réellement applicable.
Marlin : permet la mise à jour du programme. Ses performances se situent entre Sonic et Groth16.
Plonk : permet la mise à jour du programme ; les participants s’ajoutent séquentiellement à la configuration initiale, simplifiant les configurations à multiples intervenants. Plonk utilise des engagements de Kate au lieu des engagements polynomiaux traditionnels (la première étape d’un ZK-SNARK consiste à transformer un calcul en problème polynomial). De nombreux systèmes modernes de preuve ZK reposent sur Plonk, qui dispose d’une excellente chaîne d’outils.
Parmi ces algorithmes, Groth16, Halo et Plonk sont les meilleurs choix pour une étude approfondie.
CRS désigne la chaîne de référence commune générée par la voie Transparent Setup. SRS désigne la chaîne de référence structurée issue de la voie Universal Setup. La taille de la preuve détermine l'espace de stockage nécessaire sur Layer1. Les durées de preuve et de vérification reflètent la consommation de ressources de calcul.
Source : Comparing General Purpose zk-SNARKs
Le graphique ci-dessous montre un benchmark des algorithmes ZK, basé sur cette expérience.
Source : Comparing General Purpose zk-SNARKs
Autres benchmarks et comparaisons d’algorithmes :
Benchmarking Zero-Knowledge proofs with isekai | by Guillaume Drevon | Sikoba Network | Medium
Community Proposal: A Benchmarking Framework for (Zero-Knowledge) Proof Systems (zkproof.org)
En résumé, voici les critères à considérer face à un nouvel algorithme ZK :
Temps de preuve pour une et dix transactions
Temps de vérification pour une et dix transactions
Taille de la preuve après regroupement d’une et de dix transactions
Configuration initiale de confiance
Longueur de la chaîne de référence
Support CRS
Support SRS
Support des preuves récursives
Résistance aux ordinateurs quantiques
Hypothèses cryptographiques sous-jacentes à la sécurité
Ces dernières années, les ZK sont sortis des laboratoires pour entrer dans le champ des applications pratiques. Les deux domaines principaux sont Rollup et la confidentialité. L’impact des ZK sur les produits de confidentialité est manifeste, car ils permettent au vérificateur de ne rien apprendre d’autre que la validité de l’affirmation. Les Rollups s’appuient sur deux propriétés clés des ZK : la concision (succinctness) et la récursivité (recursion). La concision permet aux vérificateurs d’économiser massivement en ressources de calcul — ils n’ont pas à rejouer l’intégralité du programme. La récursivité économise de l’espace de stockage. Grâce à elle, la blockchain peut rester de taille fixe, ce qui favorise la décentralisation, car même du matériel peu puissant peut exécuter un nœud.
Processus de développement d'applications ZK
Développer une application ZK indépendante est extrêmement complexe et nécessite les compétences suivantes :
Algorithmes, arithmétique de base, compétences d'optimisation. Les développeurs doivent maîtriser l’arithmétique sur corps finis, les engagements polynomiaux et les courbes elliptiques.
Systèmes de preuve ZK, comme ZK-SNARKs, Plonkish, et configuration initiale de confiance. Les développeurs doivent choisir un système adapté et le personnaliser.
Programmation de circuits. Ils doivent traduire des algorithmes cryptographiques courants (ex. Merkle Tree, hachage) en circuits.
Développement d’applications et de protocoles cryptographiques.
Des outils efficaces accélèrent le développement et réduisent la complexité. Par exemple, des outils comme Circom s’occupent de l’algèbre de bas niveau et du système de preuve, permettant aux développeurs de se concentrer sur la programmation de circuits et le développement d’applications.
Mécanisme des Rollups
Le concept des Rollups est simple : comme le calcul sur chaîne est coûteux, on déplace le calcul hors chaîne tout en conservant la sécurité, en ne stockant que les résultats sur chaîne.
La racine de l’arbre de hachage d’état est stockée dans un contrat Rollup. Ce contrat met à jour la racine d’état à partir des informations soumises depuis Layer2.
Source : An Incomplete Guide to Rollups (vitalik.ca)
Source : An Incomplete Guide to Rollups (vitalik.ca)
Un ZK Rollup (ZKRU) utilise une preuve à connaissance nulle pour garantir que la nouvelle racine d’état soumise depuis Layer2 est correcte. Le vérificateur n’a qu’à valider la preuve pour confirmer la validité de la racine d’état, sans avoir à rejouer chaque transaction. Cela réduit considérablement la charge de travail et augmente le TPS. Cette économie de calcul illustre la propriété de concision des ZK. Grâce à la concision, la complétude et la solidité des ZK, les ZKRU peuvent augmenter le TPS en toute sécurité. (Complétude : si la preuve est valide, le vérificateur accepte l’assertion. Solidité : une assertion fausse ne peut pas produire une preuve valide.)
Globalement, les ZKRU surpassent les Optimistic Rollups (OPRU). Les OPRU ont un TPS légèrement inférieur et des délais de retrait plus longs, car ils dépendent des preuves de fraude (Fraud Proof). Alors, quand les ZKRU seront pleinement déployés, ne vont-ils pas écraser les OPRU ? Et les OPRU ne sont pas non plus en retard sur le plan écologique. Face à cette pression, ils intègrent désormais les ZK pour améliorer leur TPS et réduire les délais de retrait. Par exemple, en appliquant les ZK aux changements d’état, ils peuvent accélérer le processus de preuve de fraude.
Acteurs
Dans un système Rollup, trois rôles existent :
Utilisateurs : ils soumettent des transactions sur Layer2 et déposent des actifs depuis Layer1
Nœuds Rollup : ils maintiennent le bon fonctionnement du réseau Layer2, génèrent des preuves, exécutent et regroupent les transactions, et participent aux preuves de fraude
Layer1 : assure la sécurité de Layer2 et atteint le consensus. La plupart du temps, il s’agit d’Ethereum.
Source : Understanding rollup economics from first principles
Modèle économique
Le modèle économique repose essentiellement sur les coûts et les revenus. Pour un Layer2, les dépenses principales sont :
Coût de calcul pour générer la preuve
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
Ajouter aux favorisPartager sur les réseaux sociaux
