Skip to main content

Qu'est-ce que le zkML

Remarque : Ce document est une traduction automatique de la version originale anglaise.

Qu'est-ce que le zkML

Le zkML (Zero-Knowledge Machine Learning) est une technique qui utilise des preuves à divulgation nulle de connaissance pour vérifier qu'un modèle d'apprentissage automatique a exécuté son inférence correctement — sans révéler les poids du modèle, les données d'entrée, ou les deux. Elle fournit une garantie cryptographique : « cette sortie a été produite par ce modèle sur cette entrée », et n'importe qui peut vérifier la preuve sans voir les informations privées.

En bref : le zkML permet de prouver qu'un modèle d'IA s'est exécuté correctement sans exposer le modèle ni les données. C'est l'une des approches de l'IA vérifiable qui fournit une garantie mathématique (sans confiance) d'inférence correcte, et l'une des plus difficiles techniquement.

Analogie pour les débutants

Imaginez un examen scellé. Un étudiant entre dans une salle, passe un test et remet la feuille de réponses scellée à un surveillant. Le surveillant peut vérifier, grâce à un sceau inviolable, que l'étudiant a répondu à chaque question en utilisant le manuel approuvé et a respecté toutes les règles de l'examen — sans jamais voir les notes de l'étudiant, ses supports de révision ni son raisonnement. Le surveillant sait que le résultat est légitime, mais n'apprend rien sur la façon dont l'étudiant s'est préparé. Le zkML fonctionne de la même manière : il prouve que l'IA a « passé le test correctement » sans révéler le modèle (les supports de révision) ni les données d'entrée (les notes de l'étudiant).

Le problème qu'il résout

Dans l'IA décentralisée, la confiance est un enjeu central. Quand l'inférence s'exécute sur un nœud distant, comment le demandeur sait-il que le bon modèle a réellement été utilisé ? Le fournisseur pourrait exécuter un modèle moins cher, renvoyer un résultat mis en cache ou sauter entièrement des étapes de calcul. Dans l'IA centralisée, les utilisateurs font confiance au fournisseur par réputation. Dans les systèmes décentralisés, la réputation seule ne suffit pas — la vérification cryptographique comble cette lacune.

Ce problème devient particulièrement important lorsque les sorties de l'IA pilotent des décisions à enjeux élevés. Si un protocole on-chain s'appuie sur la sortie d'un modèle pour déclencher une action de smart contract — par exemple ajuster un paramètre de risque ou approuver une transaction — il doit exister un moyen de garantir que la sortie est authentique. Sans vérification, le système n'est digne de confiance que dans la mesure de son nœud le moins honnête.

Comment ça fonctionne (simplifié)

Un pipeline zkML suit ces étapes générales :

  1. Conversion du modèle. Le modèle ML (typiquement un réseau de neurones) est converti en circuit arithmétique — une représentation mathématique avec laquelle les systèmes de preuve ZK peuvent travailler. Cette étape traduit des opérations comme les multiplications matricielles, les fonctions d'activation et les couches de normalisation en contraintes de circuit.
  2. Exécution du modèle. Le fournisseur exécute le modèle ML sur les données d'entrée et produit une sortie (p. ex. une classification, un texte généré, une prédiction).
  3. Génération de la preuve. Avec la sortie, le fournisseur génère une preuve à divulgation nulle de connaissance — un objet mathématique compact qui encode l'affirmation « cette sortie a été produite en exécutant ce modèle spécifique sur cette entrée spécifique ». C'est l'étape coûteuse en calcul : le prouveur doit démontrer que chaque opération du circuit a été exécutée correctement.
  4. Vérification de la preuve. N'importe qui (le demandeur, un smart contract, un tiers) peut vérifier la preuve. La vérification est rapide et peu coûteuse comparée à la réexécution du modèle. Si la preuve est valide, la sortie est garantie correcte.

La propriété clé : le vérificateur n'apprend rien sur les poids du modèle ni sur les données d'entrée au-delà de ce que révèle la preuve. Confidentialité et vérifiabilité coexistent.

Ce qui rend la génération de preuves coûteuse

Le coût vient de la traduction des opérations ML en circuits ZK. Chaque multiplication ou addition dans un réseau de neurones devient une contrainte, et le prouveur doit générer un témoin cryptographique satisfaisant toutes les contraintes simultanément. Pour un modèle à des millions de paramètres, cela signifie des millions de contraintes. Les frameworks actuels utilisent différents systèmes de preuve (SNARK, STARK et approches hybrides) avec des compromis variables entre taille de preuve, temps de vérification et coût du prouveur.

Pourquoi c'est important pour DecAIHub

DecAIHub évalue si les projets d'IA crypto possèdent une IA réelle et vérifiable. Le zkML représente une approche pour rendre les affirmations d'IA prouvables cryptographiquement — un projet qui utilise le zkML peut prouver que son modèle s'est réellement exécuté, et pas seulement l'affirmer. Dans le cadre DecAI Fit, la vérification basée sur le zkML contribue à la dimension Onchain necessity, démontrant une connexion significative entre le pipeline IA et la blockchain. Les projets implémentant le zkML apparaissent dans des catégories comme AI/Inference et AI/Compute.

Du point de vue de la vérification DecAIHub, les projets zkML présentent un profil de preuves distinctif. Lorsqu'un projet implémente réellement le zkML, il existe de solides artefacts Tier-1 à évaluer : circuits de preuve, contrats de vérification on-chain, données de benchmark pour les temps de génération de preuves et pipelines documentés de conversion modèle-vers-circuit. Cela rend les affirmations zkML relativement faciles à vérifier comparées aux vagues affirmations « IA » — soit la preuve ZK fonctionne, soit elle ne fonctionne pas.

Lien avec l'IA vérifiable

Le zkML est l'une des nombreuses approches de l'inférence vérifiable. Les principales alternatives sont :

Approche Comment ça fonctionne Modèle de confiance Compromis
zkML Preuve cryptographique que l'inférence s'est exécutée correctement Garantie mathématique (sans confiance) Coût de calcul le plus élevé ; garantie mathématique (sans confiance)
TEE (Trusted Execution Environment) L'inférence s'exécute dans des enclaves isolées matériellement qui attestent de la justesse Confiance dans le fabricant du matériel Coût plus faible ; dépend des hypothèses de sécurité matérielle
Consensus / multi-fournisseurs Plusieurs fournisseurs indépendants exécutent la même inférence ; les résultats sont comparés Confiance dans une majorité honnête Calcul redondant ; garantie plus faible contre la collusion
Vérification optimiste Les résultats sont présumés corrects sauf contestation pendant une période de litige Confiance dans les incitations économiques Faible coût ; repose sur une surveillance active et des acteurs rationnels

Le zkML offre une garantie mathématique (sans confiance) — la justesse est vérifiée cryptographiquement, sans confiance dans le matériel, une majorité honnête ou des incitations économiques. Cependant, cela se paie par le coût de calcul le plus élevé. En pratique, de nombreux projets combinent les approches : utiliser la vérification optimiste pour les opérations de routine et ne recourir aux preuves zkML que lorsque les résultats sont contestés.

Limitations actuelles

Le zkML est une technologie à un stade précoce avec des contraintes pratiques significatives :

  • Coût de calcul. Générer une preuve ZK pour l'inférence d'un modèle est de plusieurs ordres de grandeur plus coûteux que l'inférence elle-même. Pour les grands modèles, la génération de preuve peut prendre de quelques minutes à plusieurs heures. Cela rend les applications en temps réel impraticables au-delà de petits modèles.
  • Limites de taille des modèles. Les frameworks zkML actuels fonctionnent avec des modèles relativement petits (de milliers à quelques millions de paramètres). Exécuter le zkML sur un LLM complet à des milliards de paramètres n'est pas encore pratique. La recherche est active sur des techniques comme la quantification de modèles, l'agrégation de preuves et les preuves récursives pour repousser ces limites.
  • Maturité des frameworks. L'outillage zkML (p. ex. EZKL, Modulus, Giza, Risc Zero pour le ML) est en développement actif. Les API, la documentation et l'expérience développeur évoluent rapidement, et les changements incompatibles sont fréquents.
  • Déploiements en production limités. Peu de projets ont le zkML en production à grande échelle. La plupart des implémentations sont des prototypes de recherche ou des démonstrations sur de petits modèles.
  • Compromis de précision. Convertir des opérations ML en virgule flottante en arithmétique à virgule fixe (nécessaire pour les circuits ZK) peut introduire de petites différences numériques. Ces différences sont généralement négligeables pour les tâches de classification mais peuvent compter pour les applications sensibles à la précision.

Ces limitations définissent la frontière actuelle. La technologie progresse rapidement, et les contraintes d'aujourd'hui pourraient être significativement réduites d'ici quelques années.

État pratique du zkML aujourd'hui

Malgré les limitations, le zkML a dépassé la pure théorie. L'état actuel comprend :

  • Les preuves pour petits modèles sont fonctionnelles. Des modèles jusqu'à quelques millions de paramètres (classifieurs d'images, petits modèles de langage) peuvent être prouvés. La génération de preuve prend de quelques secondes à quelques minutes selon la taille du modèle.
  • La vérification on-chain fonctionne. Des contrats vérificateurs ZK qui contrôlent les preuves d'inférence ML ont été déployés sur Ethereum et d'autres chaînes.
  • L'outillage s'améliore. Des frameworks comme EZKL permettent aux développeurs de convertir des modèles ONNX en circuits ZK avec relativement peu de lignes de code.
  • Des approches hybrides émergent. Certains projets ne prouvent que les étapes d'inférence les plus critiques, ou génèrent des preuves de manière asynchrone pour une vérification ultérieure.

