Ethereum ZkAPI Cache Qui Paie Sans Cacher Le Prompt

Imaginez que vous régliez une note de restaurant sans jamais montrer votre carte, puis que le serveur lise à voix haute tout ce que vous avez commandé. C’est, à peu près, le contrat que vient de poser le zkAPI sur Ethereum. Le 1er octobre 2026, la Fondation Ethereum et Open Anonymity ont ouvert sur le réseau principal un coffre de crédits et un circuit de preuve : on peut financer une session d’intelligence artificielle sans livrer au serveur de paiement une identité durable, ni au fournisseur du modèle l’adresse qui a approvisionné le coffre. Le texte de la requête, lui, voyage encore jusqu’à la machine qui répond. Cette séparation est réelle. Elle est aussi beaucoup plus étroite que le slogan d’une conversation anonyme avec une IA.

Le malentendu commence dès le vocabulaire. Dire paiement privé se entend trop souvent comme usage privé. Or une preuve à divulgation nulle ne rend invisible que ce qu’elle a été écrite pour cacher. Ici, le circuit affirme qu’une note financée peut couvrir un usage borné. Il ne dit rien du contenu du prompt, de l’adresse IP, de l’heure, du style d’écriture, ni des fichiers joints. Confondre ces couches, c’est se croire protégé là où l’on est seulement délié d’une facture.

Cette distinction n’est pas un détail de juriste. Un journaliste qui teste un document public, un chercheur qui explore une hypothèse sensible, un agent logiciel qui enchaîne des appels : chacun peut vouloir que le fournisseur voie la requête du moment sans constituer un dossier de facturation à vie. Le zkAPI vise ce besoin précis. Il décevra quiconque attend une chambre noire simplement parce que le règlement a été prouvé en zéro connaissance.

Ce que le lancement du 1er octobre change vraiment

La Fondation a été, sur ce point, plus nette que beaucoup d’annonces crypto. Le système est présenté comme vivant : dépôt dans un coffre, client, serveur de vérification, interface de démonstration, dépôt de code public. Un contrat sur le réseau principal prouve qu’il existe quelque chose à inspecter. Il ne prouve ni l’adoption, ni l’étendue d’un audit, ni l’anonymat dans chaque configuration de client, ni la protection contre un modèle qui reconnaît une écriture.

Le geste technique tient en une substitution. Au lieu d’une clé d’API collée à un compte et à un moyen de paiement, l’utilisateur approvisionne une note privée. Plus tard, sa machine produit une preuve : cette note figure parmi les notes valides, elle dispose encore d’un pouvoir de dépense, et ce pouvoir suffit pour une session courte et plafonnée. Le serveur de paiement vérifie la preuve hors chaîne et délivre une clé temporaire. Le modèle reçoit le texte. La chaîne, elle, voit surtout les dépôts, les clôtures et les retraits.

Le calendrier compte. Une recherche signée notamment par Davide Crapis et Vitalik Buterin décrivait déjà des crédits d’API en zéro connaissance. Une note de recherche pose une construction. Un déploiement doit tenir le stockage des secrets, le comportement du frontal, les pannes, les litiges de reçu, les mises à jour et des adversaires réels. Le passage au réseau principal transforme l’idée en objet testable. C’est le seul fait frais qui mérite d’être traité comme tel.

Une facture unique à la place d’une traînée de relevés

Chez la plupart des fournisseurs commerciaux, la clé d’API est une étiquette. Même si vous ne signez jamais le prompt de votre nom, le relevé relie les requêtes à un compte, souvent à une carte, parfois à une entreprise. Le zkAPI coupe cette étiquette au niveau du règlement. L’utilisateur dépose un actif pris en charge, par exemple des USDC, dans un contrat. Le logiciel local fabrique ensuite la preuve qu’une note financée peut payer un usage borné, sans dire laquelle.

Le serveur vérifie, réserve un plafond en dollars et émet une clé de courte durée. En mode direct, décrit par la Fondation, les prompts partent de l’appareil vers le fournisseur avec cette clé. Après la session, un reçu signé enregistre l’usage mesuré. Le solde privé est débité du montant consommé, pas automatiquement du plafond réservé. Une preuve peut donc couvrir plusieurs échanges. On évite d’inscrire chaque question sur Ethereum.

