A16Z: Explorer le chemin efficace et sécurisé de ZKVM

Auteur: Justin Thaler Source: A16Z Traduction: Shan Oppa, Vision de Bitchain

Machines virtuelles à connaissance zéro (ZKVMS)Le but est de «populariser les graisseurs» afin que même les personnes sans expertise en snark puissent prouver qu’elles exécutent correctement un programme sur une contribution (ou un témoin) spécifique.Son avantage principal réside dans l’expérience du développeur, mais actuellement les ZKVMSécuritéetperformanceIl y a encore d’énormes défis.Si les ZKVM veulent tenir leurs promesses, les concepteurs doivent surmonter ces obstacles.Cet article explorera les étapes possibles du développement ZKVM, et l’ensemble du processus peut être nécessaireAnnéesCe n’est qu’alors que cela peut être fait – ne croyez pas que quiconque dise que cela peut être réalisé rapidement.

Défis

existerSécuritéD’une part, les ZKVM sont des projets logiciels très complexes qui sont encore pleins de vulnérabilités.

existerperformanceQuant à, il peut être plus lent de prouver qu’un programme est exécuté correctement que nativement.Des centaines de milliers de fois, faire la plupart des applications déployées dans le monde réelPas possible pour le moment.

Pourtant, de nombreuses voix dans l’industrie de la blockchain font toujours la promotion du ZKVMSPeut être déployé immédiatement, et même certains projets paient déjà des coûts de calcul élevés pour générer des preuves de connaissances zéro d’activité sur la chaîne.Cependant, comme il y a encore de nombreuses vulnérabilités dans les ZKVM, cette approche est en fait justeUn déguisement coûteux, faire ressembler le système à être protégé par Snark, alors qu’en fait cela dépend deContrôle de l’autorisation, ou pire-Exposition au risque d’attaque.

La réalité est que nous sommes encore à des années à construire un ZKVM vraiment sécurisé et efficace.Cet article propose une série deSpécifique et progressifL’objectif de nous aider à suivre les progrès réels dans le ZKVM, à affaiblir le battage médiatique et à guider la communauté pour se concentrer sur de réelles percées technologiques.

Étape de développement de la sécurité

arrière-plan

basé surSnowdezkvmsIl contient généralement deux composants centraux:

1 et 1Polynomial Interactive Oracle Proof (PIOP): Un cadre de preuve interactif pour la prestation de polynômes (ou contraintes dérivés des polynômes).

2Schéma d’engagement polynomial (PCS): Assurez-vous que le prover ne peut pas forger les résultats d’évaluation polynomiale sans être détectés.

Pass ZKVMCoder les trajectoires d’exécution valides dans les systèmes de contrainte, assurez-vous que la machine virtuelleregistreetMémoirepuis utilisez Snark pour prouver la satisfaction de ces contraintes.

Dans un système aussi complexe, la seule façon de s’assurer que le ZKVM est vulnérable estVérification formelle.Voici les différentes étapes de la sécurité ZKVM, oùLa première phase se concentre sur l’exactitude de l’accord,Les deuxième et troisième étapes se concentrent sur la réalisation de l’exactitude.

Phase de sécurité 1: le protocole droit

1. Vérification formelle de la fiabilité du PIOP;

2. PCS est une preuve de vérification formelle liée sous certaines hypothèses de chiffrement ou modèles idéaux;

3. Si Fiat-Shamir est utilisé, l’argument concis obtenu en combinant PIOP et PCS est une preuve de sécurité officielle de la sécurité dans le modèle Oracle aléatoire (amélioré avec d’autres hypothèses de cryptage au besoin);

4. Le système de contraintes appliqué par PIOP équivaut à la vérification formelle de la preuve de sémantique des machines virtuelles;

5. Toutes ces sections sont entièrement « collées » en une seule preuve de snark sécurisée, officiellement prouvée pour exécuter tout programme spécifié par le VM Bytecode.Si le protocole a l’intention de mettre en œuvre des connaissances zéro, cet attribut doit également être officiellement vérifié pour s’assurer que les informations sensibles sur le témoin ne sont pas divulguées.

Si zkvm est utilisérécursivité, alors lePIOP, schémas d’engagement et systèmes de contrainteTous doivent être vérifiésSinon, ce sous-étage ne peut être considéré comme complet.

Phase de sécurité 2: Implémentation du vérificateur correct

Cette étape nécessite ZKVMVérificateurLa mise en œuvre réelle (comme la rouille, la solidité, etc.) est réaliséeVérification formelleAssurez-vous qu’il est conforme aux protocoles qui ont été vérifiés dans la première phase.Compléter cette phase signifie que ZKVMaccompliretConception théoriqueC’est cohérent, pas seulement unContrat de sécurité sur papier, ou une spécification inefficace écrite dans une langue telle que Lean.

