L'apprentissage automatique à zéro connaissance (zkML) est la combinaison de la magie cryptographique et de l'intelligence artificielle. Imaginez prouver qu'un modèle d'apprentissage automatique a produit un résultat spécifique sans divulguer les entrées du modèle, son fonctionnement interne ou ses résultats. C'est la vision du zkML - plusieurs méthodes de pointe rivalisent actuellement pour la concrétiser.
Dans cet article, nous allons explorer trois paradigmes zkML de pointe - JOLT (modifié pour les opérations d'apprentissage automatique et avec des fonctionnalités de précompilation : JOLTx), EZKL (basé sur Halo2) et DeepProve (basé sur GKR), comparer leur fonctionnement et leurs performances, et expliquer pourquoi l'approche centrée sur la recherche de JOLT pourrait révolutionner l'ensemble du secteur comme une boule de neige sur un taxi.
Qu'est-ce que le zkML ?
L'apprentissage automatique à zéro connaissance (zkML) est un domaine émergent qui combine les preuves à zéro connaissance (ZKP) avec l'apprentissage automatique (ML) pour des calculs ML vérifiables et respectueux de la vie privée. Le zkML permet aux prouveurs de prouver qu'un modèle ML a été exécuté correctement sans divulguer d'entrées sensibles ou demander au validateur de relancer les calculs. Vous pouvez également l'utiliser pour cacher les poids du modèle et le modèle lui-même.
Cela est crucial pour des applications telles que les finances décentralisées, l'IA respectueuse de la vie privée et le calcul sécurisé hors chaîne. En garantissant la confidentialité et la décentralisation des inférences ML, le zkML ouvre la voie à des applications AI transparentes et scalables dans la blockchain, le Web3 et d'autres domaines.
Les bases techniques de zkML
zkML basé sur JOLT (JOLTx) - JOLT est un zkVM, une machine virtuelle à zéro connaissance capable de prouver l'exécution de n'importe quel programme (article JOLT, blog JOLT).
JOLT cible l'ensemble d'instructions RISC-V, ce qui signifie que vous pouvez compiler n'importe quel programme (écrit dans des langages de haut niveau comme Rust ou C++) en langage d'assemblage RISC-V, puis générer une preuve que ce code d'assemblage s'exécute correctement.
JOLT introduit en profondeur un nouveau frontend basé sur le concept de "singularités de recherche" : il n'impose plus de lourdes contraintes algébriques pour chaque opération, mais transforme les instructions CPU en recherches dans une énorme table de résultats d'instructions valides prédéfinies. Chaque étape de calcul (comme l'addition, la multiplication, et même les opérations bit à bit) sera vérifiée par des paramètres de recherche rapides appelés Lasso ou plus récemment Shout, en les comparant avec cette table.
Les circuits de JOLT n'ont besoin d'effectuer des opérations de recherche que dans ces tables, simplifiant ainsi considérablement le processus de génération de preuves. Par exemple, les opérations "ou" et "et" à 64 bits (qui seraient coûteuses à exécuter sous des contraintes arithmétiques régulières) ne nécessitent qu'une seule recherche dans le tableau sous JOLT.
Ce design garantit que le prouveur dans chaque instruction CPU n'a qu'à soumettre un petit nombre d'éléments de champ (environ 6 chiffres de 256 bits par étape) et prouver la validité de ces recherches. Cela fait de JOLT une méthode générale et évolutive : tout modèle d'apprentissage automatique peut être considéré comme un programme, et prouvé avec un minimum de conception de circuits personnalisés.
Nous prévoyons de contribuer à la pile JOLT avec certaines fonctionnalités de précompilation dédiées aux opérations d'apprentissage automatique. Les non-linéarités peuvent être efficacement traitées par des recherches, tandis que d'autres propriétés communes peuvent être gérées par des vérifications et certaines techniques uniques à JOLT zkVM.
Nous étendrons cela et l'appellerons JoltX, mais c'est en réalité juste quelques outils et fonctionnalités de précompilation ajoutées sur JOLT, et nous prévoyons de le publier dans quelques mois, restez à l'écoute !
Quels autres projets zkML intéressants existent ?
EZKL (basé sur Halo2) - EZKL adopte une méthode plus traditionnelle de circuits SNARK construits sur Halo2.
EZKL ne simule pas le CPU, mais fonctionne au niveau du graphe de calcul du modèle d'apprentissage automatique. Les développeurs exportent les réseaux neuronaux (ou tout graphe de calcul) en fichiers ONNX, et l'outil EZKL les compile en un ensemble de contraintes polynomiales personnalisées adaptées à ce modèle (circuit arithmétique).
Chaque couche d'un réseau neuronal - comme les convolutions, les multiplications matricielles, les fonctions d'activation - est transformée en contraintes que le prouveur Halo2 peut résoudre. Pour gérer les calculs non-naturels polynomiaux (comme l'activation ReLU ou les opérations sur de grands entiers), Halo2 utilise également des paramètres de recherche, mais de façon plus limitée.
Par exemple, de grandes tables (comme toutes les $2^{64}$ possibilités pour des opérations à 64 bits) doivent être fractionnées ou "chunkées" en tables plus petites (comme des blocs de 16 bits), nécessitant plusieurs recherches et des contraintes de reconstitution pour simuler les opérations d'origine. Ce fractionnement augmente le coût et la complexité du circuit.
Ainsi, la génération de preuves d'EZKL implique de créer de nombreuses telles contraintes et d'utiliser l'algorithme de preuve de Halo2 (généralement KZG ou des engagements basés sur Halo) pour générer des preuves. L'avantage de la méthode EZKL réside dans sa capacité de sensibilisation au modèle - elle peut être spécialement optimisée pour les couches de réseaux neuronaux, et même tailler ou quantifier les poids pour améliorer l'efficacité.
Cependant, chaque nouveau modèle ou type de couche peut nécessiter l'écriture de contraintes personnalisées ou au moins la régénération du circuit, et le prouveur doit gérer de grands systèmes de contraintes, ce qui peut être lent pour de grands modèles.
DeepProve (basé sur GKR) - DeepProve, proposé par Lagrange, prend une voie différente, en utilisant un protocole de preuve interactif appelé GKR (Goldwasser–Kalai–Rotblum).
Essentiellement, GKR considère tout le processus de calcul (similaire à la propagation avant de modèles d'apprentissage automatique) comme un circuit arithmétique hiérarchique et prouve sa validité à travers un protocole de vérification plutôt que des calculs polynomiaux lourds. Le flux de travail de DeepProve consiste à extraire le modèle (également via ONNX), puis à générer automatiquement une séquence de calcul correspondant à chaque couche du réseau neuronal.
Elle ne convertit pas directement en circuits SNARK statiques, mais utilise GKR avec un coût minimal en hachage cryptographique/engagement pour vérifier chaque sortie de couche par rapport à son entrée. Le prouveur dans le schéma GKR exécute alors le calcul du modèle réel, puis procède à une preuve interactive (en utilisant l'algorithme Fiat-Shamir pour la rendre non interactive) pour rassurer le validateur que chaque couche a été calculée correctement.
L'avantage de GKR réside dans le fait que la complexité de son prouveur est linéaire par rapport à la taille du circuit (O(n)), avec un ralentissement très faible par rapport à l'exécution normale, en fait, pour certaines tâches (comme la multiplication de grandes matrices), les systèmes modernes basés sur GKR peuvent être moins de 10 fois plus lents que l'exécution normale. DeepProve combine cela avec des techniques modernes d'engagement polynomial, produisant des preuves concises après les tours de vérification, créant ainsi efficacement un zkSNARK pour l'inférence de réseaux neuronaux.
Un inconvénient de GKR est qu'il est le plus adapté aux calculs structurés (comme les couches statiques des réseaux neuronaux) et qu'il implique une logique de protocole cryptographique plus complexe. Mais son avantage réside dans sa vitesse brute dans les preuves de calcul profond.
Avantages et inconvénients
Chaque méthode a ses avantages uniques et ses inconvénients potentiels.
JOLTx (zkVM précompilé basé sur la recherche)
Avantage : extrêmement flexible (il peut prouver n'importe quel code, pas seulement des réseaux neuronaux) et bénéficie des optimisations de "singularités de recherche" de JOLT, même les opérations de niveau bit sont peu coûteuses.
Il n'est pas nécessaire de personnaliser un circuit pour chaque modèle - il suffit de compiler pour exécuter - ce qui améliore considérablement l'expérience des développeurs et réduit la probabilité d'erreurs.
L'utilisation de Lasso pour trouver signifie prouver que les contraintes s'étendent principalement en fonction du nombre d'opérations exécutées plutôt que de leur complexité, permettant à JOLT d'avoir un modèle de coût cohérent.
Inconvénient : en tant que machine virtuelle générale, elle peut introduire un certain coût pour chaque instruction ; pour des modèles de très grande taille contenant des millions d'opérations simples, des méthodes spécialisées comme GKR peuvent obtenir des temps de preuve absolus plus bas grâce au calcul en flux.
De plus, JOLT est relativement nouveau - il repose sur un ensemble de paramètres de recherche novateurs et une table de niveau ISA complexe, qui sont des technologies de pointe nécessitant du temps pour mûrir. Mais compte tenu de sa conception, même le prototype actuel de JOLT est déjà plus efficace que les zkVM précédents.
EZKL (Halo2 / PLONK)
Avantage : il est construit sur un cadre SNARK largement utilisé, ce qui signifie qu'il peut bénéficier d'outils existants, d'audits et d'un support de validateurs en chaîne (les preuves Halo2 peuvent être vérifiées à l'aide de techniques cryptographiques amicales à Ethereum).
EZKL est assez facile à utiliser pour les data scientists : vous pouvez utiliser des modèles PyTorch ou TensorFlow, les exporter en ONNX, et obtenir des preuves que l'inférence du modèle a été correctement réalisée.
Elle a déjà réalisé des intégrations pratiques (des modèles de risque DeFi à l'IA de jeux, que nous discuterons ci-dessous), ce qui démontre sa capacité à prouver de vraies tâches d'apprentissage automatique.
Inconvénient : à mesure que le modèle augmente, les performances peuvent devenir un goulet d'étranglement, les circuits SNARK traditionnels entraînant souvent d'énormes coûts - historiquement, la charge de travail du prouveur était un million de fois plus importante que de simplement exécuter le modèle.
L'approche de Halo2 essaie d'optimiser, mais des opérations comme la multiplication de grandes matrices ou les activations non linéaires se traduisent toujours par de nombreuses contraintes, et la nécessité de fractionner les grandes recherches (comme l'arithmétique à 32 bits ou les fonctions non linéaires) ajoute des contraintes et des temps de preuve supplémentaires.
Essentiellement, EZKL peut avoir du mal à gérer les réseaux très grands (en termes de temps de preuve et de mémoire), nécessitant parfois le fractionnement de circuits ou des techniques spéciales pour s'adapter aux limitations pratiques. C'est une bonne méthode SNARK générale, mais ce n'est pas la plus rapide lors de l'extension.
DeepProve (GKR)
Avantage : offre une vitesse de génération de preuves extrêmement rapide pour des modèles profonds, en évitant le coût d'encoder chaque multiplication en contraintes polynomiales, GKR permet au prouveur de n'effectuer pratiquement que des calculs numériques réguliers, puis d'ajouter une mince couche de vérification cryptographique. L'équipe DeepProve rapporte que, pour un réseau neuronal équivalent, la vitesse de preuve de GKR est de 54 à 158 fois plus rapide qu'EZKL.
En fait, plus le modèle est grand, plus l'avantage de GKR est important : à mesure que la complexité du modèle augmente, l'avantage de DeepProve augmente également, car son extension linéaire reste contrôlable, tandis que le coût des méthodes basées sur des circuits continue d'exploser.
Inconvénient : cette méthode n'est en quelque sorte applicable qu'aux calculs de type circuit (heureusement, ce type de calcul couvre la plupart des apprentissages automatiques feedforward), si votre charge de travail contient beaucoup de logique conditionnelle ou d'opérations irrégulières, alors sa flexibilité sera réduite - ces opérations sont plus faciles à gérer dans des machines virtuelles comme JOLT.
De plus, faire des preuves GKR de manière à ce qu'elles soient des preuves à zéro connaissance et concises entraînera des tailles de preuves plus grandes que celles des preuves SNARK classiques et des programmes de vérification. Bien que ces derniers soient beaucoup plus rapides que de relancer le modèle entier, cela ne se fait pas instantanément.
Le temps de validation de la preuve de DeepProve pour un CNN est d'environ 0,5 seconde, ce qui est excellent pour de grands modèles, mais les validateurs SNARK traditionnels peuvent le faire en millisecondes.
Ainsi, DeepProve se concentre sur la performance, ce qui peut se faire au prix de la complexité du protocole de preuve et de tâches de validation légèrement plus lourdes que celles des preuves Halo2, c'est une méthode puissante pour étendre le zkML, en particulier dans des environnements serveur ou cloud, bien qu'elle ne soit peut-être pas aussi adaptée aux clients légers ou à la validation en chaîne avant d'être optimisée davantage.
Comparaison des performances et de l'efficacité
En termes de performances brutes, chaque méthode zkML a des priorités différentes, le temps de génération de preuves étant souvent un indicateur clé. Le prouveur basé sur GKR de DeepProve occupe actuellement la première place en termes de vitesse - les tests de référence montrent qu'il génère des preuves de 50 à 150 fois plus rapidement qu'EZKL pour le même modèle.
Ce saut provient de l'algorithme de temps presque linéaire de GKR, qui évite les lourdes opérations algébriques polynomiales des circuits SNARK. En fait, une inférence de réseau neuronal qui pourrait prendre des heures à prouver avec EZKL peut être réalisée en quelques minutes avec DeepProve, et à mesure que l'échelle du modèle augmente (plus de couches, plus de paramètres), cet écart se creuse encore, car le coût par opération unique de GKR reste bas tandis que celui de Halo2 continue d'augmenter.
Les objectifs de performance de JOLT sont tout aussi ambitieux - son objectif est d'être un ordre de grandeur plus rapide que les cadres SNARK existants. L'équipe a déjà démontré que Lasso (le moteur de recherche dans JOLT) fonctionne 10 fois plus vite que le mécanisme de recherche de Halo2, et elle prévoit d'augmenter cette vitesse à 40 fois.
Cela signifie que les opérations qui étaient autrefois des goulets d'étranglement (comme ces opérations bit à bit ou des calculs dans de grands champs) deviennent beaucoup moins coûteuses. JOLT échange essentiellement des calculs pour des recherches dans des tableaux, et grâce à Lasso, le coût de recherche de valeurs dans d'énormes tableaux virtuels est faible, le coût n'augmente pas avec la taille du tableau (non, ils ne stockent pas réellement 2^{128} lignes de données en mémoire !) - il augmente principalement avec le nombre de recherches exécutées.
Ainsi, si votre modèle d'apprentissage automatique exécute un million de ReLU, le coût du prouveur augmentera avec ces millions d'opérations, mais chaque opération n'est qu'une simple vérification de tableau, les résultats préliminaires indiquent que le prouveur de JOLT ne traite qu'un petit nombre d'éléments de champ d'engagement par étape d'instruction, avec un coût très faible. En résumé, JOLT optimise au maximum le volume de calcul de chaque opération, en utilisant des connaissances précalibrées (tableaux de recherche) pour sauter des calculs mathématiques dynamiques complexes, réduisant ainsi considérablement le coût traditionnel de SNARK.
La combinaison d'EZKL et de Halo2, bien que plus lente, n'a pas non plus stagné. Elle bénéficie des optimisations de Halo2, telles que des portes personnalisées et des recherches partielles. Pour des modèles de taille moyenne, EZKL est totalement utilisable et a prouvé sa supériorité sur certaines alternatives précoces. Sur Cairo, elle est environ 3 fois plus rapide que les méthodes basées sur STARK, et lors d'un test de référence en 2024, elle était 66 fois plus rapide que RISC-V STARK.
Cela indique que des circuits SNARK soigneusement optimisés peuvent surpasser des machines virtuelles aux implémentations plus simples, l'inconvénient étant qu'afin d'atteindre ces vitesses, EZKL et Halo2 doivent soigneusement peaufiner chaque détail, et ils héritent toujours des coûts fondamentaux des engagements polynomiaux, FFT et des algorithmes de preuve.
En revanche, les nouvelles approches de JOLT et de DeepProve évitent la plupart des coûts liés à la FFT ou aux polynômes de haut degré. JOLT se limite à des opérations de recherche (en ajoutant un nouveau paramètre pour traiter efficacement ces opérations de recherche), tandis que DeepProve utilise des sommes et des vérifications (ce qui est adapté aux polynômes multilineaires et nécessite uniquement des engagements de hachage légers).
Dans les SNARK classiques, une grande partie du temps est consacrée à calculer des opérations comme de grandes FFT ou des multiplications scalaires multiples. GKR évite largement les FFT en opérant sur des hypercubes booléens et des extensions multilinéaires, tandis que JOLT évite de devoir réaliser de grandes FFT dès le départ en n'implémentant pas de grandes tables.
En ce qui concerne la taille des preuves et la validation, il existe un compromis ; JOLT et EZKL (Halo2) génèrent finalement des preuves SNARK standard (généralement de quelques Ko) qui peuvent être vérifiées rapidement (avec quelques appariements ou quelques évaluations polynomiales).
La méthode de DeepProve est similaire à STARK, elle peut générer des preuves plus volumineuses (dizaines de Ko à centaines de Ko, selon le modèle), et bien que la validation soit beaucoup plus rapide que de relancer le modèle, elle pourrait inclure plus d'étapes que la validation de preuves KZG concises.
L'équipe de DeepProve souligne que leur vitesse de validation est 671 fois plus rapide que de simplement recalculer le MLP avec un GPU, permettant de réduire le temps de validation à environ 0,5 seconde pour des modèles assez complexes.
C'est un résultat puissant, montrant que même si la taille des preuves est plus grande, la validation est beaucoup plus facile que de réaliser des calculs d'intelligence artificielle bruts (ceci est particulièrement important si le validateur est un contrat intelligent ou un client léger avec des capacités de calcul limitées). Les preuves de Halo2 sont également plus petites et plus rapides à valider, mais si la vitesse de preuve initiale est trop lente pour votre application, cette différence devient négligeable.
Un aspect important de l'efficacité est la façon dont ces cadres gèrent des opérations spéciales. Par exemple, dans l'inférence d'apprentissage automatique, nous rencontrons souvent des étapes non linéaires (comme ArgMax, ReLU ou Sigmoid). EZKL peut gérer ReLU en appliquant des contraintes via des sélecteurs booléens (ce qui peut être réalisé par recherche ou d'autres contraintes).
En revanche, JOLT peut implémenter ReLU dans le programme (en tant que quelques instructions CPU basées sur des bits symboliques) et prouver ces branches à faible coût par recherche - exploitant essentiellement la capacité de comparaison du CPU.
DeepProve peut s'adapter aux fonctions linéaires par morceaux en intégrant des fonctions linéaires par morceaux dans le circuit arithmétique que GKR va valider, mais des fonctions hautement non linéaires (comme Sigmoid) peuvent nécessiter des approximations polynomiales ou par recherche. En somme, l'idée de JOLT est de rendre tout ce qui est particulier normal, en exécutant le code réel (y compris les instructions conditionnelles, les boucles, etc.) et en utilisant des paramètres de recherche pour couvrir la logique de n'importe quelle opération.
Le principe de Halo2 est de restreindre tout à des équations polynomiales (ce qui peut être fastidieux pour des calculs complexes), tandis que le principe de GKR est de décomposer les calculs en sommes et produits vérifiables de manière récursive. L'efficacité de chaque méthode pour traiter ces problèmes se reflète dans le temps de preuve : JOLT pourrait exceller au contrôle logique, GKR pourrait exceller dans de grands calculs d'algèbre linéaire, tandis que Halo2 se situe entre les deux, équilibrant les deux mais avec un coût plus élevé.
Pour valider les preuves Kinic, nous utilisons la blockchain Internet Computer, car elle traite les validations de preuves à plus grande échelle plus rapidement que les autres blockchains L1, nous ne sommes pas non plus limités par les précompilations, car celles-ci nécessitent un certain travail complexe pour mettre JOLTx sur la blockchain.
Scalabilité des grands modèles
Lorsque nous parlons de scalabilité dans zkML, nous pourrions faire référence à deux choses : gérer de grands modèles (multi-niveaux, un grand nombre de paramètres) et gérer des modèles diversifiés (différentes architectures ou même des modèles dynamiques). Nous considérons d'abord le déploiement à grande échelle - supposons que vous souhaitiez valider l'inférence sur un grand CNN ou un Transformer avec des millions de paramètres.
DeepProve est conçu pour ce scénario, sa performance s'accélérant à mesure que la taille du modèle augmente. Par exemple, si un petit modèle (comme un micro MLP) est prouvé 50 fois plus rapidement avec DeepProve qu'avec EZKL, un modèle plus grand pourrait être prouvé plus de 100 fois plus rapidement.
L'équipe note qu'à mesure que nous étendons à des modèles contenant des millions de paramètres, la vitesse de DeepProve sera plus rapide que celle d'autres solutions. Ils prévoient d'augmenter cette vitesse grâce à des techniques de preuve parallèles et distribuées. GKR se prête facilement à la parallélisation, car de nombreux sous-calculs (comme tous les neurones d'une couche) peuvent être validés en lot.
De plus, GKR ne nécessite pas une énorme "clé de preuve" monolithique qui croît avec la taille du circuit - il peut s'exécuter en temps réel, donc avec une empreinte mémoire plus faible, ce qui fait de DeepProve une solution prometteuse pour la validation de réseaux neuronaux à grande échelle dans le cloud ou même en chaîne à l'avenir.
EZKL (Halo2) peut gérer des réseaux assez grands, mais présente également des limites. Construire un seul circuit géant pour un grand modèle peut nécessiter beaucoup de mémoire et de temps (dans certains cas, des dizaines de Go de RAM et des heures de temps de calcul). L'équipe EZKL explore constamment des moyens d'améliorer, comme le fractionnement de circuits et l'agrégation (prouver séparément des parties du modèle puis combiner les preuves), ainsi que des stratégies de quantification pour réduire la complexité arithmétique.
Cependant, des algorithmes SNARK généraux comme Halo2 continueront à rencontrer des défis au-delà d'une certaine échelle sans optimisations spécifiques, ils peuvent être mieux adaptés aux modèles de taille petite à moyenne, ou à des scénarios hors ligne où les preuves ne sont pas générées fréquemment (ou si un matériel puissant est disponible).
L'avantage est qu'une fois la preuve générée, même pour de grands modèles, il est facile de la valider - ce qui est très utile dans les scénarios en chaîne, car un contrat intelligent pourrait valider une preuve pour un modèle contenant 100 millions de paramètres, ce qui est absolument impraticable à recalculer sur la chaîne.
JOLT est dans une position intéressante en termes de scalabilité, d'une part, c'est une méthode basée sur SNARK, donc sa charge de travail doit également être à peu près linéaire par rapport au nombre d'opérations exécutées (comme Halo2 et GKR).
D'autre part, grâce à l'adoption d'une technologie basée sur la recherche, le coût constant de chaque opération de JOLT est très faible. Si nous considérons un "déploiement à grande échelle", comme l'exécution d'un modèle contenant 10 millions d'opérations, JOLT devra exécuter ces 10 millions de recherches et les engagements correspondants, ce qui est lourd, mais n'est pas fondamentalement plus lourd que GKR ou même un circuit simple - c'est toujours linéaire.
La question est : à quel point JOLT peut-il optimiser et paralléliser cela ? Puisque JOLT considère chaque instruction comme une étape, si le système de preuve prend en charge le suivi fractionné, il peut réaliser la parallélisation des preuves en exécutant plusieurs instructions en parallèle (comme plusieurs cœurs CPU).
Les recherches actuelles montrent qu'ils se concentrent d'abord sur les performances monocœurs (avec un coût d'environ 6 éléments de champ par étape), mais comme cette méthode est une machine virtuelle, on peut imaginer que dans le futur, différentes parties du suivi des programmes pourraient être distribuées entre les prouveurs (ce n'est que spéculatif, mais compte tenu de la capacité de combinaison des paramètres de recherche, ce n'est pas impossible).
Même sans distributions sophistiquées, JOLT peut tirer parti des techniques d'engagement polynomial existantes - par exemple, un paramétrage universel qui prend en charge des circuits de taille arbitraire, donc il n'est pas nécessaire de fournir un nouvel paramétrage de confiance pour des modèles plus grands.
Dans le traitement de différentes architectures ML, JOLT performe bien : que votre modèle soit un CNN, un RNN avec des boucles, un ensemble d'arbres de décision ou un modèle hybride quelconque, tant que vous pouvez l'exécuter sur un CPU, JOLT peut prouver sa validité. Cela lui confère une scalabilité élevée sur le plan du développement - vous n'avez pas besoin de redessiner les méthodes de preuve pour chaque nouveau type de modèle.
DeepProve et d'autres méthodes basées sur GKR sont actuellement personnalisées pour des réseaux de neurones profonds typiques (couches d'opérations matricielles et fonctions élémentaires). Ils s'étendent de manière impressionnante avec la profondeur et la largeur du réseau, mais si vous leur imposez des charges de travail très irrégulières (comme un modèle dynamique qui saute des couches ou a des boucles de dépendance de données), le cadre peut nécessiter des ajustements ou pourrait perdre un certain degré d'efficacité.
Cependant, la plupart des modèles d'apprentissage automatique à grande échelle déjà déployés (visuels, traitement du langage naturel, etc.) ont une structure régulière, donc cela ne pose pas de problème.
On peut se demander : quelle méthode est la plus adaptée à une utilisation en temps réel ou sur appareil plutôt qu'à l'échelle du cloud ? Le temps réel signifie que même pour des modèles plus petits, nous voulons que la latence de preuve soit très basse.
L'approche de JOLT est un SNARK qui pourrait permettre de prouver des modèles plus petits en quelques secondes ou moins sur un bon appareil, en particulier dans un contexte où la technologie est mature. EZKL sur un CPU mobile pourrait être plus lent (les preuves Halo2 ne sont pas encore complètement adaptées aux appareils mobiles, bien qu'il y ait des efforts pour les accélérer).
DeepProve peut tirer parti des GPU de manière efficace - si un GPU est disponible sur le dispositif, il peut en réalité prouver rapidement un petit modèle (GKR aime le matériel parallèle), mais DeepProve sur CPU peut ne pas être optimisé pour des scénarios en temps réel autant que JOLT sur CPU.
Ainsi, la scalabilité ne concerne pas seulement le traitement de modèles plus grands - il s'agit également de traiter efficacement les bonnes tailles dans les bons environnements. L'objectif de JOLT est de devenir un pilier polyvalent à travers les environnements, ce qui en fait un candidat fort pour le déploiement cloud et edge à long terme.
JOLTx : redéfinir les capacités zkML par vérification et recherche
Avec autant d'innovations, pourquoi devrions-nous encore insister sur le fait que le zkML basé sur JOLT est le meilleur choix pour l'avenir ? La réponse réside dans sa polyvalence, ses performances et ses applications pratiques - cette combinaison est difficile à surpasser.
Tout d'abord, JOLT introduit un nouveau paradigme pour construire des SNARKs. JOLT ne cherche plus à intégrer des programmes de haut niveau dans le circuit un par un, mais réalise la vision de concevoir des circuits qui n'exécutent que des opérations de recherche, ce qui signifie que la complexité est traitée à la phase de pré-calcul (définissant ces énormes tables d'instructions), tandis qu'à la phase en ligne, c'est très simple : il suffit de prouver que vous avez effectué une recherche valide.
C'est comme transformer chaque opération complexe dans le circuit en étapes "O(1)", ce qui réduit considérablement le coût pour le prouveur d'exécuter des tâches traditionnellement très lourdes dans les SNARK (comme les opérations bit à bit, la logique de branchement arbitraire).
Pour les modèles d'apprentissage automatique, qui mélangent généralement l'algèbre linéaire (que SNARK peut traiter) et des décisions ou transformations de données non linéaires (que SNARK ne gère pas bien), JOLT propose une solution équilibrée - l'algèbre linéaire doit toujours être effectuée étape par étape, mais chaque opération arithmétique est simple, et toute décision non linéaire (comme "si le neurone > 0 alors...") est également simple, car la VM peut simplement se ramifier, et la preuve de la bonne branche n'est qu'une vérification de recherche.
Deuxièmement, JOLT est rapide et continue de s'améliorer. La recherche derrière elle montre que sa vitesse de prouveur peut être immédiatement augmentée de plus de 10 fois par rapport aux outils SNARK mainstream, et suggère qu'elle pourrait atteindre 40 fois avec des optimisations.
Elle hérite également de nombreuses améliorations initiales de SNARK : elle adopte des schémas modernes d'engagement polynomial et peut tirer parti des bibliothèques cryptographiques existantes, son argument de base Lasso étant centré sur l'efficacité, et elle a déjà montré des performances supérieures à celles des anciens arguments de recherche (qui étaient des goulets d'étranglement pour des systèmes comme Halo2).
Pour l'apprentissage automatique en temps réel ou local, cela signifie que l'idée de générer des preuves sur un smartphone ou un ordinateur portable devient soudainement moins folle. Si votre inférence de modèle prend généralement 100 millisecondes, alors JOLT pourrait le prouver en quelques secondes - c'est un gros problème !
En revanche, les preuves des anciennes méthodes peuvent prendre des minutes ou des heures, ce qui les rend irréalisables en dehors des salles de serveurs. L'augmentation de l'efficacité de JOLT rapproche le zkML du domaine d'utilisation interactive.
Par exemple, nous pouvons imaginer une extension de navigateur qui utilise JOLT pour prouver en temps réel "J'ai exécuté un modèle visuel sur l'image que vous venez de télécharger, et elle ne contient aucun contenu NSFW", puis autoriser la publication de cette image.
Ou le calculateur embarqué d'une voiture prouve à un serveur d'assurance qu'il a effectivement utilisé un modèle de conduite vérifié pendant la conduite autonome, ces scénarios nécessitant un retour rapide, et la rapidité de JOLT les rend possibles.
Un autre facteur important est l'expérience des développeurs et des utilisateurs. JOLT permet aux développeurs d'utiliser les langages et modèles avec lesquels ils sont familiers (via la compilation en RISC-V et la conversion ONNX à venir), vous n'avez pas besoin de comprendre la complexité des circuits SNARK pour l'utiliser.
Pour le domaine de l'apprentissage automatique, c'est crucial : la plupart des ingénieurs en apprentissage automatique ne sont pas des experts en cryptographie, et ils ne devraient pas avoir à le devenir. Avec JOLT, ils peuvent écrire ou compiler du code existant et obtenir des preuves, cette approche est similaire aux débuts des GPU - au départ, seuls des experts en graphisme écrivaient du code pour les GPU, mais finalement, des cadres généraux ont permis à n'importe quel programmeur d'utiliser l'accélération GPU.
Dans ce sens, JOLT ressemble à un "GPU pour les preuves à zéro connaissance" : un moteur spécialisé accessible via des chaînes d'outils standard, ce qui réduit considérablement le seuil d'adoption. Nous pourrions très bien voir certaines bibliothèques empaqueter des tâches d'apprentissage automatique courantes (comme l'inférence de modèles, la preuve d'exactitude de modèles, etc.) sur JOLT pour un usage plug-and-play.
L'auditabilité de JOLT est un autre changement subtil, car il s'agit essentiellement de prouver l'exécution d'une ISA standard, il est donc plus facile de raisonner et d'auditer que des circuits personnalisés. Vous pouvez vous fier à la précision de la spécification RISC-V bien définie et des tableaux de recherche, sans avoir à vérifier des milliers de contraintes manuscrites, ce qui signifie que la preuve des modèles d'apprentissage automatique critiques a une plus grande crédibilité.
Par exemple, si un modèle est utilisé pour des décisions judiciaires ou médicales, alors avoir une trace claire ("ce programme a été exécuté correctement") est beaucoup plus rassurant que "ce circuit personnalisé que seuls quelques experts comprennent a été satisfait". Si nécessaire, les auditeurs peuvent même exécuter pas à pas la trace d'exécution de la machine virtuelle, ce qui n'est pas réalisable dans une preuve de circuit monolithique.
Les preuves à zéro connaissance basées sur JOLT (zkML) allient à la perfection l'élégance théorique à la mise en œuvre pratique - offrant à la fois les percées de performance nécessaires à la scalabilité et la flexibilité requise pour les applications variées, transformant les preuves à zéro connaissance en utilitaires rapides et conviviaux pour les développeurs.
Bien que les méthodes basées sur Halo2 et GKR aient ouvert la voie, montrant leur potentiel (et continueront à être appliquées avec leurs avantages spécifiques), JOLT a l'ambition d'unifier et d'élever le domaine du zkML, tout comme le saut de l'assemblage manuel à la programmation de haut niveau - une fois qu'une solution générale et efficace apparaîtra, elle pourra permettre à tout un écosystème de prospérer.
Pour quiconque souhaite déployer un apprentissage automatique vérifiable en pratique, JOLT offre une voie claire et extrêmement attrayante à suivre : des preuves rapides, adaptées à n'importe quel modèle, à tout moment et en tout lieu, l'avenir du zkML appartient également aux zkVM soigneusement conçus et à leur code précompilé !
Le contenu IC qui vous intéresse
Avancées techniques | Informations sur le projet | Événements mondiaux
Suivez le canal Binance IC
Restez informé