Співзасновник Ethereum Віталік Бутерін протестував налаштування штучного інтелекту, орієнтоване на приватність, яке використовує локальну модель, zkAPI та Tor для генерації персоналізованих рекомендацій щодо дієти та фізичних вправ, обмежуючи при цьому обсяг особистої інформації, що надсилається до віддалених моделей.
Підсумок
- Віталік Бутерін тестує приватні поради щодо здоров'я від ШІ, використовуючи локальний Qwen, zkAPI та маршрутизацію через Tor.
- Його локальна модель переписує запити, перш ніж віддалені моделі отримають обмежені дані про здоров'я та подорожі.
- zkAPI відокремлює платіжну ідентичність від запитів до моделі, тоді як Tor використовується для маскування IP-інформації.
- Бутерін зазначив, що затримка Tor залишається у 10–100 разів вищою, що робить роз'єднання запитів один за одним неефективним у поточних тестах.
- Qwen3.8-Flash-Next працює локально зі швидкістю близько 20–30 TPS, тоді як Бутерін хоче швидкості понад 100 TPS для комфорту.
Бутерін сказав 4 жовтня, що цей самодослід використовує його інформацію про здоров'я та подорожі локально, тоді як потужніші віддалені моделі обробляють вибрані питання, які потребують сильнішого міркування або знань.
У налаштуванні використовується Alibaba Qwen3.8-Flash-Next як локальна модель. Бутерін сказав, що локальна система вирішує, яка інформація потрібна віддаленій моделі, і переписує запити перед їх надсиланням, зменшуючи ймовірність того, що особисті дані або його стиль письма розкриють його особу.
Віталік Бутерін використовує три шари для відокремлення своєї особи
Бутерін описав цю конструкцію як тришарову систему приватності, що охоплює зміст запитів, платіжну інформацію та інтернет-трафік. Локальна модель Qwen обробляє перший шар, самостійно формуючи запити замість надсилання його оригінального формулювання та повного особистого контексту до віддалених систем ШІ.
Другий шар використовує zkAPI для відокремлення платежів від окремих запитів до ШІ. Ethereum Foundation представила zkAPI 1 жовтня, описавши його як систему, що дозволяє користувачам платити за вимірювані API, не пов'язуючи окремі запити з їхньою особою. Проєкт був створений Open Anonymity Project у співпраці з Ethereum Foundation і працює в головній мережі Ethereum.
У рамках zkAPI користувач поповнює приватний баланс і згодом доводить, що достатньо коштів доступно, не показуючи, який саме депозит оплачує конкретний запит. Сервіс, що обробляє платіж, не потребує запиту користувача, тоді як постачальник ШІ отримує запит, не дізнаючись платіжну ідентичність, пов'язану з депозитом.
Tor забезпечує третій шар, приховуючи звичайну IP-адресу користувача від сервісів, які отримують мережеві запити. Бутерін написав, що всі три засоби захисту потрібні, оскільки приховування лише платіжної інформації не заважає постачальнику ШІ дізнаватися деталі через зміст запиту або мережеві метадані.
«Потрібні всі три», — сказав Бутерін.
zkAPI не приховує все, що надсилається до моделі ШІ
Це налаштування приватності не заважає віддаленим постачальникам ШІ читати інформацію, навмисно включену до запиту. Офіційна документація zkAPI зазначає, що постачальник вищого рівня все ще бачить запити, тоді як мережева інформація та інформація про час може залишатися спостережуваною поза системою доказів з нульовим розголошенням.
Ethereum Foundation зробила таке саме розмежування, коли запускала zkAPI. У поясненні від 1 жовтня зазначалося, що платіжна система приховує зв'язок між користувачем і запитом, але конфіденційність вмісту та анонімність мережі потребують окремих засобів захисту. Повторно використані особисті дані, шаблони письма, історія розмов або документи все ще можуть дозволити пов'язати сеанси.
Локальна модель Бутеріна покликана зменшити цей вплив на вміст. Файл навичок вказує моделі, коли використовувати віддалену систему та як побудувати запит, що містить менше ідентифікувальної інформації. Його особисті медичні записи та записи про подорожі залишаються доступними локальній системі, тоді як віддалена модель отримує лише ту частину, яка вибрана для конкретного завдання.
Бутерін сказав, що ця конфігурація дала рекомендації щодо дієти та фізичних вправ, і що інформація, повернута передовими моделями, покращила результати. Він не опублікував основні медичні записи, детальні рекомендації чи незалежну оцінку їхньої точності.
Експеримент узгоджується з його попереднім фокусом на приватності, оскільки системи ШІ обробляють дедалі більше особистої інформації. Як раніше повідомлялося в матеріалі crypto.news про занепокоєння Бутеріна щодо приватності, у квітні 2025 року він стверджував, що зростання можливостей ШІ та централізований збір даних підвищують потребу в потужніших інструментах приватності.
Підтримка Tor дійшла до кодової бази zkAPI
Бутерін посилався на нову зміну в репозиторії Ethereum zkAPI, яка додає підтримку клієнта, маршрутизованого через Tor. GitHub показує, що pull request #16 відкритий станом на 4 жовтня, з одним комітом, який пропонує зміни в семи файлах. Його ще не було злито з основною гілкою проєкту.
Запропонований код створює новий тимчасовий клієнт Tor, коли запускається демон zkAPI. Скрипт використовує новий каталог даних і з'єднання Tor, тоді як інша команда може перезапустити службу для отримання нової мережевої ідентичності перед початком нового одиничного запиту або розмови.
Патч змінює кілька мережевих тайм-аутів, оскільки запити, маршрутизовані через Tor, можуть тривати довше. Один тайм-аут для списку моделей зростає з однієї хвилини до трьох хвилин, тоді як інші обмеження запитів збільшуються з 15 секунд до 60 секунд і з п'яти секунд до 30 секунд.
Окремий скрипт клієнта Tor, включений до пропозиції, зазначає, що новий сервер створюється для одного запиту або початку нової розмови. Подальші повідомлення в межах тієї самої розмови зберігають існуючий сервер запущеним, що означає, що вони не отримують автоматично нову ідентичність Tor для кожного повідомлення.
Затримка Tor і швидкість локального ШІ залишаються проблемами
Бутерін назвав Tor однією з найслабших частин поточного експерименту. Він сказав, що Tor не був розроблений для того типу роз'єднання запит за запитом, якого він хоче, коли окремі виклики ШІ в ідеалі було б важко пов'язати один з одним.
У його тестуванні Tor створював затримку приблизно в 10–100 разів вищу за ту, яку він вважав бажаною. Зміни в GitHub, що збільшують кілька обмежень тайм-ауту, узгоджуються з очікуванням повільніших мережевих запитів, коли клієнт zkAPI маршрутизується через Tor.
Локальна модель становить ще одне обмеження продуктивності. Бутерін сказав, що Qwen3.8-Flash-Next працював зі швидкістю приблизно 20–30 токенів за секунду в його конфігурації, але він вважав, що локальний інференс почне відчуватися швидким лише за понад 100 токенів за секунду.
Команда Qwen від Alibaba випустила Qwen3.8-Flash-Next 26 серпня. Офіційний репозиторій описує його як фундаментальну модель з відкритими вагами, яка може працювати через локальні фреймворки інференсу, включно з розгортаннями з використанням vLLM і SGLang.
Бутерін уже експериментував з локальними моделями Qwen до останнього тесту приватності. Його поточна конфігурація йде на крок далі, дозволяючи локальній моделі виступати посередником між приватними файлами та віддаленими системами ШІ, замість того щоб тримати кожне завдання повністю на пристрої користувача.
Приватність також залишалася частиною його роботи над Ethereum. У супутньому матеріалі crypto.news повідомляло про оновлену дорожню карту Ethereum у серпні, яка включала посилену приватність протоколу поряд із роботою над квантовою стійкістю та нативними rollup'ами.
Бутерін сказав, що правила написання запитів у його поточному експерименті все ще потребують покращення, оскільки видалення більшого обсягу особистого контексту може зменшити корисність віддалених моделей. Він описав це обмеження прямо: «що обережнішими ви є» з інформацією, що надсилається віддалено, то менше допомоги може надати віддалена модель.
Документація zkAPI від Ethereum Foundation робить подібне технічне розмежування. Платіжний рівень може розірвати зв'язок між поповненим балансом та окремим використанням API, але він не може видалити ідентифікувальну інформацію, яку користувач або локальний агент вміщує в сам підказковий запит.