PourquoiSe concentrer uniquement sur le validateur, pas sur la preuveIl y a deux raisons principales: premièrement,Assurez-vous que le validateur est correct, vous pouvez assurer l’exhaustivité du système de preuve ZKVM(c’est-à-dire: assurez-vous que le validateur n’est pas usurpé pour accepter une fausse preuve).Deuxième,La mise en œuvre du vérificateur de ZKVM est plus qu’un ordre de grandeur plus simple que la mise en œuvre du prover, l’exactitude du vérificateur est plus facile à garantir à court terme.

Phase de sécurité 3: la mise en œuvre du prover correct

Cette étape nécessite ZKVMPreuveLa mise en œuvre réelle deVérification formelle, assurez-vous que cela peutCorrectement généréPreuve du système de preuve qui a été vérifié dans les première et deuxième étapes.Le but de cette étape estComplétude, c’est-à-dire que tout système utilisant ZKVM ne pourra pas prouver une déclaration juridique.Rester coincé.Si ZKVM doit avoir des attributs de connaissances zéro, une vérification formelle doit être fournie pour s’assurer que la preuve ne divulgue aucune information sur le témoin.

Horaire estimé

Progrès de la phase 1: Nous pouvons espérer quelques progrès l’année prochaine (par exemple,ZklibC’est un effort).Mais aucun ZKVM ne peut répondre pleinement aux exigences de la phase 1 au moins deux ans.

Étapes 2 et 3: Ces phases peuvent être avancées simultanément avec certains aspects de la phase 1.Par exemple, certaines équipes ont démontré que la mise en œuvre du validateur PLONK correspond au protocole dans l’article (bien que le protocole lui-même ne soit pas entièrement vérifié).Pourtant, je ne m’attends pas à ce que le ZKVM atteigne la phase 3 en moins de quatre ans – peut-être même plus.

Notes clés: Fiat-Shamir Security vs Code d’octet vérifié

Un problème de complexité majeur est queIl y a encore des questions de recherche non résolues sur la sécurité de la transformation de Fiat-Shamir.Les trois phases de sécurité traitent le fiat-shamir et les oracles aléatoires comme absolument sûrs, mais en réalité, il peut y avoir des vulnérabilités dans tout le paradigme.Cela est dû àIl y a une différence entre le modèle idéalisé d’un oracle aléatoire et la fonction de hachage réellement utilisée.

Dans le pire des cas, on a atteintPhase de sécurité 2Le système peutTrouvé complètement dangereux en raison de problèmes liés à la fiat-shamir.Cela mérite notre grande attention et notre recherche continue.Nous pouvons avoir besoinModifiez la transformation Fiat-Shamir elle-même pour mieux se défendre contre de telles vulnérabilités.

Les systèmes qui n’utilisent pas de récursivité sont théoriquement plus sûrs, parce que certaines attaques connues impliquent des circuits similaires à ceux utilisés dans les preuves récursives.Mais ce risque est toujours unProblèmes de base non résolus.

Un autre problème à noter est que même si ZKVM prouve qu’un certain programme de calcul (spécifié par le bytecode) estEffectuer correctement, mais siLe bytecode lui-même a des défauts, alors la valeur de cette preuveExtrêmement limité.Par conséquent, le caractère pratique du ZKVM dépend dans une large mesureComment générer des bytecode officiellement vérifiés, et ce défiExtrêmement énorme,etAu-delà de la portée de cet article.

À propos de la sécurité quantique

Les ordinateurs quantiques ne constitueront pas une menace sérieuse pendant au moins 5 ans (ou plus), tandis que les vulnérabilités logicielles sont une question de vie ou de mort.Par conséquent, la priorité actuelle devrait être d’atteindre les objectifs de sécurité et de performance proposés dans cet article.Si les grains non en sécurité peuvent atteindre ces objectifs plus rapidement, nous devons les prioriser.Envisagez de changer lorsque les SNARKS résistants quantum rattrapent leur retard, ou lorsqu’il y a des signes que les ordinateurs quantiques avec des menaces réelles sont sur le point d’émerger.

Niveau de sécurité spécifique

Sécurité classique 100 bitsTout snark est-il utilisé pour protéger les actifs précieuxStandard minimum(Mais il y a encore des systèmesNe pas respecter ce faible standard).Même ainsi, c’est toujoursNe doit pas être acceptéLa pratique de la cryptographie standard nécessite généralementSécurité 128 bits et au-dessus.Si les performances de Snark sont vraiment à la hauteur des normes, nous ne devons pas réduire la sécurité afin d’améliorer les performances.

