La Machine Virtuelle Zéro Connaissance (zkVMs) vise à "rendre les SNARKs grand public", permettant à toute personne sans connaissance spécialisée en SNARK de prouver qu'elle a correctement exécuté un programme sur une entrée spécifique (ou un témoin). Son principal avantage réside dans l'expérience des développeurs, mais actuellement, le zkVMs est confronté à d'importants défis en termes de sécurité et de performance. Pour que le zkVMs tienne ses promesses, les concepteurs doivent surmonter ces obstacles. Cet article explorera les différentes étapes possibles du développement du zkVM, un processus qui pourrait prendre plusieurs années pour être achevé - ne croyez pas ceux qui disent que cela peut être réalisé rapidement.
Les défis à relever
En termes de sécurité, les zkVMs sont des projets logiciels très complexes et restent pleins de failles.
En termes de performance, prouver l'exécution correcte d'un programme peut être des dizaines de milliers de fois plus lent que l'exécution native, rendant la plupart des déploiements d'applications dans le monde réel actuellement impossibles.
Cependant, de nombreuses voix de l'industrie de la blockchain continuent de promouvoir que les zkVMs peuvent être déployées immédiatement, et même certains projets ont déjà payé des coûts de calcul élevés pour générer des preuves de connaissance nulle des activités de la chaîne. Cependant, en raison des nombreuses failles des zkVMs, cette pratique n'est en fait qu'un coûteux déguisement, faisant paraître le système protégé par SNARK, alors qu'en réalité il repose soit sur un contrôle d'autorisation, soit, pire encore, il est exposé aux risques d'attaque.
La réalité est que nous sommes encore à des années de la construction d'un zkVM réellement sécurisé et efficace. Cet article propose une série d'objectifs spécifiques et échelonnés pour nous aider à suivre les progrès réels de zkVM, à réduire la spéculation et à orienter l'attention de la communauté vers de véritables avancées technologiques.
Phase de développement de la sécurité
Contexte
Les zkVMs basés sur SNARK comprennent généralement deux composants principaux :
Preuve interactive de l'oracle polynomial (PIOP) : cadre de preuve interactive utilisé pour prouver un polynôme (ou des contraintes dérivées d'un polynôme)
Schéma d'engagement polynômial (Polynomial Commitment Scheme, PCS): garantit que le prouveur ne peut pas falsifier les résultats de l'évaluation polynomiale sans être détecté.
zkVM utilise l'encodage des trajectoires d'exécution valides en tant que système de contraintes pour garantir l'utilisation correcte des registres et de la mémoire de la machine virtuelle, puis prouver la satisfaction de ces contraintes à l'aide de SNARK.
Dans un système aussi complexe, la seule façon de garantir l'absence de bugs dans zkVM est la vérification formelle. Voici les différentes phases de sécurité de zkVM, la première phase se concentrant sur la correction du protocole, tandis que les deuxième et troisième phases se concentrent sur la correction de la mise en œuvre.
Phase de sécurité 1: Protocole correct
La preuve formelle de la fiabilité de PIOP;
PCS est une forme de preuve vérifiable dans certains cas cryptographiques ou modèles idéaux contraignants;
Si Fiat-Shamir est utilisé, la preuve concise obtenue en combinant PIOP et PCS est sécurisée dans le modèle de prédiction aléatoire en tant que preuve de vérification formelle (renforcée si nécessaire par d'autres hypothèses cryptographiques);
Le système de contraintes appliqué par PIOP est équivalent à la preuve formelle de la sémantique de VM;
Toutes ces parties doivent être entièrement "collées" ensemble pour former une preuve SNARK sécurisée unique et vérifiée formellement, utilisée pour exécuter n'importe quel programme spécifié en bytecode VM. Si le protocole vise à atteindre une confidentialité totale, cette propriété doit également être vérifiée formellement pour garantir qu'aucune information sensible sur les témoins n'est divulguée.
Si zkVM utilise la récursion, alors le PIOP, les engagements et les systèmes de contraintes impliqués dans le processus de récursion doivent tous être vérifiés, sinon cette sous-étape ne peut pas être considérée comme terminée.
Étape 2 de sécurité : Implémentation correcte du validateur
Cette phase exige la vérification formelle de la mise en œuvre réelle des validateurs zkVM (comme Rust, Solidity, etc.) pour garantir leur conformité aux protocoles validés à la première phase. L'achèvement de cette phase signifie que la mise en œuvre de zkVM est cohérente avec la conception théorique, et non pas simplement un protocole de sécurité sur papier, ou une spécification inefficace écrite dans des langages tels que Lean.
Pourquoi se concentrer uniquement sur les validateurs et non sur les prouveurs ? Il y a deux raisons principales : tout d'abord, en s'assurant que les validateurs sont corrects, on peut garantir l'intégrité du système de preuve zkVM (c'est-à-dire : s'assurer que les validateurs ne peuvent pas être trompés pour accepter une preuve erronée). Deuxièmement, la mise en œuvre des validateurs zkVM est plus d'un ordre de grandeur plus simple que celle des prouveurs, ce qui rend plus facile de garantir leur exactitude à court terme.
Phase 3 de sécurité : Réalisation correcte du prouveur
Cette phase exige une vérification formelle de la mise en œuvre réelle des proveurs zkVM pour s'assurer qu'ils peuvent générer correctement les preuves des systèmes de preuve vérifiés des première et deuxième phases. L'objectif de cette phase est la complétude, c'est-à-dire : aucun système utilisant zkVM ne devrait se retrouver bloqué en raison de l'incapacité de prouver une assertion légitime. Si zkVM doit posséder des propriétés de connaissance nulle, une vérification formelle doit être fournie pour s'assurer que la preuve ne divulgue aucune information sur le témoignage.
Calendrier prévisionnel
Phase 1 Progress: We can expect some progress next year (for example, ZKLib is such an effort). But no zkVM can fully meet the requirements of Phase 1 for at least two years.
Phase 2 and Phase 3: These phases can proceed simultaneously with certain aspects of Phase 1. For example, some teams have already demonstrated the implementation of the Plonk validator matching the protocol in the paper (although the protocol itself may not have been fully validated). Nevertheless, I expect that any zkVM will not reach Phase 3 in less than four years - and possibly even longer.
Fiat-Shamir sécurité et bytecode vérifié
Un problème majeur de complexité est que la sécurité de la transformation Fiat-Shamir reste un problème de recherche non résolu. Les trois phases de sécurité considèrent toutes Fiat-Shamir et l'oracle aléatoire comme absolument sécurisés, mais en réalité, tout le paradigme pourrait présenter des failles. Cela est dû aux différences entre le modèle idéalisé de l'oracle aléatoire et les fonctions de hachage réellement utilisées.
Dans le pire des cas, un système qui a déjà atteint le stade de sécurité 2 peut être découvert complètement non sécurisé en raison de problèmes liés à Fiat-Shamir. Cela mérite toute notre attention et une recherche continue. Il se peut que nous ayons besoin de modifier la transformation de Fiat-Shamir elle-même pour mieux nous protéger contre de telles failles.
Un système sans récursivité est théoriquement plus sécurisé, car certains circuits impliqués dans des attaques connues sont similaires aux circuits utilisés dans les preuves récursives. Cependant, ce risque reste un problème fondamental non résolu.
Un autre point à noter est que même si zkVM prouve qu'un programme de calcul particulier (spécifié par un bytecode) est correctement exécuté, la valeur de cette preuve est extrêmement limitée si le bytecode lui-même est défectueux. Par conséquent, l'utilité de zkVM dépend largement de la manière dont le bytecode vérifié formellement est généré, un défi énorme qui dépasse le cadre de cet article.
Sur la sécurité contre les attaques quantiques
Pendant au moins 5 ans (voire plus longtemps), les ordinateurs quantiques ne constitueront pas une menace sérieuse, tandis que les failles logicielles posent un problème de vie ou de mort. Par conséquent, la priorité actuelle devrait être de réaliser les objectifs de sécurité et de performance énoncés dans cet article. Si les SNARKs non résistants aux attaques quantiques peuvent satisfaire plus rapidement ces objectifs, nous devrions les utiliser en priorité. Attendez que les SNARKs résistants aux attaques quantiques se développent ou qu'il y ait des signes indiquant l'émergence imminente d'ordinateurs quantiques réellement menaçants avant d'envisager de changer.
Niveau de sécurité spécifique
La sécurité classique de 100 bits est la norme minimale pour toute SNARK utilisée pour protéger des actifs de valeur (mais certains systèmes ne sont toujours pas conformes à cette norme minimale). Cependant, cela ne devrait pas être accepté, les pratiques standard en cryptographie exigent généralement une sécurité de 128 bits et plus. Si les performances de la SNARK sont réellement conformes aux normes, nous ne devrions pas compromettre la sécurité pour améliorer les performances.
Phase de performance
Current situation
Actuellement, le coût de calcul du vérificateur zkVM est d'environ 1 million de fois l'exécution native. En d'autres termes, si l'exécution native d'un programme nécessite X cycles CPU, alors la génération d'une preuve d'exécution correcte nécessitera environ X × 1 000 000 cycles CPU. C'était le cas il y a un an, et cela reste vrai aujourd'hui (bien qu'il y ait eu quelques malentendus).
Certains termes populaires dans l'industrie actuelle peuvent être trompeurs, par exemple :
Le coût de génération de preuves pour l'ensemble du réseau principal d'Ethereum est inférieur à 1 million de dollars par an.
Nous avons presque réalisé la génération en temps réel de preuves de blocs Ethereum, avec seulement quelques dizaines de GPU.
"Notre dernier zkVM est 1000 fois plus rapide que son prédécesseur."
Cependant, ces déclarations peuvent être trompeuses sans contexte :
• 1000 fois plus rapide que l’ancien zkVM et peut encore être très lent, ce qui est plus révélateur de combien il était mauvais dans le passé que de combien il est bon maintenant.
• La puissance de calcul du réseau principal d'Ethereum pourrait augmenter de 10 fois à l'avenir, ce qui rendrait les performances actuelles du zkVM largement insuffisantes pour répondre à la demande.
• La prétendue génération de preuves "presque en temps réel" est toujours trop lente pour de nombreuses applications de la blockchain (par exemple, le temps de bloc d'Optimism est de 2 secondes, beaucoup plus rapide que les 12 secondes d'Ethereum).
• « Des dizaines de GPU fonctionnant 24h/24 et 7j/7 pendant de longues périodes » n’offre pas de garanties d’activité suffisantes.
• Ces temps de génération de preuves sont généralement conçus pour des tailles de preuves supérieures à 1 Mo, ce qui est trop important pour de nombreuses applications.
• Le coût annuel inférieur à 1 million de dollars n'est dû qu'au fait que un nœud complet d'Ethereum n'exécute qu'environ 25 dollars de calculs par an.
Pour les cas d'utilisation en dehors de la blockchain, ces frais de calcul sont clairement trop élevés. Aucune quantité de calcul parallèle ou d'optimisation de l'ingénierie ne peut compenser un tel coût de calcul énorme.
Notre objectif de base devrait être de limiter les coûts de performance à 100 000 fois l'exécution native. Cependant, cela n'est que le premier pas. Pour réaliser des applications grand public à grande échelle, il faudra peut-être réduire les coûts à 10 000 fois l'exécution native, voire moins.
Mesure de performance
Les performances SNARK se composent de trois éléments principaux :
L'efficacité de preuve de travail du système sous-jacent.
Optimisation pour des applications spécifiques (par exemple la précompilation).
Ingénierie et accélération matérielle (comme GPU, FPGA ou CPU multi-cœurs).
Bien que (2) et (3) soient cruciaux pour le déploiement réel, ils s'appliquent à tout système de preuve, ce qui ne garantit pas nécessairement une amélioration des coûts de base. Par exemple, l'ajout d'une accélération GPU et de précompilations à zkEVM peut facilement augmenter la vitesse de 50 fois par rapport à une simple dépendance du CPU - ce qui peut donner l'impression qu'un système inefficace est supérieur à un autre système non optimisé de la même manière.
Par conséquent, cet article met l'accent sur les performances de base de SNARK sans matériel dédié ni précompilation. Cela diffère des méthodes actuelles de benchmarking, qui combinent généralement ces trois facteurs en une seule "valeur globale". C'est comme juger un diamant par son temps de polissage plutôt que par son éclat inhérent.
Notre objectif est de isoler les coûts inhérents des systèmes de preuve généraux, de réduire les barrières à l'entrée des technologies encore peu étudiées et d'aider la communauté à éliminer les facteurs perturbateurs, afin de se concentrer sur les véritables progrès de la conception des systèmes de preuve.
Phase de performance
Voici les cinq étapes de performance que j'ai proposées. Tout d'abord, nous devons réduire considérablement les coûts des validateurs sur le CPU, avant de pouvoir compter davantage sur le matériel pour réduire les coûts. De plus, l'utilisation de la mémoire doit également être améliorée.
À toutes les étapes, les développeurs ne doivent pas ajuster le code pour les performances de zkVM. L'expérience des développeurs est l'avantage clé de zkVM. Sacrifier l'expérience des développeurs pour répondre aux exigences de performance non seulement perd le sens des tests de référence, mais contredit également l'objectif initial de zkVM.
Ces mesures se concentrent principalement sur le coût du prouveur. Cependant, si l'on permet une croissance illimitée des coûts du validateur (c'est-à-dire une taille de preuve ou un temps de validation sans limite), alors n'importe quelle mesure du prouveur peut facilement être satisfaite. Par conséquent, pour répondre aux exigences des étapes suivantes, la taille maximale de la preuve et le temps de validation maximum doivent être fixés simultanément.
• Taille de la preuve : doit être inférieure à la taille de la preuve.
• Temps de vérification : La vitesse de verification de la preuve ne doit pas être plus lente que l'exécution native du programme (c'est-à-dire, elle ne doit pas être plus lente que l'exécution directe du calcul).
Ce sont les exigences minimales de concision pour s'assurer que la taille de la preuve et le temps de vérification ne seront pas pires que d'envoyer directement le témoin au vérificateur pour inspection directe.
Étape 2 et plus
• Taille maximale de la preuve : 256 KB.
• Temps de validation maximal : 16 millisecondes.
Ces plafonds ont été délibérément fixés à des niveaux assez élevés pour s'adapter aux nouvelles technologies de preuve rapide, même si elles peuvent entraîner des coûts de validation plus élevés. En même temps, ces plafonds excluent les preuves si coûteuses que pratiquement aucun projet ne serait prêt à les utiliser sur la blockchain.
Phase 1 de vitesse
La vitesse de preuve en un seul fil ne doit pas être plus de 100 000 fois plus lente que l'exécution native (applicable à diverses applications, pas seulement aux preuves de blocs Ethereum), et ne doit pas dépendre de la précompilation.
Plus précisément, supposons qu'un processeur RISC-V sur un ordinateur portable moderne fonctionne à une vitesse d'environ 30 milliards de cycles par seconde, alors atteindre l'étape 1 signifie que cet ordinateur portable peut générer une preuve à une vitesse de 30 000 cycles RISC-V par seconde (monotâche).
Le coût du validateur doit satisfaire aux normes de "coût de validation raisonnable non trivial" définies précédemment.
Phase 2 de vitesse
La preuve en simple thread ne doit pas être plus lente que l'exécution native de plus de 10 000 fois.
Ou, en raison des restrictions actuelles du CPU et du GPU sur certaines méthodes SNARK prometteuses (en particulier le SNARK de domaine binaire), cela peut être satisfait par FPGA (voire ASIC) à ce stade :
Calculer le nombre de cœurs RISC-V simulés à la vitesse native par FPGA.
Calculer, simuler et prouver le nombre de FPGA nécessaires pour exécuter (quasiment en temps réel) RISC-V.
Si la quantité de (2) n'excède pas 10 000 fois celle de (1), alors la phase 2 est satisfaite.
• Taille de la preuve : maximum 256 Ko.
• Temps de validation : maximum 16 millisecondes sur un CPU standard.
Phase 3 de vitesse
Sur la base de la phase 2 de la vitesse, réaliser des dépenses de preuve inférieures à 1000× (applicables à diverses applications), et utiliser obligatoirement une précompilation à synthèse automatique et vérification formelle. Fondamentalement, personnaliser dynamiquement l'ensemble d'instructions de chaque programme pour accélérer la génération de preuves, tout en garantissant l'accessibilité et la vérification formelle. (Pourquoi la précompilation est une arme à double tranchant et pourquoi écrire manuellement la précompilation n'est pas une méthode durable, veuillez vous référer à la section suivante.)
Étape 1 de la mémoire
Atteindre la phase de vitesse 1 avec moins de 2 Go de RAM tout en respectant les exigences de confidentialité zéro. Cette étape est cruciale pour les appareils mobiles ou les navigateurs et ouvre la voie à de nombreux cas d'utilisation zkVM côté client. Par exemple, les smartphones sont utilisés pour la confidentialité de l'emplacement, les identifiants d'identité, etc. Si la génération de preuves nécessite plus de 1-2 Go de RAM, la plupart des appareils mobiles ne pourront pas fonctionner.
Deux points importants à noter :
Même pour les calculs à grande échelle (nécessitant des milliards de cycles CPU pour une exécution native), le système de preuve doit également maintenir une limite de mémoire de 2 Go, faute de quoi sa pertinence serait limitée.
Si la vitesse est prouvée très lente, il est très facile de maintenir la limite de mémoire de 2 Go. Ainsi, pour que la phase de mémoire 1 ait un sens, il est nécessaire d'atteindre la phase 1 de vitesse dans la limite de mémoire de 2 Go.
Phase 2 de la mémoire
Atteindre la phase de vitesse 1 (10 fois plus rapide que la phase de mémoire 1) avec moins de 200 Mo de mémoire.
Pourquoi réduire à 200 Mo? Considérez un scénario non blockchain: lorsque vous accédez à un site Web HTTPS, vous téléchargez des certificats d'authentification et de chiffrement. Si le site Web commençait à envoyer ces certificats sous forme de preuves zk, un grand site Web pourrait avoir besoin de générer des millions de preuves par seconde. Si chaque preuve nécessite 2 Go de mémoire, les besoins en ressources informatiques atteindraient un niveau PB, ce qui est clairement irréalisable. Par conséquent, réduire davantage l'utilisation de la mémoire est crucial pour les applications non blockchain.
Pré-compilation: Dernier kilomètre, ou béquille ?
La compilation anticipée fait référence à un système de contraintes SNARK spécifiquement optimisé pour des fonctions particulières (telles que le hachage, les signatures de courbe elliptique). Sur Ethereum, la compilation anticipée peut réduire les coûts de hachage de Merkle et de vérification de signature, mais une dépendance excessive à la compilation anticipée ne peut pas vraiment améliorer l'efficacité fondamentale de SNARK.
Problème de précompilation
1. Toujours trop lent : même avec la précompilation des hachages et des signatures, zkVM reste confronté à des problèmes d'inefficacité du système de preuve fondamental à l'intérieur et à l'extérieur de la blockchain.
2. Vulnérabilités de sécurité : Si la précompilation manuelle n'est pas vérifiée formellement, des vulnérabilités sont presque inévitablement présentes, ce qui peut entraîner des échecs de sécurité catastrophiques.
3. Mauvaise expérience des développeurs : Actuellement, de nombreux zkVM nécessitent que les développeurs écrivent manuellement des systèmes de contraintes, ce qui ressemble à la manière de programmer dans les années 1960, ce qui affecte considérablement l'expérience de développement.
4.测试基准误导：Si les tests de référence dépendent de la précompilation optimisée spécifique, cela pourrait induire en erreur les gens en les amenant à se concentrer sur la contrainte manuelle du système optimisé, plutôt que sur l'amélioration de la conception SNARK elle-même.
5. Coûts d'E/S et accès sans RAM Bien que la précompilation puisse améliorer les performances des tâches de chiffrement intenses, elle peut ne pas offrir d'accélération significative pour des charges de travail plus diversifiées, car elles génèrent des coûts importants lors de la transmission des entrées/sorties et ne peuvent pas utiliser la RAM.
Même dans l'environnement de la blockchain, dès que vous dépassez une seule couche L1 comme Ethereum (par exemple, si vous souhaitez construire une série de ponts inter-chaînes), vous serez confronté à des fonctions de hachage et des schémas de signature différents. Pour résoudre ce problème, une compilation constante est effectuée, ce qui n'est ni évolutif, ni présente d'énormes risques de sécurité.
Je crois vraiment que la précompilation reste essentielle à long terme, mais seulement si elle est automatiquement synthétisée et formellement vérifiée. Cela nous permet de conserver un avantage d'expérience pour les développeurs de zkVM tout en évitant les risques de sécurité catastrophiques. Cette perspective se reflète dans la phase 3.
Calendrier prévu
Je m'attends à ce que quelques zkVM atteignent plus tard cette année les étapes de vitesse 1 et de mémoire 1. Je pense que nous pourrons également réaliser l'étape de vitesse 2 au cours des deux prochaines années, mais il n'est pas clair pour le moment si nous pourrons atteindre cet objectif sans nouvelles pistes de recherche.
Je m'attends à ce que les étapes restantes (Étape de vitesse 3 et Étape de mémoire 2) prennent plusieurs années pour être réalisées.
Bien que cet article énumère séparément la sécurité et les performances de zkVM, les deux ne sont pas totalement indépendantes. À mesure que des failles dans zkVM sont découvertes, je m'attends à ce que la correction de certaines d'entre elles entraîne inévitablement une baisse significative des performances. Par conséquent, les résultats des tests de performance de zkVM devraient être considérés comme des données provisoires jusqu'à ce que zkVM atteigne la Phase de sécurité 2.
zkVM a un énorme potentiel pour démocratiser réellement la preuve de connaissance zéro, mais il est actuellement encore à un stade précoce, rempli de défis en matière de sécurité et souffre de sérieux goulots d'étranglement en termes de performances. Les spéculations du marché et les campagnes marketing rendent difficile de mesurer les progrès réels. Avec des jalons clairs en termes de sécurité et de performances, j'espère fournir une feuille de route qui dissipera les doutes. Nous atteindrons finalement nos objectifs, mais cela prendra du temps et un effort continu en recherche et développement.
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
a16z: Explore the efficient and secure path of zkVM
Auteur : Justin Thaler Source : a16z Traduction : Shano Ouba, Finance Dorée
La Machine Virtuelle Zéro Connaissance (zkVMs) vise à "rendre les SNARKs grand public", permettant à toute personne sans connaissance spécialisée en SNARK de prouver qu'elle a correctement exécuté un programme sur une entrée spécifique (ou un témoin). Son principal avantage réside dans l'expérience des développeurs, mais actuellement, le zkVMs est confronté à d'importants défis en termes de sécurité et de performance. Pour que le zkVMs tienne ses promesses, les concepteurs doivent surmonter ces obstacles. Cet article explorera les différentes étapes possibles du développement du zkVM, un processus qui pourrait prendre plusieurs années pour être achevé - ne croyez pas ceux qui disent que cela peut être réalisé rapidement.
Les défis à relever
En termes de sécurité, les zkVMs sont des projets logiciels très complexes et restent pleins de failles.
En termes de performance, prouver l'exécution correcte d'un programme peut être des dizaines de milliers de fois plus lent que l'exécution native, rendant la plupart des déploiements d'applications dans le monde réel actuellement impossibles.
Cependant, de nombreuses voix de l'industrie de la blockchain continuent de promouvoir que les zkVMs peuvent être déployées immédiatement, et même certains projets ont déjà payé des coûts de calcul élevés pour générer des preuves de connaissance nulle des activités de la chaîne. Cependant, en raison des nombreuses failles des zkVMs, cette pratique n'est en fait qu'un coûteux déguisement, faisant paraître le système protégé par SNARK, alors qu'en réalité il repose soit sur un contrôle d'autorisation, soit, pire encore, il est exposé aux risques d'attaque.
La réalité est que nous sommes encore à des années de la construction d'un zkVM réellement sécurisé et efficace. Cet article propose une série d'objectifs spécifiques et échelonnés pour nous aider à suivre les progrès réels de zkVM, à réduire la spéculation et à orienter l'attention de la communauté vers de véritables avancées technologiques.
Phase de développement de la sécurité
Contexte
Les zkVMs basés sur SNARK comprennent généralement deux composants principaux :
Preuve interactive de l'oracle polynomial (PIOP) : cadre de preuve interactive utilisé pour prouver un polynôme (ou des contraintes dérivées d'un polynôme)
Schéma d'engagement polynômial (Polynomial Commitment Scheme, PCS): garantit que le prouveur ne peut pas falsifier les résultats de l'évaluation polynomiale sans être détecté.
zkVM utilise l'encodage des trajectoires d'exécution valides en tant que système de contraintes pour garantir l'utilisation correcte des registres et de la mémoire de la machine virtuelle, puis prouver la satisfaction de ces contraintes à l'aide de SNARK.
Dans un système aussi complexe, la seule façon de garantir l'absence de bugs dans zkVM est la vérification formelle. Voici les différentes phases de sécurité de zkVM, la première phase se concentrant sur la correction du protocole, tandis que les deuxième et troisième phases se concentrent sur la correction de la mise en œuvre.
Phase de sécurité 1: Protocole correct
Si zkVM utilise la récursion, alors le PIOP, les engagements et les systèmes de contraintes impliqués dans le processus de récursion doivent tous être vérifiés, sinon cette sous-étape ne peut pas être considérée comme terminée.
Étape 2 de sécurité : Implémentation correcte du validateur
Cette phase exige la vérification formelle de la mise en œuvre réelle des validateurs zkVM (comme Rust, Solidity, etc.) pour garantir leur conformité aux protocoles validés à la première phase. L'achèvement de cette phase signifie que la mise en œuvre de zkVM est cohérente avec la conception théorique, et non pas simplement un protocole de sécurité sur papier, ou une spécification inefficace écrite dans des langages tels que Lean.
Pourquoi se concentrer uniquement sur les validateurs et non sur les prouveurs ? Il y a deux raisons principales : tout d'abord, en s'assurant que les validateurs sont corrects, on peut garantir l'intégrité du système de preuve zkVM (c'est-à-dire : s'assurer que les validateurs ne peuvent pas être trompés pour accepter une preuve erronée). Deuxièmement, la mise en œuvre des validateurs zkVM est plus d'un ordre de grandeur plus simple que celle des prouveurs, ce qui rend plus facile de garantir leur exactitude à court terme.
Phase 3 de sécurité : Réalisation correcte du prouveur
Cette phase exige une vérification formelle de la mise en œuvre réelle des proveurs zkVM pour s'assurer qu'ils peuvent générer correctement les preuves des systèmes de preuve vérifiés des première et deuxième phases. L'objectif de cette phase est la complétude, c'est-à-dire : aucun système utilisant zkVM ne devrait se retrouver bloqué en raison de l'incapacité de prouver une assertion légitime. Si zkVM doit posséder des propriétés de connaissance nulle, une vérification formelle doit être fournie pour s'assurer que la preuve ne divulgue aucune information sur le témoignage.
Calendrier prévisionnel
Phase 1 Progress: We can expect some progress next year (for example, ZKLib is such an effort). But no zkVM can fully meet the requirements of Phase 1 for at least two years.
Phase 2 and Phase 3: These phases can proceed simultaneously with certain aspects of Phase 1. For example, some teams have already demonstrated the implementation of the Plonk validator matching the protocol in the paper (although the protocol itself may not have been fully validated). Nevertheless, I expect that any zkVM will not reach Phase 3 in less than four years - and possibly even longer.
Fiat-Shamir sécurité et bytecode vérifié
Un problème majeur de complexité est que la sécurité de la transformation Fiat-Shamir reste un problème de recherche non résolu. Les trois phases de sécurité considèrent toutes Fiat-Shamir et l'oracle aléatoire comme absolument sécurisés, mais en réalité, tout le paradigme pourrait présenter des failles. Cela est dû aux différences entre le modèle idéalisé de l'oracle aléatoire et les fonctions de hachage réellement utilisées.
Dans le pire des cas, un système qui a déjà atteint le stade de sécurité 2 peut être découvert complètement non sécurisé en raison de problèmes liés à Fiat-Shamir. Cela mérite toute notre attention et une recherche continue. Il se peut que nous ayons besoin de modifier la transformation de Fiat-Shamir elle-même pour mieux nous protéger contre de telles failles.
Un système sans récursivité est théoriquement plus sécurisé, car certains circuits impliqués dans des attaques connues sont similaires aux circuits utilisés dans les preuves récursives. Cependant, ce risque reste un problème fondamental non résolu.
Un autre point à noter est que même si zkVM prouve qu'un programme de calcul particulier (spécifié par un bytecode) est correctement exécuté, la valeur de cette preuve est extrêmement limitée si le bytecode lui-même est défectueux. Par conséquent, l'utilité de zkVM dépend largement de la manière dont le bytecode vérifié formellement est généré, un défi énorme qui dépasse le cadre de cet article.
Sur la sécurité contre les attaques quantiques
Pendant au moins 5 ans (voire plus longtemps), les ordinateurs quantiques ne constitueront pas une menace sérieuse, tandis que les failles logicielles posent un problème de vie ou de mort. Par conséquent, la priorité actuelle devrait être de réaliser les objectifs de sécurité et de performance énoncés dans cet article. Si les SNARKs non résistants aux attaques quantiques peuvent satisfaire plus rapidement ces objectifs, nous devrions les utiliser en priorité. Attendez que les SNARKs résistants aux attaques quantiques se développent ou qu'il y ait des signes indiquant l'émergence imminente d'ordinateurs quantiques réellement menaçants avant d'envisager de changer.
Niveau de sécurité spécifique
La sécurité classique de 100 bits est la norme minimale pour toute SNARK utilisée pour protéger des actifs de valeur (mais certains systèmes ne sont toujours pas conformes à cette norme minimale). Cependant, cela ne devrait pas être accepté, les pratiques standard en cryptographie exigent généralement une sécurité de 128 bits et plus. Si les performances de la SNARK sont réellement conformes aux normes, nous ne devrions pas compromettre la sécurité pour améliorer les performances.
Phase de performance
Current situation
Actuellement, le coût de calcul du vérificateur zkVM est d'environ 1 million de fois l'exécution native. En d'autres termes, si l'exécution native d'un programme nécessite X cycles CPU, alors la génération d'une preuve d'exécution correcte nécessitera environ X × 1 000 000 cycles CPU. C'était le cas il y a un an, et cela reste vrai aujourd'hui (bien qu'il y ait eu quelques malentendus).
Certains termes populaires dans l'industrie actuelle peuvent être trompeurs, par exemple :
Nous avons presque réalisé la génération en temps réel de preuves de blocs Ethereum, avec seulement quelques dizaines de GPU.
Cependant, ces déclarations peuvent être trompeuses sans contexte :
• 1000 fois plus rapide que l’ancien zkVM et peut encore être très lent, ce qui est plus révélateur de combien il était mauvais dans le passé que de combien il est bon maintenant.
• La puissance de calcul du réseau principal d'Ethereum pourrait augmenter de 10 fois à l'avenir, ce qui rendrait les performances actuelles du zkVM largement insuffisantes pour répondre à la demande.
• La prétendue génération de preuves "presque en temps réel" est toujours trop lente pour de nombreuses applications de la blockchain (par exemple, le temps de bloc d'Optimism est de 2 secondes, beaucoup plus rapide que les 12 secondes d'Ethereum).
• « Des dizaines de GPU fonctionnant 24h/24 et 7j/7 pendant de longues périodes » n’offre pas de garanties d’activité suffisantes.
• Ces temps de génération de preuves sont généralement conçus pour des tailles de preuves supérieures à 1 Mo, ce qui est trop important pour de nombreuses applications.
• Le coût annuel inférieur à 1 million de dollars n'est dû qu'au fait que un nœud complet d'Ethereum n'exécute qu'environ 25 dollars de calculs par an.
Pour les cas d'utilisation en dehors de la blockchain, ces frais de calcul sont clairement trop élevés. Aucune quantité de calcul parallèle ou d'optimisation de l'ingénierie ne peut compenser un tel coût de calcul énorme.
Notre objectif de base devrait être de limiter les coûts de performance à 100 000 fois l'exécution native. Cependant, cela n'est que le premier pas. Pour réaliser des applications grand public à grande échelle, il faudra peut-être réduire les coûts à 10 000 fois l'exécution native, voire moins.
Mesure de performance
Les performances SNARK se composent de trois éléments principaux :
L'efficacité de preuve de travail du système sous-jacent.
Optimisation pour des applications spécifiques (par exemple la précompilation).
Ingénierie et accélération matérielle (comme GPU, FPGA ou CPU multi-cœurs).
Bien que (2) et (3) soient cruciaux pour le déploiement réel, ils s'appliquent à tout système de preuve, ce qui ne garantit pas nécessairement une amélioration des coûts de base. Par exemple, l'ajout d'une accélération GPU et de précompilations à zkEVM peut facilement augmenter la vitesse de 50 fois par rapport à une simple dépendance du CPU - ce qui peut donner l'impression qu'un système inefficace est supérieur à un autre système non optimisé de la même manière.
Par conséquent, cet article met l'accent sur les performances de base de SNARK sans matériel dédié ni précompilation. Cela diffère des méthodes actuelles de benchmarking, qui combinent généralement ces trois facteurs en une seule "valeur globale". C'est comme juger un diamant par son temps de polissage plutôt que par son éclat inhérent.
Notre objectif est de isoler les coûts inhérents des systèmes de preuve généraux, de réduire les barrières à l'entrée des technologies encore peu étudiées et d'aider la communauté à éliminer les facteurs perturbateurs, afin de se concentrer sur les véritables progrès de la conception des systèmes de preuve.
Phase de performance
Voici les cinq étapes de performance que j'ai proposées. Tout d'abord, nous devons réduire considérablement les coûts des validateurs sur le CPU, avant de pouvoir compter davantage sur le matériel pour réduire les coûts. De plus, l'utilisation de la mémoire doit également être améliorée.
À toutes les étapes, les développeurs ne doivent pas ajuster le code pour les performances de zkVM. L'expérience des développeurs est l'avantage clé de zkVM. Sacrifier l'expérience des développeurs pour répondre aux exigences de performance non seulement perd le sens des tests de référence, mais contredit également l'objectif initial de zkVM.
Ces mesures se concentrent principalement sur le coût du prouveur. Cependant, si l'on permet une croissance illimitée des coûts du validateur (c'est-à-dire une taille de preuve ou un temps de validation sans limite), alors n'importe quelle mesure du prouveur peut facilement être satisfaite. Par conséquent, pour répondre aux exigences des étapes suivantes, la taille maximale de la preuve et le temps de validation maximum doivent être fixés simultanément.
Phase 1 requirement: "Reasonable non-trivial verification cost"
• Taille de la preuve : doit être inférieure à la taille de la preuve.
• Temps de vérification : La vitesse de verification de la preuve ne doit pas être plus lente que l'exécution native du programme (c'est-à-dire, elle ne doit pas être plus lente que l'exécution directe du calcul).
Ce sont les exigences minimales de concision pour s'assurer que la taille de la preuve et le temps de vérification ne seront pas pires que d'envoyer directement le témoin au vérificateur pour inspection directe.
Étape 2 et plus
• Taille maximale de la preuve : 256 KB.
• Temps de validation maximal : 16 millisecondes.
Ces plafonds ont été délibérément fixés à des niveaux assez élevés pour s'adapter aux nouvelles technologies de preuve rapide, même si elles peuvent entraîner des coûts de validation plus élevés. En même temps, ces plafonds excluent les preuves si coûteuses que pratiquement aucun projet ne serait prêt à les utiliser sur la blockchain.
Phase 1 de vitesse
La vitesse de preuve en un seul fil ne doit pas être plus de 100 000 fois plus lente que l'exécution native (applicable à diverses applications, pas seulement aux preuves de blocs Ethereum), et ne doit pas dépendre de la précompilation.
Plus précisément, supposons qu'un processeur RISC-V sur un ordinateur portable moderne fonctionne à une vitesse d'environ 30 milliards de cycles par seconde, alors atteindre l'étape 1 signifie que cet ordinateur portable peut générer une preuve à une vitesse de 30 000 cycles RISC-V par seconde (monotâche).
Le coût du validateur doit satisfaire aux normes de "coût de validation raisonnable non trivial" définies précédemment.
Phase 2 de vitesse
La preuve en simple thread ne doit pas être plus lente que l'exécution native de plus de 10 000 fois.
Ou, en raison des restrictions actuelles du CPU et du GPU sur certaines méthodes SNARK prometteuses (en particulier le SNARK de domaine binaire), cela peut être satisfait par FPGA (voire ASIC) à ce stade :
Calculer le nombre de cœurs RISC-V simulés à la vitesse native par FPGA.
Calculer, simuler et prouver le nombre de FPGA nécessaires pour exécuter (quasiment en temps réel) RISC-V.
Si la quantité de (2) n'excède pas 10 000 fois celle de (1), alors la phase 2 est satisfaite.
• Taille de la preuve : maximum 256 Ko.
• Temps de validation : maximum 16 millisecondes sur un CPU standard.
Phase 3 de vitesse
Sur la base de la phase 2 de la vitesse, réaliser des dépenses de preuve inférieures à 1000× (applicables à diverses applications), et utiliser obligatoirement une précompilation à synthèse automatique et vérification formelle. Fondamentalement, personnaliser dynamiquement l'ensemble d'instructions de chaque programme pour accélérer la génération de preuves, tout en garantissant l'accessibilité et la vérification formelle. (Pourquoi la précompilation est une arme à double tranchant et pourquoi écrire manuellement la précompilation n'est pas une méthode durable, veuillez vous référer à la section suivante.)
Étape 1 de la mémoire
Atteindre la phase de vitesse 1 avec moins de 2 Go de RAM tout en respectant les exigences de confidentialité zéro. Cette étape est cruciale pour les appareils mobiles ou les navigateurs et ouvre la voie à de nombreux cas d'utilisation zkVM côté client. Par exemple, les smartphones sont utilisés pour la confidentialité de l'emplacement, les identifiants d'identité, etc. Si la génération de preuves nécessite plus de 1-2 Go de RAM, la plupart des appareils mobiles ne pourront pas fonctionner.
Deux points importants à noter :
Même pour les calculs à grande échelle (nécessitant des milliards de cycles CPU pour une exécution native), le système de preuve doit également maintenir une limite de mémoire de 2 Go, faute de quoi sa pertinence serait limitée.
Phase 2 de la mémoire
Atteindre la phase de vitesse 1 (10 fois plus rapide que la phase de mémoire 1) avec moins de 200 Mo de mémoire.
Pourquoi réduire à 200 Mo? Considérez un scénario non blockchain: lorsque vous accédez à un site Web HTTPS, vous téléchargez des certificats d'authentification et de chiffrement. Si le site Web commençait à envoyer ces certificats sous forme de preuves zk, un grand site Web pourrait avoir besoin de générer des millions de preuves par seconde. Si chaque preuve nécessite 2 Go de mémoire, les besoins en ressources informatiques atteindraient un niveau PB, ce qui est clairement irréalisable. Par conséquent, réduire davantage l'utilisation de la mémoire est crucial pour les applications non blockchain.
Pré-compilation: Dernier kilomètre, ou béquille ?
La compilation anticipée fait référence à un système de contraintes SNARK spécifiquement optimisé pour des fonctions particulières (telles que le hachage, les signatures de courbe elliptique). Sur Ethereum, la compilation anticipée peut réduire les coûts de hachage de Merkle et de vérification de signature, mais une dépendance excessive à la compilation anticipée ne peut pas vraiment améliorer l'efficacité fondamentale de SNARK.
Problème de précompilation
1. Toujours trop lent : même avec la précompilation des hachages et des signatures, zkVM reste confronté à des problèmes d'inefficacité du système de preuve fondamental à l'intérieur et à l'extérieur de la blockchain.
2. Vulnérabilités de sécurité : Si la précompilation manuelle n'est pas vérifiée formellement, des vulnérabilités sont presque inévitablement présentes, ce qui peut entraîner des échecs de sécurité catastrophiques.
3. Mauvaise expérience des développeurs : Actuellement, de nombreux zkVM nécessitent que les développeurs écrivent manuellement des systèmes de contraintes, ce qui ressemble à la manière de programmer dans les années 1960, ce qui affecte considérablement l'expérience de développement.
4.测试基准误导：Si les tests de référence dépendent de la précompilation optimisée spécifique, cela pourrait induire en erreur les gens en les amenant à se concentrer sur la contrainte manuelle du système optimisé, plutôt que sur l'amélioration de la conception SNARK elle-même.
5. Coûts d'E/S et accès sans RAM Bien que la précompilation puisse améliorer les performances des tâches de chiffrement intenses, elle peut ne pas offrir d'accélération significative pour des charges de travail plus diversifiées, car elles génèrent des coûts importants lors de la transmission des entrées/sorties et ne peuvent pas utiliser la RAM.
Même dans l'environnement de la blockchain, dès que vous dépassez une seule couche L1 comme Ethereum (par exemple, si vous souhaitez construire une série de ponts inter-chaînes), vous serez confronté à des fonctions de hachage et des schémas de signature différents. Pour résoudre ce problème, une compilation constante est effectuée, ce qui n'est ni évolutif, ni présente d'énormes risques de sécurité.
Je crois vraiment que la précompilation reste essentielle à long terme, mais seulement si elle est automatiquement synthétisée et formellement vérifiée. Cela nous permet de conserver un avantage d'expérience pour les développeurs de zkVM tout en évitant les risques de sécurité catastrophiques. Cette perspective se reflète dans la phase 3.
Calendrier prévu
Je m'attends à ce que quelques zkVM atteignent plus tard cette année les étapes de vitesse 1 et de mémoire 1. Je pense que nous pourrons également réaliser l'étape de vitesse 2 au cours des deux prochaines années, mais il n'est pas clair pour le moment si nous pourrons atteindre cet objectif sans nouvelles pistes de recherche.
Je m'attends à ce que les étapes restantes (Étape de vitesse 3 et Étape de mémoire 2) prennent plusieurs années pour être réalisées.
Bien que cet article énumère séparément la sécurité et les performances de zkVM, les deux ne sont pas totalement indépendantes. À mesure que des failles dans zkVM sont découvertes, je m'attends à ce que la correction de certaines d'entre elles entraîne inévitablement une baisse significative des performances. Par conséquent, les résultats des tests de performance de zkVM devraient être considérés comme des données provisoires jusqu'à ce que zkVM atteigne la Phase de sécurité 2.
zkVM a un énorme potentiel pour démocratiser réellement la preuve de connaissance zéro, mais il est actuellement encore à un stade précoce, rempli de défis en matière de sécurité et souffre de sérieux goulots d'étranglement en termes de performances. Les spéculations du marché et les campagnes marketing rendent difficile de mesurer les progrès réels. Avec des jalons clairs en termes de sécurité et de performances, j'espère fournir une feuille de route qui dissipera les doutes. Nous atteindrons finalement nos objectifs, mais cela prendra du temps et un effort continu en recherche et développement.