Critique de la preuve à divulgation nulle (ZKP), devenue une discipline incontournable en cryptographie
TechFlow SélectionTechFlow Sélection
Critique de la preuve à divulgation nulle (ZKP), devenue une discipline incontournable en cryptographie
Les systèmes ZK pourraient nécessiter l'utilisation conjointe d'outils de sécurité tels que la vérification formelle ou d'autres outils liés à la sécurité comme Ecne.
Dédié à des analyses Web3 approfondies*Note : Tout d'abord, il s'agit d'un brouillon rédigé en une heure. Il vise principalement à rassembler rapidement des informations ; par conséquent, il peut contenir de nombreuses erreurs potentielles et des informations incomplètes.
Les principales critiques adressées au ZK concernent deux aspects :
-
Premièrement, le temps de génération des preuves est long (d'où l'apparition de nombreux benchmarks, de nouveaux protocoles ZK et d'optimisations matérielles) ;
-
Deuxièmement, la sécurité des systèmes et des applications reste encore à tester.
Performance de génération des preuves
La preuve à divulgation nulle (ZK) est une technologie très populaire dans le domaine de la blockchain. En raison de la rareté et du coût élevé des ressources computationnelles sur la chaîne, les ZK permettent d'exécuter ces calculs hors chaîne. Bien que le temps total requis pour générer les preuves hors chaîne soit très élevé, cela compresse finalement la preuve finale et la vérification associée, rendant ainsi possible un calcul « sur chaîne ».
Le problème du temps excessivement long de génération des preuves ZK est souvent négligé par les chercheurs et développeurs, car il s'agit fondamentalement d'un compromis inhérent aux ZK.
Bien qu'ils ne critiquent pas directement cet inconvénient du ZK, ils proposent de nombreuses approches et discussions visant à le contourner.
Autrement dit, ils abordent implicitement la durée excessive de génération des preuves ZK en proposant diverses solutions et en réalisant de nombreux tests de performance.
a) Benchmark
Avant d'évaluer les performances des applications ZK, nous devons d'abord tester celles des primitives cryptographiques sous-jacentes, telles que les schémas de commitment.
Par exemple, FRI conduit aux STARK, KZG aux SNARK classiques, IPA aux Bulletproofs. Les tests de performance des primitives de commitment ne sont pas directement représentatifs des performances des applications ZK, mais ils aident à comprendre pourquoi les preuves ZK prennent tant de temps à être générées.
À partir du lien ci-dessus, on constate que ces protocoles de base ne sont pas seulement computationnellement complexes (ce qui peut entraîner des temps de preuve longs), mais présentent également un problème majeur de consommation mémoire.
Bien sûr, la consommation mémoire concerne davantage les exigences en matière de configuration matérielle, ce qui diffère du sujet principal de notre discussion aujourd'hui.
Concernant les tests de performance spécifiques des SNARK, a16z crypto distingue deux composantes : front-end et back-end :
-
Le front-end correspond généralement aux langages de haut niveau accessibles aux développeurs d'applications ZK, tels que Cairo ou les zkVM ;
-
Le back-end concerne les opérations cryptographiques fondamentales, comme les commitments, plus proches du temps de génération des preuves SNARK.
L'auteur mentionne que la génération d'une preuve SNARK implique environ un surcoût computationnel de 100 fois, et chaque protocole ZK ajoute un surcoût supplémentaire. Par exemple :
« Dans Groth16, P doit travailler dans un groupe compatible avec les appariements (pairing-friendly), dont les opérations sont typiquement au moins 2 fois plus lentes que celles des groupes non compatibles. Cela entraîne un ralentissement supplémentaire d’au moins un facteur 6 par rapport à l’estimation 100-|C| mentionnée ci-dessus. »
Dans l'ensemble, on peut dire que le surcoût de performance des zk-SNARK se situe entre 200 et 1000 fois.
En outre, l'article mentionne d'autres limitations des zk-SNARK, telles que la configuration fiable (trusted setup) et l'utilisation mémoire.
L'article de Modulus Labs mesure les performances réelles de plusieurs protocoles ZK. Certains benchmarks portent sur le nombre de paramètres, ce qui n'est pas très intuitif pour nous. Toutefois, en pratique, l'article indique que même avec Plonky2, considéré comme le « plus rapide », l'application Worldcoin nécessite plusieurs minutes pour générer une preuve et consomme des dizaines de Go de mémoire, ce qui empêche son exécution sur un ordinateur personnel.
b) Récursion et traitement par lots
Pour réduire le temps de génération des preuves, nous pouvons paralléliser la création de plusieurs preuves.
Généralement, deux méthodes sont utilisées : le traitement par lots (batching) et la récursion.
En termes simples, le traitement par lots consiste à prouver simultanément un ensemble de preuves, puis à les agréger à la fin, tandis que la récursion consiste à valider d'autres preuves à l'intérieur d'une seule preuve. En général, la méthode récursive présente l'avantage supplémentaire d'une taille de preuve plus petite.
Parmi les méthodes d'agrégation les plus courantes figurent Halo2 et Plonky2. Chacune applique différemment le traitement par lots et la récursion, réduisant ainsi le temps de génération des preuves.
Outre les optimisations au niveau du protocole ZK, des améliorations ciblées peuvent également être apportées au niveau applicatif. Par exemple, utiliser simultanément plusieurs protocoles ZK (STARK + SNARK), ou adopter une stratégie récursive adaptée au cas macroscopique pour un réglage spécifique à l'application.
En général, cela réduit effectivement le temps de génération des preuves en matière de protocole et de distribution des preuves. Lors de l'exploration de nouveaux protocoles ZK, la réduction du temps de preuve constitue l'un des critères les plus importants.
c) Accélération matérielle
En outre, de nombreux efforts ont été faits pour réduire davantage le temps de génération des preuves ZK au niveau physique et des nœuds, notamment par des optimisations matérielles.
Tout d'abord, comme pour les nouveaux protocoles mentionnés précédemment, les protocoles ZK sont conçus pour être aussi compatibles que possible avec le matériel, par exemple HyperPlonk.
Selon Paradigm, la lenteur de génération des preuves ZK provient principalement des grandes opérations MSM (Multi-Scalar Multiplication) et FFT (Transformée de Fourier rapide), peu adaptées au matériel, ce qui ralentit la génération finale des preuves en raison d'accès mémoire aléatoires, entre autres problèmes. Pour ces calculs cryptographiques de base, les protocoles ZK doivent faire certains compromis dans leur conception et leur échelle afin d'être plus adaptés au matériel.
Plusieurs entreprises spécialisées dans l'accélération matérielle ZK affirment que les GPU constituent actuellement le choix matériel le plus économique et configurable, avant une transition progressive vers les FPGA puis les ASIC. Selon les sociétés spécialisées dans le matériel ZK, leur première version d'ASIC pourrait réduire directement d'au moins 30 % le temps de génération des preuves ZK.
En outre, en raison des configurations serveur différentes, l'utilisation de différents serveurs cloud comme nœuds peut nécessiter des optimisations spécifiques au matériel.
Sécurité
Une autre critique fréquente du ZK est que le code du circuit doit toujours être correct (sans bogues).
Si le protocole ZK est attaqué du point de vue de la solidité, de l'intégrité ou de la confidentialité, alors nous n'avons plus un système ZK valide. Nous pouvons voir divers exemples d'attaques selon différents angles via ce lien.
Même si les applications ZK peuvent être qualifiées d'« inconditionnelles » (trustless), nous devons tout de même garantir que les protocoles ZK, ainsi que le code et l'architecture des applications, sont corrects. Diverses failles ZK existent dans le domaine de la blockchain. Par exemple, en raison de la taille importante de la base de code des circuits ZK dans les zkEVM, Vitalik a évoqué la nécessité de plusieurs validateurs indépendants pour les applications ZK.
Par conséquent, les systèmes ZK pourraient avoir besoin d'être combinés avec des outils de sécurité tels que la vérification formelle ou d'autres outils liés à la sécurité comme Ecne. Au niveau applicatif, des audits plus poussés sont nécessaires, en particulier pour de grands projets comme les zkEVM.
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
msfew / Suning Yao