Phase de performance

Situation actuelle

Actuellement, ZKVMPreuveLa surcharge de calcul est approximativement1 million de fois l’exécution native.En d’autres termes, si l’exécution native d’un programme nécessiteX cycles CPU,DoncGénérer une preuve d’exécution correcteApproximativement nécessaireX × 1 000 000 CPU Cycles.Cette situation estDonc c’était il y a un an, et c’est quand même aujourd’hui(Bien qu’il y ait des malentendus).

Certaines déclarations populaires dans l’industrie aujourd’hui peuvent être trompeuses, comme:

1 et 1«Le coût de la génération de preuve pour l’ensemble du Mainnet Ethereum est inférieur à 1 million de dollars par an.»

2«Nous avons presque mis en œuvre une génération de blocs d’Ethereum en temps réel, ne nécessitant que des dizaines de GPU.»

3 et 3«Notre dernier ZKVM est 1000 fois plus rapide que les générations précédentes.»

Cependant, ces affirmations peuvent être trompeuses sans contexte:

•1000 fois plus rapide que le ZKVM plus ancien, et peut toujours être très lent, c’est plus révélateurÀ quel point le passé était mauvais, pas à quel point.

•Le volume informatique du réseau principal Ethereum peut augmenter de 10 fois dans le futur, ce qui rendra les performances actuelles de ZKVM beaucoup moins susceptibles de répondre à la demande.

• La génération de preuve dite « presque en temps réel » est toujours sous les besoins de nombreuses applications de blockchainTrop lentement(Par exempleL’optimisme a un temps de bloc de 2 secondes, beaucoup plus rapide que les 12 secondes d’Ethereum).

•« Les GPU fonctionnent 24/7 pendant longtemps »Pas disponibleAssez d’activité garantie.

• CesLe temps de génération de preuve est généralement destiné à des tailles à plus de 1 Mo, et c’est pour de nombreuses applicationsTrop grand.

•« Coût moins de 1 million de dollars par an »Juste parce queEthereum Node complet ne fait que des calculs d’environ 25 $ par an.

Pour les scénarios d’application en dehors de la blockchain, cette surcharge informatique est évidemment trop élevée.Peu importe le nombre d’optimisations parallèles de l’informatique ou de l’ingénierie, il ne peut pas compenser une telle frais générale informatique.

L’objectif de base que nous devons fixer est: les frais généraux de performance ne dépassent pas 100 000 fois l’exécution native.Mais même ainsi, ce n’est encore que la première étape.Si nous voulons mettre en œuvre des applications grand public à grande échelle, nous devrons peut-être réduire les frais généraux à 10 000 fois ou moins d’exécution native.

Mesure du rendement

Snark Performance a trois composants principaux:

1 et 1L’efficacité inhérente du système prouvé sous-jacent.

2Optimisation pour des applications spécifiques(par exemple précompilé).

3 et 3Ingénierie et accélération matérielle(par exemple, GPU, FPGA ou CPU multi-core).

Alors que (2) et (3) sont essentiels pour le déploiement réel, ils conviennent à tout système de preuve, doncDes améliorations qui ne reflètent pas nécessairement les frais généraux de base.Par exemple, l’ajout d’accélération et de précompilation du GPU à ZKEVM peut facilement améliorer la vitesse de 50 fois plus rapide que de s’appuyer uniquement sur des processeurs – ce qui peut rendre un système intrinsèquement moins efficace paraître mieux qu’un autre qui n’a pas été la même optimisation.

Par conséquent, cet article se concentre sur la mesurePerformances de base du snark sans matériel et précompilation dédiés.Ceci est différent de l’approche d’analyse comparative actuelle, qui combine généralement les trois facteurs en une « valeur populaire ».C’est commeJuger les diamants en polissant le temps, plutôt que d’évaluer leur clarté inhérente.

Notre objectif estLes frais généraux inhérents à l’isolement des systèmes de preuve universelle, réduire les obstacles à l’entrée pour les technologies qui n’ont pas encore été étudiées, et aider la communauté à éliminer les distractions, se concentrant ainsi surProuver le véritable progrès dans la conception du système.

Phase de performance

Voici les étapes des cinq phases de performance que j’ai proposées.Premièrement, nous devons réduire considérablement les frais généraux des proverants sur le CPU avant de pouvoir davantage compter sur le matériel pour réduire les frais généraux.Dans le même temps, 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 essentiel du ZKVM.Si Devex est sacrifié pour répondre à des références de performance, elle perdra non seulement la signification de l’analyse comparative, mais violera également l’intention initiale du ZKVM.