Ce partage des regards est le cœur du dispositif. La chaîne enregistre l’entrée et la sortie des fonds. Le fournisseur voit le texte et le trafic d’API. Le serveur de paiement voit qu’une session est financée et quel total a été facturé. En mode direct, il n’est pas censé recevoir le prompt. Ce sont des propriétés de l’architecture décrite, pas une garantie que les journaux d’un déploiement particulier ne pourront jamais corréler personne.

Une preuve cache la note qui paie. Elle ne rend pas le prompt invisible, et elle n’efface pas l’adresse qui a approvisionné le coffre.

Il existe un mode plus simple, le mode proxy. Le serveur zkAPI relaie alors la requête vers le modèle. Selon la Fondation, ce serveur peut voir le trafic. Deux interfaces peuvent sembler identiques et router très différemment. Avant d’envoyer quoi que ce soit de sensible, la question utile n’est pas « est-ce privé ? ». Elle est : quelle partie a besoin du texte, et quelle partie n’a besoin que d’une preuve de paiement ?

La note prouve une valeur sans nommer le déposant

Sous le capot, le schéma repose sur des engagements dans un arbre de Merkle. La preuve dit que la note de l’utilisateur appartient à l’ensemble des notes financées valides, sans désigner la feuille. Un nullificateur, dérivé d’un secret de note, empêche de dépenser deux fois le même solde. La Fondation cite des preuves Groth16 sur la courbe BN254, des hachages Poseidon et un arbre à 32 niveaux. Ces choix intéressent les implémenteurs. Le principe financier est plus simple : vérifier l’appartenance et le droit de dépenser restant, sans publier le compte qui a fourni le crédit.

Cacher une identité ne donne pas un usage gratuit. Le serveur doit contrôler la preuve et réserver un plafond avant d’émettre la clé. Le fournisseur mesure la consommation. Le reçu règle le montant réel après expiration. Si un plafond de 10 dollars est réservé et que 3 dollars de service sont consommés, le mécanisme est conçu pour débiter 3 dollars, pas 10. Cet exemple illustre la logique de réservation. Ce n’est ni un tarif publié, ni un minimum garanti. Le reste demeure dans la note, selon les règles de l’implémentation.

Le nullificateur traite un échec précis : la double dépense. Il ne prouve pas que le modèle a répondu juste, ne préserve pas la confidentialité du prompt et n’empêche pas le fournisseur d’archiver les requêtes. Une preuve à divulgation nulle est un énoncé sur la validité d’une opération dans un circuit défini. Ses garanties ne s’étendent pas toutes seules aux données qui voyagent à côté.

La sortie du contrat compte autant que l’entrée. La Fondation indique qu’un utilisateur peut clôturer le solde et retirer on-chain même si les serveurs zkAPI disparaissent. Le serveur de paiement n’est donc pas le seul chemin pour récupérer les fonds. Cette sortie n’est pas invisible : Ethereum enregistre les transactions concernées. La capacité à sortir dépend du contrat et de la possession du secret. Avant d’y placer une somme importante, un utilisateur prudent inspecte les adresses de déploiement, les permissions et tout examen indépendant.

Trois couches de vie privée, une seule est visée

Le test le plus clair tient en trois questions. La vie privée du paiement demande si une facture peut être rattachée à une note ou à une personne. La vie privée du réseau demande si le service peut identifier une connexion par l’IP, le rythme ou des traits d’appareil. La vie privée du contenu demande si quiconque opère le modèle peut lire le prompt. Le zkAPI est conçu surtout pour la première. Il peut affaiblir le lien de compte entre le journal d’usage du fournisseur et la source des fonds. Il ne livre pas les deux autres.

Ce n’est pas un défaut caché dans les petites lignes. L’annonce dit que le fournisseur voit les requêtes. La description honnête vaut mieux qu’un slogan d’anonymat large, parce qu’elle indique où poser les précautions supplémentaires. Quelqu’un qui pose des questions génériques peut gagner un découplage de facturation substantiel. Quelqu’un qui colle un contrat signé et un nom complet a déjà livré son identité dans le texte, quel que soit le chemin du paiement.

• Paiement : la note qui finance la session reste cachée au fournisseur, dans le modèle décrit.
• Réseau : une IP stable et des horaires corrélés peuvent recoller les sessions.
• Contenu : le prompt, les fichiers et l’historique restent lisibles par celui qui fait tourner le modèle.
• Sortie : le dépôt et le retrait restent des transactions publiques sur Ethereum.

