Le cofondateur d'Ethereum, Vitalik Buterin, a testé une configuration d'IA axée sur la confidentialité qui utilise un modèle local, zkAPI et Tor pour générer des recommandations personnalisées en matière d'alimentation et d'exercice tout en limitant les informations personnelles envoyées aux modèles distants.
Résumé
- Vitalik Buterin teste des conseils de santé par IA privée en utilisant Qwen local, zkAPI et le routage Tor.
- Son modèle local réécrit les invites avant que les modèles distants ne reçoivent des données de santé et de voyage limitées à distance.
- zkAPI sépare l'identité de paiement des requêtes de modèle, tandis que Tor est utilisé pour masquer les informations IP.
- Buterin a déclaré que la latence de Tor reste 10 à 100 fois plus élevée, ce qui rend la dissociation requête par requête inefficace dans les tests actuels.
- Qwen3.8-Flash-Next fonctionne à environ 20–30 TPS localement, tandis que Buterin souhaite des vitesses supérieures à 100 TPS pour plus de confort.
Buterin a déclaré le 4 octobre que l'auto-expérimentation utilise ses informations de santé et de voyage localement, tandis que des modèles distants plus puissants traitent des questions sélectionnées qui nécessitent un raisonnement ou des connaissances plus solides.
La configuration utilise Qwen3.8-Flash-Next d'Alibaba comme modèle local. Buterin a déclaré que le système local décide quelles informations un modèle distant nécessite et réécrit les requêtes avant de les envoyer, réduisant ainsi le risque que des détails personnels ou son style d'écriture révèlent son identité.
Vitalik Buterin utilise trois couches pour séparer son identité
Buterin a décrit la conception comme une configuration de confidentialité à trois couches couvrant le contenu des requêtes, les informations de paiement et le trafic Internet. Le modèle Qwen local gère la première couche en construisant lui-même les requêtes au lieu d'envoyer sa formulation originale et son contexte personnel complet aux systèmes d'IA distants.
La deuxième couche utilise zkAPI pour séparer les paiements des requêtes d'IA individuelles. La Fondation Ethereum a présenté zkAPI le 1er octobre, le décrivant comme un système qui permet aux utilisateurs de payer pour des API à la consommation sans lier les requêtes individuelles à leur identité. Le projet a été construit par l'Open Anonymity Project en collaboration avec la Fondation Ethereum et fonctionne sur le réseau principal Ethereum.
Avec zkAPI, un utilisateur alimente un solde privé et prouve ensuite que suffisamment de fonds sont disponibles sans montrer quel dépôt paie pour une requête particulière. Le service qui gère le paiement n'a pas besoin de l'invite de l'utilisateur, tandis que le fournisseur d'IA reçoit l'invite sans connaître l'identité de facturation liée au dépôt.
Tor fournit la troisième couche en masquant l'adresse IP normale de l'utilisateur aux services recevant les requêtes réseau. Buterin a écrit que les trois protections sont nécessaires car masquer uniquement les informations de paiement n'empêche pas un fournisseur d'IA d'apprendre des détails via le contenu de l'invite ou les métadonnées du réseau.
« Vous avez besoin des trois », a déclaré Buterin.
zkAPI ne cache pas tout ce qui est envoyé à un modèle d'IA
La configuration de confidentialité n'empêche pas les fournisseurs d'IA distants de lire les informations délibérément incluses dans une invite. La documentation officielle de zkAPI indique que le fournisseur en amont voit toujours les invites, tandis que les informations de réseau et de timing peuvent rester observables en dehors du système de preuve à divulgation nulle de connaissance.
La Fondation Ethereum a fait la même distinction lors du lancement de zkAPI. Son explication du 1er octobre indiquait que le système de paiement masque le lien entre un utilisateur et une requête, mais que la confidentialité du contenu et l'anonymat du réseau nécessitent des protections distinctes. Les détails personnels réutilisés, les habitudes d'écriture, l'historique des conversations ou les documents peuvent encore permettre de relier les sessions.
Le modèle local de Buterin vise à réduire cette exposition du contenu. Un fichier de compétences indique au modèle quand utiliser un système distant et comment construire une requête contenant moins d'informations identifiantes. Ses dossiers personnels de santé et de voyage restent disponibles pour le système local, tandis que le modèle distant ne reçoit que la partie sélectionnée pour une tâche particulière.
Buterin a déclaré que la configuration produisait des recommandations en matière d'alimentation et d'exercice et que les informations renvoyées par les modèles de pointe amélioraient les résultats. Il n'a pas publié les dossiers de santé sous-jacents, les recommandations détaillées ni une évaluation indépendante de leur exactitude.
L'expérience s'inscrit dans la continuité de son intérêt antérieur pour la confidentialité, alors que les systèmes d'IA traitent de plus en plus d'informations personnelles. Comme précédemment rapporté dans la couverture par crypto.news des préoccupations de Buterin en matière de confidentialité, il a soutenu en avril 2025 que la croissance des capacités de l'IA et la collecte centralisée de données augmentaient la nécessité d'outils de confidentialité plus robustes.
Le support de Tor a atteint la base de code zkAPI
Buterin a renvoyé à un nouveau changement dans le dépôt Ethereum zkAPI qui ajoute un support client routé via Tor. GitHub montre la pull request #16 comme ouverte au 4 octobre, avec un commit proposant des modifications dans sept fichiers. Elle n'a pas encore été fusionnée dans la branche principale du projet.
Le code proposé crée un nouveau client Tor temporaire lorsque le démon zkAPI démarre. Le script utilise un nouveau répertoire de données et une nouvelle connexion Tor, tandis qu'une autre commande peut redémarrer le service pour une nouvelle identité réseau avant qu'une nouvelle requête unique ou conversation ne commence.
Le correctif modifie plusieurs délais d'attente réseau parce que les requêtes routées via Tor peuvent prendre plus de temps. Un délai d'attente pour la liste des modèles passe d'une minute à trois minutes, tandis que d'autres limites de requête augmentent de 15 secondes à 60 secondes et de cinq secondes à 30 secondes.
Un script client Tor distinct inclus dans la proposition indique qu'un nouveau serveur est créé pour une seule requête ou le début d'une nouvelle conversation. Les messages suivants au sein de la même conversation maintiennent le serveur existant en fonctionnement, ce qui signifie qu'ils ne reçoivent pas automatiquement une nouvelle identité Tor pour chaque message.
La latence de Tor et la vitesse de l'IA locale restent des problèmes
Buterin a identifié Tor comme l'un des points les plus faibles de l'expérience actuelle. Il a déclaré que Tor n'avait pas été conçu pour le type de dissociation requête par requête qu'il souhaite, où des appels d'IA distincts seraient idéalement difficiles à associer les uns aux autres.
Dans ses tests, Tor a produit une latence environ 10 à 100 fois supérieure à ce qu'il considérait comme souhaitable. Les modifications GitHub augmentant plusieurs limites de délai d'attente sont cohérentes avec des requêtes réseau plus lentes attendues lorsque le client zkAPI est routé via Tor.
Le modèle local présente une autre limite de performance. Buterin a déclaré que Qwen3.8-Flash-Next fonctionnait à environ 20 à 30 tokens par seconde dans sa configuration, mais il estimait que l'inférence locale ne commencerait à sembler rapide qu'à plus de 100 tokens par seconde.
L'équipe Qwen d'Alibaba a publié Qwen3.8-Flash-Next le 26 août. Le dépôt officiel le décrit comme un modèle de fondation à poids ouverts qui peut fonctionner via des frameworks d'inférence locaux, y compris des déploiements utilisant vLLM et SGLang.
Buterin expérimentait déjà avec des modèles Qwen locaux avant le dernier test de confidentialité. Sa configuration actuelle va plus loin en laissant le modèle local agir comme intermédiaire entre les fichiers privés et les systèmes d'IA distants, au lieu de garder chaque tâche entièrement sur l'appareil de l'utilisateur.
La confidentialité est également restée partie intégrante de son travail sur Ethereum. Dans une couverture connexe,crypto.news a rapporté sur la feuille de route mise à jour d'Ethereum en août, qui incluait une confidentialité protocolaire renforcée aux côtés de travaux sur la résistance quantique et les rollups natifs.
Buterin a déclaré que les règles de rédaction des requêtes dans son expérience actuelle nécessitent encore des améliorations, car la suppression de davantage de contexte personnel peut réduire l'utilité des modèles distants. Il a décrit la limite directement : « plus vous êtes prudent » avec les informations envoyées à distance, moins le modèle distant peut fournir d'assistance.
La documentation zkAPI de la Fondation Ethereum établit une distinction technique similaire. La couche de paiement peut rompre le lien entre un solde approvisionné et l'utilisation individuelle de l'API, mais elle ne peut pas supprimer les informations identifiantes qu'un utilisateur ou un agent local place dans le prompt lui-même.