Ces indicateurs se concentrent principalement surPreuve du coût.Cependant, si le validateur est autoriséCroissance des coûts illimités(c.-à-d. Taille ou temps de vérification illimité), alors tout indicateur de prover peut être facilement respecté.Par conséquent, les exigences des étapes suivantes doivent être satisfaites,La taille maximale de la preuve et le temps de vérification maximum doivent être définis en même temps.

Exigences de phase 1: « Coûts de vérification non triviale rationnels »

•Taille de preuve: Doit être plus petit que la taille du témoin.

•Temps de vérification: La vitesse de la preuve de vérification ne doit pas être plus lente que l’exécution native du programme (c’est-à-dire qu’elle ne doit pas être plus lente que l’exécution directe du calcul).

Ce sontExigences minimales de simplicité,s’assurerLa taille de la preuve et le temps de vérification ne sont pas pires que d’envoyer un témoin directement au validateur et de le vérifier directement.

Étape 2 et plus

•Taille maximale: 256 Ko.

•Temps de vérification maximal: 16 millisecondes.

Ces plafonds sont intentionnellement plus lâcheurs pour s’adapter à de nouvelles technologies de preuve rapide, même si elles peuvent apporter des coûts de vérification plus élevés.Dans le même temps, ces limites supérieures excluent une preuve si chère que peu de projets sont prêts à utiliser sur la blockchain.

Étape de vitesse 1

La preuve unique ne doit pas être plus de 100 000 fois plus lente que l’exécution native(Applicable à plusieurs applications, pas seulement à la preuve du bloc Ethereum) et ne doit pas compter sur la précompilation.

Spécifiquement, Supposons que le processeur RISC-V sur un ordinateur portable moderne fonctionne à environ.3 milliards de cycles par seconde, alors atteindre l’étape 1 signifie que le cahier peut30 000 cycles RISC-V / secondePreuve de génération de vitesse (thread unique).

Le coût du validateur doit respecter la norme «Norme de vérification non triviale raisonnable» précédemment définie.

Phase de vitesse 2

La preuve unique ne doit pas être plus de 10 000 fois plus lente que l’exécution native.

ou, Puisque certaines méthodes de snark prometteuses (en particulier le snark du domaine binaire) sont limitées par le CPU et le GPU actuels, cette phase peut être respectée via les FPGA (ou même les ASIC):

1. Calculez le nombre de noyaux RISC-V que le FPGA simule à vitesse native.

2. Calculez le nombre de FPGA nécessaires pour simuler et prouver l’exécution de RISC-V (presque en temps réel).

3. Si (2) quantitéPas plus de 10 000 fois (1), alors l’étape 2 est satisfaite.

•Taille de preuve: Maximum 256 Ko.

•Temps de vérification: 16 millisecondes maximales sur le processeur standard.

Étape de vitesse 3

En atteignantPhase de vitesse 2Basé sur leProof de frais de preuve dans 1000 ×(Applicable à plusieurs applications) et doit être utiliséPrécompilation de la synthèse automatique et de la vérification formelle.Essentiellement,Personnalisez dynamiquement l’ensemble d’instructions de chaque programme pour accélérer la génération d’épreuves, mais il doit être garantiFacilité d’utilisation et vérification formelle.(à proposPourquoi une épée à double tranchant est-elle précompilée, et pourquoi la précompilation « manuscrite » n’est pas une approche durable, voir la section suivante.)

Étape de mémoire 1

En cas de moins de 2 Go de mémoireatteindreÉtape de vitesse 1et satisfaireZéro-connaissances exigences.Cette étape pourAppareil mobile ou navigateurC’est crucial etUn grand nombre de cas d’utilisation du client ZKVMOuvrit la porte.Par exemple, un smartphone est utiliséIntimité de localisation, références d’identité, etc..Si la génération d’épreuve nécessite plus de 1 à 2 Go de mémoire, la plupart des appareils mobiles ne fonctionneront pas.

Deux notes importantes:

1. Même pour l’informatique à grande échelle (qui nécessite des milliards de cycles CPU d’exécution native), le système de preuve doit maintenir un capuchon de mémoire de 2 Go, sinon l’applicabilité sera limitée.

2. Si la preuve est extrêmement lente, il est facile de maintenir un capuchon de mémoire de 2 Go.Par conséquent, pour que l’étape de la mémoire 1 ait un sens, l’étape de vitesse 1 doit être atteinte dans la limite de mémoire de 2 Go.

Mémoire étape 2

Dans moins de 200 Mo de mémoireatteindreÉtape de vitesse 1(10 fois plus rapide que l’étape de mémoire 1).