Le corps de la requête peut contenir un nom, un employeur, un historique médical ou du code propriétaire. Un fournisseur qui lit le prompt peut le relier à des sessions antérieures par des tournures répétées, des fichiers, un fil de conversation ou des faits très distinctifs. Aucun lien de portefeuille n’est nécessaire. Trois sessions qui citent le même nom de projet interne non publié se désignent toutes seules.

Les métadonnées réseau ouvrent un autre chemin. En mode clé d’exécution, le fournisseur peut voir l’adresse IP depuis laquelle l’appareil se connecte. En mode proxy, l’intermédiaire peut voir le trafic et, potentiellement, des informations sur le réseau d’origine. La Fondation dit explicitement qu’une IP stable et des horaires corrélés affaiblissent la confidentialité, et suggère des outils d’anonymat réseau à qui veut une protection plus forte. Un VPN ou Tor peut modifier le chemin. Ni l’un ni l’autre n’efface un nom tapé dans le prompt.

Un ensemble d’anonymat peut rester minuscule

Le zéro connaissance peut cacher laquelle de plusieurs notes a payé. La foule réelle compte davantage. Si une seule personne alimente le coffre dans une fenêtre étroite, avec un montant inhabituel, et qu’un retrait tout aussi distinctif suit la session, un observateur peut former une corrélation plausible à partir des heures et des sommes publiques. La preuve peut rester cryptographiquement valide. L’inférence à partir d’informations externes est une attaque séparée.

L’arbre à 32 niveaux est un paramètre de capacité, pas la preuve que des milliards d’utilisateurs mélangent leurs crédits aujourd’hui. Un service tout juste ouvert peut n’abriter qu’un petit ensemble de notes. Pour juger l’anonymat en pratique, il faudrait des comptes datés de dépôts, de notes actives distinctes et de retraits, agrégés sans compromettre les utilisateurs. Un dépôt de code ou une taille théorique d’arbre ne fournit pas ces chiffres.

Supposez dix notes éligibles, et que des faits publics en écartent neuf. La preuve mathématique peut encore cacher parfaitement son témoin, pendant que l’entourage désigne la dixième. Cet exemple jouet explique pourquoi la taille et la diversité de l’ensemble plausible importent plus que le nombre brut de transactions dans le coffre. Standardiser les montants, retarder l’activité et user régulièrement du service peuvent aider. Le comportement et la conception du service décident de ce qui reste corrélable.

La preuve peut être parfaite et l’ensemble d’anonymat, lui, tenir dans une seule personne.

Il existe un second ensemble, du côté du fournisseur : le groupe de requêtes qui partagent une clé éphémère. La clé relie les échanges à l’intérieur de sa session plafonnée, même si elle n’identifie pas le dépôt. C’est inhérent au mesurage. Si le client renvoie les mêmes documents dans des sessions ultérieures, le fournisseur peut les recoller à travers les clés. Cacher le compte de facturation est utile. Cela n’oblige pas le modèle à oublier ce qu’il a lu.

Dessiner les registres d’une seule session

On peut tracer une session sans supposer que quiconque triche. Ethereum enregistre la transaction de dépôt et son adresse de financement. L’appareil garde le secret de note et envoie une preuve au serveur de paiement. Le serveur note la validité, un nullificateur et l’émission d’une clé plafonnée. Le fournisseur note cette clé, les requêtes et l’usage facturé. Le reçu signé attache la clé à un total mesuré. À la clôture, le contrat peut enregistrer une sortie. Chaque partie détient un registre partiel.

La propriété visée est qu’aucun registre d’une partie honnête ne joigne directement l’adresse de financement aux prompts du fournisseur. Une coalition, une fuite ou un observateur extérieur muni d’horodatages peut en savoir plus. Déposer un montant rare puis envoyer aussitôt une requête tout aussi rare rend la corrélation plus facile. Si le fournisseur reçoit un document qui identifie l’utilisateur, il peut savoir qui a demandé sans jamais voir l’adresse du coffre. C’est un problème de composition, pas une preuve cassée.

L’exercice met aussi en lumière la durée de vie des clés. Un identifiant de session groupe volontairement les requêtes qu’il autorise, afin que le fournisseur puisse les mesurer. Un plafond de 50 dollars peut couvrir beaucoup de prompts sous une seule clé. Des plafonds plus bas et des sessions plus courtes réduisent le volume de contenu lié à un identifiant, au prix de preuves plus fréquentes, parfois de latence et de coût. Il n’existe pas de réglage universellement privé. L’utilisateur et le fournisseur arbitrent confort, prix et capacité de liaison.

