A16z : Les éléments clés pour les créateurs : ‘Jolt Inside’

Auteur de l’article : a16z crypto

Traduction de l’article : Block unicorn

Préface

Aujourd’hui, LayerZero a lancé sa nouvelle chaîne Zero, qui intègre plusieurs avancées technologiques — notamment une toute nouvelle méthode de preuve à zéro connaissance, qui découple l’exécution des transactions de leur vérification. Tout cela est rendu possible grâce à « Jolt Inside ».

Qu’est-ce que Jolt ? Jolt est une machine virtuelle zk RISC-V (ou plus précisément, une machine virtuelle « épurée ») open source, rapide, sécurisée et facile à utiliser. Elle représente une toute nouvelle approche de conception SNARK, développée en trois ans par a16z crypto, que nous rendons open source pour que quiconque puisse l’utiliser ou la faire évoluer. Mais la naissance de Jolt est en réalité une histoire qui a mûri pendant plusieurs décennies.

Pourquoi la conception de zkVM et de SNARK est-elle si importante ?

Avant d’explorer l’évolution de la conception SNARK, il est essentiel de comprendre ce qu’est une zkVM.

Ce type de machine virtuelle est souvent appelé « zk » virtual machine, mais la caractéristique la plus courante ici est la simplicité. Bien que « zéro connaissance » soit crucial pour la confidentialité, « épuré » signifie que la preuve est courte et facile à vérifier — deux caractéristiques utiles mais distinctes, souvent confondues. (Jolt possède déjà cette simplicité, et implémentera bientôt la zero knowledge.)

Mais pourquoi la zkVM est-elle si cruciale ? La zkVM, ainsi que la notion plus large de SNARK (preuve à connaissance succincte et non interactive), jouent un rôle clé dans l’amélioration de la scalabilité, de la confidentialité et de la sécurité des blockchains. Ces preuves, arguments et zéro connaissance (collectivement appelés technologies de calcul vérifiable) ont d’innombrables applications dans la cryptographie et au-delà.

En raison de l’architecture traditionnelle et d’autres raisons, l’industrie a jusqu’ici adopté des méthodes plutôt complexes pour construire des zkVM ; nous en discuterons plus en détail ci-après. Cependant, Jolt a été conçue dès le départ avec une approche radicalement différente de la conception SNARK, visant une efficacité, une facilité d’utilisation et des performances accrues.

En résumé, une zkVM est une méthode pour prouver que vous avez correctement exécuté un programme informatique. La zkVM est plus conviviale que d’autres SNARK, car elle permet aux développeurs d’utiliser l’infrastructure informatique existante (par exemple, l’écosystème open source LLVM) pour générer des preuves SNARK dans leur langage de programmation préféré, sans avoir besoin d’un langage spécifique à domaine (DSL).

Cela ressemble beaucoup à ce que l’on trouve dans de nombreux domaines modernes de la cryptographie — nous disposons de standards et de bibliothèques intégrés pour le chiffrement et la signature numérique — des bibliothèques que les développeurs utilisent quotidiennement sans connaître leur fonctionnement interne. Jolt offre une abstraction similaire : il suffit d’utiliser un programme existant et de le faire vérifier, sans se soucier de l’interaction entre les deux. C’est une condition essentielle pour la démocratisation de toute nouvelle application cryptographique.

Les développeurs peuvent se concentrer sur leur tâche réelle. Avec Jolt, ils n’ont pas besoin de connaissances spécialisées en SNARK : en appuyant simplement sur un bouton, ils peuvent générer une preuve Jolt à partir de leur code informatique.

Cependant, même si Jolt a réalisé de nombreux progrès, générer une preuve pour une opération de complexité moyenne (par exemple, une opération effectuée en une seconde par un seul cœur CPU standard) nécessite encore une puissance de calcul importante. Pour produire une preuve complexe dans un délai raisonnable, il faut plusieurs GPU. LayerZero a porté le générateur de preuve Jolt sur CUDA, et a lancé Zero : une version hautement parallélisée de l’algorithme Jolt adaptée au matériel GPU, permettant une meilleure scalabilité.