Ce que le zkML ne prouve pas

  • Même avec une preuve ZK valide, le modèle sous-jacent pourrait être mauvais, biaisé ou non pertinent. Le zkML prouve que le modèle s'est exécuté correctement — il ne prouve pas que le modèle est bon.
  • Le zkML prouve l'intégrité du calcul, pas la qualité des données. Si les données d'entrée sont des déchets, la sortie est un déchet vérifié.
  • Le zkML ne prouve pas qu'un token est nécessaire. Un projet peut implémenter le zkML sans avoir besoin d'une blockchain ni d'un token pour que la vérification fonctionne.
  • Le zkML ne prouve pas la décentralisation. Un fournisseur centralisé unique peut générer des preuves ZK pour sa propre inférence. La décentralisation vient de l'architecture du système, pas du zkML lui-même.
  • Le zkML ne prouve pas que le modèle est celui revendiqué, sauf si l'engagement du modèle (un hash des poids) est ancré à une référence de confiance. Sans cette liaison, le prouveur pourrait utiliser n'importe quel modèle.

Ne pas confondre avec

  • L'inférence — le processus d'exécution d'un modèle. Le zkML ajoute une couche de vérification par-dessus l'inférence ; il ne la remplace pas.
  • Le ZK (preuves à divulgation nulle de connaissance) en général — le ZK est utilisé dans toute la crypto pour la confidentialité, la mise à l'échelle et l'identité. Le zkML est l'application spécifique du ZK à l'inférence ML.
  • L'inférence comme AI component — décrit comment l'inférence apparaît dans les fiches projets DecAIHub. Le zkML est l'un des mécanismes qui rendent l'inférence vérifiable.
  • Le chiffrement de modèle — chiffrer un modèle le protège de la lecture, mais ne prouve pas qu'il s'est exécuté correctement. Le zkML fournit une preuve d'exécution correcte, ce qui est une garantie fondamentalement différente.
  • L'apprentissage fédéré — une technique pour entraîner des modèles sur des sources de données distribuées sans partager les données brutes. Il résout un problème différent (la confidentialité pendant l'entraînement, pas la vérification pendant l'inférence).