Effacer un nom de facturation d’une base est utile. C’est insuffisant si un identifiant persistant d’appareil reconstruit le même profil en silence. Le zkAPI déplace une jointure. Il n’abolit pas la tentation, chez chaque opérateur, de garder plus que le strict nécessaire.

Le reçu signé déplace la confiance vers le compteur

Il faut bien facturer le travail réellement fait. Le schéma s’appuie sur un reçu signé, associé à la clé courte et à son usage. La question commerciale centrale glisse alors vers l’exactitude du mesurage. Si un fournisseur surcompte les jetons, les requêtes ou le temps, une preuve de paiement valide ne corrige pas la note. La signature rend un total affirmé difficile à réécrire ensuite. Elle n’établit pas que l’usage affirmé était juste au regard du barème.

Un client devrait demander quelle unité est facturée, qui signe le reçu, comment la réservation inutilisée est libérée, et ce qui se passe quand une requête échoue à mi-chemin. Ce sont des questions de facturation ordinaires, habillées de cryptographie inhabituelle. Un plafond limite la surprise d’une session. Beaucoup de petites sessions peuvent tout de même accumuler un coût réel. Limites de débit et factures appelleraient un processus de contestation qui ne force pas à se réidentifier.

Le compromis est opérationnel. Les comptes classiques simplifient le support, les remboursements et la lutte contre les abus, parce que le fournisseur peut identifier l’acheteur. Le zkAPI retire une identité de facturation persistante du chemin de paiement visé. Les fournisseurs peuvent encore avoir besoin de contrôles d’abus, de filtres de sanctions lorsque le droit l’exige, et d’une application des limites. La Fondation indique que prix et plafonds de débit peuvent demeurer. Les intégrations réelles montreront comment les services équilibrent paiements sans compte, obligations et fraude.

Un test pratique consiste à interrompre volontairement une session. Le client obtient une clé plafonnée, envoie plusieurs requêtes, perd le réseau, puis se reconnecte. Le reçu ne reflète-t-il que l’usage livré ? L’utilisateur peut-il contrôler localement le montant mesuré sans renvoyer le prompt au serveur de paiement ? Si le serveur disparaît, le solde inutilisé revient-il par le contrat, comme annoncé ? Ces essais dépassent la question « la preuve vérifie-t-elle ? » pour demander si le produit tient la séparation promise en cas de panne.

Le contrat est une trappe de sortie, pas un bouclier

Le coffre peut vérifier des preuves pour le dépôt, la clôture et des opérations d’échappement, selon la Fondation. Une voie de sortie on-chain importe, parce qu’un arrêt du fournisseur ne devrait pas bloquer des fonds dans une base d’opérateur. Le contrat remplace une part de confiance institutionnelle par un risque de contrat intelligent. Un défaut dans la vérification des preuves, la comptabilité ou la logique de retrait peut affecter les fonds malgré une idée de confidentialité saine. Une adresse en ligne prouve un déploiement, pas un audit.

Dépôts et retraits publics ont aussi un coût de vie privée. Quelqu’un qui connaît l’adresse de financement peut observer qu’elle a interagi avec le coffre. Il ne voit pas forcément quelle session d’API a été payée, mais il voit la participation et les montants. Si le même utilisateur retire vite une somme inhabituelle vers une adresse déjà associée à lui, une partie de l’anonymat périphérique se réduit. La note privée casse un lien de facturation déterministe. Elle n’efface pas la transaction de financement publique.

Il faut aussi séparer les produits. Une proposition de confidentialité native sur Ethereum concerne un changement de protocole encore à l’état de dessin. Le lancement récent d’un portefeuille de transferts privés concerne un autre environnement. Ni l’un ni l’autre ne prouve qu’un prompt envoyé via zkAPI est caché à son fournisseur de modèle. Mélanger ces annonces, c’est faire porter à une application d’aujourd’hui les promesses d’une feuille de route.

Ce qu’un examen reproductible devrait mesurer

