Un nouveau système de paiement a discrètement été mis en service sur le réseau principal d’Ethereum cette semaine, et il est conçu pour résoudre un problème auquel la plupart des gens ne pensent qu’une fois qu’il est trop tard : chaque fois que vous payez pour utiliser un modèle d’IA, une API cloud ou presque n’importe quel service en ligne à facturation à l’usage, ce paiement relie généralement votre identité à tout ce que vous avez déjà demandé. La Fondation Ethereum et l’Open Anonymity Project ont annoncé le 1er octobre 2026 qu’ils avaient déployé un système appelé zkAPI, conçu pour permettre aux utilisateurs d’effectuer des paiements privés pour des API à facturation à l’usage sans lier chaque requête à un compte de facturation persistant.
Points clés à retenir
- zkAPI a été lancé sur le réseau principal d’Ethereum le 1er octobre 2026, développé par l’équipe dAI de la Fondation Ethereum et l’Open Anonymity Project.
- Les utilisateurs déposent de l’ETH ou de l’USDC dans un contrat de coffre-fort, transformant ce solde en une « note » privée qui fonctionne comme de la monnaie numérique.
- Les preuves à divulgation nulle de connaissance permettent au système de confirmer qu’un paiement est valide sans révéler qui l’a effectué ni ce qu’il a payé.
- Les paiements restent non corrélables sur la chaîne, mais le protocole ne masque pas le contenu des requêtes ni les métadonnées réseau comme les adresses IP.
- Il est compatible avec les points de terminaison d’API standard de type OpenAI et Ollama, de sorte que les applications existantes nécessitent des modifications minimales pour s’y connecter.
La Fondation Ethereum et Open Anonymity amènent zkAPI sur le réseau principal
zkAPI fonctionne désormais sur Ethereum, offrant aux utilisateurs un moyen de payer des services à facturation à l’usage sans le compromis habituel entre commodité et exposition. Vittorio Rivabella, membre de l’équipe dAI de la Fondation Ethereum, a fait l’annonce, et le système met en pratique une idée de recherche antérieure proposée par Davide Crapis et Vitalik Buterin.
Origines de la recherche et déploiement sur le réseau principal
Le problème que zkAPI cherche à résoudre est enraciné dans l’approche standard de la facturation des API : une clé d’API est liée à un utilisateur, cet utilisateur est lié à un moyen de paiement, et le fournisseur de l’autre côté peut silencieusement reconstituer des mois ou des années de requêtes en un seul profil. Étant donné la fréquence à laquelle les gens interrogent des modèles d’IA sur des questions de santé, de finances ou des doutes privés, cette configuration revient à remettre une longue transcription de la pensée de quelqu’un à la personne qui contrôle la relation de facturation.
Payer à l’appel directement sur une blockchain publique contourne l’intermédiaire, mais c’est lent, coûteux et entièrement traçable sur la chaîne. Faire confiance à un tiers pour ne pas regarder le trafic est l’autre compromis habituel. zkAPI est présenté comme une troisième option, et la Fondation décrit le protocole comme encore quelque peu expérimental même s’il est déjà en production sur le réseau principal. Il est conçu pour se brancher sur des points de terminaison d’API compatibles avec OpenAI et Ollama, ce qui signifie que les développeurs peuvent diriger des outils de chat ou des éditeurs existants vers un client local sans reconstruire toute leur pile.
Comment zkAPI permet des paiements privés pour des API à facturation à l’usage
L’idée centrale est simple à énoncer, même si la cryptographie sous-jacente ne l’est pas : zkAPI sépare l’acte de payer du contenu de ce pour quoi l’on paie. Un utilisateur dépose de l’ETH, de l’USDC ou un actif similaire dans un contrat de coffre-fort via une transaction ordinaire. À partir de ce moment, le solde existe sous forme de note privée — essentiellement de la monnaie numérique que seul le détenteur peut dépenser, et qui ne peut pas être reliée au dépôt initial.
Dépôts, notes privées et preuves à divulgation nulle de connaissance
Au moment d’utiliser réellement le service payant, un logiciel fonctionnant sur l’appareil de l’utilisateur génère une preuve à divulgation nulle de connaissance compacte. Cette preuve confirme qu’une note approvisionnée peut couvrir une quantité limitée d’utilisation et n’a pas encore été dépensée, le tout sans divulguer quelle note, quel dépôt ou quel individu est impliqué. Une seule preuve peut couvrir un appel ou une session entière, et le serveur récepteur peut confirmer que l’assertion est vraie sans apprendre aucun des détails sous-jacents. Au niveau du paiement, une requête ne se rattache jamais à l’utilisateur ni à aucune autre requête qu’il a effectuée.
Arbres de Merkle, nullifiers et vérification hors chaîne
Deux éléments cryptographiques maintiennent l’ensemble. Les dépôts sont enregistrés sous forme d’engagements à l’intérieur d’un arbre de Merkle, de sorte qu’une preuve peut montrer qu’une note appartient à l’ensemble valide sans indiquer laquelle. Chaque fois qu’une note est dépensée, le système publie un nullifier — un numéro de série à sens unique dérivé du secret de cette note. Les actions d’un utilisateur restent non corrélables tant qu’il reste dans la limite de son solde ; toutefois, tenter de dépenser deux fois les mêmes fonds génère un nullifier en double qui ne révèle que la tentative de double dépense et rien de plus.
En pratique, un client léger sur la machine de l’utilisateur imite une API familière. Une preuve de paiement — excluant l’invite et tout détail identifiant — est envoyée au serveur zkAPI, qui la vérifie et fournit une clé à durée de vie limitée, plafonnée en dollars, stockée uniquement en mémoire locale, après quoi les invites circulent directement de l’appareil vers le fournisseur d’IA en utilisant cette clé temporaire. Une fois la clé expirée, un reçu d’utilisation signé consigne la consommation réelle, et le serveur soustrait ce montant de la note privée plutôt que le plafond réservé complet, garantissant qu’aucune des parties ne peut ensuite modifier la facture. Sous le capot, le système s’appuie sur des preuves à divulgation nulle de connaissance Groth16 sur la courbe BN254, des hachages Poseidon pour les engagements et les nullifiers, et des notes conservées dans un arbre de Merkle à 32 niveaux. Les preuves de dépense sont vérifiées hors chaîne par le serveur, tandis que le contrat de coffre-fort vérifie des preuves équivalentes au dépôt, à la clôture et au retrait — ce qui signifie que les utilisateurs peuvent toujours récupérer leurs fonds même si tous les serveurs zkAPI disparaissaient.
Ce que zkAPI protège — et ce qu’il ne protège pas
C’est là que la conception devient intéressante, et où cela compte pour quiconque évalue le niveau de confidentialité réellement obtenu. Les connaissances dans le système sont clairement réparties entre trois parties : le serveur zkAPI sait qu’un paiement valide a été effectué et connaît le total en dollars de la session, mais il ignore l’identité du payeur et le contenu de la requête. Comme il doit exécuter le modèle, le fournisseur d’IA voit les invites et les réponses mais ne sait pas qui paie, tandis que la chaîne publique Ethereum enregistre les dépôts, clôtures et retraits sans révéler comment un solde a réellement été utilisé.
Confidentialité des paiements sur la chaîne
Cette séparation est l’objectif même de la conception. Elle signifie que la relation de facturation — la partie la plus vulnérable au profilage — est isolée cryptographiquement à la fois du contenu d’une requête et de l’identité qui la sous-tend. Le même client et les mêmes contrats pourraient, en théorie, servir d’interface à d’autres services à facturation à l’usage, y compris des requêtes RPC blockchain, des tâches de génération d’images ou de vidéos, de la bande passante VPN ou des transactions machine-à-machine, en masquant le lien de financement dans chaque cas de la même manière que pour les requêtes d’IA.
Lacunes en matière de confidentialité du contenu et des métadonnées réseau
Voici pourquoi cela importe pour quiconque suppose que zkAPI rend son utilisation de l’IA totalement anonyme : les protections s’arrêtent au lien de paiement. Le fournisseur d’IA voit toujours le contenu réel de chaque requête, et il observe toujours les métadonnées réseau telles que les adresses IP. Un fournisseur pourrait, en principe, tenter de corréler des sessions par des schémas temporels, ou en repérant des détails personnels récurrents, un style d’écriture ou un historique de conversation intégré dans les invites elles-mêmes. Une véritable anonymisation réseau nécessiterait une couche séparée, comme le routage du trafic via Tor avec un nouveau circuit par session, et la confidentialité du contenu reste un problème distinct, encore en cours de développement, que des techniques comme l’informatique confidentielle commencent seulement à aborder.
En d’autres termes, zkAPI résout spécifiquement le problème du lien entre facturation et identité — il ne prétend pas assurer l’anonymat de bout en bout. Pour les développeurs et les utilisateurs qui l’évaluent, cette distinction fait la différence entre « personne ne peut lier mon paiement à mon identité » et « personne ne peut voir ce que je fais du tout ». Ce sont deux promesses très différentes, et seule la première est actuellement tenue sur Ethereum.
Article produit avec l’assistance de l’intelligence artificielle et relu par l’équipe éditoriale.