Alliance Dao : Comment créer des produits Web3 grâce aux ZKP ?
TechFlow SélectionTechFlow Sélection
Alliance Dao : Comment créer des produits Web3 grâce aux ZKP ?
La preuve à divulgation nulle de connaissance (ZKP) est en train de devenir une technologie fondamentalement transformatrice pour la décennie à venir.
Dédié à des analyses Web3 approfondies
Rédaction : Mohamed Fouda, Qiao Wang, Alliance Dao
Traduction : TechFlow
Les preuves à divulgation nulle de connaissance (ZKP) deviennent une technologie fondamentalement transformatrice pour la prochaine décennie. Les ZKP ont des applications tant dans Web3 qu'en dehors.
Dans Web3, les ZKP résolvent deux goulets d'étranglement majeurs — l'extensibilité et la confidentialité :
-
En matière d'extensibilité, plusieurs ZK Rollups, aussi appelés Validity Rollups, sont en cours de déploiement afin de multiplier par 10 à 100 la capacité d'Ethereum, tout en améliorant l'expérience utilisateur grâce à la réduction des coûts de transaction.
-
En matière de confidentialité, les ZKP évoluent au-delà des transactions privées et du mixage, vers des domaines plus complexes et utiles tels que les transactions en chaîne confidentielles, l'identité et les accréditations vérifiées.
Il existe une grande quantité d'informations sur les ZKP, y compris notre propre vision de l'avenir de ce domaine et des startups nécessaires pour y parvenir. Toutefois, un certain écart pédagogique subsiste quant à la manière dont les développeurs peuvent tirer parti des ZKP et par où commencer.
Cet article vise à combler ce manque en rassemblant des ressources essentielles, afin de guider les développeurs sur le fonctionnement pratique des ZKP et sur leur intégration dans leurs applications.
Comment fonctionnent les ZKP en pratique ?
Une preuve à divulgation nulle de connaissance (ZKP) est techniquement un mécanisme par lequel un « prouveur » démontre à un « vérificateur » qu’il connaît une information spécifique sans divulguer ladite information.
En pratique, du moins dans Web3, les ZKP sont souvent utilisées différemment. La plupart des applications n'utilisent pas les ZKP pour prouver la possession de données propriétaires. Au contraire, les ZKP servent à renforcer la confiance via la vérifiabilité. Nous prévoyons que les ZKP deviendront à l’avenir un modèle standard de confiance entre entités. La raison en est que les deux composants principaux des ZKP — la preuve et sa vérification — sont désormais séparés d’une manière qui crée un nouveau schéma d'interaction entre les entités cherchant à inspirer confiance et leurs utilisateurs.
Les composants principaux des ZKP sont la génération de la preuve et la vérification de la preuve.
-
La génération de la preuve consiste à effectuer des calculs intensifs afin de produire une preuve attestant du bon déroulement d’un processus, éliminant ainsi le besoin de faire confiance au prouveur.
-
Inversement, n'importe qui peut exécuter un processus simple sur cette preuve afin de vérifier l'intégrité du processus mené par le prouveur.
Ce modèle mental permet à une entreprise d’exécuter un processus (souvent complexe), tout en donnant à ses clients la possibilité de faire confiance à l’exécution de ce processus sans avoir à le reproduire eux-mêmes.
Prenons un exemple :
Supposons que vous soyez abonné à un plan payant d’OpenAI, utilisant l'un de leurs grands modèles linguistiques (LLMs), comme chatGPT. Vous devez faire confiance à OpenAI pour avoir bien exécuté le modèle que vous avez demandé, plutôt que de le remplacer par un modèle plus simple et moins performant. Et si OpenAI pouvait vous envoyer une petite quantité de données prouvant qu'ils ont effectivement exécuté le modèle demandé ? Imaginez alors ce qui se passerait si chaque produit SaaS propriétaire pouvait offrir une telle garantie à ses consommateurs ?
Cette minimisation de la confiance est la promesse des ZKP. Par exemple, dans Web2, les ZKP pourraient garantir une évaluation de crédit équitable ou un traitement équitable des sinistres d'assurance, en s'assurant que tous les clients utilisent le même algorithme. La technologie ZK n’en est pas encore là, car l'exécution des processus ZKP reste relativement coûteuse. Toutefois, nous voyons déjà des entreprises comme Modulus Labs construire des solutions permettant de prouver, grâce aux ZKP, les inférences d'IA.
Exigences techniques des ZKP
Sur le plan technique, un système ZKP efficace doit simultanément atteindre les objectifs suivants :
-
Réduire la complexité computationnelle et la latence du système de preuve, c’est-à-dire permettre au prouveur de générer rapidement la preuve et de la transmettre au vérificateur en un temps minimal.
-
Obtenir une taille de preuve réduite.
-
Assurer une vérification efficace, c’est-à-dire minimiser le coût de vérification.
Outre ces objectifs principaux, certains objectifs secondaires peuvent être requis selon les cas d'utilisation, par exemple :
-
Protéger la confidentialité des données dans les applications axées sur la vie privée, ce qui signifie que le système de preuve doit pouvoir traiter des entrées privées sans les exposer dans la preuve générée.
-
Éviter autant que possible toute configuration initiale de confiance, afin de simplifier les hypothèses de sécurité.
-
Permettre la récursion des preuves afin de réduire davantage les coûts de vérification, c’est-à-dire qu’une seule vérification puisse valider plusieurs preuves, permettant ainsi de mutualiser les coûts.
Atteindre simultanément tous ces objectifs est difficile. En fonction du cas d’usage, les systèmes ZKP priorisent certains objectifs. Par exemple, les systèmes de preuve SNARK produisent des preuves très courtes, mais augmentent la complexité de la génération. À l’inverse, STARK possède un prouveur très efficace, mais la taille de la preuve peut être jusqu’à 100 fois plus grande que celle d’un SNARK. Les chercheurs en ZK s'efforcent continuellement de repousser les limites technologiques en inventant de nouveaux mécanismes de preuve capables d'améliorer simultanément ces trois indicateurs.
Comparaison des différents systèmes de preuve
Pour les développeurs créant des produits liés aux ZKP, une question importante est comment choisir le système de preuve sous-jacent. Il existe plusieurs implémentations de preuves ZKP, et de nombreuses autres sont encore en phase de recherche et développement.
Le choix du backend ZKP dépend non seulement des aspects techniques, mais aussi du produit cible. Prenons l'exemple du choix d’un système de preuve pour un Rollup. Des caractéristiques clés du Rollup telles que le délai de retrait, le coût des transactions, voire son niveau de décentralisation, seront principalement déterminées par l’architecture du système de preuve ZKP, comme illustré dans le tableau ci-dessous.
Dans les Rollups, la preuve est générée côté opérateur. Les ZK Rollups existants (zkRUs), comme Starknet et Zksync, utilisent actuellement des prouveurs centralisés. Ils peuvent donc externaliser la génération de preuves à des sociétés spécialisées dans les preuves en tant que service (proof-as-a-service), afin d’améliorer les performances. Grâce à cette spécialisation et à l’utilisation de logiciels/matériels optimisés, le temps de preuve peut être ramené à quelques minutes pour les zkEVM compatibles Ethereum. Par exemple, le temps de preuve de Polygon zkEVM est actuellement d’environ 2 minutes. Un délai de quelques minutes, correspondant au délai de retrait, est acceptable pour un Rollup.
En revanche, certains cas d’usage exigent que la preuve soit générée côté utilisateur, notamment pour créer des transactions privées comme celles de Tornado Cash. Pour garantir une expérience utilisateur satisfaisante, le temps de preuve ne doit pas excéder quelques secondes. De plus, étant donné que les utilisateurs exécutent ces calculs depuis leur portefeuille ou un navigateur sur des appareils aux ressources limitées, il est crucial de choisir un système de preuve avec un prouveur rapide. Un bon exemple est celui de Zcash, qui en 2018 a migré vers Groth16 lors de la mise à jour Sapling, ce qui a été un facteur clé dans l’accélération des transactions masquées.
Comparer les systèmes de preuve
Il est généralement difficile d'obtenir une comparaison précise des performances entre différents systèmes de preuve, en particulier concernant la vitesse de génération et de vérification, car ces performances dépendent de l'implémentation de la bibliothèque, de la courbe cryptographique choisie et du matériel utilisé.
L’équipe Mina propose dans cet article une excellente comparaison de haut niveau. D'autres efforts visent également à créer des outils de benchmarking pour les différents systèmes ZK.
Ce tableau fournit une bonne comparaison des implémentations SNARK et illustre leur évolution en termes de rapidité, de Groth16 à Plonk puis à Halo. Malgré ces progrès, STARK reste supérieur en vitesse de génération, au prix d'une taille de preuve plus importante. Le tableau aborde également deux caractéristiques importantes des systèmes de preuve : l'absence de configuration de confiance et la programmabilité du circuit.
La section sur l’absence de configuration de confiance traite de la phase de prétraitement lors de la création du circuit. Certaines techniques de preuve nécessitent une participation multi-parties dans un calcul sécurisé afin de générer des nombres aléatoires secrets. Si au moins un participant est honnête, les nombres générés restent secrets et la phase est sécurisée. Ce processus est appelé « configuration de confiance », car il repose sur le fait qu’au moins un participant soit honnête durant cette phase. Cette configuration est considérée comme une faiblesse. Dans ce sens, STARK et les nouveaux systèmes SNARK comme Halo 2 présentent un avantage. Cependant, certains projets utilisent la configuration de confiance comme un levier d’engagement communautaire, comme Aztec et Manta.
La section sur la programmabilité examine si le système de preuve peut attester de tout type de calcul. Généralement, les SNARK peuvent programmer n’importe quel calcul. Toutefois, l’efficacité dépend du type de calcul effectué. Pour certains types de systèmes STARK, l’adaptation à divers calculs n’est pas aussi aisée.
Comment tirer parti des ZKP pour votre produit ?
Construire un produit capable de tirer parti de la technologie ZKP n’est pas chose aisée et nécessite d’avoir le bon modèle mental.
Cette section tente de fournir aux développeurs un cadre pour choisir la meilleure approche afin d’intégrer les ZKP à leur produit. Selon les besoins du produit, l’alignement avec l’écosystème et les exigences de performance, plusieurs outils seront disponibles. Certains développeurs pourront réutiliser leur code existant, tandis que d’autres devront apprendre un nouveau langage spécifique au domaine (DSL) pour créer leurs applications.
Applications ZK axées sur les performances
Les développeurs peuvent utiliser les ZKP pour obtenir un débit plus élevé (TPS) ou des frais plus bas, en déplaçant la majorité des calculs hors chaîne et en publiant uniquement la preuve sur chaîne. Dans ce cas, plusieurs cadres sont disponibles. Chaque cadre fournit un ensemble d'outils pour compiler le code de l'application, générer le circuit ZK, implémenter le prouveur ZK et produire le code du vérificateur adapté à l'écosystème cible. On peut classer ces cadres en deux catégories principales : centrés sur EVM et non-EVM.
Cadres ZK centrés sur EVM
Ce groupe de cadres ZK est aligné sur Ethereum et destiné à être utilisé pour construire des Rollups. Les transactions et applications s'exécutent sur la machine virtuelle ZK (zkVM) du Rollup. La preuve est générée par un prouveur spécialisé et publiée sur la couche L1, où elle est vérifiée par un contrat intelligent.
Le premier sous-groupe implémente une zkVM compatible avec EVM, appelée zkEVM. Leur objectif est de minimiser la friction pour les développeurs Ethereum en leur permettant d'utiliser Solidity et des outils familiers comme Hardhat et Foundry. Ils abstraient la complexité ZK en créant des circuits et des prouveurs adaptés à l'EVM. Polygon zkEVM et Scroll font partie de cette catégorie.
Le deuxième sous-groupe comprend des zkVM non nativement compatibles avec EVM. Bien qu’incompatibles, ils réduisent la friction en créant une couche intermédiaire permettant aux développeurs d’utiliser Solidity. Vitalik qualifie ce type de zkEVM de type-4. zkSync Era et Starknet sont de bons exemples de ce groupe. L'avantage des zkEVM de type-4 est qu’ils peuvent offrir un débit plus élevé et des frais plus bas que les versions compatibles EVM. Cela les rend adaptés à la construction d'applications à haut débit, comme les jeux en chaîne ou des produits financiers performants comme les DEX à carnet d'ordres.
Développer des applications pour zkEVM de type-4 demande plus d'efforts aux développeurs, en raison de certaines limitations sur le code Solidity utilisable. Sinon, les développeurs peuvent choisir d’apprendre un autre langage, comme Cairo, pour développer des applications natives pour ces cadres.
Cadres ZK non-EVM
Un autre type de cadre n'est pas orienté vers l'architecture EVM, car il cible des L1 concurrents ou des calculs généralistes. Néanmoins, ils peuvent toujours être utilisés, via un SDK spécialisé comme Sovereign, pour construire des zkRUs spécifiques à une application sur Ethereum.
Deux approches sont possibles :
-
Les développeurs écrivent du code en langage haut niveau, compilé ensuite pour une architecture VM spécifique, puis transformé en circuit ZK.
-
Les développeurs utilisent un langage spécifique au domaine (DSL), comme Circom, pour générer directement le circuit ZK.
La première approche est plus conviviale pour les développeurs, mais conduit généralement à des circuits plus volumineux et à des temps de preuve plus longs.
Applications ZK axées sur la confidentialité
Développer des applications axées sur la confidentialité avec les ZKP est généralement une tâche plus difficile pour les développeurs. Moins de solutions existent comparées aux solutions axées sur l’extensibilité, ce qui rend la courbe d’apprentissage plus abrupte. Les applications de confidentialité existantes se concentrent principalement sur les paiements privés et offrent peu de programmabilité. Combiner confidentialité et programmabilité est un défi important. Ces applications suivent l’une des deux options suivantes :
1. Construire au-dessus d'une L1 généraliste
Pour activer des applications de paiement privé sur une L1, la logique ZKP doit être intégrée dans un contrat intelligent. L’application utilise souvent les ZKP pour créer des pools de capitaux privés. Les utilisateurs utilisent ces pools comme mixeurs pour financer de nouveaux portefeuilles non liés à leur portefeuille d’origine. Un exemple célèbre est Tornado Cash. Pour ces applications, la preuve est générée par l’utilisateur et la vérification s’effectue en chaîne. Il est donc crucial d’utiliser un système ZKP avec un prouveur rapide, une vérification simple, et ne divulguant aucune information utilisateur.
Comme les blockchains généralistes ne sont pas optimisées pour les calculs cryptographiques coûteux, le coût de vérification est souvent prohibitif pour les utilisateurs, limitant ainsi l’adoption. Déplacer ces applications vers un Rollup pour réduire les frais semble intuitif, mais pose des défis : la preuve de transaction privée doit alors être incluse dans la preuve du Rollup (récursion de preuve), or les zk Rollups généraux sur Ethereum ne supportent pas encore la récursion.
2. Construire une nouvelle L1/L2 axée sur la confidentialité
Pour réduire les coûts des transactions privées et des applications, les développeurs doivent construire une nouvelle L1 centrée sur la confidentialité (ex : Manta Network, Penumbra) ou un Rollup spécialisé (ex : Aztec). La plupart de ces chaînes axées sur la confidentialité ne supportent pas encore le calcul généralisé et se concentrent sur des usages spécifiques. Par exemple, Penumbra et Renegade ciblent les transactions privées. Aleo construit un cadre pour les applications privées en créant un langage dédié, Leo, qui compile des programmes écrits en langage haut niveau vers des circuits ZK correspondants. Les interactions d’application sont réalisées hors chaîne, seule la preuve étant publiée en chaîne comme transaction privée. Aztec suit une direction similaire, mais en tant que L2 Ethereum. Ils ont récemment annoncé leur intention de se concentrer sur un Rollup privé généraliste utilisant Noir comme langage par défaut pour les contrats intelligents.
Accélération ZK
Après avoir choisi le bon cadre de développement ZK adapté à leur application et sélectionné le système de preuve sous-jacent, les développeurs doivent optimiser les performances pour améliorer l’expérience utilisateur. Cela revient généralement à accélérer le prouveur et réduire la latence. Comme discuté précédemment, pour un Rollup, un temps de preuve plus court signifie un délai plus court pour soumettre la preuve à la L1, donc un délai de retrait réduit. Pour les preuves générées par l’utilisateur (applications de confidentialité), une preuve plus rapide signifie un temps de génération de transaction plus court et une meilleure expérience.
Comme nous l’avons discuté dans un précédent article, l’accélération du processus de preuve nécessite généralement des optimisations logicielles et du matériel dédié. Ces derniers mois, la concurrence autour du matériel spécialisé s’est intensifiée, avec l’entrée de nombreuses entreprises. Cette section présente l’état actuel de l’accélération ZK et comment les développeurs peuvent en tirer parti.
Preuve en tant que service
Jusqu’à présent, le modèle standard pour exécuter les preuves ZK consiste à utiliser des serveurs puissants dotés de CPU multicœurs et/ou GPU, combinés à des bibliothèques open source optimisées (comme Bellperson de Filecoin). Ce modèle augmente la complexité opérationnelle pour les développeurs, qui doivent gérer l’infrastructure de preuve. Un meilleur modèle, réduisant cette complexité et favorisant la spécialisation, est celui de la « preuve en tant que service ». Dans ce modèle, une entité ayant besoin de générer une preuve pour un circuit ZK ou un cas d’usage donné se connecte à un fournisseur exécutant un logiciel propriétaire pour effectuer les calculs. Certaines entreprises peuvent se spécialiser sur des cas d’usage spécifiques. Par exemple, Axiom construit un système pour générer des preuves Halo 2 sur l'historique d'Ethereum. D'autres peuvent se concentrer sur un backend ZKP spécifique (Plonk ou Halo 2) et développer des optimisations propriétaires pour des calculs plus rapides et efficaces. =nil Foundation va plus loin en construisant un marché de calcul ZKP. Sur ce « Proof Market », les acheteurs de preuves soumettent des offres, qui sont appariées et exécutées par des générateurs de preuves. Mina a un concept similaire, appelé Snarketplace, mais limité aux preuves SNARK nécessaires au réseau Mina.
Accélération matérielle
Avec le lancement de plusieurs L1 et Rollups nécessitant une génération efficace de preuves zk, la compétition pour produire ces preuves et percevoir les récompenses associées va s’intensifier. Si ces chaînes et L2 attirent beaucoup d’utilisateurs, la génération de preuves pourrait devenir une course aux armements similaire au minage Bitcoin. Différentes méthodes d’accélération ZKP existent : GPU vs FPGA vs ASIC. Un article d’Amber Group analyse bien ces options et les défis associés. À long terme, les entreprises produisant les ASIC les plus efficaces pour la génération de preuves auront un avantage économique significatif sur les chaînes axées sur zk.
Une différence importante entre la compétition ZK et le minage Bitcoin mérite d’être soulignée. Dans Bitcoin, le minage repose sur un calcul simple (hachage SHA256), fixe et peu changeant, ce qui met l’accent sur l’innovation en conception de puces et l’accès aux nœuds semi-conducteurs les plus avancés. Dans le domaine ZKP, il existe une fragmentation marquée entre protocoles. Même avec le même backend (ex : Plonk), la taille du circuit cible peut affecter les performances de l’ASIC. Cette différence pourrait conduire à plusieurs gagnants, chacun spécialisé sur un backend ZK différent.
Plusieurs acteurs entrent sur le marché des puces dédiées aux ZKP. Chacun se concentre sur l’un des deux calculs principaux : la multiplication scalaire multiple (MSM) ou la transformation de Fourier rapide (NTT). Le dernier à sortir de l’ombre est Cysic, qui a annoncé lors d’ETH Denver une levée de fonds de 6 millions de dollars. Cysic se concentre sur l’accélération des MSM via des FPGA. La flexibilité des FPGA leur permet de supporter différents systèmes ZK. Cette approche est similaire à celle d’Ulventanna, qui a levé 15 millions de dollars en janvier. Parmi les autres acteurs figurent Ingonyama, qui a publié Icicle, une bibliothèque accélérant MSM et NTT sur GPU, ainsi que Accseal, Snarkify et Supranational. En dehors de cette liste, d’autres entreprises connues dans l’espace Web3 mènent des recherches confidentielles, comme Jump Crypto avec CycloneMSM (accélération FPGA des MSM) et Jane Street avec des implémentations FPGA pour accélérer MSM et NTT.
En raison de l’importance croissante de l’accélération ZKP, des compétitions visant à évaluer équitablement différentes implémentations (comme ZPrize) deviennent des catalyseurs importants pour le progrès du domaine. La compétition 2022 a offert plus de 4 millions de dollars de prix.
Avec le lancement de plusieurs L1 et Rollups nécessitant une génération efficace de preuves zk, la compétition pour produire ces preuves et percevoir les récompenses associées va s’intensifier. Si ces chaînes et L2 attirent beaucoup d’utilisateurs, la génération de preuves pourrait devenir une course aux armements similaire au minage Bitcoin. Différentes méthodes d’accélération ZKP existent : GPU vs FPGA vs ASIC. Un article d’Amber Group analyse bien ces options et les défis associés. À long terme, les entreprises produisant les ASIC les plus efficaces pour la génération de preuves auront un avantage économique significatif sur les chaînes axées sur zk.
Une différence importante entre la compétition ZK et le minage Bitcoin mérite d’être soulignée. Dans Bitcoin, le minage repose sur un calcul simple (hachage SHA256), fixe et peu changeant, ce qui met l’accent sur l’innovation en conception de puces et l’accès aux nœuds semi-conducteurs les plus avancés. Dans le domaine ZKP, il existe une fragmentation marquée entre protocoles. Même avec le même backend (ex : Plonk), la taille du circuit cible peut affecter les performances de l’ASIC. Cette différence pourrait conduire à plusieurs gagnants, chacun spécialisé sur un backend ZK différent.
Plusieurs acteurs entrent sur le marché des puces dédiées aux ZKP. Chacun se concentre sur l’un des deux calculs principaux : la multiplication scalaire multiple (MSM) ou la transformation de Fourier rapide (NTT). Le dernier à sortir de l’ombre est Cysic, qui a annoncé lors d’ETH Denver une levée de fonds de 6 millions de dollars. Cysic se concentre sur l’accélération des MSM via des FPGA. La flexibilité des FPGA leur permet de supporter différents systèmes ZK. Cette approche est similaire à celle d’Ulventanna, qui a levé 15 millions de dollars en janvier. Parmi les autres acteurs figurent Ingonyama, qui a publié Icicle, une bibliothèque accélérant MSM et NTT sur GPU, ainsi que Accseal, Snarkify et Supranational. En dehors de cette liste, d’autres entreprises connues dans l’espace Web
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
Alliance