Un relecteur indépendant pourrait créer deux notes depuis des adresses sans lien, ouvrir de courtes sessions chez le même fournisseur, puis inspecter chaque paquet et chaque journal visible par le client, le serveur de paiement et le fournisseur. Les modes direct et proxy se testent séparément. Si, en mode direct, le serveur de paiement reçoit un prompt, la séparation décrite est contredite. Si le fournisseur reçoit une adresse de dépôt ou un identifiant de compte durable, le découplage visé a échoué à la couche d’intégration, même si le circuit est sain.

Le test plus dur est statistique. On lance de nombreuses sessions, montants et horaires variés, puis on demande si une partie qui ne dispose que des données publiques de la chaîne et des journaux serveur corrèle financement et usage mieux que le hasard. Le seuil dépend de l’ensemble d’anonymat réel et des données auxiliaires de l’adversaire. Une démonstration de laboratoire réussie n’établit pas la confidentialité sous une base d’utilisateurs minuscule. Elle crée une méthode pour mesurer si les déploiements s’améliorent.

Le test de contenu est simple et sévère. On soumet le même document distinctif sous deux clés de session neuves. Si le fournisseur le reconnaît dans les deux, le découplage de paiement n’a pas donné un découplage de conversation. Une affirmation sur le paiement se juge sur les deux premiers tests. Une affirmation sur un usage anonyme de l’IA doit aussi survivre au troisième. Publier le mode, le modèle de menace et les résultats permettrait de choisir l’outil selon le souci réel.

Le meilleur cas : délier la facture d’un contenu utile

Il y a de vraies raisons de poser une question sensible à un fournisseur sans bâtir un dossier d’usage lié à un compte permanent. Un journaliste qui confronte un document public, un chercheur qui explore une hypothèse controversée, un développeur qui branche une API dans un agent peuvent vouloir que le modèle voie la requête courante tout en coupant la relation de facturation durable. Le dessin du zkAPI répond à ce besoin plus étroit. Il permet aussi à une machine de payer des services mesurés sans gérer un compte personnel de longue durée pour chaque appel.

Le cas contre la survente est aussi solide. Les fournisseurs voient les prompts, et certains prompts révèlent nécessairement une identité. Une entreprise aux exigences strictes de confidentialité peut avoir besoin de clauses contractuelles, de modèles locaux ou de calcul confidentiel, en plus du découplage de paiement. D’autres préféreront un compte ordinaire, avec support et remboursements rodés, à une couche cryptographique dont les voies de litige sont encore jeunes. Le choix dépend du modèle de menace réel.

Une preuve révèle un fait défini sans révéler le témoin. Ce n’est pas une cape d’invisibilité générale. La question utile pour le zkAPI est de savoir quelle partie voit quel enregistrement à chaque étape, pas de savoir si le projet mérite le mot large de privé. La meilleure objection à une lecture sceptique serait un usage mesuré sans lien d’identité persistant, des étiquettes de mode claires, une revue de sécurité indépendante et un modèle de menace publié couvrant IP, télémétrie du navigateur et reçus. La meilleure objection à une promesse marketing expansive est déjà dans le texte de la Fondation : le fournisseur voit le prompt. Les deux observations peuvent être vraies ensemble.

Quand une machine paie à la place d’une personne

La Fondation cite les paiements d’API de machine à machine comme usage possible. Un agent autonome peut envoyer des centaines d’appels avec une note financée, ou avec beaucoup de sessions courtes. Si ses tâches transportent des dossiers de clients, le fournisseur du modèle peut apprendre des choses sur ces clients pendant que la source de paiement de l’agent reste privée. Le bénéfice de confidentialité appartient au lien de facturation. Il ne se transmet pas à chaque sujet nommé dans une requête.

Un agent a aussi besoin de bornes budgétaires. Un plafond par clé limite une session, mais une boucle peut obtenir des clés répétées jusqu’à vider la note, sauf si le client impose une politique de dépense plus large. L’opérateur devrait définir une limite quotidienne ou par tâche, une alerte et une pause, séparées de la preuve cryptographique. La preuve vérifie un crédit autorisé. Elle ne dit pas si l’appel était nécessaire ou économique.

Lorsque plusieurs agents partagent un pool de crédits, la comptabilité interne peut devenir le système de facturation caché. L’opérateur peut vouloir imputer des charges à des équipes ou à des clients sans exporter leurs identités vers le fournisseur d’API. Un registre local peut le faire. Il crée un autre jeu de données sensible à protéger. Passer de la facture de compte à la facture de note n’abolit pas le rapprochement. Il le déplace.

