Vitalik Buterin teste une IA qui protège les données personnelles

Le co-fondateur d'Ethereum, Vitalik Buterin, a testé un système d'IA axé sur la confidentialité qui utilise un modèle local, zkAPI et Tor pour générer des recommandations personnalisées en matière de régime alimentaire et d'exercice tout en limitant les informations personnelles envoyées aux modèles distants.

• Vitalik Buterin teste des conseils de santé privés en utilisant Qwen local, zkAPI et le routage Tor.
• Son modèle local réécrit les requêtes avant que les modèles distants ne reçoivent des données de santé et de voyage limitées.
• 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, rendant le découplage requête par requête inefficace lors des 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érience utilise ses informations de santé et de voyage localement, tandis que des modèles distants plus puissants traitent des questions sélectionnées nécessitant un raisonnement ou des connaissances plus solides.

Je fais un petit auto-expériment.

Objectif : utiliser mes données personnelles de santé et de voyage pour fournir des recommandations personnalisées en matière de régime alimentaire et d'exercice pour moi, en utilisant des modèles de pointe mais d'une manière qui évite de leur divulguer des informations privées.

Stratégie : utiliser un modèle local (Qwen 3.8 Flash... pic.twitter.com/mi38E5jlfN
--- vitalik.eth (@VitalikButerin) 4 octobre 2026

Le système 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 a besoin et réécrit les demandes avant de les envoyer, réduisant ainsi la chance 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 un système 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 des 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 individuelles d'IA. La Fondation Ethereum a introduit zkAPI le 1er octobre, le décrivant comme un système qui permet aux utilisateurs de payer pour des API mesurées sans lier les requêtes individuelles à leur identité. Le projet a été construit par le Projet d'Anonymat Ouvert en collaboration avec la Fondation Ethereum et fonctionne sur le réseau principal d'Ethereum.

Avec zkAPI, un utilisateur finance un solde privé et prouve ensuite qu'il dispose de fonds suffisants sans montrer quel dépôt paie pour une demande particulière. Le service de paiement n'a pas besoin de la demande de l'utilisateur, tandis que le fournisseur d'IA reçoit la demande sans apprendre l'identité de facturation liée au dépôt.

Tor fournit la troisième couche en cachant l'adresse IP normale de l'utilisateur des services recevant des demandes réseau. Buterin a écrit que les trois protections sont nécessaires car cacher les informations de paiement à elles seules ne prévient pas un fournisseur d'IA d'apprendre des détails par le contenu des requêtes ou les métadonnées 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

Le système de confidentialité ne prévient pas les fournisseurs d'IA distants de lire les informations délibérément incluses dans une requête. La documentation officielle de zkAPI indique que le fournisseur en amont voit toujours les requêtes, tandis que les informations de réseau et de timing peuvent rester observables en dehors du système de preuve à connaissance nulle.

La Fondation Ethereum a fait la même distinction lors du lancement de zkAPI. Son explication du 1er octobre a déclaré que le système de paiement cache le lien entre un utilisateur et une demande, mais la confidentialité du contenu et l'anonymat réseau nécessitent des protections séparées. Les détails personnels réutilisés, les modèles d'écriture, l'historique des conversations ou les documents peuvent toujours permettre de relier les sessions.

Le modèle local de Buterin vise à réduire cette exposition au contenu. Un fichier de compétences indique au modèle quand utiliser un système distant et comment construire une demande 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 diététiques et d'exercice et que les informations retourné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 ou une évaluation indépendante de leur précision.

L'expérience s'inscrit dans son attention antérieure sur la confidentialité alors que les systèmes d'IA traitent davantage d'informations personnelles. Comme précédemment rapporté dans la couverture de crypto.news sur les préoccupations de confidentialité de Buterin, il a soutenu en avril 2025 que les capacités croissantes de l'IA et la collecte de données centralisée augmentaient le besoin d'outils de confidentialité plus robustes.

Le support de Tor a atteint la base de code zkAPI

Buterin a lié à un nouveau changement dans le dépôt Ethereum zkAPI qui ajoute le support des clients routés par Tor. GitHub montre que la demande de tirage #16 est ouverte depuis le 4 octobre, avec un engagement proposant des changements 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 connexion Tor, tandis qu'une autre commande peut redémarrer le service pour une nouvelle identité réseau avant qu'une nouvelle demande unique ou conversation ne commence.

Le patch modifie plusieurs délais d'attente réseau car les demandes routées via Tor peuvent prendre plus de temps. Un délai d'attente de liste de modèles passe d'une minute à trois minutes, tandis que d'autres limites de demande augmentent de 15 secondes à 60 secondes et de cinq secondes à 30 secondes.

Un script client Tor séparé inclus dans la proposition indique qu'un nouveau serveur est créé pour une demande unique ou le début d'une nouvelle conversation. Les messages continus dans la même conversation maintiennent le serveur existant en cours d'exécution, 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'une des parties les plus faibles de l'expérience actuelle. Il a déclaré que Tor n'était pas conçu pour le type de déconnexion demande par demande qu'il souhaite, où des appels d'IA séparés seraient idéalement difficiles à associer les uns aux autres.

Dans ses tests, Tor a produit une latence environ 10 à 100 fois plus élevée que ce qu'il considérait comme souhaitable. Les changements sur GitHub augmentant plusieurs limites de délai d'attente sont cohérents avec des demandes réseau plus lentes étant 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 jetons par seconde dans sa configuration, mais il croyait que l'inférence locale ne commencerait à sembler rapide qu'à plus de 100 jetons 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 fond à poids ouvert qui peut fonctionner à travers des cadres d'inférence locaux, y compris des déploiements utilisant vLLM et SGLang.

Buterin avait déjà expérimenté avec des modèles Qwen locaux avant le dernier test de confidentialité. Sa configuration actuelle va un peu plus loin en permettant au modèle local d'agir comme un intermédiaire entre des fichiers privés et des 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 une partie 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é de protocole plus forte aux côtés des travaux sur la résistance quantique et les rollups natifs.

Buterin a déclaré que les règles d'écriture des demandes dans son expérience actuelle nécessitaient encore des améliorations car la suppression de plus 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 fait une distinction technique similaire. La couche de paiement peut rompre le lien entre un solde financé et l'utilisation individuelle de l'API, mais elle ne peut pas supprimer les informations d'identification qu'un utilisateur ou un agent local place à l'intérieur de l'invite elle-même.