a16z : Comment réaliser progressivement un zkVM sécurisé et efficace ?
TechFlow SélectionTechFlow Sélection
a16z : Comment réaliser progressivement un zkVM sécurisé et efficace ?
Indispensable pour les développeurs.
Dédié à des analyses Web3 approfondiesRédaction : a16z crypto
Traduction : Golem, Odaily Planet Daily
Les zkVM (machines virtuelles à connaissances nulles) promettent de « démocratiser les SNARK », permettant à toute personne – même sans expertise spécifique en SNARK – de prouver qu'elle a correctement exécuté un programme donné sur une entrée (ou témoin) spécifique. Leur principal avantage réside dans l'expérience des développeurs, mais actuellement, elles font face à d’énormes défis en matière de sécurité et de performances. Pour que la vision des zkVM puisse tenir ses promesses, leurs concepteurs doivent relever ces défis. Dans cet article, je présente les étapes possibles du développement des zkVM, dont la réalisation prendra plusieurs années.
Défis
En termes de sécurité, les zkVM sont des projets logiciels extrêmement complexes, encore truffés de vulnérabilités. En matière de performance, le temps nécessaire pour produire une preuve d'exécution correcte d’un programme peut être jusqu’à cent mille fois plus lent que son exécution native, rendant la plupart des applications impossibles à déployer concrètement aujourd’hui.
Malgré ces obstacles concrets, la majorité des entreprises du secteur blockchain présentent les zkVM comme immédiatement déployables. En effet, certains projets ont déjà engagé des coûts massifs en calcul pour générer des preuves des activités sur chaîne. Mais comme les zkVM ne sont pas encore matures, cela revient simplement à simuler un système protégé par des SNARK de manière coûteuse, alors qu’en réalité il est soit protégé par permission, soit pire encore, vulnérable aux attaques.
Nous sommes encore à plusieurs années d’une zkVM sécurisée et performante. Cet article propose une série d’étapes concrètes et progressivement définies afin de suivre l’avancement des zkVM – des objectifs qui permettraient d’éliminer les spéculations et d’aider la communauté à se concentrer sur des progrès réels.
Étapes de sécurité
Les zkVM basées sur des SNARK comprennent généralement deux composants principaux :
-
Un Protocole Interactif d'Oracle Polynomial (PIOP) : un cadre de preuve interactive utilisé pour démontrer des énoncés relatifs à des polynômes (ou aux contraintes qui en découlent).
-
Un schéma de compromis polynomial (PCS) : garantit que le prouveur ne peut pas mentir impunément sur les évaluations des polynômes.
Fondamentalement, une zkVM code une trace d’exécution valide sous forme de système de contraintes – c’est-à-dire qu’elle impose que la machine virtuelle utilise correctement registres et mémoire – puis applique un SNARK pour prouver que ces contraintes sont satisfaites.
La seule façon de s'assurer qu'un système aussi complexe qu'une zkVM ne contient pas d'erreurs est la vérification formelle. Voici la répartition des étapes de sécurité. L'étape 1 porte sur un protocole correct ; les étapes 2 et 3 portent sur une implémentation correcte.
Étape de sécurité 1 : protocole correct
-
Preuve formellement vérifiée de la solidité du PIOP ;
-
Preuve formellement vérifiée que le PCS est contraignant sous certaines hypothèses cryptographiques ou dans un modèle idéal ;
-
Si Fiat-Shamir est utilisé, preuve formellement vérifiée que l'argument succinct obtenu en combinant PIOP et PCS est sécurisé dans le modèle de l'oracle aléatoire (avec renforcement si nécessaire via d'autres hypothèses cryptographiques) ;
-
Preuve formellement vérifiée que le système de contraintes auquel le PIOP s'applique est équivalent à la sémantique de la VM ;
-
Intégration complète et formellement vérifiée de tous les éléments ci-dessus en une preuve SNARK unique et sécurisée, capable de prouver tout programme spécifié par un bytecode VM. Si le protocole vise à être à connaissance nulle, cette propriété doit également faire l’objet d’une vérification formelle afin de garantir qu’aucune information sensible sur le témoin n’est divulguée.
Avertissement sur la récursion : si la zkVM utilise la récursion, chaque PIOP, schéma de compromis et système de contraintes impliqué dans cette récursion doit être validé pour que cette étape soit considérée comme terminée.
Étape de sécurité 2 : implémentation correcte du vérificateur
Preuve formellement vérifiée que l’implémentation réelle du vérificateur zkVM (en Rust, Solidity, etc.) correspond bien au protocole validé à l’étape 1. Réaliser ceci garantit que le protocole implémenté est effectivement valable (et non seulement un design théorique ou une spécification inefficace écrite en Lean, par exemple).
Le fait que l’étape 2 se concentre uniquement sur le vérificateur (et non sur le prouveur) s’explique par deux raisons. Premièrement, une utilisation correcte du vérificateur suffit déjà à assurer la fiabilité (c’est-à-dire garantir qu’aucun faux énoncé ne sera accepté comme vrai). Deuxièmement, l’implémentation du vérificateur zkVM est plus simple d’un ordre de grandeur ou plus que celle du prouveur.
Étape de sécurité 3 : implémentation correcte du prouveur
L’implémentation réelle du prouveur zkVM génère correctement les preuves du système validé aux étapes 1 et 2, ce qui doit être formellement vérifié. Cela garantit l’intégrité, c’est-à-dire qu’aucun système utilisant la zkVM ne sera bloqué par des énoncés impossibles à prouver. Si le prouveur vise à être à connaissance nulle, cette propriété doit également être formellement vérifiée.
Calendrier prévu
Progrès de l’étape 1 : nous pouvons espérer des réalisations progressives l’année prochaine (par exemple ZKLib). Mais aucune zkVM ne pourra pleinement satisfaire aux exigences de l’étape 1 avant au moins deux ans.
Étapes 2 et 3 : ces étapes peuvent avancer simultanément avec certaines parties de l’étape 1. Par exemple, certaines équipes ont déjà prouvé que l’implémentation d’un vérificateur Plonk correspond bien au protocole décrit dans les articles (bien que le protocole lui-même puisse ne pas avoir été entièrement vérifié). Malgré cela, je prévois qu’aucune zkVM n’atteindra l’étape 3 avant quatre ans au minimum – voire davantage.
Points clés : sécurité de Fiat-Shamir et bytecode vérifié
Un facteur majeur de complexité réside dans les problèmes de recherche non résolus concernant la sécurité de la transformation Fiat-Shamir. Les trois étapes supposent Fiat-Shamir et l’oracle aléatoire comme partie intégrante de leur sécurité infaillible, mais en réalité, tout le paradigme pourrait présenter des failles dues à l’écart entre l’oracle aléatoire (trop idéalisé) et les fonctions de hachage réellement utilisées. Dans le pire des cas, un système ayant atteint l’étape 2 pourrait s’avérer totalement non sécurisé à cause de problèmes liés à Fiat-Shamir. Cela suscite de graves inquiétudes et motive des recherches continues. Nous pourrions devoir modifier la transformation elle-même pour mieux résister à de telles vulnérabilités.
Les systèmes sans récursion sont théoriquement plus robustes, car certaines attaques connues exploitent des circuits similaires à ceux utilisés dans les preuves récursives.
Un autre point important : si le bytecode lui-même comporte des erreurs, la valeur de la preuve – même correctement générée pour un programme informatique spécifié par ce bytecode – reste limitée. Ainsi, l'utilité pratique d'une zkVM dépend fortement de méthodes permettant de générer du bytecode formellement vérifié – un défi colossal qui dépasse le cadre de cet article.
Sécurité à l’ère post-quantique
Pendant au moins les cinq prochaines années (probablement davantage), les ordinateurs quantiques ne constitueront pas une menace sérieuse, tandis que les vulnérabilités restent un risque existentiel. L’objectif principal devrait donc consister à satisfaire aux étapes de sécurité et de performance discutées ici. Si nous pouvons atteindre ces objectifs de sécurité plus rapidement grâce à des SNARK non sécurisés contre les ordinateurs quantiques, nous devrions le faire, jusqu’à ce que des SNARK post-quantiques rattrapent leur retard, ou que la menace d’ordinateurs quantiques perturbant la cryptographie devienne concrète.
État actuel des performances des zkVM
Actuellement, le facteur de surcoût généré par le prouveur zkVM approche le 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 preuve de son exécution correcte est d’environ X multiplié par un million de cycles CPU. Cette situation était vraie il y a un an, et elle l’est toujours aujourd’hui.
Les récits populaires décrivent souvent ce surcoût de manière apparemment acceptable. Par exemple :
-
« Coût inférieur à un million de dollars par an pour générer des preuves de toutes les activités du réseau principal Ethereum. »
-
« Nous pouvons presque générer en temps réel les preuves des blocs Ethereum avec un cluster composé de dizaines de GPU. »
-
« Notre dernière zkVM est 1000 fois plus rapide que sa prédécesseure. »
Bien que techniquement exacts, ces énoncés peuvent être trompeurs sans contexte approprié. Par exemple :
-
Être 1000 fois plus rapide qu’une ancienne zkVM ne change rien si la vitesse absolue reste très lente. Cela illustre davantage à quel point la situation est mauvaise qu’à quel point elle est bonne.
-
On a proposé d’augmenter de 10 fois la charge de calcul traitée par le réseau principal Ethereum. Cela rendrait les performances actuelles des zkVM encore moins viables.
-
Ce que l’on appelle « preuve quasi en temps réel des blocs Ethereum » reste beaucoup plus lent que ce que demandent de nombreuses applications blockchain (par exemple, Optimism a un temps de bloc de 2 secondes, bien plus rapide que les 12 secondes d’Ethereum).
-
« Des dizaines de GPU fonctionnant en permanence sans erreur » ne garantissent pas une activité fiable acceptable.
-
Dépenser moins d’un million de dollars par an pour prouver toutes les activités d’Ethereum reflète simplement le fait qu’un nœud complet Ethereum ne coûte que 25 dollars par an environ en calcul.
Pour les applications hors blockchain, un tel surcoût est manifestement trop élevé. Aucune parallélisation ni ingénierie ne peut compenser un tel écart. Nous devrions considérer comme seuil minimal que les zkVM ne ralentissent pas de plus de 100 000 fois par rapport à l’exécution native – même si ce n’est qu’un premier pas. Une adoption massive nécessitera probablement un surcoût proche de 10 000 fois ou moins.
Comment mesurer les performances
Les performances d’un SNARK reposent sur trois composantes principales :
-
L’efficacité intrinsèque du système de preuve sous-jacent.
-
Les optimisations spécifiques à l’application (par exemple, les précompilations).
-
L’ingénierie et l’accélération matérielle (GPU, FPGA ou processeurs multicœurs).
Bien que les deux derniers points soient cruciaux pour le déploiement pratique, ils s’appliquent généralement à tout système de preuve et ne reflètent donc pas nécessairement le surcoût fondamental. Par exemple, ajouter une accélération GPU et des précompilations à un zkEVM peut facilement apporter un gain de 50 fois, ce qui rend un système intrinsèquement inefficace semblable à un système plus performant – simplement parce qu’il est mieux optimisé.
Par conséquent, l’accent est mis ici sur les performances des SNARK sans matériel spécialisé ni précompilations. Ceci diffère des méthodes courantes de benchmark, qui regroupent souvent les trois facteurs en un seul « chiffre phare ». C’est comme juger la valeur d’un diamant par son temps de polissage plutôt que par sa pureté intrinsèque. L’objectif est d’isoler le surcoût intrinsèque des systèmes de preuve génériques – aidant ainsi la communauté à distinguer le signal du bruit et à se concentrer sur les véritables progrès en conception.
Étapes de performance
Voici cinq jalons de performance. D’abord, nous devons réduire le surcoût du prouveur sur CPU de plusieurs ordres de grandeur. Seulement après cela, l’accent devrait porter sur la réduction via le matériel. L’utilisation mémoire doit également être améliorée.
Dans toutes les étapes ci-dessous, les développeurs ne doivent pas avoir à personnaliser manuellement du code selon la configuration zkVM pour atteindre les performances requises. L’expérience développeur est l’avantage principal des zkVM. Sacrifier cette expérience pour atteindre des objectifs de performance va à l’encontre même de leur objectif.
Ces indicateurs se concentrent sur le coût du prouveur. Toutefois, n’importe quel indicateur du prouveur peut être facilement satisfait si le coût du vérificateur est illimité (c’est-à-dire sans borne sur la taille de la preuve ou le temps de vérification). Par conséquent, pour qu’un système corresponde à une étape donnée, des limites maximales doivent être fixées pour la taille de la preuve et le temps de vérification.
Exigences de performance
Exigence de l’étape 1 : « coût de vérification raisonnable et non trivial » :
-
Taille de la preuve : la taille de la preuve doit être inférieure à celle du témoin.
-
Temps de vérification : la vérification de la preuve ne doit pas être plus lente que l’exécution native du programme (c’est-à-dire l’exécution du calcul sans preuve de correction).
Ce sont les exigences minimales de concision. Elles garantissent que la taille de la preuve et le temps de vérification ne soient pas pires que d’envoyer directement le témoin au vérificateur pour qu’il en vérifie la validité.
Exigences pour l’étape 2 et au-delà :
-
Taille maximale de la preuve : 256 Ko.
-
Temps maximal de vérification : 16 millisecondes.
Ces seuils sont volontairement généreux pour accommoder de nouvelles techniques de preuve rapides pouvant entraîner des coûts plus élevés. En même temps, ils excluent les preuves trop chères pour être intégrées dans une blockchain par la plupart des projets.
Vitesse – Étape 1
La preuve monothread doit être au maximum cent mille fois plus lente que l’exécution native, mesurée sur une série d’applications (pas seulement la preuve de blocs Ethereum), sans recourir aux précompilations.
Plus précisément, imaginez un processeur RISC-V fonctionnant sur un ordinateur portable moderne à environ 3 milliards de cycles par seconde. Atteindre l’étape 1 signifie pouvoir prouver environ 30 000 cycles RISC-V par seconde (monothread) sur le même appareil. Le coût de vérification doit rester « raisonnable et non trivial », comme défini précédemment.
Vitesse – Étape 2
La preuve monothread doit être au maximum dix mille fois plus lente que l’exécution native.
Ou, étant donné que certaines méthodes SNARK prometteuses (notamment celles basées sur des corps binaires) sont freinées par les CPU et GPU actuels, vous pouvez atteindre cette étape en comparant via FPGA (voire ASIC) :
-
Nombre de cœurs RISC-V que l’on peut simuler à vitesse native sur FPGA ;
-
Nombre de FPGA nécessaires pour simuler et prouver une exécution RISC-V quasi en temps réel.
Si le second nombre est au plus 10 000 fois supérieur au premier, vous êtes éligible pour l’étape 2. Sur CPU standard, la taille de la preuve doit être au maximum de 256 Ko et le temps du vérificateur au maximum de 16 ms.
Vitesse – Étape 3
Outre l’atteinte de l’étape 2, il faut obtenir un surcoût de preuve inférieur à 1000 fois grâce à des précompilations synthétisées automatiquement et formellement vérifiées (applicables à de nombreuses applications). En substance, on peut personnaliser dynamiquement le jeu d'instructions pour chaque programme afin d'accélérer la preuve, mais de manière conviviale et formellement vérifiée.
Mémoire – Étape 1
L’étape 1 de vitesse est atteinte lorsque la mémoire requise par le prouveur est inférieure à 2 Go (avec preuve à connaissance nulle).
Ceci est crucial pour de nombreux appareils mobiles ou navigateurs, ouvrant ainsi une multitude d’applications zkVM côté client. Les preuves côté client sont importantes car nos téléphones sont notre lien constant avec le monde réel : ils suivent notre localisation, nos identifiants, etc. Si la génération d’une preuve nécessite plus de 1-2 Go de RAM, cela devient impossible pour la plupart des appareils mobiles actuels. Deux précisions :
-
La limite de 2 Go s’applique à de grandes instructions (nécessitant des milliers de milliards de cycles CPU pour s’exécuter localement). Un système de preuve qui ne respecte cette limite qu’avec de petites instructions manque d’applicabilité générale.
-
Il est facile de garder la mémoire du prouveur sous 2 Go si celui-ci est très lent. Ainsi, pour que l’étape mémoire 1 ne soit pas triviale, je demande qu’elle soit atteinte tout en satisfaisant l’étape de vitesse 1.
Mémoire – Étape 2
L’étape 1 de vitesse est atteinte avec une utilisation mémoire inférieure à 200 Mo (10 fois mieux que l’étape mémoire 1).
Pourquoi descendre en dessous de 2 Go ? Prenons un exemple hors blockchain : à chaque accès HTTPS à un site web, vous téléchargez un certificat pour l’authentification et le chiffrement. À la place, le site pourrait envoyer une preuve zk de possession de ce certificat. Les grands sites pourraient émettre des millions de telles preuves par seconde. Si chaque preuve nécessite 2 Go de RAM pour être générée, cela représenterait des pétaoctets de RAM. Réduire davantage l’utilisation mémoire est essentiel pour les déploiements hors blockchain.
Précompilations : dernier kilomètre ou béquille ?
Dans la conception des zkVM, les précompilations désignent des SNARK (ou systèmes de contraintes) spécialisés, conçus pour des fonctions spécifiques comme les hachages Keccak/SHA ou les opérations de groupes de courbes elliptiques utilisées pour les signatures numériques. Dans Ethereum (où la majeure partie du travail consiste en hachages Merkle et vérifications de signatures), quelques précompilations manuelles peuvent réduire le surcoût du prouveur. Mais compter sur elles comme une béquille empêche les SNARK d’atteindre leur but. Pour plusieurs raisons :
-
Toujours trop lents pour la plupart des applications (blockchain ou non) : même avec des précompilations pour hachages et signatures, les zkVM actuelles restent trop lentes, car le système de preuve sous-jacent est inefficace.
-
Défaillances de sécurité : les précompilations codées à la main et non formellement vérifiées sont presque certainement entachées d’erreurs, pouvant causer des failles catastrophiques.
-
Mauvaise expérience développeur : dans la plupart des zkVM actuelles, ajouter une nouvelle précompilation signifie écrire manuellement un système de contraintes pour chaque fonction – revenir essentiellement aux méthodologies des années 1960. Même avec des précompilations existantes, les développeurs doivent restructurer leur code pour appeler chaque fonction. Nous devrions optimiser pour la sécurité et l’expérience développeur, pas sacrifier les deux pour des gains marginaux de performance. Faire autrement prouve simplement que la performance n’est pas à la hauteur.
-
Surcoût d’E/S et absence de RAM : bien que les précompilations améliorent les performances pour les tâches cryptographiques intensives, elles peuvent ne pas accélérer significativement des charges de travail plus variées, car elles imposent un fort surcoût lors du transfert d’entrées/sorties et ne peuvent pas utiliser la RAM. Même dans les environnements blockchain, dès que vous sortez du cadre d’une L1 monolithique comme Ethereum (par exemple, construire une série de ponts inter-chaînes), vous rencontrez différentes fonctions de hachage et schémas de signature. Précompiler à répétition sur chaque nouveau problème n’est pas évolutif et pose d’énormes risques de sécurité.
Pour toutes ces raisons, notre priorité devrait être d’améliorer l’efficacité de la zkVM sous-jacente. La meilleure technologie pour les zkVM produira aussi les meilleures précompilations. Je crois que les précompilations resteront cruciales à long terme, mais seulement si elles sont synthétisées automatiquement et formellement vérifiées. Ainsi, l’avantage d’expérience développeur des zkVM est préservé, tout en évitant les risques de sécurité catastrophiques. Ce point de vue est reflété dans l’étape de vitesse 3.
Calendrier prévu
Je prévois que quelques zkVM atteindront les étapes de vitesse 1 et mémoire 1 d’ici la fin de cette année. Je pense que nous atteindrons également la vitesse 2 dans les deux prochaines années, bien que cela reste incertain sans de nouvelles idées encore inédites. Les étapes restantes (vitesse 3 et mémoire 2) prendront probablement plusieurs années supplémentaires.
Résumé
Bien que j’aie présenté séparément les étapes de sécurité et de performance des zkVM dans cet article, ces aspects ne sont pas totalement indépendants. À mesure que de nouvelles vulnérabilités seront découvertes dans les zkVM, certaines ne pourront probablement être corrigées qu’au prix d’une baisse importante des performances. Avant qu’une zkVM n’atteigne la sécurité niveau 2, les performances devraient être mises en attente.
Les zkVM ont le potentiel de rendre les preuves à connaissance nulle véritablement accessibles, mais elles en sont encore à leurs balbutiements – confrontées à d’importants défis de sécurité et à un surcoût énorme en performance. Les spéculations et campagnes marketing rendent difficile l’évaluation des progrès réels. En clarifiant des jalons précis de sécurité et de performance, j’espère fournir une feuille de route permettant d’éliminer le bruit. Nous atteindrons ces objectifs, mais cela prendra du temps et des efforts soutenus.
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
a16z
