Ethereum-Mitbegründer Vitalik Buterin hat ein datenschutzorientiertes KI-Setup getestet, das ein lokales Modell, zkAPI und Tor verwendet, um personalisierte Ernährungs- und Trainingsempfehlungen zu generieren und gleichzeitig die an entfernte Modelle gesendeten persönlichen Informationen zu begrenzen.
Zusammenfassung
- Vitalik Buterin testet private KI-Gesundheitsberatung mit lokalem Qwen, zkAPI und Tor-Routing.
- Sein lokales Modell schreibt Prompts um, bevor entfernte Modelle begrenzte Gesundheits- und Reisedaten remote erhalten.
- zkAPI trennt die Zahlungsidentität von Modellanfragen, während Tor verwendet wird, um IP-Informationen zu maskieren.
- Buterin sagte, die Tor-Latenz bleibe 10–100 Mal höher, was das Anfrage-für-Anfrage-Entkoppeln in aktuellen Tests ineffizient mache.
- Qwen3.8-Flash-Next läuft lokal mit etwa 20–30 TPS, während Buterin für Komfort Geschwindigkeiten über 100 TPS wünscht.
Buterin sagte am 4. Oktober, dass das Selbstexperiment seine Gesundheits- und Reiseinformationen lokal verwendet, während leistungsfähigere entfernte Modelle ausgewählte Fragen bearbeiten, die eine stärkere Argumentation oder Kenntnisse erfordern.
Das Setup verwendet Alibabas Qwen3.8-Flash-Next als lokales Modell. Buterin sagte, das lokale System entscheide, welche Informationen ein entferntes Modell benötigt, und schreibe Anfragen um, bevor sie gesendet werden, wodurch die Wahrscheinlichkeit verringert wird, dass persönliche Details oder sein Schreibstil seine Identität verraten.
Vitalik Buterin verwendet drei Schichten, um seine Identität zu trennen
Buterin beschrieb das Design als ein dreischichtiges Datenschutz-Setup, das den Inhalt von Anfragen, Zahlungsinformationen und Internetverkehr abdeckt. Das lokale Qwen-Modell übernimmt die erste Schicht, indem es Abfragen selbst erstellt, anstatt seinen ursprünglichen Wortlaut und den vollständigen persönlichen Kontext an entfernte KI-Systeme zu senden.
Die zweite Schicht verwendet zkAPI, um Zahlungen von einzelnen KI-Anfragen zu trennen. Die Ethereum Foundation führte zkAPI am 1. Oktober ein und beschrieb es als ein System, das es Nutzern ermöglicht, für abgerechnete APIs zu bezahlen, ohne einzelne Anfragen mit ihrer Identität zu verknüpfen. Das Projekt wurde vom Open Anonymity Project in Zusammenarbeit mit der Ethereum Foundation entwickelt und läuft auf dem Ethereum-Mainnet.
Unter zkAPI lädt ein Nutzer ein privates Guthaben auf und weist später nach, dass genügend Mittel verfügbar sind, ohne preiszugeben, welche Einzahlung für eine bestimmte Anfrage bezahlt. Der Dienst, der die Zahlung abwickelt, benötigt nicht den Prompt des Nutzers, während der KI-Anbieter den Prompt erhält, ohne die mit der Einzahlung verbundene Abrechnungsidentität zu erfahren.
Tor bietet die dritte Schicht, indem es die normale IP-Adresse des Nutzers vor den Diensten verbirgt, die Netzwerkanfragen erhalten. Buterin schrieb, dass alle drei Schutzmaßnahmen erforderlich sind, weil das alleinige Verbergen von Zahlungsinformationen einen KI-Anbieter nicht daran hindert, Details durch Prompt-Inhalte oder Netzwerk-Metadaten zu erfahren.
„Man braucht alle drei“, sagte Buterin.
zkAPI verbirgt nicht alles, was an ein KI-Modell gesendet wird
Das Datenschutz-Setup verhindert nicht, dass entfernte KI-Anbieter Informationen lesen, die absichtlich in einen Prompt aufgenommen wurden. Die offizielle zkAPI-Dokumentation gibt an, dass der vorgelagerte Anbieter weiterhin Prompts sieht, während Netzwerk- und Timing-Informationen außerhalb des Zero-Knowledge-Beweissystems beobachtbar bleiben können.
Die Ethereum Foundation machte dieselbe Unterscheidung, als sie zkAPI startete. Ihre Erklärung vom 1. Oktober besagte, dass das Zahlungssystem die Verbindung zwischen einem Nutzer und einer Anfrage verbirgt, aber Inhaltsdatenschutz und Netzwerkanonymität separate Schutzmaßnahmen erfordern. Wiederverwendete persönliche Details, Schreibmuster, Gesprächsverlauf oder Dokumente können es weiterhin ermöglichen, Sitzungen zu verbinden.
Buterins lokales Modell soll diese Inhaltsweitergabe reduzieren. Eine Skill-Datei weist das Modell an, wann ein Remote-System verwendet werden soll und wie eine Anfrage zu erstellen ist, die weniger identifizierende Informationen enthält. Seine persönlichen Gesundheits- und Reiseaufzeichnungen bleiben für das lokale System verfügbar, während das Remote-Modell nur den für eine bestimmte Aufgabe ausgewählten Teil erhält.
Buterin sagte, das Setup habe Ernährungs- und Trainingsempfehlungen hervorgebracht und die von Frontier-Modellen zurückgegebenen Informationen hätten die Ergebnisse verbessert. Er veröffentlichte weder die zugrunde liegenden Gesundheitsdaten noch die detaillierten Empfehlungen oder eine unabhängige Bewertung ihrer Genauigkeit.
Das Experiment passt zu seinem früheren Fokus auf Privatsphäre, während KI-Systeme mehr persönliche Informationen verarbeiten. Wie zuvor in crypto.news-Berichterstattung über Buterins Datenschutzbedenken berichtet, argumentierte er im April 2025, dass wachsende KI-Fähigkeiten und zentralisierte Datenerfassung den Bedarf an stärkeren Datenschutzwerkzeugen erhöhen.
Tor-Unterstützung hat die zkAPI-Codebasis erreicht
Buterin verwies auf eine neue Änderung im Ethereum-zkAPI-Repository, die Tor-geroutete Client-Unterstützung hinzufügt. GitHub zeigt Pull Request #16 als offen mit Stand vom 4. Oktober, mit einem Commit, der Änderungen über sieben Dateien vorschlägt. Er wurde noch nicht in den Hauptzweig des Projekts gemergt.
Der vorgeschlagene Code erstellt einen frischen temporären Tor-Client, wenn der zkAPI-Daemon startet. Das Skript verwendet ein neues Datenverzeichnis und eine neue Tor-Verbindung, während ein anderer Befehl den Dienst für eine frische Netzwerkidentität neu starten kann, bevor eine neue einzelne Anfrage oder Konversation beginnt.
Der Patch ändert mehrere Netzwerk-Timeouts, weil über Tor geroutete Anfragen länger dauern können. Ein Modelllisten-Timeout steigt von einer Minute auf drei Minuten, während andere Anfragelimits von 15 Sekunden auf 60 Sekunden und von fünf Sekunden auf 30 Sekunden erhöht werden.
Ein separates Tor-Client-Skript, das im Vorschlag enthalten ist, besagt, dass für eine einzelne Anfrage oder den Beginn einer neuen Konversation ein frischer Server erstellt wird. Fortgesetzte Nachrichten innerhalb derselben Konversation lassen den bestehenden Server weiterlaufen, was bedeutet, dass sie nicht automatisch für jede Nachricht eine neue Tor-Identität erhalten.
Tor-Latenz und lokale KI-Geschwindigkeit bleiben Probleme
Buterin bezeichnete Tor als einen der schwächsten Teile des aktuellen Experiments. Er sagte, Tor sei nicht für die Art von Anfrage-für-Anfrage-Entkopplung konzipiert, die er anstrebt, bei der separate KI-Aufrufe idealerweise schwer miteinander in Verbindung zu bringen wären.
In seinen Tests erzeugte Tor eine Latenz, die etwa 10- bis 100-mal höher war als das, was er für wünschenswert hielt. Die GitHub-Änderungen, die mehrere Timeout-Limits erhöhen, stehen im Einklang mit langsameren Netzwerkanfragen, die erwartet werden, wenn der zkAPI-Client über Tor geroutet wird.
Das lokale Modell stellt eine weitere Leistungsgrenze dar. Buterin sagte, Qwen3.8-Flash-Next lief in seinem Setup mit etwa 20 bis 30 Tokens pro Sekunde, aber er glaubte, dass sich lokale Inferenz erst ab mehr als 100 Tokens pro Sekunde schnell anfühlen würde.
Alibabas Qwen-Team veröffentlichte Qwen3.8-Flash-Next am 26. August. Das offizielle Repository beschreibt es als ein Open-Weight-Foundation-Modell, das über lokale Inferenz-Frameworks ausgeführt werden kann, einschließlich Bereitstellungen mit vLLM und SGLang.
Buterin hatte bereits vor dem neuesten Privatsphäre-Test mit lokalen Qwen-Modellen experimentiert. Sein aktuelles Setup geht einen Schritt weiter, indem es das lokale Modell als Vermittler zwischen privaten Dateien und entfernten KI-Systemen agieren lässt, anstatt jede Aufgabe vollständig auf dem Gerät des Nutzers zu belassen.
Privatsphäre ist auch Teil seiner Ethereum-Arbeit geblieben. In verwandter Berichterstattung berichtete crypto.news im August über Ethereums aktualisierte Roadmap, die stärkere Protokoll-Privatsphäre neben Arbeit an Quantenresistenz und nativen Rollups enthielt.
Buterin sagte, die Regeln zum Verfassen von Anfragen in seinem aktuellen Experiment müssten noch verbessert werden, weil das Entfernen von mehr persönlichem Kontext die Nützlichkeit von Remote-Modellen verringern kann. Er beschrieb die Grenze direkt: „Je vorsichtiger man ist“ mit remote gesendeten Informationen, desto weniger Unterstützung kann das Remote-Modell bieten.
Die zkAPI-Dokumentation der Ethereum Foundation macht eine ähnliche technische Unterscheidung. Die Zahlungsschicht kann die Verbindung zwischen einem finanzierten Guthaben und der individuellen API-Nutzung trennen, aber sie kann keine identifizierenden Informationen entfernen, die ein Nutzer oder lokaler Agent im Prompt selbst platziert.
