zkAPI s’attaque à un problème précis de l’intelligence artificielle facturée à l’usage : payer un service sans rattacher automatiquement chaque requête à une identité de facturation. Le recours aux preuves à divulgation nulle de connaissance ne rend pas, à lui seul, le contenu envoyé au modèle anonyme.
Une autre distinction concerne l’état du logiciel, vérifié le 26 octobre 2026. L’annonce de la Fondation Ethereum du 1er octobre décrit un service sur le réseau principal, tandis que la branche de développement actuelle signale des composants et des configurations qui ne sont pas prêts pour la production.
zkAPI : séparer paiement et identité
Le billet de la Fondation Ethereum décrit une séparation entre l’autorisation de dépense et l’identité associée au dépôt. Le fournisseur d’inférence reçoit toujours la requête nécessaire à son traitement : protéger le paiement ne revient pas à cacher le contenu du prompt.
La bonne question n’est donc pas simplement de savoir si une conversation est « privée ». Il faut identifier qui voit les contenus, qui gère l’argent et quels acteurs pourraient rapprocher les deux grâce à d’autres informations.
Une application peut supprimer un lien et en laisser un autre intact. Si le texte contient un nom, une entreprise et un document interne, un mode de paiement moins identifiable ne retire pas ces éléments de ce que reçoit le prestataire.
La recherche n’est pas la fiche d’une version publiée
La proposition ZK API Usage Credits de Davide Crapis et Vitalik Buterin explore l’association entre paiement, confidentialité et résistance aux abus. Elle fournit le contexte de recherche, pas une description automatiquement applicable à toutes les révisions suivantes.
Cette distinction évite une erreur fréquente : considérer un schéma théorique, une démonstration et un contrat déployé comme des preuves équivalentes. Chacun répond à une question différente et laisse d’autres points ouverts.
La recherche expose l’objectif. Le code montre comment une version précise tente de l’atteindre. Un déploiement vérifié identifie le système avec lequel l’utilisateur peut réellement interagir. Une évaluation sérieuse doit relier explicitement ces trois niveaux.
La vérification essentielle porte sur la version utilisée
Le dépôt officiel, consulté le 26 octobre, qualifie le protocole d’expérimental et précise que sa branche de développement du client axée sur la confidentialité n’est pas une version de production. Il mentionne aussi des configurations non déployées pour la révision actuelle et une branche distincte pour les notes antérieures.
Ces avertissements ne prouvent ni que l’annonce initiale était fausse ni que tous les services précédents ont cessé de fonctionner. Ils montrent en revanche que télécharger la branche principale n’équivaut pas automatiquement à utiliser le service présenté au début du mois.
Avant d’engager de l’argent réel, il faut identifier la version, le réseau, l’adresse du contrat et la documentation correspondante. Si un de ces éléments manque, interrompre la démarche est raisonnable ; contourner les contrôles de déploiement ne constitue pas une solution.
Les protections et leurs limites
| Question | Interprétation correcte | Vérification utile |
|---|---|---|
| Paiement et requêtes sont-ils séparés ? | C’est l’objectif du protocole | Examiner la version réelle |
| Le modèle lit-il le prompt ? | La confidentialité du paiement ne l’empêche pas | Réduire les données transmises |
| La branche principale est-elle prête ? | Ne pas le présumer | Lire les avertissements de publication |
| Le dépôt est-il sans risque ? | Non | Évaluer contrat, client et procédure de sortie |
Notre article sur les RPC de wallet et la confidentialité illustre une difficulté comparable. Une information protégée à un niveau peut rester visible pour un autre service participant à la même activité.
Un exemple concret, sans promesse d’anonymat
Imaginons un assistant qui classe des descriptions publiques de produits avec un budget plafonné. Séparer l’origine du paiement des opérations pourrait être utile, à condition que le service et la version choisis permettent effectivement ce fonctionnement.
Pour un assistant traitant des contrats confidentiels, le problème principal peut être le texte transmis. Il faut alors comparer cette approche au traitement local, aux engagements contractuels du prestataire et à la réduction des documents envoyés, plutôt qu’au seul changement de moyen de paiement.
Il s’agit d’un scénario d’évaluation, pas d’un test d’intégration effectué par notre rédaction. Nous n’avons ni déposé de fonds, ni testé les retraits, ni mesuré la résistance du système à la corrélation entre sessions.
Les questions à résoudre avant un essai
Il faut commencer par définir le périmètre : quel acteur ne devrait pas pouvoir rapprocher paiement et utilisation ? Il faut ensuite identifier les informations incluses dans les requêtes et celles conservées dans les journaux du client.
Viennent les questions opérationnelles : comment protéger l’état local, que se passe-t-il si l’appareil est perdu, et quelle procédure permet de récupérer un solde pour cette version ? Une présentation générale de la cryptographie ne suffit pas.
Des plafonds de dépense et une gestion explicite des erreurs sont également nécessaires. L’application ne devrait pas basculer silencieusement vers un parcours moins confidentiel lorsque son mécanisme préféré ne répond plus.
Une infrastructure à suivre, pas une promesse financière
zkAPI mérite l’attention comme tentative de dissocier accès aux services et identité économique. Son intérêt ne nécessite ni prévision sur le cours d’Ethereum ni promesse de rendement sur les fonds déposés.
Le principe reste celui de la confidentialité crypto et des usages légitimes : définir le risque, vérifier les limites et choisir une protection proportionnée. Une direction prometteuse ne constitue pas encore une garantie démontrée pour chaque implémentation.
