Współzałożyciel Ethereum, Vitalik Buterin, przetestował skoncentrowaną na prywatności konfigurację AI, która wykorzystuje lokalny model, zkAPI i Tor do generowania spersonalizowanych zaleceń dotyczących diety i ćwiczeń, jednocześnie ograniczając ilość danych osobowych wysyłanych do zdalnych modeli.
Podsumowanie
- Vitalik Buterin testuje prywatne porady zdrowotne AI przy użyciu lokalnego Qwen, zkAPI i routingu Tor.
- Jego lokalny model przepisuje podpowiedzi, zanim zdalne modele otrzymają ograniczone dane zdrowotne i podróżne.
- zkAPI oddziela tożsamość płatnika od żądań do modelu, a Tor służy do maskowania informacji o adresie IP.
- Buterin powiedział, że opóźnienia Tor pozostają 10–100 razy wyższe, co czyni rozłączanie poszczególnych żądań nieefektywnym w obecnych testach.
- Qwen3.8-Flash-Next działa lokalnie z prędkością około 20–30 TPS, podczas gdy Buterin chciałby prędkości powyżej 100 TPS dla komfortu.
Buterin powiedział 4 października, że ten samoeksperyment wykorzystuje jego informacje zdrowotne i podróżne lokalnie, podczas gdy potężniejsze zdalne modele obsługują wybrane pytania wymagające silniejszego rozumowania lub wiedzy.
Konfiguracja wykorzystuje Qwen3.8-Flash-Next firmy Alibaba jako model lokalny. Buterin powiedział, że lokalny system decyduje, jakich informacji potrzebuje zdalny model, i przepisuje żądania przed ich wysłaniem, zmniejszając szansę, że szczegóły osobiste lub jego styl pisania ujawnią jego tożsamość.
Vitalik Buterin używa trzech warstw do oddzielenia swojej tożsamości
Buterin opisał ten projekt jako trójwarstwową konfigurację prywatności obejmującą treść żądań, informacje o płatnościach i ruch internetowy. Lokalny model Qwen obsługuje pierwszą warstwę, samodzielnie konstruując zapytania zamiast wysyłać jego oryginalne sformułowania i pełny kontekst osobisty do zdalnych systemów AI.
Druga warstwa wykorzystuje zkAPI do oddzielenia płatności od poszczególnych żądań AI. Fundacja Ethereum wprowadziła zkAPI 1 października, opisując je jako system, który pozwala użytkownikom płacić za rozliczane API bez łączenia poszczególnych żądań z ich tożsamością. Projekt został zbudowany przez Open Anonymity Project we współpracy z Fundacją Ethereum i działa w głównej sieci Ethereum.
W ramach zkAPI użytkownik zasila prywatne saldo, a następnie dowodzi, że dostępne są wystarczające środki, nie pokazując, który depozyt płaci za konkretne żądanie. Usługa obsługująca płatność nie potrzebuje podpowiedzi użytkownika, podczas gdy dostawca AI otrzymuje podpowiedź bez poznania tożsamości rozliczeniowej powiązanej z depozytem.
Tor zapewnia trzecią warstwę, ukrywając normalny adres IP użytkownika przed usługami odbierającymi żądania sieciowe. Buterin napisał, że wszystkie trzy zabezpieczenia są potrzebne, ponieważ samo ukrycie informacji o płatności nie powstrzymuje dostawcy AI przed poznaniem szczegółów poprzez treść podpowiedzi lub metadane sieciowe.
„Potrzebujesz wszystkich trzech” – powiedział Buterin.
zkAPI nie ukrywa wszystkiego, co jest wysyłane do modelu AI
Konfiguracja prywatności nie powstrzymuje zdalnych dostawców AI przed odczytaniem informacji celowo zawartych w podpowiedzi. Oficjalna dokumentacja zkAPI stwierdza, że dostawca nadrzędny nadal widzi podpowiedzi, podczas gdy informacje o sieci i czasie mogą pozostać obserwowalne poza systemem dowodów zerowej wiedzy.
Fundacja Ethereum dokonała tego samego rozróżnienia, uruchamiając zkAPI. Jej wyjaśnienie z 1 października mówiło, że system płatności ukrywa związek między użytkownikiem a żądaniem, ale prywatność treści i anonimowość sieci wymagają oddzielnych zabezpieczeń. Ponownie wykorzystane dane osobowe, wzorce pisania, historia rozmów lub dokumenty mogą nadal pozwalać na połączenie sesji.
Lokalny model Buterina ma na celu ograniczenie tego ujawniania treści. Plik umiejętności instruuje model, kiedy używać zdalnego systemu i jak skonstruować żądanie zawierające mniej informacji identyfikujących. Jego osobiste zapisy dotyczące zdrowia i podróży pozostają dostępne dla lokalnego systemu, podczas gdy zdalny model otrzymuje tylko część wybraną dla konkretnego zadania.
Buterin powiedział, że konfiguracja ta generowała zalecenia dotyczące diety i ćwiczeń, a informacje zwracane przez modele frontier poprawiły wyniki. Nie opublikował jednak bazowych zapisów zdrowotnych, szczegółowych zaleceń ani niezależnej oceny ich dokładności.
Eksperyment ten wpisuje się w jego wcześniejsze skupienie na prywatności, gdy systemy AI przetwarzają coraz więcej danych osobowych. Jak wcześniej informowano w relacji crypto.news na temat obaw Buterina dotyczących prywatności, argumentował on w kwietniu 2025 r., że rosnące możliwości AI i scentralizowane gromadzenie danych zwiększają potrzebę silniejszych narzędzi prywatności.
Wsparcie dla Tor dotarło do bazy kodu zkAPI
Buterin podlinkował nową zmianę w repozytorium Ethereum zkAPI, która dodaje obsługę klienta kierowanego przez Tor. GitHub pokazuje pull request #16 jako otwarty na dzień 4 października, z jednym commitem proponującym zmiany w siedmiu plikach. Nie został jeszcze scalony z główną gałęzią projektu.
Proponowany kod tworzy świeżego tymczasowego klienta Tor, gdy demon zkAPI się uruchamia. Skrypt używa nowego katalogu danych i połączenia Tor, podczas gdy inne polecenie może zrestartować usługę w celu uzyskania świeżej tożsamości sieciowej przed rozpoczęciem nowego pojedynczego żądania lub rozmowy.
Poprawka zmienia kilka limitów czasu sieci, ponieważ żądania kierowane przez Tor mogą trwać dłużej. Jeden limit czasu dla listy modeli wzrasta z jednej minuty do trzech minut, podczas gdy inne limity żądań zwiększają się z 15 sekund do 60 sekund oraz z pięciu sekund do 30 sekund.
Osobny skrypt klienta Tor zawarty w propozycji mówi, że świeży serwer jest tworzony dla pojedynczego żądania lub rozpoczęcia nowej rozmowy. Kontynuowane wiadomości w tej samej rozmowie utrzymują działający istniejący serwer, co oznacza, że nie otrzymują automatycznie nowej tożsamości Tor dla każdej wiadomości.
Opóźnienia Tor i szybkość lokalnego AI pozostają problemami
Buterin wskazał Tor jako jedną z najsłabszych części obecnego eksperymentu. Powiedział, że Tor nie został zaprojektowany do typu odłączania żądanie po żądaniu, którego pragnie, gdzie oddzielne wywołania AI idealnie byłoby trudne do powiązania ze sobą.
W jego testach Tor generował opóźnienia około 10 do 100 razy wyższe niż to, co uważał za pożądane. Zmiany w GitHubie zwiększające kilka limitów czasu są zgodne z oczekiwanymi wolniejszymi żądaniami sieciowymi, gdy klient zkAPI jest kierowany przez Tor.
Lokalny model przedstawia kolejne ograniczenie wydajności. Buterin powiedział, że Qwen3.8-Flash-Next działał z prędkością około 20 do 30 tokenów na sekundę w jego konfiguracji, ale uważał, że lokalne wnioskowanie zacznie wydawać się szybkie dopiero przy ponad 100 tokenach na sekundę.
Zespół Qwen firmy Alibaba wydał Qwen3.8-Flash-Next 26 sierpnia. Oficjalne repozytorium opisuje go jako otwarty model bazowy, który może działać poprzez lokalne frameworki wnioskowania, w tym wdrożenia wykorzystujące vLLM i SGLang.
Buterin już wcześniej eksperymentował z lokalnymi modelami Qwen przed najnowszym testem prywatności. Jego obecna konfiguracja idzie o krok dalej, pozwalając lokalnemu modelowi działać jako pośrednik między prywatnymi plikami a zdalnymi systemami AI, zamiast utrzymywać każde zadanie w całości na urządzeniu użytkownika.
Prywatność pozostała również częścią jego pracy nad Ethereum. W powiązanej relacji crypto.news informowało o zaktualizowanej mapie drogowej Ethereum w sierpniu, która obejmowała silniejszą prywatność protokołu wraz z pracami nad odpornością kwantową i natywnymi rollupami.
Buterin powiedział, że zasady pisania żądań w jego obecnym eksperymencie wciąż wymagają poprawy, ponieważ usuwanie większej ilości kontekstu osobistego może zmniejszyć użyteczność zdalnych modeli. Opisał to ograniczenie bezpośrednio: „im bardziej ostrożny jesteś” z informacjami wysyłanymi zdalnie, tym mniej pomocy może zapewnić zdalny model.
Dokumentacja zkAPI Fundacji Ethereum dokonuje podobnego rozróżnienia technicznego. Warstwa płatności może zerwać połączenie między zasilonym saldem a indywidualnym użyciem API, ale nie może usunąć informacji identyfikujących, które użytkownik lub lokalny agent umieszcza w samym prompcie.
