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é leur 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 et la vérification des transactions. Tout cela grâce à « Jolt Inside ».

Qu’est-ce que Jolt ? Jolt est une machine virtuelle zkRISC-V open source (ou plus précisément, une machine virtuelle « simple »), 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 tout le monde 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 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é, « simple » signifie que la preuve est courte et facile à vérifier — deux qualités utiles mais distinctes, souvent confondues. (Jolt possède déjà la propriété de simplicité, et implémentera bientôt la zéro connaissance.)

Mais pourquoi une zkVM est-elle si importante ? La zkVM, ainsi que la notion plus large de SNARK (preuve à connaissance succincte non interactive), sont des éléments clés pour la scalabilité, la confidentialité et la sécurité de la blockchain. Ces preuves, arguments et zéro connaissance (au sens général) sont utilisés dans de nombreux domaines, notamment en cryptographie.

En raison de l’architecture de conception traditionnelle et d’autres raisons, l’industrie a jusqu’ici adopté des méthodes plutôt complexes pour construire des zkVM ; nous détaillerons cela plus loin. Cependant, Jolt a été conçu dès le départ avec une approche radicalement différente, 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 a l’avantage par rapport à d’autres SNARKs d’être plus conviviale pour les développeurs. En exploitant l’infrastructure informatique existante (par exemple, l’écosystème open source LLVM), les développeurs peuvent utiliser SNARK sans recourir à un langage spécifique au domaine (DSL), dans le langage de programmation de leur choix.

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ées pour le chiffrement et la signature numérique — des développeurs ordinaires utilisent ces bibliothèques 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 des nouvelles applications cryptographiques.

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

Cependant, même si Jolt a fait de grands 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) nécessite encore une puissance de calcul importante. Pour produire des preuves complexes en un temps raisonnable, il faut plusieurs GPU. LayerZero a porté le générateur de preuves Jolt sur CUDA, et a lancé Zero : une version hautement parallélisée de l’algorithme Jolt adaptée au hardware GPU, permettant une meilleure scalabilité.

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

R&D open source

Jolt est open source, ce qui permet à quiconque de l’utiliser ou de développer dessus. L’open source est un multiplicateur ultime : partager ouvertement les résultats permet à un plus grand nombre dans l’écosystème de réutiliser, tester, auditer, corriger et innover.

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 laboratoires d’entreprises ou, aujourd’hui, les laboratoires de fondations — ou sur la recherche académique. La création de a16z crypto vise à établir un laboratoire de recherche industriel et une équipe d’ingénierie reliant la théorie académique à la pratique industrielle. En tant que fonds de capital-risque, nous pouvons aussi financer des projets que d’autres ne peuvent pas, notamment dans une optique de reverse investing.

Soutenir une approche de conception SNARK basée sur le reverse 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 a été mûrie sur plusieurs années.

L’histoire de l’innovation est souvent celle d’un changement d’architecture

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, que des érudits du Moyen-Orient, d’Asie et d’autres régions ont ensuite enrichis.

Ces premières preuves — des déductions logiques écrites étape par étape — étaient enregistrées sous forme de langages formels ou d’équations, 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 sur un support fixe, est à l’origine de la classe NP en complexité.

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 la notion 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é.] La preuve interactive repose sur l’idée que, par échange en temps réel, deux parties — un prouveur et un vérifieur — peuvent explorer la validité d’une assertion sans attendre que le prouveur écrive une preuve complète. En d’autres termes, ils peuvent poser des questions en direct, permettant une exploration interactive de la preuve.

Ce pouvoir énorme, par rapport à la preuve statique 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 d’Adi Shamir, cette approche a rapidement conduit à la conclusion fondamentale « IP=PSPACE » — une formulation technique qui résume intuitivement que :

si le prouveur et le vérifieur peuvent interagir — comme dans un système de challenge-réponse — (en supposant qu’un prouveur menteur ne sera pas capable de répondre à des défis qu’il ne peut pas prévoir), 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 la conception des systèmes de preuve. La vérification par sommation (sum-check) en est le cœur : elle permet au vérifieur 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 informaticien) écrit une preuve dans un « livre » très redondant. La particularité est que le vérifieur 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, vérifier la validité de la preuve.

Mais le problème, c’est que ces preuves PCP sont très longues, même si leur vérification est peu coûteuse.

Kilian a donc montré comment combiner PCP et cryptographie : le prouveur peut « promettre » qu’il a écrit le livre entier, 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érifieur de la validité de l’ensemble.