LayerZero s’engage à faire passer Jolt à un niveau de preuve GPU prêt pour la production, en collaborant notamment au développement d’une version GPU-friendly de l’algorithme Jolt, essentielle pour améliorer la scalabilité des zkVM et des preuves.

Recherche open source

Jolt est open source, ce qui permet à quiconque de l’utiliser ou de développer à partir de ses innovations. L’open source est le multiplicateur ultime : partager ouvertement les résultats permet à un plus grand nombre d’écosystèmes de l’utiliser, de le réutiliser, de le tester, de l’auditer, de le corriger et de l’améliorer, favorisant ainsi l’innovation continue.

Investir dans des projets open source peut sembler atypique pour un fonds de capital-risque, mais la structure de la recherche moderne repose en grande partie sur des travaux internes — comme les anciens laboratoires d’entreprise ou, aujourd’hui, les laboratoires de fondations — ou sur la recherche académique. La création de notre institut de recherche a16z crypto vise à établir un pont entre la théorie académique et la pratique industrielle, en réunissant un laboratoire de recherche et une équipe d’ingénierie. En tant que fonds de capital-risque, nous pouvons aussi financer des projets que d’autres ne peuvent pas, notamment dans le cadre d’investissements inversés.

Le soutien à une approche de conception SNARK basée sur le reverse engineering est particulièrement crucial pour Jolt, car elle représente une rupture radicale avec les méthodes traditionnelles — un véritable changement de paradigme. Cette évolution de conception s’est construite sur plusieurs années.

L’histoire de l’innovation est souvent celle d’une transformation architecturale

Pour comprendre la révolution que Jolt apporte à la conception SNARK, il faut remonter à plus de deux millénaires : les Grecs ont initié le développement de systèmes formels de preuves mathématiques, qui ont ensuite été étendus par des savants du Moyen-Orient, d’Asie et d’autres régions.

Ces premières preuves — des déductions logiques écrites étape par étape — étaient enregistrées dans un langage formel ou une formule, permettant à quiconque de les vérifier. Par exemple, un mathématicien pouvait écrire une preuve dans un « livre », qu’un autre pouvait lire mot à mot pour la valider. Ce concept de preuve statique, écrit à la main, est l’ancêtre du célèbre problème de complexité « P vs NP » dans la classe NP.

Il est important de noter que cette méthode de preuve était séquentielle, nécessitant une interaction ordonnée : elle était statique, non interactive.

Mais en 1985*, Shafi Goldwasser, Silvio Micali et Charles Rackoff ont introduit le concept de preuve interactive (« IP »). [*En réalité, leur article a été soumis quelques années plus tôt, mais a été rejeté plusieurs fois avant d’être accepté.] L’idée centrale était que, si deux mathématiciens communiquaient en temps réel, ils n’avaient pas besoin d’attendre qu’une partie rédige une preuve pour convaincre l’autre. Au contraire, ils pouvaient poser des questions en direct ; autrement dit, l’interaction permettait d’explorer la véracité de la preuve.

Ce pouvoir énorme des preuves interactives — par rapport aux preuves statiques de l’Antiquité grecque — n’a été pleinement compris qu’en 1990. Carsten Lund, Lance Fortnow, Howard Karloff et Noam Nisan ont alors proposé le protocole de vérification par sommation : une méthode algébrique pour les systèmes de preuve interactifs. Associée aux travaux ultérieurs d’Adi Shamir, cette approche a rapidement conduit à la conclusion fondamentale « IP=PSPACE » — une formulation technique qui résume l’intuition suivante :

Si le prouveur et le vérificateur peuvent interagir — comme dans un système de preuve traditionnel challenge-réponse — (en supposant qu’un prouveur menteur ne sera pas pris au piège par ses défis insolubles), alors, comparé à la preuve statique grecque, on peut vérifier plus rapidement des affirmations plus complexes.

En d’autres termes : l’interactivité confère un avantage considérable dans les systèmes de preuve. La vérification par sommation (sum-check) en est la clé : elle permet au vérificateur de valider un résultat sans reconstruire tout le calcul sous-jacent.