Enfin, un agent peut se trahir par son comportement. Des appels au même rythme, les mêmes en-têtes d’outils et les mêmes formules propres à une tâche peuvent rendre des clés courtes faciles à regrouper. Cacher une note de financement on-chain est utile contre la surveillance du paiement. Ce n’est pas une défense contre une empreinte comportementale que l’agent envoie avec chaque requête.

Ce qu’un audit de modèle de menace devrait encore ouvrir

Au 2 octobre, la Fondation dit le code, le serveur, le client et le coffre en ligne, et renvoie vers un contrat de réseau principal et un dépôt. L’annonce ne publie pas un nombre définitif d’utilisateurs, une valeur totale auditée, toutes les intégrations tierces, ni la garantie que chaque configuration de client utilise le mode direct. Rien ici n’allègue une brèche ou un écart d’un fournisseur nommé. Il s’agit de nommer l’information que chaque partie est censée recevoir, et les fuites supplémentaires que les auteurs du projet reconnaissent.

Une évaluation externe devrait inspecter les défauts du client et les connexions sortantes. La démonstration dans le navigateur envoie-t-elle de la télémétrie vers des domaines sans rapport ? Le client local conserve-t-il des clés ou des journaux de prompts ? Le serveur de paiement peut-il joindre les horodatages d’émission aux adresses réseau ? Les reçus sont-ils reliables d’une session à l’autre ? Comment les mises à jour de circuit et de contrat sont-elles gouvernées ? Une preuve peut être mathématiquement saine pendant qu’une interface livre par accident l’identité qu’elle devait séparer.

La même évaluation devrait regarder la vue du fournisseur d’IA. Il verra le contenu qu’il traite et un identifiant de session. Il peut collecter des métadonnées d’appareil ou de réseau selon le chemin. Sa politique de conservation et les clauses contractuelles restent centrales. La couche de paiement peut réduire une source d’identification sans contraindre toutes les autres.

Le zkAPI marque une avancée réelle s’il empêche de façon fiable un fournisseur de modèle de lier des requêtes utiles à un compte de facturation, tout en préservant la capacité de l’utilisateur à récupérer ses fonds. Il décevra quiconque attend une conversation privée simplement parce que le paiement a été prouvé en zéro connaissance. Les deux affirmations se jugent séparément.

Comment lire une annonce sans se faire raconter une cape

Le réflexe, dans ce secteur, est de traduire chaque primitive en promesse grand public. Arbre de Merkle, nullificateur, Groth16 : le vocabulaire impressionne, et il sert. Il ne remplace pas une phrase simple sur ce qui reste visible. Une lecture saine commence par le bord du système, pas par le circuit. Qui reçoit le texte ? Qui reçoit l’IP ? Qui peut recoller deux sessions par le style ? Qui peut voir que telle adresse a déposé dans le coffre ?

Cette grille évite deux erreurs symétriques. La première consiste à traiter le zkAPI comme un gadget marketing sans intérêt, alors qu’il retire une jointure de facturation que les API commerciales laissent ouverte par défaut. La seconde consiste à le traiter comme une messagerie secrète, alors que le modèle doit lire le prompt pour répondre. Entre les deux, il y a un outil de paiement découplé, utile dans un périmètre nommé, dangereux dès qu’on lui prête les propriétés des couches qu’il ne couvre pas.

Le même réflexe vaut pour la feuille de route plus large d’Ethereum. Un objectif de confidentialité à l’échelle du protocole ne se téléporte pas dans une application déjà en ligne. L’utilisateur d’IA doit juger le client vivant et le chemin fournisseur qui manipule réellement son prompt. Le reste est un contexte, pas une garantie.

Ce qu’un particulier devrait vérifier avant le premier dépôt

Avant d’approvisionner le coffre, le geste le plus utile est modeste : lire le mode affiché, pas le slogan. Si l’interface ne dit pas si la requête part en direct vers le fournisseur ou transite par un relais, l’utilisateur ne sait pas qui voit le texte. Une étiquette claire, avant l’envoi, vaut mieux qu’un paragraphe de documentation enfoui. Le mode proxy n’est pas illégitime. Il est simplement moins étroit sur le contenu, et il doit être choisi en connaissance de cause.

