Le chemin vers des zkVM sécurisés et efficaces : Comment suivre les progrès
Auteur original : a16z crypto
Golem, Odaily Planet Daily
zkVM (Zero Knowledge Virtual Machine) s'engage à "rendre la SNARK accessible au grand public", permettant à quiconque (même sans expertise professionnelle en SNARK) de prouver qu'il a correctement exécuté n'importe quel programme sur une entrée donnée (ou un témoin). Leur principal avantage réside dans l'expérience des développeurs, mais ils sont actuellement confrontés à d'énormes défis en termes de sécurité et de performances. Pour concrétiser la vision de zkVM, les concepteurs doivent surmonter ces défis. Dans cet article, j'ai répertorié les étapes possibles du développement de zkVM, qui prendront plusieurs années à compléter.
Défi
En termes de sécurité, zkVM est un projet logiciel hautement complexe et reste rempli de failles. En termes de performances, la vitesse d'exécution correcte du programme de preuve peut être des centaines de milliers de fois plus lente que l'exécution locale, ce qui rend la plupart des applications actuellement impossibles à déployer dans le monde réel.
Malgré ces défis réels, la plupart des entreprises de l'industrie de la blockchain décrivent le zkVM comme déployable immédiatement. En fait, certains projets ont déjà payé un coût de calcul considérable pour générer la preuve des activités on-chain. Cependant, comme le zkVM n'est pas encore parfait, il s'agit simplement d'une manière coûteuse de prétendre que le système est protégé par SNARK, alors qu'en réalité, il est soit protégé par une permission, soit pire encore, vulnérable aux attaques.
Nous sommes encore à plusieurs années de la réalisation d'un zkVM sécurisé et haute performance. Cet article propose une série d'objectifs spécifiques par étapes pour suivre les progrès du zkVM - ces objectifs peuvent éliminer la spéculation et aider la communauté à se concentrer sur de véritables progrès.
Phase de sécurité
Un zkVM basé sur SNARK comprend généralement deux composants principaux :
· Preuve interactive de l'oracle du polynôme (PIOP): Un cadre de preuve interactive pour prouver des déclarations sur les polynômes (ou des contraintes dérivées d'eux).
· Schéma d'engagement polynômial (PCS) : Assurez-vous que le prouveur ne peut pas mentir sur l'évaluation polynomiale sans être découvert.
zkVM essentiellement encode l'exécution efficace en systèmes de contraintes - ce qui signifie essentiellement qu'ils obligent la machine virtuelle à utiliser correctement les registres et la mémoire - puis prouvent ces contraintes satisfaites en appliquant SNARK.
La seule façon de garantir qu'un système aussi complexe que zkVM est exempt d'erreurs est la vérification formelle. Voici les phases de sécurité. La phase 1 se concentre sur le bon protocole, tandis que les phases 2 et 3 se concentrent sur la bonne implémentation.
Étape de sécurité 1: protocole correct
1、La vérification formelle de la fiabilité de PIOP;
2,PCS vérifie la preuve contraignante dans certains cas d'hypothèses cryptographiques ou modèles idéaux.
Si Fiat-Shamir est utilisé, la preuve concise obtenue en combinant PIOP et PCS est formellement vérifiée comme sûre dans le modèle de prédiction aléatoire (en renforçant si nécessaire avec d'autres hypothèses cryptographiques);
Le système de contraintes appliqué par PIOP est équivalent à la preuve formelle de la sémantique de VM.
Assembler toutes ces parties pour former une preuve SNARK unique et sécurisée, vérifiée formellement, pour exécuter n'importe quel programme spécifié en bytecode VM. Si le protocole vise à être à divulgation nulle, il est également nécessaire de vérifier formellement cette propriété pour garantir qu'aucune information sensible sur les témoins n'est divulguée.
Avertissement de récursivité : Si zkVM utilise la récursivité, il est impératif de vérifier chaque PIOP, engagement et système de contraintes impliqués à tout moment dans cette récursivité pour considérer cette phase comme achevée.
Étape de sécurité 2: Implémentation correcte du validateur
La vérification formelle prouve que l'implémentation réelle du vérificateur zkVM (utilisant Rust, Solidity, etc.) correspond au protocole de vérification de phase 1. Cela garantit que le protocole implémenté est raisonnable (et non seulement un design sur papier ou des spécifications inefficaces écrites en Lean, etc.).
La deuxième phase ne se concentre que sur la mise en œuvre du validateur (et non du prouveur) pour deux raisons. Premièrement, l'utilisation correcte du validateur est suffisante pour garantir la fiabilité (c'est-à-dire garantir que le validateur ne peut pas croire que toute déclaration fausse est en réalité vraie). Deuxièmement, la mise en œuvre du validateur zkVM est plus simple d'un ordre de grandeur que celle du prouveur.
Étape de sécurité 3: Implémentation correcte du vérificateur
La mise en œuvre concrète du vérificateur zkVM génère correctement la preuve du système de vérification de la phase 1 et de la phase 2, c'est-à-dire une vérification formelle. Cela garantit l'intégrité, c'est-à-dire que tout système utilisant zkVM ne sera pas bloqué par des énoncés non prouvables. Si le vérificateur a l'intention de mettre en œuvre la confidentialité, cette propriété doit être formellement vérifiée.
Calendrier prévisionnel
· Étape 1 : Nous pouvons nous attendre à des progrès graduels l'année prochaine (comme ZKLib). Mais il faudra au moins deux ans avant qu'un zkVM puisse pleinement satisfaire les exigences de la première étape ;
· Étapes 2 et 3 : Ces étapes peuvent progresser simultanément avec certains aspects de l'étape 1. Par exemple, certaines équipes ont déjà démontré que la mise en œuvre du vérificateur Plonk correspond au protocole décrit dans le document (bien que le protocole du document lui-même n'ait peut-être pas été entièrement vérifié). Cependant, je m'attends à ce qu'aucun zkVM n'atteigne l'étape 3 en moins de quatre ans - et peut-être plus longtemps.
Points clés à retenir : Fiat-Shamir sécurité et bytecode vérifié
Un facteur complexe majeur est l'existence de problèmes de recherche non résolus concernant la sécurité de la transformation de Fiat-Shamir. Les trois phases considèrent toutes Fiat-Shamir et l'oracle aléatoire comme faisant partie de leur sécurité inattaquable, mais en réalité, tout le paradigme pourrait présenter des failles. Cela est dû à la différence entre l'oracle aléatoire idéalisé et les fonctions de hachage réellement utilisées. Dans le pire des cas, en raison du problème de Fiat-Shamir, il pourrait être découvert ultérieurement que le système de la phase 2 n'est pas du tout sécurisé. Cela suscite de graves préoccupations et des recherches continues. Il se peut que nous ayons besoin de modifier la transformation elle-même pour mieux prévenir de telles failles.
Un système sans récursivité est théoriquement plus stable, car certains circuits impliqués dans certaines attaques connues sont similaires aux circuits utilisés dans les preuves récursives.
Un autre point important est que même si le programme informatique a été correctement exécuté (tel que spécifié par le bytecode), sa valeur est 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 pour la vérification formelle est généré - un défi énorme qui dépasse le cadre de cet article.
Sécurité dans l'ère post-quantique
Pendant au moins les cinq prochaines années (et peut-être plus longtemps), l'ordinateur quantique ne représentera pas une menace sérieuse, tandis que les failles constituent un risque de survie. Par conséquent, l'accent principal actuel devrait être mis sur la satisfaction des exigences de sécurité et de performance discutées dans cet article. Si nous pouvons utiliser des SNARK non sécurisés quantiquement pour répondre plus rapidement à ces exigences de sécurité, alors nous devrions le faire jusqu'à ce que les SNARK post-quantiques rattrapent, ou jusqu'à ce que les gens soient sérieusement préoccupés par la possibilité d'apparition d'ordinateurs quantiques liés au cryptage.
La situation actuelle des performances de zkVM
Actuellement, le coefficient de dépenses généré par le vérificateur zkVM est environ un million de fois le coût d'exécution natif. Si un programme nécessite X cycles pour s'exécuter, le coût de l'exécution correcte est d'environ X fois 1 million de cycles CPU. Il y a un an, c'était le cas, et c'est toujours le cas aujourd'hui.
Les récits populaires décrivent généralement ces dépenses de manière acceptable. Par exemple:
·“Le coût annuel de la génération de preuves pour l'ensemble du réseau principal d'Ethereum est inférieur à un million de dollars.”
·"Nous pouvons presque générer en temps réel la preuve de bloc Ethereum à l'aide d'un cluster composé de dizaines de GPU."
·"Notre dernier zkVM est 1000 fois plus rapide que son prédécesseur."
Bien que ces déclarations soient techniquement exactes, elles peuvent être trompeuses sans le contexte approprié. Par exemple :
· Bien que zkVM soit 1000 fois plus rapide que la version précédente, sa vitesse absolue reste très lente. Cela souligne davantage à quel point les choses sont mauvaises, plutôt que bonnes.
· Quelqu'un a déjà proposé d'augmenter de 10 fois la charge de calcul sur le réseau principal d'Ethereum. Cela rendrait les performances actuelles de zkVM plus lentes.
· La « preuve de quasi-temps réel des blocs d'Ethereum » dont on parle est encore beaucoup plus lente que ce que de nombreuses applications de la blockchain exigent (par exemple, le temps de bloc d'Optimism est de 2 secondes, beaucoup plus rapide que le temps de bloc de 12 secondes d'Ethereum).
·« Des dizaines de GPU fonctionnant en continu sans erreur » ne peuvent garantir une activité acceptable.
· Le fait que moins d'un million de dollars par an sont nécessaires pour prouver toutes les activités sur le réseau principal d'Ethereum reflète le fait qu'il ne coûte que environ 25 dollars par an pour qu'un nœud complet d'Ethereum effectue des calculs.
Pour les applications en dehors de la blockchain, de telles dépenses sont clairement trop élevées. Aucune parallélisation ou ingénierie ne peut compenser de telles dépenses énormes. Nous devrions considérer que la vitesse de zkVM ralentit par rapport à l'exécution native de base jusqu'à 100 000 fois - même si ce n'est que le premier pas. Une adoption réelle à grande échelle pourrait nécessiter des dépenses proches de 10 000 fois ou moins.
Comment mesurer les performances
Les performances SNARK se composent de trois éléments principaux :
· L'efficacité intrinsèque du système de preuve de travail.
Optimisation spécifique à l'application (par exemple, précompilation).
· Accélération logicielle et matérielle (par exemple GPU, FPGA ou CPU multi-cœurs).
Bien que les deux derniers soient cruciaux pour le déploiement réel, ils s'appliquent généralement à tout système de preuve, de sorte qu'ils ne reflètent pas nécessairement les coûts de base. Par exemple, l'ajout d'une accélération GPU et de précompilations dans zkEVM peut facilement entraîner un gain de performance de 50 fois, ce qui est bien plus rapide que les méthodes sans précompilation basées uniquement sur le CPU - suffisamment pour rendre un système intrinsèquement moins efficace semble supérieur à un système non affiné de la même manière.
Par conséquent, nous allons maintenant nous concentrer sur les performances de SNARK sans matériel spécialisé ni précompilation. Cela diffère des méthodes de test de référence actuelles, qui regroupent généralement ces trois facteurs en un seul "chiffre d'en-tête". Cela revient à évaluer la valeur d'un diamant en fonction de son temps de polissage plutôt que de sa pureté intrinsèque. Notre objectif est d'éliminer les coûts internes des systèmes de preuve générale - aidant la communauté à éliminer les facteurs perturbateurs et à se concentrer sur les véritables progrès de la conception du système de preuve.
Phase de performance
Voici 5 jalons de performance. Tout d'abord, nous devons réduire les coûts du vérificateur sur le CPU de plusieurs ordres de grandeur. Ce n'est qu'alors que l'accent devrait être mis sur la réduction supplémentaire via le matériel. Le taux d'utilisation de la mémoire doit également être amélioré.
À toutes les étapes ci-dessous, les développeurs n'ont pas besoin de personnaliser le code selon zkVM pour atteindre les performances nécessaires. L'expérience des développeurs est le principal avantage de zkVM. Sacrifier le DevEx pour répondre aux performances de référence serait contraire à la signification même de zkVM.
Ces mesures mettent l'accent sur le coût du prouveur. Cependant, si le coût du vérificateur est illimité (c'est-à-dire s'il n'y a pas de limite à la taille de la preuve ou au temps de vérification), il serait facile de satisfaire n'importe quelle mesure du prouveur. Ainsi, pour qu'un système soit conforme à la phase susmentionnée, il doit spécifier une limite maximale pour la taille de la preuve et le temps de vérification.
Exigences de performance
Étape 1 Exigence : "Coût de vérification raisonnable et non trivial" :
· Taille de la preuve : La taille de la preuve doit être inférieure à la taille de la signature.
· Temps de vérification : la vitesse de vérification ne doit pas être inférieure à celle du programme en cours d'exécution sur la machine locale (c'est-à-dire exécuter le calcul sans preuve de correction).
Ce sont les exigences minimales de concision. Ils garantissent que la taille de la preuve et le temps de vérification ne seront pas pires que d'envoyer le témoin aux validateurs et de permettre aux validateurs de vérifier directement sa justesse.
Phase 2 and later requirements:
· Taille de preuve maximale: 256 Ko.
· Temps de validation maximal : 16 millisecondes.
Ces valeurs de seuil sont intentionnellement augmentées pour s'adapter aux nouvelles technologies de preuve rapide qui pourraient entraîner des coûts de vérification plus élevés. Ils excluent également des preuves très coûteuses, de sorte que peu de projets sont prêts à les inclure dans la blockchain.
Étape 1 de vitesse
La preuve à un seul fil doit être au moins cent mille fois plus lente que l'exécution locale, mesurée dans une série d'applications (pas seulement la preuve de bloc Ethereum), sans dépendre de la précompilation.
Plus précisément, imaginez un processus RISC-V fonctionnant à environ 30 milliards de cycles par seconde sur un ordinateur portable moderne. Réaliser la phase 1 signifie que vous pouvez prouver environ 30 000 cycles RISC-V par seconde sur le même ordinateur portable (monotâche). Cependant, le coût de la vérification doit être "raisonnable et non trivial" comme mentionné précédemment.
Phase de vitesse 2
La preuve en un seul thread doit être au moins 10 000 fois plus lente que l'exécution native.
Ou, en raison de certains SNARK prometteurs (en particulier ceux basés sur des champs binaires) entravés par les CPU et GPU actuels, vous pouvez atteindre cette étape en comparant l'utilisation de FPGA (voire ASIC) :
Le nombre de cœurs RISC-V pouvant être simulés à la vitesse native par le FPGA;
Simuler et démontrer (presque) le nombre de FPGA nécessaires pour exécuter en temps quasi réel RISC-V.
Si le second est au plus 10 000 fois supérieur au premier, vous êtes éligible pour passer à la phase 2. Sur un CPU standard, la taille de la preuve doit être au plus de 256 Ko et le temps du validateur au plus de 16 millisecondes.
Étape 3 de vitesse
**En plus d'atteindre l'étape 2 de vitesse, vous pouvez également utiliser une mise en œuvre précompilée avec synthèse automatique et vérification formelle pour réduire les coûts de preuve de moins de 1000 fois (pour une large gamme d'applications). Fondamentalement, il est possible de personnaliser dynamiquement un jeu d'instructions pour chaque programme afin d'accélérer la preuve, mais de manière conviviale et vérifiable formellement.
Phase 1 de la mémoire
La vitesse de la phase 1 a été atteinte avec moins de 2 Go de mémoire requise pour le vérificateur (tout en étant également zéro connaissance).
Ceci est crucial pour de nombreux appareils mobiles ou navigateurs, ouvrant ainsi la voie à de nombreux cas d'utilisation zkVM côté client. La preuve côté client est essentielle car nos téléphones sont notre lien continu avec le monde réel : ils suivent notre emplacement, nos justificatifs, etc. Si la génération de preuves nécessite plus de 1-2 Go de mémoire, cela représente une charge excessive pour la plupart des appareils mobiles actuels. Deux points doivent être clarifiés :
· La limite de 2 Go d'espace s'applique aux grandes requêtes (nécessitant des milliards de cycles CPU pour s'exécuter localement). Les systèmes de preuve de limite d'espace pour les petites requêtes manquent de polyvalence.
· S'il est prouvé que le vérificateur est très lent, il est très facile de maintenir l'espace du vérificateur en dessous de 2 Go de mémoire. Par conséquent, pour rendre la phase de mémoire 1 moins simple, je demande que la vitesse de la phase 1 soit respectée dans la limite de 2 Go d'espace.
Phase de mémoire 2
La vitesse de la phase 1 a été atteinte avec une utilisation de mémoire inférieure à 200 Mo (10 fois meilleure que la phase 1 de la mémoire).
Pourquoi réduire en dessous de 2 Go ? Considérez un exemple non blockchain : chaque fois que vous accédez à un site Web via HTTPS, vous téléchargez un certificat pour l'authentification et le chiffrement. Au lieu de cela, le site peut envoyer des preuves zk détenant ces certificats. Un grand site Web peut émettre des millions de telles preuves par seconde. Si chaque preuve nécessite 2 Go de mémoire pour être générée, alors cela nécessiterait au total de la RAM de niveau PB. Réduire encore plus la consommation de mémoire est crucial pour les déploiements non blockchain.
Pré-compilation: Dernier kilomètre ou bâton?
Dans la conception de zkVM, la précompilation fait référence à des SNARK spécialisés conçus sur mesure pour des fonctionnalités spécifiques, tels que le hachage Keccak/SHA ou les opérations de groupe elliptique utilisées pour les signatures numériques. Dans Ethereum (où la plupart des travaux intensifs impliquent des hachages Merkle et des vérifications de signature), certaines précompilations faites manuellement peuvent réduire les coûts du vérificateur. Cependant, les utiliser comme béquilles ne permet pas aux SNARK d'atteindre leur objectif. Les raisons en sont les suivantes :
· Pour la plupart des applications (internes et externes à la blockchain), c'est encore trop lent : même avec la précompilation des hachages et des signatures, le zkVM actuel est encore trop lent (que ce soit à l'intérieur ou à l'extérieur de l'environnement blockchain) en raison de l'inefficacité du système de preuve fondamental.
· Panne de sécurité : Une précompilation manuscrite non officiellement validée est presque certainement truffée d'erreurs, ce qui pourrait entraîner des pannes de sécurité catastrophiques.
· Mauvaise expérience des développeurs : Dans la plupart des zkVM actuels, l'ajout de nouveaux précompilés signifie écrire manuellement un système de contraintes pour chaque fonction - essentiellement revenir à un flux de travail des années 1960. Même en utilisant les précompilés existants, les développeurs doivent refactoriser le code pour appeler chaque précompilé. Nous devrions optimiser la sécurité et l'expérience des développeurs, plutôt que de sacrifier les deux pour poursuivre des performances incrémentielles. Cela ne fait que prouver que les performances ne sont pas à la hauteur.
· Coûts d'E/S et pas de RAM : Bien que la précompilation puisse améliorer les performances des tâches de cryptage lourdes, elles pourraient ne pas offrir d'accélération significative pour des charges de travail plus variées, car elles entraînent des coûts importants lors de la transmission des entrées/sorties et ne peuvent pas utiliser la RAM. Même dans un environnement de blockchain, dès que vous dépassez des L1 monolithiques comme Ethereum (par exemple, si vous voulez construire une série de ponts inter-chaînes), vous serez confronté à des fonctions de hachage et des schémas de signature différents. Précompiler à plusieurs reprises sur cette question ne peut pas être étendu et présente d'énormes risques de sécurité.
Pour toutes ces raisons, notre tâche principale devrait être d'améliorer l'efficacité de zkVM sous-jacent. La meilleure technologie zkVM produira également les meilleurs précompilations. Je crois vraiment que les précompilations restent essentielles à long terme, mais à condition qu'elles soient automatiquement synthétisées et formellement vérifiées. De cette manière, nous pouvons maintenir l'avantage de l'expérience des développeurs zkVM tout en évitant les risques de sécurité catastrophiques. Cette perspective se reflète dans la phase 3 de la vitesse.
Calendrier prévisionnel
Je m'attends à ce que quelques zkVM atteignent plus tard cette année les phases de vitesse 1 et de mémoire 1. Je pense que nous atteindrons également la phase de vitesse 2 au cours des deux prochaines années, mais il n'est pas encore clair si nous pourrons atteindre cet objectif sans de nouvelles idées non encore apparues. Je prévois que les phases restantes (phase de vitesse 3 et phase de mémoire 2) prendront quelques années à se concrétiser.
Résumé
Bien que j'aie séparément déterminé les aspects de sécurité et de performance de zkVM dans cet article, ces aspects de zkVM ne sont pas totalement indépendants. Avec la découverte de plus de vulnérabilités dans zkVM, il est prévu que certaines vulnérabilités ne pourront être corrigées que si les performances chutent considérablement. Avant que zkVM n'atteigne le stade de sécurité 2, les performances devraient être mises en attente.
zkVM a le potentiel de rendre les preuves de connaissance nulle vraiment populaires, mais elles en sont encore à leurs débuts - pleines de défis en matière de sécurité et de coûts de performance énormes. Le battage médiatique et la publicité rendent difficile l'évaluation des progrès réels. En clarifiant les jalons de sécurité et de performance spécifiques, nous espérons fournir une feuille de route sans ambiguïté pour éliminer les distractions. Nous atteindrons nos objectifs, mais cela prendra du temps et des efforts continus.
Lien original
：
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: Comment mettre en œuvre de manière sécurisée et efficace zkVM par étapes (essentiel pour les développeurs)
zkVM (Zero Knowledge Virtual Machine) s'engage à "rendre la SNARK accessible au grand public", permettant à quiconque (même sans expertise professionnelle en SNARK) de prouver qu'il a correctement exécuté n'importe quel programme sur une entrée donnée (ou un témoin). Leur principal avantage réside dans l'expérience des développeurs, mais ils sont actuellement confrontés à d'énormes défis en termes de sécurité et de performances. Pour concrétiser la vision de zkVM, les concepteurs doivent surmonter ces défis. Dans cet article, j'ai répertorié les étapes possibles du développement de zkVM, qui prendront plusieurs années à compléter.
Défi
En termes de sécurité, zkVM est un projet logiciel hautement complexe et reste rempli de failles. En termes de performances, la vitesse d'exécution correcte du programme de preuve peut être des centaines de milliers de fois plus lente que l'exécution locale, ce qui rend la plupart des applications actuellement impossibles à déployer dans le monde réel.
Malgré ces défis réels, la plupart des entreprises de l'industrie de la blockchain décrivent le zkVM comme déployable immédiatement. En fait, certains projets ont déjà payé un coût de calcul considérable pour générer la preuve des activités on-chain. Cependant, comme le zkVM n'est pas encore parfait, il s'agit simplement d'une manière coûteuse de prétendre que le système est protégé par SNARK, alors qu'en réalité, il est soit protégé par une permission, soit pire encore, vulnérable aux attaques.
Nous sommes encore à plusieurs années de la réalisation d'un zkVM sécurisé et haute performance. Cet article propose une série d'objectifs spécifiques par étapes pour suivre les progrès du zkVM - ces objectifs peuvent éliminer la spéculation et aider la communauté à se concentrer sur de véritables progrès.
Phase de sécurité
Un zkVM basé sur SNARK comprend généralement deux composants principaux :
· Preuve interactive de l'oracle du polynôme (PIOP): Un cadre de preuve interactive pour prouver des déclarations sur les polynômes (ou des contraintes dérivées d'eux).
· Schéma d'engagement polynômial (PCS) : Assurez-vous que le prouveur ne peut pas mentir sur l'évaluation polynomiale sans être découvert.
zkVM essentiellement encode l'exécution efficace en systèmes de contraintes - ce qui signifie essentiellement qu'ils obligent la machine virtuelle à utiliser correctement les registres et la mémoire - puis prouvent ces contraintes satisfaites en appliquant SNARK.
La seule façon de garantir qu'un système aussi complexe que zkVM est exempt d'erreurs est la vérification formelle. Voici les phases de sécurité. La phase 1 se concentre sur le bon protocole, tandis que les phases 2 et 3 se concentrent sur la bonne implémentation.
Étape de sécurité 1: protocole correct
1、La vérification formelle de la fiabilité de PIOP;
2,PCS vérifie la preuve contraignante dans certains cas d'hypothèses cryptographiques ou modèles idéaux.
Si Fiat-Shamir est utilisé, la preuve concise obtenue en combinant PIOP et PCS est formellement vérifiée comme sûre dans le modèle de prédiction aléatoire (en renforçant si nécessaire avec d'autres hypothèses cryptographiques);
Le système de contraintes appliqué par PIOP est équivalent à la preuve formelle de la sémantique de VM.
Assembler toutes ces parties pour former une preuve SNARK unique et sécurisée, vérifiée formellement, pour exécuter n'importe quel programme spécifié en bytecode VM. Si le protocole vise à être à divulgation nulle, il est également nécessaire de vérifier formellement cette propriété pour garantir qu'aucune information sensible sur les témoins n'est divulguée.
Avertissement de récursivité : Si zkVM utilise la récursivité, il est impératif de vérifier chaque PIOP, engagement et système de contraintes impliqués à tout moment dans cette récursivité pour considérer cette phase comme achevée.
Étape de sécurité 2: Implémentation correcte du validateur
La vérification formelle prouve que l'implémentation réelle du vérificateur zkVM (utilisant Rust, Solidity, etc.) correspond au protocole de vérification de phase 1. Cela garantit que le protocole implémenté est raisonnable (et non seulement un design sur papier ou des spécifications inefficaces écrites en Lean, etc.).
La deuxième phase ne se concentre que sur la mise en œuvre du validateur (et non du prouveur) pour deux raisons. Premièrement, l'utilisation correcte du validateur est suffisante pour garantir la fiabilité (c'est-à-dire garantir que le validateur ne peut pas croire que toute déclaration fausse est en réalité vraie). Deuxièmement, la mise en œuvre du validateur zkVM est plus simple d'un ordre de grandeur que celle du prouveur.
Étape de sécurité 3: Implémentation correcte du vérificateur
La mise en œuvre concrète du vérificateur zkVM génère correctement la preuve du système de vérification de la phase 1 et de la phase 2, c'est-à-dire une vérification formelle. Cela garantit l'intégrité, c'est-à-dire que tout système utilisant zkVM ne sera pas bloqué par des énoncés non prouvables. Si le vérificateur a l'intention de mettre en œuvre la confidentialité, cette propriété doit être formellement vérifiée.
Calendrier prévisionnel
· Étape 1 : Nous pouvons nous attendre à des progrès graduels l'année prochaine (comme ZKLib). Mais il faudra au moins deux ans avant qu'un zkVM puisse pleinement satisfaire les exigences de la première étape ;
· Étapes 2 et 3 : Ces étapes peuvent progresser simultanément avec certains aspects de l'étape 1. Par exemple, certaines équipes ont déjà démontré que la mise en œuvre du vérificateur Plonk correspond au protocole décrit dans le document (bien que le protocole du document lui-même n'ait peut-être pas été entièrement vérifié). Cependant, je m'attends à ce qu'aucun zkVM n'atteigne l'étape 3 en moins de quatre ans - et peut-être plus longtemps.
Points clés à retenir : Fiat-Shamir sécurité et bytecode vérifié
Un facteur complexe majeur est l'existence de problèmes de recherche non résolus concernant la sécurité de la transformation de Fiat-Shamir. Les trois phases considèrent toutes Fiat-Shamir et l'oracle aléatoire comme faisant partie de leur sécurité inattaquable, mais en réalité, tout le paradigme pourrait présenter des failles. Cela est dû à la différence entre l'oracle aléatoire idéalisé et les fonctions de hachage réellement utilisées. Dans le pire des cas, en raison du problème de Fiat-Shamir, il pourrait être découvert ultérieurement que le système de la phase 2 n'est pas du tout sécurisé. Cela suscite de graves préoccupations et des recherches continues. Il se peut que nous ayons besoin de modifier la transformation elle-même pour mieux prévenir de telles failles.
Un système sans récursivité est théoriquement plus stable, car certains circuits impliqués dans certaines attaques connues sont similaires aux circuits utilisés dans les preuves récursives.
Un autre point important est que même si le programme informatique a été correctement exécuté (tel que spécifié par le bytecode), sa valeur est 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 pour la vérification formelle est généré - un défi énorme qui dépasse le cadre de cet article.
Sécurité dans l'ère post-quantique
Pendant au moins les cinq prochaines années (et peut-être plus longtemps), l'ordinateur quantique ne représentera pas une menace sérieuse, tandis que les failles constituent un risque de survie. Par conséquent, l'accent principal actuel devrait être mis sur la satisfaction des exigences de sécurité et de performance discutées dans cet article. Si nous pouvons utiliser des SNARK non sécurisés quantiquement pour répondre plus rapidement à ces exigences de sécurité, alors nous devrions le faire jusqu'à ce que les SNARK post-quantiques rattrapent, ou jusqu'à ce que les gens soient sérieusement préoccupés par la possibilité d'apparition d'ordinateurs quantiques liés au cryptage.
La situation actuelle des performances de zkVM
Actuellement, le coefficient de dépenses généré par le vérificateur zkVM est environ un million de fois le coût d'exécution natif. Si un programme nécessite X cycles pour s'exécuter, le coût de l'exécution correcte est d'environ X fois 1 million de cycles CPU. Il y a un an, c'était le cas, et c'est toujours le cas aujourd'hui.
Les récits populaires décrivent généralement ces dépenses de manière acceptable. Par exemple:
·“Le coût annuel de la génération de preuves pour l'ensemble du réseau principal d'Ethereum est inférieur à un million de dollars.”
·"Nous pouvons presque générer en temps réel la preuve de bloc Ethereum à l'aide d'un cluster composé de dizaines de GPU."
·"Notre dernier zkVM est 1000 fois plus rapide que son prédécesseur."
Bien que ces déclarations soient techniquement exactes, elles peuvent être trompeuses sans le contexte approprié. Par exemple :
· Bien que zkVM soit 1000 fois plus rapide que la version précédente, sa vitesse absolue reste très lente. Cela souligne davantage à quel point les choses sont mauvaises, plutôt que bonnes.
· Quelqu'un a déjà proposé d'augmenter de 10 fois la charge de calcul sur le réseau principal d'Ethereum. Cela rendrait les performances actuelles de zkVM plus lentes.
· La « preuve de quasi-temps réel des blocs d'Ethereum » dont on parle est encore beaucoup plus lente que ce que de nombreuses applications de la blockchain exigent (par exemple, le temps de bloc d'Optimism est de 2 secondes, beaucoup plus rapide que le temps de bloc de 12 secondes d'Ethereum).
·« Des dizaines de GPU fonctionnant en continu sans erreur » ne peuvent garantir une activité acceptable.
· Le fait que moins d'un million de dollars par an sont nécessaires pour prouver toutes les activités sur le réseau principal d'Ethereum reflète le fait qu'il ne coûte que environ 25 dollars par an pour qu'un nœud complet d'Ethereum effectue des calculs.
Pour les applications en dehors de la blockchain, de telles dépenses sont clairement trop élevées. Aucune parallélisation ou ingénierie ne peut compenser de telles dépenses énormes. Nous devrions considérer que la vitesse de zkVM ralentit par rapport à l'exécution native de base jusqu'à 100 000 fois - même si ce n'est que le premier pas. Une adoption réelle à grande échelle pourrait nécessiter des dépenses proches de 10 000 fois ou moins.
Comment mesurer les performances
Les performances SNARK se composent de trois éléments principaux :
· L'efficacité intrinsèque du système de preuve de travail.
Optimisation spécifique à l'application (par exemple, précompilation).
· Accélération logicielle et matérielle (par exemple GPU, FPGA ou CPU multi-cœurs).
Bien que les deux derniers soient cruciaux pour le déploiement réel, ils s'appliquent généralement à tout système de preuve, de sorte qu'ils ne reflètent pas nécessairement les coûts de base. Par exemple, l'ajout d'une accélération GPU et de précompilations dans zkEVM peut facilement entraîner un gain de performance de 50 fois, ce qui est bien plus rapide que les méthodes sans précompilation basées uniquement sur le CPU - suffisamment pour rendre un système intrinsèquement moins efficace semble supérieur à un système non affiné de la même manière.
Par conséquent, nous allons maintenant nous concentrer sur les performances de SNARK sans matériel spécialisé ni précompilation. Cela diffère des méthodes de test de référence actuelles, qui regroupent généralement ces trois facteurs en un seul "chiffre d'en-tête". Cela revient à évaluer la valeur d'un diamant en fonction de son temps de polissage plutôt que de sa pureté intrinsèque. Notre objectif est d'éliminer les coûts internes des systèmes de preuve générale - aidant la communauté à éliminer les facteurs perturbateurs et à se concentrer sur les véritables progrès de la conception du système de preuve.
Phase de performance
Voici 5 jalons de performance. Tout d'abord, nous devons réduire les coûts du vérificateur sur le CPU de plusieurs ordres de grandeur. Ce n'est qu'alors que l'accent devrait être mis sur la réduction supplémentaire via le matériel. Le taux d'utilisation de la mémoire doit également être amélioré.
À toutes les étapes ci-dessous, les développeurs n'ont pas besoin de personnaliser le code selon zkVM pour atteindre les performances nécessaires. L'expérience des développeurs est le principal avantage de zkVM. Sacrifier le DevEx pour répondre aux performances de référence serait contraire à la signification même de zkVM.
Ces mesures mettent l'accent sur le coût du prouveur. Cependant, si le coût du vérificateur est illimité (c'est-à-dire s'il n'y a pas de limite à la taille de la preuve ou au temps de vérification), il serait facile de satisfaire n'importe quelle mesure du prouveur. Ainsi, pour qu'un système soit conforme à la phase susmentionnée, il doit spécifier une limite maximale pour la taille de la preuve et le temps de vérification.
Exigences de performance
Étape 1 Exigence : "Coût de vérification raisonnable et non trivial" :
· Taille de la preuve : La taille de la preuve doit être inférieure à la taille de la signature.
· Temps de vérification : la vitesse de vérification ne doit pas être inférieure à celle du programme en cours d'exécution sur la machine locale (c'est-à-dire exécuter le calcul sans preuve de correction).
Ce sont les exigences minimales de concision. Ils garantissent que la taille de la preuve et le temps de vérification ne seront pas pires que d'envoyer le témoin aux validateurs et de permettre aux validateurs de vérifier directement sa justesse.
Phase 2 and later requirements:
· Taille de preuve maximale: 256 Ko.
· Temps de validation maximal : 16 millisecondes.
Ces valeurs de seuil sont intentionnellement augmentées pour s'adapter aux nouvelles technologies de preuve rapide qui pourraient entraîner des coûts de vérification plus élevés. Ils excluent également des preuves très coûteuses, de sorte que peu de projets sont prêts à les inclure dans la blockchain.
Étape 1 de vitesse
La preuve à un seul fil doit être au moins cent mille fois plus lente que l'exécution locale, mesurée dans une série d'applications (pas seulement la preuve de bloc Ethereum), sans dépendre de la précompilation.
Plus précisément, imaginez un processus RISC-V fonctionnant à environ 30 milliards de cycles par seconde sur un ordinateur portable moderne. Réaliser la phase 1 signifie que vous pouvez prouver environ 30 000 cycles RISC-V par seconde sur le même ordinateur portable (monotâche). Cependant, le coût de la vérification doit être "raisonnable et non trivial" comme mentionné précédemment.
Phase de vitesse 2
La preuve en un seul thread doit être au moins 10 000 fois plus lente que l'exécution native.
Ou, en raison de certains SNARK prometteurs (en particulier ceux basés sur des champs binaires) entravés par les CPU et GPU actuels, vous pouvez atteindre cette étape en comparant l'utilisation de FPGA (voire ASIC) :
Le nombre de cœurs RISC-V pouvant être simulés à la vitesse native par le FPGA;
Simuler et démontrer (presque) le nombre de FPGA nécessaires pour exécuter en temps quasi réel RISC-V.
Si le second est au plus 10 000 fois supérieur au premier, vous êtes éligible pour passer à la phase 2. Sur un CPU standard, la taille de la preuve doit être au plus de 256 Ko et le temps du validateur au plus de 16 millisecondes.
Étape 3 de vitesse
**En plus d'atteindre l'étape 2 de vitesse, vous pouvez également utiliser une mise en œuvre précompilée avec synthèse automatique et vérification formelle pour réduire les coûts de preuve de moins de 1000 fois (pour une large gamme d'applications). Fondamentalement, il est possible de personnaliser dynamiquement un jeu d'instructions pour chaque programme afin d'accélérer la preuve, mais de manière conviviale et vérifiable formellement.
Phase 1 de la mémoire
La vitesse de la phase 1 a été atteinte avec moins de 2 Go de mémoire requise pour le vérificateur (tout en étant également zéro connaissance).
Ceci est crucial pour de nombreux appareils mobiles ou navigateurs, ouvrant ainsi la voie à de nombreux cas d'utilisation zkVM côté client. La preuve côté client est essentielle car nos téléphones sont notre lien continu avec le monde réel : ils suivent notre emplacement, nos justificatifs, etc. Si la génération de preuves nécessite plus de 1-2 Go de mémoire, cela représente une charge excessive pour la plupart des appareils mobiles actuels. Deux points doivent être clarifiés :
· La limite de 2 Go d'espace s'applique aux grandes requêtes (nécessitant des milliards de cycles CPU pour s'exécuter localement). Les systèmes de preuve de limite d'espace pour les petites requêtes manquent de polyvalence.
· S'il est prouvé que le vérificateur est très lent, il est très facile de maintenir l'espace du vérificateur en dessous de 2 Go de mémoire. Par conséquent, pour rendre la phase de mémoire 1 moins simple, je demande que la vitesse de la phase 1 soit respectée dans la limite de 2 Go d'espace.
Phase de mémoire 2
La vitesse de la phase 1 a été atteinte avec une utilisation de mémoire inférieure à 200 Mo (10 fois meilleure que la phase 1 de la mémoire).
Pourquoi réduire en dessous de 2 Go ? Considérez un exemple non blockchain : chaque fois que vous accédez à un site Web via HTTPS, vous téléchargez un certificat pour l'authentification et le chiffrement. Au lieu de cela, le site peut envoyer des preuves zk détenant ces certificats. Un grand site Web peut émettre des millions de telles preuves par seconde. Si chaque preuve nécessite 2 Go de mémoire pour être générée, alors cela nécessiterait au total de la RAM de niveau PB. Réduire encore plus la consommation de mémoire est crucial pour les déploiements non blockchain.
Pré-compilation: Dernier kilomètre ou bâton?
Dans la conception de zkVM, la précompilation fait référence à des SNARK spécialisés conçus sur mesure pour des fonctionnalités spécifiques, tels que le hachage Keccak/SHA ou les opérations de groupe elliptique utilisées pour les signatures numériques. Dans Ethereum (où la plupart des travaux intensifs impliquent des hachages Merkle et des vérifications de signature), certaines précompilations faites manuellement peuvent réduire les coûts du vérificateur. Cependant, les utiliser comme béquilles ne permet pas aux SNARK d'atteindre leur objectif. Les raisons en sont les suivantes :
· Pour la plupart des applications (internes et externes à la blockchain), c'est encore trop lent : même avec la précompilation des hachages et des signatures, le zkVM actuel est encore trop lent (que ce soit à l'intérieur ou à l'extérieur de l'environnement blockchain) en raison de l'inefficacité du système de preuve fondamental.
· Panne de sécurité : Une précompilation manuscrite non officiellement validée est presque certainement truffée d'erreurs, ce qui pourrait entraîner des pannes de sécurité catastrophiques.
· Mauvaise expérience des développeurs : Dans la plupart des zkVM actuels, l'ajout de nouveaux précompilés signifie écrire manuellement un système de contraintes pour chaque fonction - essentiellement revenir à un flux de travail des années 1960. Même en utilisant les précompilés existants, les développeurs doivent refactoriser le code pour appeler chaque précompilé. Nous devrions optimiser la sécurité et l'expérience des développeurs, plutôt que de sacrifier les deux pour poursuivre des performances incrémentielles. Cela ne fait que prouver que les performances ne sont pas à la hauteur.
· Coûts d'E/S et pas de RAM : Bien que la précompilation puisse améliorer les performances des tâches de cryptage lourdes, elles pourraient ne pas offrir d'accélération significative pour des charges de travail plus variées, car elles entraînent des coûts importants lors de la transmission des entrées/sorties et ne peuvent pas utiliser la RAM. Même dans un environnement de blockchain, dès que vous dépassez des L1 monolithiques comme Ethereum (par exemple, si vous voulez construire une série de ponts inter-chaînes), vous serez confronté à des fonctions de hachage et des schémas de signature différents. Précompiler à plusieurs reprises sur cette question ne peut pas être étendu et présente d'énormes risques de sécurité.
Pour toutes ces raisons, notre tâche principale devrait être d'améliorer l'efficacité de zkVM sous-jacent. La meilleure technologie zkVM produira également les meilleurs précompilations. Je crois vraiment que les précompilations restent essentielles à long terme, mais à condition qu'elles soient automatiquement synthétisées et formellement vérifiées. De cette manière, nous pouvons maintenir l'avantage de l'expérience des développeurs zkVM tout en évitant les risques de sécurité catastrophiques. Cette perspective se reflète dans la phase 3 de la vitesse.
Calendrier prévisionnel
Je m'attends à ce que quelques zkVM atteignent plus tard cette année les phases de vitesse 1 et de mémoire 1. Je pense que nous atteindrons également la phase de vitesse 2 au cours des deux prochaines années, mais il n'est pas encore clair si nous pourrons atteindre cet objectif sans de nouvelles idées non encore apparues. Je prévois que les phases restantes (phase de vitesse 3 et phase de mémoire 2) prendront quelques années à se concrétiser.
Résumé
Bien que j'aie séparément déterminé les aspects de sécurité et de performance de zkVM dans cet article, ces aspects de zkVM ne sont pas totalement indépendants. Avec la découverte de plus de vulnérabilités dans zkVM, il est prévu que certaines vulnérabilités ne pourront être corrigées que si les performances chutent considérablement. Avant que zkVM n'atteigne le stade de sécurité 2, les performances devraient être mises en attente.
zkVM a le potentiel de rendre les preuves de connaissance nulle vraiment populaires, mais elles en sont encore à leurs débuts - pleines de défis en matière de sécurité et de coûts de performance énormes. Le battage médiatique et la publicité rendent difficile l'évaluation des progrès réels. En clarifiant les jalons de sécurité et de performance spécifiques, nous espérons fournir une feuille de route sans ambiguïté pour éliminer les distractions. Nous atteindrons nos objectifs, mais cela prendra du temps et des efforts continus.
Lien original
：