Quelques années plus tard, Joe Kilian a proposé de partir de preuves vérifiables probabilistes (PCP) pour construire des preuves à connaissance succincte (SNARK). Dans la théorie PCP, le prouveur (qu’on peut imaginer comme un mathématicien grec ou un ordinateur) écrit une preuve dans un « livre » très redondant. La particularité est que le vérificateur n’a pas besoin de lire tout le livre : il peut simplement tirer au hasard quelques positions — par exemple, trois « mots » — et, avec une haute confiance, juger de la validité de la preuve.

Mais le problème est que la preuve PCP est très longue, même si la vérification est peu coûteuse.

Kilian a donc montré comment combiner PCP et cryptographie : le prouveur peut « promettre » d’avoir écrit ce long livre, puis ne révéler que quelques mots choisis, accompagnés d’une courte preuve cryptographique. La preuve finale dans le protocole de Kilian consiste en ces quelques mots (plus quelques données cryptographiques) — qui suffisent à convaincre le vérificateur que tout le livre est correct.

À l’époque, ces preuves étaient encore interactives. Ensuite, Micali a montré comment appliquer la transformation Fiat-Shamir pour convertir la preuve interactive de Kilian en une preuve non interactive. En résumé, la transformation Fiat-Shamir « supprime » le défi aléatoire du vérificateur, permettant au prouveur de générer lui-même le défi et de produire une preuve unique.

L’impact durable de l’architecture héritée

En regardant l’histoire et l’évolution des systèmes de preuve, on voit qu’on est passé d’un modèle statique à interactif, puis à probabiliste et non interactif (PCP), puis de nouveau à interactif (Kilian), et enfin à non interactif (Micali). SNARK apparaît à la fin de cette évolution : en appliquant la transformation Fiat-Shamir à la preuve interactive de Kilian, Micali a obtenu ce que l’on appelle aujourd’hui le premier SNARK.

Mais dans ces premiers SNARK basés sur PCP, la charge du prouveur était énorme — leur calcul prenait trop de temps — ce qui rendait leur déploiement difficile.

Cependant, la conception des SNARK a évolué sur plusieurs décennies. Même si l’industrie a tenté de s’éloigner des méthodes basées sur PCP, les concepteurs ont continué à utiliser des concepts liés (par exemple, « PCP linéaire »), qui ne sont en réalité que des variantes heuristiques de PCP. Bien que ces approches produisent des SNARK très courts, elles ne sont pas nécessairement les plus rapides pour le prouveur.

Les concepteurs de SNARK n’ont jamais vraiment revisité leur origine — le protocole de sommation — pour obtenir des preuves plus rapides et plus faciles à utiliser grâce à la puissance de calcul moderne.

Pour faire plus tôt appel au protocole de sommation, il faut envisager une perspective non linéaire de l’histoire des SNARK. En passant de (a) preuve interactive → (b) PCP → © preuve interactive succincte → (d) SNARKs primitifs, l’industrie a connu plusieurs changements :

Lors de la transition de (a) à (b), le principal défi était de supprimer l’interactivité tout en conservant la simplicité de vérification. Cela a conduit à abandonner le protocole de sommation (l’interactivité).

Puis, lors de la transition de (b) à ©, l’interactivité est revenue… jusqu’à ce qu’on la supprime à nouveau via la transformation Fiat-Shamir, passant de © à (d).

En regardant tout cela de manière linéaire, on voit que les concepteurs de SNARK ont en fait omis deux fois l’interactivité — une fois lors de la transition (a) → (b), une autre lors de © → (d).

Mais si l’on veut utiliser la transformation Fiat-Shamir pour éliminer l’interactivité… il faut sauter directement l’étape (b), c’est-à-dire le PCP probabiliste ! C’est cette idée clé derrière Jolt : partir directement d’un preuve interactive pour construire un SNARK — en utilisant la sommation.

Pourquoi plus de gens n’ont-ils pas adopté plus tôt la conception basée sur la sommation ? Peut-être parce que les premiers SNARK semblaient très proches des preuves PCP, puisqu’ils partageaient l’idée de vérification succincte. La suite a été influencée par des architectures — et des malentendus — qui ont perduré.

Pour nous, investir massivement dans le zkVM basé sur la sommation, Jolt, c’est un pari inversé : cela va à l’encontre du paradigme dominant dans le domaine des SNARK depuis des décennies.