À l’époque, ces preuves étaient encore interactives. Ensuite, Micali a montré comment appliquer la transformation de Fiat-Shamir pour convertir une preuve interactive basée sur PCP en preuve non interactive. En résumé, la transformation Fiat-Shamir « supprime » le défi aléatoire du vérifieur, 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 (voir Kilian), pour revenir finalement à non interactif (voir Micali). SNARK apparaît à la fin de cette évolution : en appliquant la transformation de Fiat-Shamir à la preuve interactive de Kilian, Micali a obtenu ce que l’on appelle 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 limitait leur déploiement pratique.

Pourtant, la conception des SNARK a suivi cette voie pendant des décennies. Même si l’industrie a tenté de s’en détacher, les concepteurs ont continué à utiliser des concepts liés (par exemple, « PCP linéaire »), qui ne sont que des variantes inspirées de PCP. Ces méthodes ont permis de produire des SNARK très courts, mais pas forcément les plus rapides à générer.

Les concepteurs de SNARK n’ont pas 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.

En fait, pour adopter plus tôt la vérification par sommation, il faudrait repenser l’histoire des SNARK de façon non linéaire. En passant de (a) preuve interactive → (b) PCP → © preuve interactive succincte → (d) SNARKs précoces, l’industrie a connu plusieurs changements :

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

Mais lors de la transition de (b) à ©, l’interactivité est revenue… puis, via la transformation de Fiat-Shamir, elle a été éliminée, permettant de passer de © à (d).

En regardant tout cela de manière linéaire, on voit que les concepteurs de SNARK ont en réalité 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 de Fiat-Shamir pour supprimer l’interactivité… il faut sauter directement l’étape (b), c’est-à-dire la preuve vérifiable probabiliste ! C’est cette idée clé derrière Jolt : construire directement un SNARK à partir d’une preuve interactive en utilisant la vérification par sommation.

Pourquoi plus tôt n’a-t-on pas adopté cette approche basée sur la vérification par sommation ? Peut-être parce que, initialement, SNARK et PCP semblaient très similaires, tous deux visant la 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 vérification par sommation, comme Jolt, c’est un pari inversé : cela va à l’encontre du paradigme dominant en SNARK depuis des décennies.

‘Jolt Inside’

La méthode SNARK de Jolt (fondée sur la vérification par sommation et la mémoire tampon, comme Twist + Shout) repose sur des principes issus de la preuve interactive et de la vérification par sommation.

Après plusieurs années de développement de Jolt, d’autres commencent aussi à utiliser cette approche dans leurs propres designs. 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-decode-execute » de chaque cœur CPU peut s’appliquer à la vérification par sommation, Jolt atteint une efficacité inégalée avec une complexité minimale.

À l’inverse, 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 reproduiraient l’erreur des méthodes de conception SNARK antérieures : nécessitant des experts pour concevoir ces circuits spécialisés, ils sont plus sujets aux bugs et plus difficiles à rendre accessibles aux 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à optimisée. Les infrastructures mondiales sont conçues pour supporter le CPU, et Jolt exploite cette « structure » intrinsèque pour maximiser simplicité et performance.

Dès le départ, Jolt a mis l’accent sur la disponibilité et la performance de 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, ce qui facilite l’adoption, l’audit et la mise à jour.

Et surtout, Jolt est 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 : chaque instruction de base peut être codée en une dizaine de lignes en Rust. Pas besoin de circuits, seulement quelques lignes de code.

La prochaine étape pour Jolt ?

Nous sommes déjà en avance en termes de vitesse. Avec des optimisations et fonctionnalités supplémentaires — notamment la récursivité et la preuve à zéro connaissance, et la transition prévue de la cryptographie elliptique vers la cryptographie par lattices — nous atteindrons d’ici la fin de l’année une nouvelle étape de performance, y compris pour 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. Les preuves à zéro connaissance seront prêtes à l’emploi, sans nécessiter des mois ou des années d’ingénierie cryptographique.

Mais en avançant, notamment en développant une zkVM rapide et simple pour smartphones et ordinateurs portables, les développeurs pourront exploiter davantage de cas d’usage côté client et en matière de confidentialité. Par exemple, des applications de protection de la vie privée sur mobile, autrefois difficiles à maintenir ou à faire fonctionner, deviendront simples à déployer.

À 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 envoyer un fichier de preuve de 50 Ko attestant qu’il possède plusieurs gigaoctets de données répondant à certains critères — est si puissante qu’il est difficile d’imaginer toutes les applications qu’elle pourra alimenter. Les possibilités sont infinies.