zkAPI d'Ethereum vise à dissocier les paiements IA de l'identité des utilisateurs
Points clés
- •zkAPI, lancé le 1er octobre par l'Ethereum Foundation et l'Open Anonymity Project, permet aux utilisateurs de payer l'accès à des API d'IA depuis un coffre Ethereum alimenté en ETH, USDC ou autres crédits pris en charge, sans exposer leur identité de facturation.
- •Le système utilise des preuves à divulgation nulle, des arbres de Merkle de 32 niveaux et une protection anti-double dépense par nullifiers, permettant aux serveurs d'autoriser les dépenses sans les lier à un dépôt spécifique.
- •Plutôt que d'émettre des clés API permanentes, zkAPI crée des clés éphémères avec des plafonds en dollars, et les fournisseurs soumettent des reçus d'utilisation signés afin que seul le montant réellement consommé soit déduit de la note privée.
- •zkAPI ne masque ni le contenu des requêtes ni les métadonnées réseau, et la Fondation avertit que les détails personnels répétés dans les requêtes peuvent servir d'empreintes identificatrices, Tor étant suggéré pour un anonymat réseau renforcé.
- •Au-delà de l'IA, le même mécanisme pourrait prendre en charge des requêtes RPC blockchain, des tâches d'image et de vidéo, de la bande passante VPN et des paiements entre agents logiciels autonomes.