‘Jolt Inside’

La méthode SNARK de Jolt (basée sur l’évaluation par lot et la vérification de mémoire, comme Twist + Shout) s’appuie sur des protocoles interactifs et de sommation.

Aujourd’hui, après plusieurs années de développement de Jolt, d’autres commencent à adopter la méthode de vérification par sommation dans leurs propres designs. Alors, quelles sont les caractéristiques remarquables de Jolt dans le contexte actuel des zkVM ? Jolt exploite au maximum la structure répétitive lors de l’exécution CPU. En observant comment l’abstraction « fetch-décode-exécuter » de chaque cœur CPU peut s’appliquer à la vérification par lot, Jolt atteint une efficacité inégalée avec une complexité minimale.

En comparaison, d’autres zkVM dépendent fortement de « précompilés » (similaires à des accélérateurs ASIC pour des sous-programmes spécifiques) pour atteindre des performances raisonnables. Jolt rejette ces précompilés, car ils reproduisent les erreurs des méthodes SNARK avant l’émergence de cette architecture : nécessitant des experts pour concevoir ces circuits spécialisés, ils sont plus sujets aux bugs et plus difficiles à utiliser pour la majorité des développeurs. L’objectif de Jolt est la démocratisation du SNARK.

Vérifier la correction de l’exécution CPU est au cœur de la valeur de la zkVM — une avancée majeure pour l’expérience développeur — car cela permet de réutiliser l’infrastructure informatique générale, déjà renforcée. L’infrastructure mondiale est construite pour supporter le CPU, et Jolt exploite pleinement cette « structure » pour maximiser simplicité et performance.

Depuis ses débuts, Jolt privilégie la disponibilité et la performance de niveau production : les développeurs peuvent vérifier directement leurs programmes existants ; même pour une vérification rapide, aucune modification de code n’est nécessaire. Contrairement à d’autres solutions, Jolt ne force pas à une refonte autour de « précompilés » ou d’API spécifiques pour atteindre des performances acceptables, mais conserve l’intégrité du code original, facilitant son adoption, son audit et sa mise à jour.

Plus important encore, Jolt est à la fois plus rapide et plus simple. D’autres solutions nécessitent que chaque instruction de la machine virtuelle soit spécifiée par un circuit dédié, alors que Jolt n’a pas besoin de cela : chaque instruction de base peut être codée en une dizaine de lignes en Rust. Pas de circuits, seulement une dizaine de lignes de code.

Quelle est la prochaine étape pour Jolt ?

Nous avons déjà une avance en termes de vitesse. Avec des optimisations supplémentaires et de nouvelles fonctionnalités — notamment la récursivité et la preuve à zéro connaissance —, et en anticipant la transition de la cryptographie elliptique vers la cryptographie par réseaux de neurones, nous prévoyons d’atteindre d’ici la fin de l’année une nouvelle étape de performance, sans parler de l’ère post-quantique.

Jolt ouvre la voie à davantage d’applications. Sur la blockchain, la scalabilité et la décentralisation tant attendues deviendront plus faciles à déployer. La synthèse de preuves à zéro connaissance sera prête à l’emploi, sans nécessiter des mois ou des années d’ingénierie cryptographique.

Mais, à mesure que Jolt évoluera — par exemple, en créant une machine virtuelle de preuve à zéro connaissance rapide et simple pour smartphones et ordinateurs portables — les développeurs pourront exploiter davantage de cas d’usage côté client et pour la protection de la vie privée. Par exemple, des applications mobiles de confidentialité pourraient devenir plus faciles à maintenir et à faire fonctionner, avec une mise en œuvre prête à l’emploi.

À long terme, ces systèmes de preuve deviendront des composants fondamentaux de l’infrastructure numérique mondiale, à l’image du chiffrement et des signatures numériques. Cette technologie cryptographique universelle — où chacun peut simplement envoyer un fichier de preuve de 50 Ko pour prouver qu’il possède des dizaines de gigaoctets de données répondant à certains critères — est si puissante qu’il est difficile d’imaginer toutes les applications qu’elle pourrait permettre. Les possibilités sont infinies.