Questions fréquentes

Comment fonctionne le zkML ?

Le zkML convertit un modèle d'apprentissage automatique en circuit mathématique, exécute le modèle pour produire une sortie et génère une preuve cryptographique que le circuit a été exécuté correctement. La preuve est compacte et peut être vérifiée rapidement par n'importe qui — y compris un smart contract — sans réexécuter le modèle ni voir les poids du modèle ou les données d'entrée. Le défi technique est que chaque opération ML doit être représentée comme une contrainte de circuit, rendant la génération de preuve coûteuse en calcul pour les modèles plus grands.

Le zkML est-il pratique aujourd'hui ?

Pour les modèles petits à moyens (jusqu'à quelques millions de paramètres), oui — la génération de preuves fonctionne et la vérification on-chain est opérationnelle. Pour les grands modèles comme les LLM modernes à des milliards de paramètres, le zkML n'est pas encore pratique en raison du coût de calcul énorme de la génération de preuves. La technologie progresse rapidement : les frameworks s'améliorent, les systèmes de preuve deviennent plus efficaces, et les approches hybrides (ne prouver que les étapes critiques) étendent le champ pratique. Aux fins d'évaluation DecAIHub, un projet qui implémente le zkML sur un petit modèle possède un AI component vérifiable, même si la même approche ne peut pas encore passer à l'échelle des plus grands modèles.

Pourquoi un projet crypto utiliserait-il le zkML ?

La motivation première est la vérification sans confiance. Dans un système décentralisé, aucune partie ne devrait être crue aveuglément. Si la sortie d'un modèle d'IA déclenche des actions on-chain (scoring de risque, approbation de transactions, distribution de récompenses), les utilisateurs et le protocole ont besoin d'une garantie que le modèle s'est réellement exécuté comme revendiqué. Le zkML fournit cette garantie sans exiger de confiance envers le fournisseur de calcul. Les motivations secondaires incluent la confidentialité (prouver qu'un modèle s'est exécuté sans exposer des poids propriétaires) et la composabilité (d'autres smart contracts peuvent vérifier les sorties d'IA on-chain et construire dessus). Dans le cadre DecAI Fit, la vérification basée sur le zkML renforce à la fois les dimensions AI reality et Onchain necessity.

Le zkML est-il le seul moyen de vérifier l'IA en crypto ?

Non. Les alternatives incluent les TEE (confiance dans le matériel), la vérification par consensus (confiance dans une majorité honnête) et la vérification optimiste (confiance dans les incitations économiques). Chacune a des hypothèses de confiance, des coûts et des limites différents. De nombreux projets combinent les approches. DecAIHub consigne le mécanisme de vérification dans la fiche projet afin que les lecteurs puissent évaluer eux-mêmes le modèle de confiance.

Références externes

Voir aussi

No comments to display

Back to top