Chaque requête envoyée à un modèle d'IA commercial peut laisser une trace plus longue que ce que la plupart des utilisateurs imaginent. Une clé API est liée à un compte, le compte est lié à de l'argent, et les requêtes s'accumulent derrière les deux. L'Ethereum Foundation (EF) résume le problème sans détour : « Chaque appel d'API IA porte aujourd'hui une identité. » zkAPI, l'outil récemment lancé par la Fondation, est conçu précisément pour briser ce lien.
Lancé le 1er octobre par l'Ethereum Foundation et l'Open Anonymity Project, zkAPI permet à un utilisateur de déposer des ETH, des USDC — un stablecoin adossé au dollar — ou d'autres crédits pris en charge dans un coffre Ethereum, puis de payer des requêtes d'IA sans révéler au serveur de paiement qui il est. Le fournisseur d'IA reçoit la requête, mais pas l'identité de facturation qui se cache derrière.
L'enjeu est autant personnel que financier. « Les requêtes sont personnelles. Les gens posent aux modèles d'IA des questions sur leur santé, leurs finances, leurs doutes », indique l'article de blog de la Fondation intitulé « Introducing zkAPI : private usage credits for any API ». Accumulez assez de ces questions sous un même compte, et le fournisseur détient plus qu'une facture — il peut détenir un historique de plusieurs années des réflexions d'une personne.
Un coffre, une note privée et une preuve à divulgation nulle
Le mécanisme de zkAPI commence par une transaction Ethereum ordinaire. Un utilisateur dépose des crédits dans un contrat de coffre, après quoi les fonds sont représentés par une note privée pouvant être dépensée sans révéler quel dépôt initial a fourni l'argent. Comme l'explique la description de l'EF, « zkAPI sépare paiement et identité ».
Un logiciel exécuté sur l'appareil de l'utilisateur génère ensuite une preuve à divulgation nulle montrant qu'une note financée couvre la dépense demandée et n'a pas déjà été dépensée. Les preuves à divulgation nulle sont une famille de techniques cryptographiques permettant à une partie de démontrer qu'une affirmation est vraie sans réler les données qui la sous-tendent, et elles sont devenues un élément de construction courant dans les conceptions de confidentialité et de passage à l'échelle des blockchains. La preuve atteste ici uniquement de la validité, de sorte que le serveur peut autoriser la dépense sans apprendre quelle note appartient à l'utilisateur.
La mécanique sous-jacente est technique. Les dépôts sont des engagements dans un arbre de Merkle — une structure qui permet à quiconque de vérifier l'inclusion d'un dépôt sans exposer de quelle entrée il s'agit — de 32 niveaux de profondeur. Les dépenses produisent des numéros de série à sens unique appelés nullifiers, tandis que les preuves Groth16 sur la courbe BN254 et le hachage Poseidon assurent le gros du travail cryptographique. Le nullifier sert de garde-fou contre la double dépense : tentez de dépenser deux fois le même solde et le doublon trahit l'opération, tandis que rester dans les limites du solde est conçu pour que la note reste non traçable. Selon les mots de la Fondation, « un utilisateur qui reste dans les limites de son solde reste non traçable ».
Des clés jetables au lieu de comptes permanents
La partie la plus ingénieuse intervient après l'autorisation du paiement. Au lieu de remettre au fournisseur d'IA une clé API permanente liée à un compte client ordinaire, le serveur de zkAPI vérifie la preuve de paiement et crée une clé fraîche et éphémère avec un plafond en dollars. La clé ne vit que dans la mémoire de l'appareil de l'utilisateur, puis la requête part directement vers le fournisseur d'IA.
« Le serveur qui gère l'argent ne voit jamais le contenu, et le fournisseur qui voit le contenu n'apprend jamais l'identité de facturation derrière une clé », a expliqué la Fondation.
Lorsque la clé temporaire expire, le fournisseur enregistre le montant réellement consommé dans un reçu d'utilisation signé. zkAPI déduit ce montant de la note privée de l'utilisateur au lieu de prélever automatiquement l'intégralité du plafond de dépense, si bien qu'une seule autorisation peut couvrir toute une session au lieu d'exiger une transaction Ethereum pour chaque question.
La séparation est délibérée : le système de paiement sait que quelqu'un a payé, l'IA sait que quelqu'un a posé une question, et ni l'un ni l'autre n'est censé en savoir assez pour relier les deux. Ethereum lui-même en voit encore moins. La blockchain publique peut observer les dépôts, les clôtures et les retraits, mais pas ce que le solde a acheté. L'argent peut également être récupéré si les serveurs zkAPI disparaissent. « Vous pouvez clôturer votre solde et retirer onchain, même si tous les serveurs zkAPI disparaissent », explique l'article de blog de l'EF.
Les limites de la cape d'invisibilité
Il n'y a toutefois aucune cape d'invisibilité. zkAPI sépare l'identité de facturation de l'utilisation de l'API ; il ne masque pas ce que quelqu'un tape dans un modèle d'IA. Le fournisseur reçoit toujours les requêtes et les réponses, car c'est lui qui fait tourner le modèle. Les informations réseau peuvent également trahir la personne à l'autre bout — une adresse IP stable, des schémas temporels ou unement répétitif peuvent aider à relier des sessions censées être distinctes.
La Fondation se montre tout aussi franche sur un risque plus subtil : « Le contenu partagé des requêtes peut servir d'empreinte pour quiconque peut lire ces requêtes. » Mentionnez régulièrement le même employeur, des membres de votre famille, vos habitudes rédactionnelles, des documents de projet ou un ancien historique de conversations, et le contenu lui-même peut commencer à reconstituer une identité. Les utilisateurs en quête d'un anonymat réseau plus fort sont orientés vers Tor, le réseau d'anonymat de longue date, et vers de nouveaux circuits pour des sessions distinctes, et le dépôt du protocole qualifie zkAPI d'expérimental — une désignation qui laisse la place à une évolution de la conception à mesure du développement.
Au-delà de l'IA
L'IA n'est que la première porte franchie. Le même système pourrait gérer des requêtes RPC blockchain, des tâches d'image et de vidéo, de la bande passante VPN et des services de machine à machine où des agents logiciels paient un travail sans maintenir de comptes clients conventionnels.
Cela rend la proposition de zkAPI à la fois plus étroite et plus intéressante que l'IA anonyme. Elle ne promet pas que personne ne sache quoi que ce soit. Elle cherche à garantir que personne ne sache tout.