Le deuxième geste concerne le montant. Un dépôt rond, proche de ceux des autres notes, se fond mieux qu’une somme signature suivie d’un retrait immédiat vers une adresse déjà connue. Rien de cela ne casse la preuve. Cela réduit seulement les indices que la chaîne laisse autour d’elle. Retarder la sortie, éviter de republier le même document distinctif, et ne pas coller de pièces d’identité dans le prompt sont des habitudes plus efficaces que le choix d’une courbe.

Le troisième geste est budgétaire. Une clé plafonnée limite une session, pas une journée d’agent qui redemande des clés. Fixer soi-même un plafond local, journaliser les reçus sans y joindre les prompts, et prévoir une pause manuelle évite qu’une boucle vide la note pendant que la cryptographie, elle, fonctionne parfaitement. Le circuit autorise. Il n’économise pas.

• Mode : exiger de voir direct ou proxy avant d’envoyer le moindre texte.
• Montant : éviter les sommes et les horaires qui ne ressemblent qu’à soi.
• Contenu : traiter chaque prompt comme lisible par le fournisseur.
• Réseau : ne pas compter sur le zkAPI pour masquer une IP stable.
• Sortie : garder le secret de note et comprendre le retrait on-chain.
• Reçu : savoir qui signe, quelle unité est comptée, comment contester.

Ce que les équipes produit peuvent en tirer

Pour une équipe qui intègre des modèles, le zkAPI est moins une baguette qu’une option de règlement. Elle permet d’éviter de créer un compte nominatif chez chaque fournisseur pour chaque flux. Elle n’exonère pas de rédiger une politique de rétention, de choisir un chemin réseau, ni de décider ce qui a le droit de quitter le périmètre. Un agent qui envoie des dossiers clients vers un modèle tiers reste un transfert de données, même si la note qui paie est cachée.

Le reçu signé peut devenir un objet de contrôle interne, à condition de ne pas le recoller au prompt dans le même journal. Séparer le total mesuré du texte, limiter la durée des clés, et étiqueter le mode de routage dans les traces d’exploitation rendent l’intégration auditable sans reconstituer le lien que le circuit cherche à casser. À l’inverse, un tableau de bord unique qui joint dépôt, IP, clé et contenu annule l’intérêt du schéma au premier export.

Les obligations ne disparaissent pas avec le compte. Filtres d’abus, sanctions lorsqu’elles s’appliquent, plafonds de débit : la Fondation laisse entendre qu’ils peuvent coexister avec le paiement sans identité durable. La manière de les appliquer sans recréer un dossier nominatif sera le vrai test des intégrations, bien plus que la vérification d’une preuve Groth16 en démonstration.

Les points à suivre dans les prochaines semaines

L’annonce ouvre une fenêtre d’observation, pas un verdict. Quatre signaux permettraient de passer du récit à la mesure. D’abord, l’étiquetage du mode : chaque client affiche-t-il le routage direct ou proxy avant l’envoi ? Ensuite, l’activité sur le réseau principal : des comptes datés de notes financées et d’usage, publiés sans compromettre l’anonymat. Puis la portée des revues indépendantes, sur les sorties du contrat, les circuits, le stockage client et le règlement des reçus. Enfin, le traitement des métadonnées dans les intégrations réelles : IP, télémétrie, durée des clés, conservation chez le fournisseur.

Le cinquième signal est plus terre à terre, et souvent oublié : les litiges de facturation. Requêtes échouées, libération du plafond, reçus contestés : comment tout cela se règle sans forcer une divulgation d’identité ? Un mécanisme qui ne sait répondre qu’en redemandant un compte a réintroduit par la porte du support ce qu’il avait retiré par la porte du paiement.

Rien de cela ne constitue un conseil d’investissement, ni une invitation à confier des dossiers sensibles à un chemin non revu. C’est une grille de lecture. Le zkAPI d’Ethereum, porté avec Open Anonymity, déplace la facture hors du champ de vision du modèle. Il laisse le prompt dans ce champ. Tant que cette phrase reste la première, et non la dernière, le outil peut être jugé pour ce qu’il fait, pas pour la cape qu’on lui prête.

La suite se lira dans les clients, pas dans les fils d’annonce. Une étiquette de mode, un ensemble de notes assez large, un reçu contestable sans nom, une sortie de contrat qui tient sans le serveur : voilà les preuves qui vaudront, le moment venu, plus qu’un circuit élégant. D’ici là, qui paie peut rester caché. Ce qui est demandé, non.