Chaque appel à un modèle d’intelligence artificielle emporte aujourd’hui une identité. La clé pointe vers un compte, le compte vers un moyen de paiement, et le fournisseur peut recoller des années d’usage en un seul profil. Le 1er octobre, l’Ethereum Foundation a mis en ligne une parade : zkAPI. Il s’agit d’un système qui sépare le paiement de l’identité. Le fournisseur voit les requêtes. La couche de paiement voit la dépense. Aucun des deux ne voit le lien.
L’approche n’est en rien nouvelle. En effet, celle-ci fait suite à un fil de recherche présenté en février.
Points clés
- zkAPI est en ligne sur Ethereum depuis le 1er octobre, annoncé par Vittorio Rivabella (équipe dAI) et construit avec l’Open Anonymity Project
- Un dépôt unique dans un coffre, puis des preuves à connaissance nulle à la place d’une clé nominative : le serveur émet une clé temporaire, plafonnée, qui ne vit que dans la mémoire de l’appareil
- Le fournisseur voit les prompts, pas le payeur. La chaîne voit le dépôt, pas ce qu’il a payé. L’adresse IP et le contenu des requêtes restent, eux, exposés
- Le dessin date d’un fil de Davide Crapis et Vitalik Buterin publié le 11 février 2026 sur ethresear.ch. Cointelegraph l’a couvert le 12
Le problème, tel que le pose la fondation
Le 1er octobre, la Fondation Ethereum a dévoilé zkAPI, une nouvelle manière de payer pour des API.
« zkAPI vous permet de payer des API d’IA et d’autres API avec de l’ETH et d’effectuer des requêtes impossibles à relier. Il sépare l’utilisation des API de votre dépôt sur la chaîne : le service peut vérifier que vous êtes en mesure de payer sans savoir quel dépôt vous appartient. »
Sous le capot, le protocole a été construit avec l’Open Anonymity Project. « Chaque appel d’API d’IA emporte aujourd’hui une identité », écrit-il. La clé d’API désigne un compte, le compte un moyen de paiement, et chaque prompt rejoint le dossier attaché aux deux. L’alternative classique, payer chaque requête on-chaîne, est lente, chère, et laisse un graphe de transactions. La solution zkAPI propose une méthode différente avec un prépaiement, puis des autorisations qui ne désignent personne.
On dépose des crédits une fois, en ETH ou en USDC, dans un coffre Ethereum. Le solde devient une note privée, que seul le détenteur peut dépenser, et qu’on ne peut pas remonter jusqu’au dépôt. Pour autoriser une dépense, un logiciel sur la machine produit une preuve à divulgation nulle de connaissance : une note approvisionnée couvre ce montant, et personne ne l’a déjà dépensée. Le serveur vérifie l’énoncé sans apprendre quelle note, quel dépôt, ni quelle personne.
Comment ça passe, du dépôt à la clé jetable
Le parcours décrit le 1er octobre tient en quatre temps. L’application parle à un petit client sur la machine de l’utilisateur, avec la même interface qu’avant. Ce client envoie au serveur zkAPI une preuve de paiement, sans prompt et sans identité. Le serveur vérifie la preuve et émet une clé d’API neuve, de courte durée, plafonnée en dollars. Elle n’existe que dans la mémoire de l’appareil. Les prompts partent ensuite de l’appareil vers le fournisseur d’IA, avec cette clé. À l’expiration, un reçu signé enregistre la consommation réelle, et le serveur débite le solde privé de ce montant, et non pas du plafond réservé.
Le plafond sert donc de réservation. Les preuves de dépense sont vérifiées hors chaîne en Groth16 sur la courbe BN254, avec Poseidon pour les engagements et les nullificateurs. Ces nullificateurs empêchent de dépenser deux fois la même note. Le contrat du coffre vérifie les preuves au dépôt, à la clôture et en cas de sortie forcée.
Le coffre est un contrat Ethereum, pas un compte d’entreprise. On peut clôturer le solde et retirer sur la chaîne, même si les serveurs zkAPI disparaissent.
D’où vient le dessin
L’idée date du 11 février 2026. Davide Crapis, responsable IA de la fondation, et Vitalik Buterin publient sur ethresear.ch le fil « ZK API Usage Credits: LLMs and Beyond ». Le texte vise d’abord l’inférence des grands modèles de langage, où l’utilisateur envoie des données personnelles, mais aussi les appels RPC Ethereum, la génération d’images, le calcul, les VPN et les API de données. L’exemple du fil : 100 dollars d’USDC déposés, 500 requêtes à un modèle hébergé, que le fournisseur ne peut pas rattacher au même déposant.
Ce n’est pas encore le protocole d’octobre, ce n’est alors que le cahier des charges. Le lancement transforme le dessin de février en implémentation. Il n’en reprend pas toute la mécanique, notamment les nullificateurs de limite de débit et le mécanisme de slashing vers une adresse de brûlage décrits dans le fil de Crapis et Buterin.
Ce que la preuve ne cache pas
La fondation est explicite sur la frontière. Le serveur zkAPI apprend qu’un paiement valide existe, et le total en dollars de la session. Le fournisseur d’IA apprend les prompts et les réponses, pas qui paie. La chaîne voit les dépôts, les clôtures et les retraits, pas ce que les soldes ont payé.
Elle ne cache ni l’adresse IP, ni le contenu. Une IP stable permet au serveur de recouper les sessions. Le billet suggère Tor, avec un circuit neuf à chaque session. Le texte du prompt peut aussi recoller les séances : un détail personnel, un style, un historique réutilisé. La parade avancée est un modèle local, ou dans un environnement d’exécution de confiance, avec une mémoire partagée, plutôt que de tout renvoyer à la main. Requêtes isolées plus privées, mais moins utiles sans contexte : le compromis est assumé.
Le dessin n’est pas neuf. Le 9 février, dans sa vision d’une Ethereum mêlée à l’IA, Vitalik Buterin plaçait déjà les paiements ZK pour des appels d’API, sans lien d’identité, dans le quadrant « Infrastructure / Survivre ». Crapis n’y figurait pas, et le fil de recherche n’était pas encore le sujet. Ce qui change, c’est que le mécanisme tourne désormais sur le réseau principal.
L’article zkAPI : l’Ethereum Foundation sépare le paiement d’une API de l’identité est apparu en premier sur Journal du Coin.