Pourquoi le réduire à 200 Mo?Considérer unScénarios non blockchain: Lorsque vous visitez un site Web HTTPS, les certificats d’authentification et de chiffrement seront téléchargés.Si le site Web envoie à la place des preuves ZK pour ces certificats, les grands sites Web peuvent avoir besoin de générer chaque secondeMillions de preuves.Si 2 Go de mémoire sont requis par preuve, l’exigence de ressource informatique sera satisfaiteNiveau PB, évidemment pas possible.Par conséquent, réduisez davantage l’utilisation de la mémoireApplications non blockchainC’est crucial.

Précompilé: dernier mile ou béquilles?

PrécompiléSe réfère àSystème de contrainte de snark optimisé spécifiquement pour des fonctions spécifiques (telles que le hachage, les signatures de courbe elliptique).Dans Ethereum, la précompilation peut réduire les frais généraux du hachage de Merkle et de la vérification de la signature, mais la surdiffion sur la précompilation ne peut pas vraiment améliorer l’efficacité centrale du snark.

Problèmes de précompilation

1. Toujours trop lent: Même si elle est précompilée avec du hachage et des signatures, ZKVM a toujours le problème d’inefficacité des systèmes d’épreuve de base à l’intérieur et à l’extérieur de la blockchain.

2. Vulnérabilités de sécurité: Si la précompilation manuscrite n’est pas officiellement vérifiée, il existe presque certaines vulnérabilités, ce qui peut entraîner une défaillance de la sécurité catastrophique.

3. Mauvaise expérience des développeurs: Actuellement, de nombreux ZKVM ont besoin de développeursSystème de contraintes d’écriture, similaire à la méthode de programmation dans les années 1960, affectant sérieusement l’expérience de développement.

4. Cerfection de référence: Si les repères reposent sur l’optimisation de précompilations spécifiques, il peut induire les gens en erreur de se concentrer sur l’optimisation des systèmes de contraintes manuelles plutôt que d’améliorer la conception de Snark elle-même.

5. Accès des frais généraux d’E / S et sans bélierBien que le précompilation puisse améliorer les performances des tâches de cryptographie lourdes, ils peuvent ne pas fournir une accélération significative pour des charges de travail plus diverses, car elles engagent des frais généraux significatifs lorsqu’ils passent d’entrée / sortie, et ils ne peuvent pas utiliser RAM.

Même dans un environnement de blockchain, tant que vous allez au-delà d’un seul L1 comme Ethereum (par exemple, vous souhaitez construire une série de ponts transversales), vous serez confronté à différentes fonctions de hachage et schémas de signature.La précompilation continue pour résoudre ce problème n’est ni évolutive ni ne présente un énorme risque de sécurité.

Je crois que la précompilation est toujours cruciale à long terme, mais cela ne se produira qu’une fois qu’ils seront automatiquement synthétisés et officiellement validés.De cette façon, nous pouvons maintenir les avantages de l’expérience du développeur du ZKVM tout en évitant les risques de sécurité catastrophiques.Cette vue se reflète dans la phase 3.

Horaire attendu

Je m’attends à ce que quelques ZKVMs atteignent plus tard cette annéeÉtape de vitesse 1etÉtape de mémoire 1.Je pense que nous pouvons y parvenir au cours des deux prochaines années.Phase de vitesse 2, mais il n’est pas clair si cet objectif peut être atteint sans de nouvelles idées de recherche.

Je m’attends au reste des étapes (Étape de vitesse 3etMémoire étape 2) Il faudra des années à réaliser.

Bien que cet article répertorie respectivement les étapes de sécurité et de performance de ZKVM, les deux ne sont pas complètement indépendants.Alors que les vulnérabilités dans le ZKVM continuent d’être découvertes, je m’attends à ce que les correctifs de certaines de ces vulnérabilités conduisent inévitablement à une baisse significative des performances.Par conséquent, dans ZKVM, il est réaliséPhase de sécurité 2Auparavant, les résultats des tests de performance doivent être considérés comme des données provisoires.

Le ZKVM a un grand potentiel dans la fait que la connaissance zéro s’est avérée vraiment populaire, mais elle est toujours à ses débuts – pleine de défis de sécurité et de gravement des goulots d’étranglement de performance.Le battage médiatique du marché et la publicité marketing rendent la mesure de réels progrès difficiles.Avec des étapes claires de sécurité et de performance, j’espère fournir une feuille de route qui effacera le brouillard.Nous finirons par atteindre notre objectif, mais cela prendra du temps, ainsi que des efforts continus dans la recherche et l’ingénierie.