a16z : Comprendre les réflexions et clarifications relatives à Jolt zkVM
TechFlow SélectionTechFlow Sélection
a16z : Comprendre les réflexions et clarifications relatives à Jolt zkVM
Le coût du zkVM dépend principalement du nombre de cycles, et non des caractéristiques d'une application spécifique, ce qui est un petit miracle.
Dédié à des analyses Web3 approfondiesRédaction : Justin Thaler, associé de recherche chez a16z
Traduction : xiaozou, Jinse Finance
Depuis la publication de notre article fondateur et le déploiement de Lasso l'été dernier, jusqu'à la sortie le mois dernier de Jolt entièrement open source (notre nouveau système performant et simple basé sur les arguments de lookup et une machine virtuelle à connaissances nulles), nous avons réalisé des progrès constants dans le développement de la technologie Lasso+Jolt.
Cette implémentation démontre les grandes promesses de Jolt par rapport aux technologies existantes, tout en remettant en question plusieurs idées reçues classiques en conception de SNARK. Depuis sa sortie, nous avons continué d’apporter des mises à jour : ajout du support de la bibliothèque standard Rust, intégration d'améliorations apportées par plus de 10 contributeurs, fusion de près de 50 demandes de tirage (pull requests), ainsi qu'une amélioration significative de la modularité, des performances et de l'extensibilité du code.
Alors que nous poursuivons l'amélioration de Jolt, je souhaite répondre aux interrogations et malentendus externes, clarifier certaines confusions, et partager mon point de vue sur quelques questions clés. Les quatre sujets que j'aborderai ici sont : (1) la relation entre le protocole sum-check et le schéma de compromis Binius, (2) les rôles respectifs du sum-check et des lookups dans Jolt, (3) les courbes elliptiques et les fonctions de hachage, et (4) les précompilations liées aux zkVM.
1. Le protocole Sum-check et le schéma de compromis Binius
Les schémas de compromis (commitment schemes) sont généralement considérés comme un élément central des SNARK. Toutefois, il faut également souligner l'importance d'un autre composant : les preuves interactives oracles polynomiales (polynomial interactive oracle proof, PIOP). Par exemple, le schéma de compromis Binius pour les polynômes multilinéaires constitue une avancée majeure, mais doit être couplé à un PIOP polynomial afin de garantir que les données engagées vérifient effectivement l'affirmation du prouveur.
Le schéma de compromis Binius est hautement compatible avec les PIOP utilisant le protocole sum-check. Cela tient à des raisons évidentes (le sum-check repose sur des polynômes multilinéaires plutôt que sur des polynômes à variable unique ; FRI-Binius utilise même internement le sum-check) mais aussi à des subtilités importantes (les PIOP fondés sur le sum-check fonctionnent naturellement sur tout corps de caractéristique arbitraire, ce qui est crucial pour exploiter pleinement les nouvelles performances offertes par Binius). En revanche, Binius est incompatible avec les PIOP les plus courants actuellement, qui malheureusement n'utilisent pas le sum-check.
Concevoir un PIOP rapide nécessite bien plus qu’une simple application du sum-check. Binius utilise le protocole sum-check pour réaliser un IOP polynomial efficace. Les sections 4 et 5 de l'article Binius sont consacrées à la conception de nouveaux PIOP efficaces fondés sur le sum-check, destinés à être combinés au schéma de compromis.
Le couple Binius et Jolt s'accorde parfaitement, comme le beurre de cacahuète et la confiture, car Jolt est à ce jour la seule zkVM entièrement basée sur le protocole sum-check. Actuellement, Jolt utilise un schéma de compromis reposant sur la cryptographie à courbe elliptique, mais l'intégration du schéma de compromis Binius dans Jolt est une priorité absolue dans nos travaux.
2. Sum-check, lookups, performance et concision
Qu'est-ce qui distingue Jolt ? Est-ce le fait que Jolt soit la première (et actuellement la seule) zkVM à utiliser exclusivement un IOP polynomial fondé sur le sum-check ? Ou bien le fait qu'il atteigne un « point de singularité » des lookups, où presque toutes les opérations sont réalisées via des lookups plutôt que par des systèmes de contraintes ou des circuits ? La réponse est les deux à la fois. Comparée aux zkVM précédentes, la majeure partie de l'avantage de Jolt en termes de concision provient des lookups, tandis que son avantage en performance découle de l'utilisation conjointe des lookups et du sum-check.
L'approche purement basée sur les lookups est meilleure pour certaines instructions (celles qui n'ont pas de petits circuits), mais peut être moins performante pour d'autres ayant des circuits très compacts. Globalement cependant, cette approche n'a que des avantages en termes de performance, du moins lorsqu'on travaille sur des champs de 256 bits. Actuellement, le prouveur Jolt passe 20 % de son temps sur les lookups d'« exécution » des instructions, et 40 % à prouver les contraintes. Ajouter davantage de contraintes pour réduire les lookups ne serait d'aucune aide.
En gros, Jolt utilise des lookups pour implémenter les étapes de « récupération » et d'« exécution » du cycle CPU « fetch - decode - execute ». Ces lookups sont suffisamment rapides pour que la majeure partie du temps du prouveur soit consacrée à prouver l'étape de « décodage », qui elle est traitée par des contraintes traditionnelles.
L'approche par lookups favorise également des implémentations plus concises et plus audibles. Ces bénéfices sont difficiles à quantifier et leur reconnaissance prend du temps. Mais en termes de nombre de lignes de code (environ 25 000 pour Jolt, soit 2 à 4 fois moins que les zkVM RISC-V antérieures) et de durée de développement, Jolt se distingue nettement. De telles améliorations sont bien plus difficiles à obtenir que celles en performance : alors que je m'attends à ce que les zkVM deviennent environ cent fois plus rapides dans les prochains mois par rapport à août 2023, il est difficile d'imaginer qu’un jour le nombre de lignes de code d'une zkVM puisse être divisé par dix.
3. Courbes elliptiques
Le discours public sous-estime les avantages d'une zkVM rapide spécialisée dans les courbes elliptiques, en partie à cause de l'enthousiasme généralisé autour des schémas de compromis basés sur le hachage, comme Binius.
Lorsqu’on veut prouver des affirmations relatives à la cryptographie sur courbe elliptique, une zkVM basée sur les courbes permet d'éviter les algorithmes non natifs sur les champs, dont le coût en temps de preuve peut augmenter de plusieurs ordres de grandeur. Ces applications incluent notamment la preuve de nombreuses signatures numériques (opération principale pour les clients légers blockchain et les ponts basés sur des SNARK), l'agrégation de preuves Plonk/Groth16/Nova/Honk, ainsi que la preuve des chemins d'authentification dans les arbres de Verkle.
Je suis optimiste quant au fait que la communauté reconnaîtra bientôt l'association du PIOP fondé sur le sum-check et du schéma de compromis FRI-Binius comme la méthode appropriée pour exécuter des SNARK dans de nombreuses applications. Même si cela se produit, les SNARK rapides basés sur les courbes resteront utiles, sauf si le monde abandonne complètement la cryptographie sur courbe elliptique (par exemple après la transition complète vers des systèmes cryptographiques résistants aux ordinateurs quantiques).
Conclusion :
Les schémas de compromis basés sur les courbes sont concurrentiels face à tous les autres zkVM existants (qui utilisent déjà des schémas de compromis basés sur le hachage pour les petits champs).
Pour prouver des affirmations concernant les courbes elliptiques (au moins tant qu'aucune percée majeure n’est faite sur les algorithmes non natifs), on souhaitera utiliser Jolt avec courbes.
En tant que zkVM pur, le couple Jolt avec Binius sera beaucoup plus rapide que toute autre alternative, sauf précisément pour les preuves sur courbes ou les preuves sur petits champs (dans ces cas, on utilisera Jolt avec courbes). Autrement dit, on choisira Jolt avec Binius.
Avant la publication des preuves sur chaîne, les SNARK basés sur les courbes elliptiques continueront d'être utilisés pour réduire la taille des preuves et le coût pour le vérificateur. Dans ce cas, une zkVM capable de gérer les grands champs jouera un rôle important. Aujourd'hui déjà, certains projets perçus comme des zkVM basées sur le hachage utilisent en réalité une zkVM définie sur la courbe BN254 dans le cadre d'un processus récursif.
4. Précompilations et benchmarks pour zkVM
Des discussions ont eu lieu concernant les précompilations et leur rôle dans les zkVM et les benchmarks. Avant d'aborder mon point de vue, il peut être utile de préciser ce qu'est une précompilation, car ce terme varie selon les contextes.
(1) « Précompilations » dans Ethereum
Dans la machine virtuelle Ethereum (EVM), une précompilation désigne une opération fréquemment exécutée, prise en charge nativement pour des raisons d'efficacité. Cela évite les coûts élevés en gaz et les surcharges dues à l'exécution de ces opérations via de longues séquences d'opcodes EVM.
La différence entre une « précompilation EVM » et une « instruction de base » (opcode) est essentiellement sémantique. Par exemple, la fonction de hachage Keccak est un opcode EVM, tandis que SHA-2 est une précompilation EVM. Précompilations et opcodes sont tous deux des opérations courantes, prises en charge nativement par Ethereum pour la même finalité : optimiser l'efficacité et le coût en gaz. Il est indéniable que les précompilations font partie intégrante de l'EVM, souvent utilisée pour décrire de façon large l'environnement d'exécution Ethereum, allant au-delà des seuls opcodes.
Si la fonctionnalité de l'EVM est fondamentalement similaire, pourquoi avoir des précompilations ? Principalement par convention. Une autre raison possible est que les précompilations impliquent des opérations relativement complexes, comme des primitives cryptographiques susceptibles d’évoluer, qu’il sera plus facile de modifier à l’avenir si elles ne disposent pas d’un opcode dédié.
(2) « Précompilations » dans la conception des zkVM
Dans la conception des zkVM, une précompilation désigne un SNARK spécialisé pour une fonction particulière (comme les hachages Keccak ou SHA) ou un ensemble spécifique d'opérations sur courbes elliptiques. Les précompilations SNARK actuelles sont généralement réalisées via des systèmes de contraintes optimisés manuellement (bien que cette nature évoluera avec la migration de la communauté vers les SNARK basés sur le sum-check).
Il existe une forte similarité entre les précompilations EVM et celles des zkVM. Avant la sortie de Jolt, les zkVM implémentaient les instructions de base via des systèmes de contraintes optimisés manuellement, un par instruction, exactement comme elles implémentaient les précompilations. La distinction entre « précompilation zkVM » et « instruction de base » est purement sémantique. Il n’existe aucune différence pratique.
Dans Jolt, nous utilisons des lookups pour implémenter les instructions de base, sans recourir aux contraintes traditionnelles. Toutefois, choisir d’utiliser des contraintes pour certaines instructions de base n’est pas un problème majeur. (En fait, les lookups peuvent eux-mêmes être vus comme une forme de contrainte.) Comme je l’ai déjà mentionné, une fois passé au schéma de compromis Binius, nous devrons probablement utiliser des contraintes traditionnelles pour implémenter l'addition et la multiplication RISC-V.
5. Benchmarking des zkVM
Fort de ce contexte, voici maintenant mes réflexions sur les précompilations en lien avec les zkVM et les benchmarks.
Premièrement, comparer diverses zkVM RISC-V sans précompilations est précisément ce que signifie faire un benchmark de zkVM RISC-V. Le terme « zkVM » étant informel, des divergences sont inévitables, mais à mes yeux, une zkVM RISC-V dotée d'une ou plusieurs précompilations n'est plus une zkVM RISC-V : c'est une zkVM basée sur un nouvel ensemble d'instructions, chaque précompilation devenant une instruction native. À tout le moins, chaque précompilation ajoutée à une zkVM affaiblit la proposition de valeur du paradigme zkVM — chaque circuit supplémentaire augmente la surface d'attaque potentielle aux bogues, et les programmes existants ne pourront pas profiter immédiatement de ces nouvelles instructions.
Certains confondent aussi le concept de précompilation EVM dans les zkEVM avec celui de précompilation dans les zkVM. Ce sont pourtant deux choses distinctes. Bien que certaines opérations clés du zkEVM — comme les hachages Merkle ou la vérification de signatures numériques — soient plus complexes que les instructions RISC-V de base, cela ne change rien au fait qu’il n’y ait aucune différence fonctionnelle entre les précompilations EVM et les opcodes EVM initiaux. Un zkEVM doit supporter les précompilations EVM pour revendiquer l’équivalence avec l’EVM. Autrement dit, un zkEVM ne supportant pas les précompilations EVM est fondamentalement différent d’un zkVM RISC-V comme Jolt, qui étend l’ensemble d’instructions RISC-V via des précompilations.
Un autre sujet est le choix d’un ensemble « équitable » de fonctions pour benchmarker une zkVM. Pour les zkVM RISC-V, tout ensemble de fonctions est équitable. Le temps du prouveur dépend presque entièrement du nombre de cycles exécutés par le CPU RISC-V, pour deux raisons : premièrement, le prouveur passe une petite partie de son temps dans la phase « exécution » du cycle « fetch-decode-execute ». Deuxièmement, les différentes instructions RISC-V, ainsi que les accès mémoire, ont des temps de preuve très similaires. (Dans Jolt, ils sont tous gérés par des techniques de détection hors ligne de la mémoire.)
Enfin, si des précompilations étaient utilisées, Jolt ne serait probablement pas en reste par rapport aux alternatives. Je m'attends même à ce qu'il se comporte mieux, car les précompilations basées sur le sum-check seront les plus rapides, et peuvent être intégrées à Jolt sans surcoût, grâce à son usage exclusif du PIOP fondé sur le sum-check. Certains craignent que les précompilations utilisant des schémas de compromis à courbe elliptique soient bien moins performantes que celles basées sur le hachage. Actuellement, Jolt utilise une courbe, mais ce n'est pas une obligation, et nous restons ouverts à l'idée de migrer vers Binius.
6. Réflexions générales sur les benchmarks
L’objectif principal des benchmarks est d’identifier les performances intrinsèques des différents systèmes de preuve, autant que possible indépendamment de leurs implémentations spécifiques. Cette approche permet à la communauté de comprendre et de se concentrer sur les bonnes techniques pour concevoir des SNARK performants et sécurisés. Toutefois, lorsqu’on compare deux SNARK différents, d’innombrables facteurs de confusion rendent souvent impossible une comparaison rigoureuse.
Les efforts d'ingénierie en font partie, bien que de nombreux membres de la communauté semblent penser le contraire. L'idée serait que si un projet ajoute des « fonctionnalités », comme des précompilations optimisées pour du matériel spécifique, il devrait bénéficier d’un traitement favorable dans tout benchmark.
Les deux points de vue ont leurs mérites. Mais à long terme, la seconde vision n’est clairement pas tenable. Toute nouvelle méthode serait toujours désavantagée dans les benchmarks, faute de temps comparable à celui accumulé par les anciens projets. Une telle position entrave le progrès.
Avec le temps, je pense que les facteurs de confusion liés aux benchmarks diminueront. À mesure que les outils de développement des SNARK mûriront, moins d’efforts d’ingénierie seront nécessaires pour atteindre de bonnes performances. Le coût d’une zkVM dépend principalement du nombre de cycles, et non des particularités d’une application donnée — un petit miracle (du moins pour RISC-V). Si l’on portait attention au choix du système de contraintes (plutôt que l’état fragmenté actuel entre R1CS, AIR, Plonkish, etc.), on pourrait observer un phénomène similaire pour les SNARK basés sur les contraintes, en utilisant une mesure simple de la taille du système de contraintes à la place du nombre de cycles.
En attendant, il est difficile de trouver un équilibre approprié entre un contrôle insuffisant et excessif des variables parasites. Les désaccords sont inévitables, et les développeurs devront fournir tous les contextes, détails et justifications derrière chaque benchmark afin que la communauté puisse les comprendre et les discuter.
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
