Le cofondateur d'Ethereum, Vitalik Buterin, a développé un système de confidentialité open source pour les agents d'IA qui combine le routage Tor, les paiements anonymes et le traitement local des invites afin de réduire l'exposition des informations des utilisateurs lors de l'accès aux grands modèles de langage.
Résumé
- Vitalik Buterin a développé un système de confidentialité d'IA open source qui combine le routage Tor, les paiements zkAPI et la réécriture locale des invites.
- Chaque conversation d'IA utilise un circuit Tor distinct, avec l'ajout de trafic de couverture aléatoire pour rendre les requêtes plus difficiles à tracer.
- Le système fonctionne via une interface compatible avec OpenAI et utilise des restrictions de bac à sable pour acheminer l'activité réseau via Tor.
- Buterin a déclaré que la configuration devenait utilisable mais a reconnu des temps de réponse plus lents et des faiblesses face à une analyse coordonnée du trafic.
- Il s'attend à des coûts de dépôt et de retrait zkAPI moins élevés sur le réseau principal Ethereum, bien qu'aucune date de déploiement n'ait été confirmée.
Dans une publication sur X, Buterin a déclaré avoir construit un « mode paranoïaque » pour son harnais d'agent d'IA, pi, en utilisant zkAPI, un trafic de couverture aléatoire et un modèle de langage local pour réécrire les requêtes avant qu'elles n'atteignent un fournisseur d'IA externe.
La configuration fonctionne via un démon compatible avec l'API OpenAI, permettant aux fonctionnalités de confidentialité de fonctionner comme une couche distincte entre l'agent et le service de modèle de langage.
Buterin a publié le code pertinent sur GitHub, bien qu'il ait reconnu que le système introduit des délais substantiels et reste vulnérable à certaines formes d'analyse du trafic.
Le système de confidentialité d'IA de Vitalik Buterin utilise des circuits Tor distincts
Selon la description technique de Buterin, chaque conversation d'IA reçoit un circuit Tor distinct, tandis que les requêtes sont mélangées à un trafic de couverture aléatoire pour rendre l'activité réseau plus difficile à distinguer.
Tor achemine le trafic Internet via plusieurs relais pour dissimuler l'origine d'une connexion. Dans l'implémentation de Buterin, les circuits distincts assurent une isolation réseau entre les conversations.
Le trafic de couverture supplémentaire vise à rendre plus difficile pour un observateur l'identification des requêtes d'IA réelles sur la base des schémas de communication.
La confidentialité des paiements est gérée via zkAPI, ce qui, selon Buterin, empêche les utilisateurs d'exposer leur identité par le biais des informations de paiement lors de l'accès aux services d'IA.
Le système comprend un mécanisme local de réécriture des invites. Avant qu'une requête n'atteigne le modèle de langage externe, un autre modèle exécuté sur l'appareil de l'utilisateur traite le texte original.
Buterin a décrit cette fonctionnalité comme un arrangement apportez-votre-propre-modèle-local, permettant aux utilisateurs de sélectionner le modèle chargé de réécrire leurs invites.
Sa propre configuration utilise qwen3.8-flash-next, selon la publication.
La réécriture locale fournit une couche de protection distincte des composants de routage réseau et de paiement. Cependant, Buterin n'a pas affirmé que les invites réécrites éliminent toute possibilité d'identifier un utilisateur grâce aux informations qu'il soumet.
L'implémentation rassemble ces fonctions au sein d'un démon qui prend en charge l'interface API OpenAI, permettant à l'agent d'envoyer des requêtes via l'enveloppe de confidentialité.
Les restrictions de bac à sable ajoutent une autre couche d'isolation
Au-delà du routage réseau et du traitement des invites, Buterin a placé le harnais d'agent pi dans un bac à sable bubblewrap, ou bwrap.
Bubblewrap est un utilitaire de bac à sable Linux qui peut restreindre l'accès d'un programme à certaines parties de son environnement d'exploitation.
Buterin a déclaré qu'il expérimentait la technologie MicroVM comme autre option d'isolation, bien que la publication n'ait pas établi que la configuration MicroVM soit devenue partie intégrante de l'implémentation finale.
L'agent en bac à sable est enveloppé avec torsocks, un utilitaire qui dirige les connexions réseau prises en charge à travers Tor.
Selon Buterin, la disposition vise à garantir que l'activité réseau de l'agent passe par Tor au lieu d'établir des connexions directes.
La conception technique aborde donc plusieurs sources distinctes d'exposition potentielle à l'information, notamment les connexions réseau, les enregistrements de paiement, le contenu des invites et l'environnement dans lequel l'agent IA opère.
Buterin a démontré la disposition à l'aide d'une simple tâche de recherche et a déclaré que le logiciel devenait utilisable pour un travail pratique.
« C'est devenu tout à fait utilisable ! » a-t-il écrit, tout en reconnaissant que les utilisateurs font encore face à une latence considérable.
Il a particulièrement pointé le début d'une nouvelle conversation comme une partie particulièrement lente du processus.
Le post n'a pas fourni de résultats de référence, de temps de réponse moyens ou de comparaison avec une version non protégée du même agent.
La protection Tor reste vulnérable à l'analyse coordonnée du trafic
Malgré les mesures de confidentialité supplémentaires, Buterin a reconnu que Tor n'était pas un réseau idéal pour le système qu'il avait développé.
Il a déclaré que le trafic de couverture aléatoire offrait une protection raisonnable contre les observateurs passifs, mais a identifié une menace plus difficile impliquant une coopération entre un fournisseur d'IA et un relais de garde Tor.
Un relais de garde est le premier relais utilisé par un client Tor pour entrer dans le réseau.
Dans le scénario décrit par Buterin, un fournisseur d'IA travaillant avec le garde pourrait manipuler activement le timing des requêtes et des réponses pour identifier des motifs dans le trafic.
Une telle coordination rendrait le trafic de couverture aléatoire substantiellement moins efficace, selon son évaluation.
Buterin a soutenu que ce type d'application bénéficierait d'un mixnet spécialisé, un réseau de confidentialité conçu pour rendre plus difficile la connexion des communications entrantes et sortantes par l'analyse du trafic.
Son approche proposée impliquerait une exigence de bande passante plus élevée et un trafic de couverture constant intégré directement dans le réseau.
Un trafic de couverture constant signifierait générer une activité réseau supplémentaire même lorsque les utilisateurs ne font pas de requêtes authentiques, au lieu de compter uniquement sur un trafic inséré aléatoirement.
Buterin n'a pas annoncé d'implémentation fonctionnelle de mixnet ni fourni de calendrier pour en développer une.
Ses commentaires décrivaient le réseau comme une amélioration technique potentielle par rapport à la disposition Tor actuelle, qu'il a qualifiée de solution imparfaite pour protéger les interactions d'IA.
Les coûts de paiement zkAPI devraient baisser sur Ethereum
Buterin a terminé sa mise à jour avec un développement distinct concernant le coût d'utilisation de zkAPI.
Il a déclaré que des coûts de gaz nettement moins chers pour les dépôts et retraits zkAPI arriveraient bientôt sur le réseau principal Ethereum.
La déclaration n'a pas précisé la réduction attendue des coûts de transaction, le mécanisme responsable des économies ou une date de déploiement.
Les dépôts et retraits sont distincts des fonctions de confidentialité du réseau dans l'enveloppe de l'agent, qui utilise zkAPI pour répondre à la possibilité d'exposition d'identité via les paiements.
Le post de Buterin n'a pas identifié quels fournisseurs externes de modèles de langage avaient été utilisés dans sa démonstration ni divulgué le coût total d'exécution des outils de confidentialité combinés.
Les changements annoncés des coûts de gaz restent en attente, aucune date d'activation confirmée sur le réseau principal n'ayant été fournie dans le post.
Les travaux antérieurs sur zkAPI fournissent le contexte de la dernière expérience de Buterin
La dernière implémentation fait suite à un lancement du 1er octobre par la Fondation Ethereum et Open Anonymity Project, qui a introduit zkAPI comme système de paiement pour les services à la consommation.
Selon l'annonce technique de la Fondation, les utilisateurs déposent des fonds dans un coffre Ethereum et autorisent l'utilisation ultérieure de l'API via des preuves à divulgation nulle de connaissance.
Le système peut émettre des identifiants API de courte durée avec des limites de dépenses, permettant à une seule autorisation de couvrir plusieurs requêtes pendant une session.
L'autorisation de paiement et la livraison rapide sont gérées séparément. Le service de paiement vérifie les droits de dépense sans recevoir la conversation, tandis que le fournisseur du modèle traite le prompt sans qu'on lui communique l'identité de financement de l'utilisateur.
La Fondation a reconnu que le mécanisme de paiement ne dissimule pas de manière indépendante les adresses IP ni les informations contenues dans les prompts. Ces limites ont été examinées dans une analyse de la confidentialité de zkAPI du 2 octobre.
Le 4 octobre, Buterin a testé une configuration à trois couches utilisant des informations personnelles de santé et de voyage pour générer des recommandations de régime et d'exercice.
Comme crypto.news l'a rapporté précédemment, l'expérience antérieure utilisait un modèle Qwen local pour décider quelles informations devaient être partagées avec les services d'IA distants. Buterin a signalé des vitesses de traitement d'environ 20 à 30 tokens par seconde et a déclaré que des vitesses supérieures à 100 tokens par seconde seraient préférables.
Les travaux d'Ethereum sur les agents autonomes incluent l'infrastructure d'identité ERC-8004, dont le déploiement sur le réseau principal était prévu pour janvier 2026. La norme fournit des registres pour l'identité et la réputation des agents, une fonction distincte de l'autorisation de paiement privée gérée par zkAPI.
Le dernier article de Buterin décrit des contrôles supplémentaires autour de l'arrangement de confidentialité antérieur, notamment des circuits Tor spécifiques à chaque conversation, un trafic de couverture aléatoire et des restrictions de bac à sable.
