zkAPI на Ethereum приховує, хто платить за ШІ, але модель усе одно бачить запит

Фонд Ethereum та Open Anonymity Project запустили zkAPI в головній мережі Ethereum 1 жовтня. Користувач може внести кредити та довести, що пізніший запит до AI API оплачено, не розкриваючи платіжному серверу свою особу, а постачальнику моделі — адресу фінансування. Постачальник усе одно отримує запит. Таке розділення корисне, але це вужче твердження про приватність, ніж анонімна розмова з моделлю.

Технічне оголошення Фонду Ethereum надзвичайно чітко окреслює межу. Доказ приховує, яка нота оплачує використання, тоді як постачальник керує моделлю та бачить запит. У ньому також названо мережеві метадані та вміст запиту як джерела кореляції, що залишаються. Це важливо, оскільки фразу «приватні платежі за ШІ» легко сприйняти як «приватне використання ШІ».

За словами Фонду, проєкт уже працює: є публічний репозиторій GitHub, сховище в головній мережі з кредитами USDC та демонстраційний інтерфейс чату, посилання на який є в оголошенні. Живе розгортання підтверджує, що є код і контракт для перевірки. Воно не підтверджує впровадження користувачами, обсяг аудиту безпеки, анонімність у кожній конфігурації клієнта чи захист від постачальника, який розпізнає стиль письма та документи користувача.

Один депозит замінює слід із рахунків API

Більшість комерційних AI API пов’язують ключ з обліковим записом і способом оплати. Постачальник може зіставити запити з платіжною ідентичністю, навіть якщо користувач ніколи не підписує запит іменем. zkAPI запроваджує профінансоване сховище та приватну ноту. Користувач вносить підтримувані активи, як-от USDC, у контракт; програмне забезпечення на пристрої користувача згодом створює доказ з нульовим розголошенням, що дійсна профінансована нота може оплатити обмежене використання, не розкриваючи, яка саме це нота.

Платіжний сервер перевіряє доказ і видає короткочасний API-ключ з обмеженням у доларах. У режимі прямого runtime-ключа, описаному Фондом, запити йдуть з пристрою користувача до постачальника ШІ з цим ключем. Після сесії підписана квитанція фіксує виміряне використання, і приватний баланс списується на фактично використану суму, а не просто на зарезервований ліміт. Один доказ може покривати сесію з кількох запитів.

Це дозволяє не розміщувати кожен запит до моделі в Ethereum. Ланцюг бачить депозити, закриття та виведення зі сховища, тоді як сервер перевіряє докази витрат поза ланцюгом. Постачальник моделі бачить текст і трафік API. Платіжний сервер бачить доказ того, що сесія профінансована, і загальну суму списання, але в прямому режимі не отримує запит. Це твердження про описану архітектуру, а не доказ того, що журнали чи мережева конфігурація конкретного розгортання ніколи не зможуть зіставити користувачів.

Існує простіший режим проксі. У ньому сервер zkAPI пересилає запит користувача постачальнику моделі. За словами Фонду, цей сервер може бачити трафік. Людині, яка обирає між режимами, варто запитати, якій стороні вона довіряє вміст, а якій потрібно лише перевірити доказ оплати. Локальний інтерфейс, який виглядає однаково, може під капотом спрямовувати запити по-різному.

Записка доводить цінність, не називаючи свого вкладника

Криптографічна конструкція використовує зобов’язання в дереві Меркла. Доказ стверджує, що записка користувача є серед дійсних профінансованих записок, не ідентифікуючи її листок. Нультифікатор, похідний від секрету записки, запобігає подвійному витрачанню того самого балансу. Фонд називає докази Groth16 на BN254 та хеші Poseidon, з деревом 32 рівнів. Ці деталі важливі для розробників, але фінансовий принцип простіший: підтвердити членство та залишок повноважень на витрачання, не публікуючи рахунок, який надав кредит.

Користувач не отримує безкоштовного використання, приховуючи особу. Сервер повинен перевірити доказ витрати та зарезервувати ліміт, перш ніж видати тимчасовий ключ. Постачальник вимірює використання. Квитанція розраховує фактичну суму після закінчення терміну дії ключа. Якщо зарезервовано ліміт у $10, а спожито послуг на $3, система має стягнути $3, а не $10. Цей приклад ілюструє логіку резервування, а не опубліковану ціну чи гарантований мінімум. Залишок балансу залишається в приватній записці відповідно до правил реалізації.

Нультифікатор вирішує конкретну проблему: спробу витратити одну записку двічі. Він не доводить, що модель ШІ відповіла точно, не зберігає конфіденційність підказки та не заважає постачальнику записувати запити. Доказ з нульовим розголошенням — це твердження про дійсність транзакції за визначеною схемою. Його гарантії не поширюються автоматично на інші дані, що рухаються разом із транзакцією.

Шлях виходу з контракту також має значення. Фонд заявляє, що користувач може закрити баланс сховища та вивести кошти на ланцюг, навіть якщо сервери zkAPI зникнуть. Це дозволяє уникнути того, щоб платіжний сервер був єдиним шляхом для повернення коштів. Це не робить виходи невидимими: Ethereum записує відповідні транзакції. Здатність користувача вийти залежить від контракту та володіння необхідним секретом, і розсудливий користувач повинен перевірити адреси розгортання, дозволи та будь-який незалежний аудит, перш ніж призначати велику цінність цьому механізму.

Постачальник може розпізнати те, що доказ не може розкрити

Платіжний доказ може приховати джерело фінансування, тоді як тіло запиту містить ім’я особи, роботодавця, медичну історію або пропрієтарний код. Постачальник моделі, який читає підказку, може пов’язати її з попередніми сесіями, використовуючи повторювані фрази, завантажені файли, історію розмов або дуже характерні факти. Жодного зв’язку з гаманцем не потрібно. Підказка про неопублікований продукт з однаковою внутрішньою назвою проєкту протягом трьох сесій є власним ідентифікатором.

Мережеві метадані надають інший шлях. У режимі ключа виконання постачальник може бачити IP-адресу, з якої підключається пристрій. У режимі проксі посередник може бачити трафік і потенційно його вихідну мережеву інформацію. Фонд прямо заявляє, що стабільна IP-адреса та корельований час можуть послабити приватність, і пропонує інструменти мережевої анонімності для користувачів, які шукають сильнішого захисту. VPN або Tor можуть змінити мережевий шлях, але жоден з них не видаляє ім’я, введене в підказку.

Існує трирівневий тест на приватність. Платіжна приватність запитує, чи можна пов’язати рахунок із запискою про фінансування або особою. Мережева приватність запитує, чи може служба ідентифікувати з’єднання за IP, часом або характеристиками пристрою. Приватність вмісту запитує, чи може будь-хто, хто керує моделлю, прочитати підказку. zkAPI розроблено головним чином для першого рівня. Він може зменшити зв’язок на рівні рахунку між журналом використання постачальника моделі та джерелом платежу користувача. Він не забезпечує два інші сам по собі.

Це не дефект, прихований у дрібному шрифті. У власному оголошенні проєкту сказано, що постачальник бачить запити. Чесний опис сильніший за розширений слоган про анонімність, оскільки він підказує користувачам, де зосередити додаткові запобіжні заходи. Людина, яка використовує службу для загальних запитань, може отримати значну непов’язаність платежів. Людина, яка вставляє підписаний контракт і повне ім’я, розкрила особу у вмісті незалежно від платіжного шляху.

Набір анонімності може бути малим навіть за надійних доказів

Нульове знання може приховати, яка з кількох записок заплатила, але практичний натовп має значення. Якщо лише один користувач фінансує сховище у вузькому часовому вікні з незвичайною сумою депозиту, і після сесії відбувається так само характерне виведення, спостерігач може сформувати правдоподібну кореляцію з публічного часу та сум. Доказ може залишатися криптографічно дійсним і незламним. Висновок із зовнішньої інформації є окремою атакою.

Дерево 32 рівнів є параметром ємності в дизайні, а не доказом того, що мільярди різних користувачів сьогодні змішують свої кредити. Новозапущена служба може мати невеликий набір профінансованих записок. Щоб оцінити анонімність на практиці, потрібно було б мати датовані підрахунки депозитів, різних активних записок і моделей виведення, з агрегацією, що враховує приватність. Репозиторій або теоретичний розмір дерева не надають цих чисел.

Припустімо, що для сесії придатні десять нот, і публічні факти виключають дев'ять із них. Математичний доказ усе ще може ідеально приховати свого свідка, тоді як навколишня інформація вказує на десяту. Цей іграшковий приклад пояснює, чому розмір і різноманітність правдоподібної множини важливіші за сиру кількість транзакцій у сховищі. Стандартизація сум, відкладена активність і регулярне використання можуть допомогти, але поведінка користувача та дизайн сервісу визначають, що доступно для кореляції.

Існує другий тип множини в постачальника ШІ: група запитів, що спільно використовують короткочасний ключ. Ключ може пов'язувати запити в межах своєї обмеженої сесії, навіть якщо він не може ідентифікувати депозит. Це притаманно вимірюванню сесії. Якщо клієнт неодноразово надсилає ті самі документи в пізніших сесіях, постачальник може також пов'язати їх між ключами. Приховування платіжного рахунку є цінним, але воно не змушує постачальника забути те, що він прочитав.

Накресліть записи для однієї сесії, не припускаючи, що хтось шахраює. Ethereum записує транзакцію депозиту та її адресу фінансування. Пристрій користувача зберігає секрет ноти та надсилає доказ на платіжний сервер. Сервер записує дійсність доказу, нуліфікатор і подію випуску для обмеженого ключа. Постачальник моделі записує цей ключ, запити та використання, за яке він виставив рахунок. Підписана квитанція пов'язує ключ із виміряною загальною сумою. Після закриття контракт може записати вихід. Кожна сторона має частковий реєстр.

Задумана властивість приватності полягає в тому, що жоден реєстр окремої чесної сторони не пов'язує безпосередньо адресу фінансування з підказками постачальника. Коаліція, витік даних або зовнішній спостерігач із часовими мітками можуть мати більше інформації. Якщо користувач вносить незвичайну суму й негайно надсилає один незвичайний запит, кореляція подій може стати легшою. Якщо постачальник отримує документ, який ідентифікує користувача, він може знати, хто запитав, хоча ніколи не бачив адресу сховища. Це проблема композиції, а не невдалий доказ із нульовим розголошенням.

Вправа з реєстром також виявляє важливість часу життя ключів. Обліковий дані сесії навмисно групують усі запити, які він авторизує, щоб постачальник міг їх вимірювати. Ліміт у 50 доларів може дозволити багато підказок під одним ключем. Нижчі ліміти та коротші сесії можуть зменшити обсяг вмісту, пов'язаного в межах одного облікового даного, але вони вимагають частіших доказів і можуть додати затримку або витрати. Не існує універсально приватного налаштування; користувач і постачальник обирають між зручністю, вартістю та можливістю зв'язування.

Публічна модель загроз має точно називати, які записи зберігаються і як довго. Вона має вказувати, чи сервер реєструє вихідні IP-адреси під час подання доказу, чи зберігає нуліфікатори безстроково, і чи може постачальник пов'язати ідентифікатори квитанцій із вмістом запиту після розрахунку. Видалення платіжного імені з бази даних є корисним. Цього недостатньо, якщо постійний ідентифікатор пристрою тихо відтворює той самий профіль.

Підписана квитанція про використання переносить довіру у вимірювання

Постачальник або сервер потребує способу стягувати плату за фактично виконану роботу. Дизайн використовує підписану квитанцію, пов'язану з короткочасним ключем та його використанням. Це переносить центральне комерційне питання до точності вимірювання. Якщо постачальник перераховує токени, запити або час, дійсний доказ оплати не може виправити основну суму рахунку. Підпис робить заявлену загальну суму важкою для переписування пізніше; він не встановлює, що заявлене використання було справедливим згідно з тарифною сіткою постачальника.

Клієнт має запитати, яка одиниця стягується, хто підписує квитанцію, як вивільняється невикористаний резерв і що відбувається, коли запит не вдається на півдорозі. Це звичайні питання виставлення рахунків у незвичайному криптографічному вбранні. Ліміт обмежує розмір несподіваного списання в одній сесії, але багато невеликих сесій все ще можуть накопичити значні витрати. Обмеження швидкості та рахунки-фактури можуть потребувати процесу вирішення спорів із збереженням приватності.

Компроміс є операційним. Традиційні облікові записи API спрощують підтримку клієнтів, повернення коштів і розслідування зловживань, оскільки постачальник може ідентифікувати покупця. zkAPI видаляє постійну платіжну ідентичність із призначеного платіжного шляху. Постачальники все ще можуть потребувати контролю за зловживаннями, перевірки санкцій, де це застосовно, та забезпечення використання. Фонд каже, що ціноутворення та обмеження швидкості можуть залишатися, але фактичні інтеграції покажуть, як сервіси балансують платежі без облікових записів зі своїми зобов'язаннями та контролем шахрайства.

Одним із практичних тестів є навмисно перервана сесія. Клієнт отримує обмежений ключ, робить кілька запитів, втрачає доступ до мережі й пізніше відновлює з'єднання. Чи відображає квитанція лише доставлене використання? Чи може користувач перевірити виміряну суму локально, не надсилаючи підказку на платіжний сервер? Якщо сервер зникає, чи може користувач отримати невикористаний баланс через контракт, як було обіцяно? Ці тести виходять за межі того, чи доказ перевіряється, до того, чи продукт зберігає обіцяне розділення в разі збою.

Ончейн-контракт — це аварійний вихід, а не щит приватності

Згідно з Фондом, контракт сховища може перевіряти докази для операцій депозиту, закриття та виходу. Ончейн-маршрут виходу має значення, оскільки вимкнення постачальника не повинно залишати кошти користувача в базі даних оператора. Контракт замінює частину інституційної довіри на ризик смарт-контракту. Помилка в перевірці доказів, обліку або логіці виведення може вплинути на кошти, незважаючи на обґрунтовану концепцію приватності. Активна адреса є доказом розгортання, а не сертифікатом аудиту.

Публічні депозити та виведення також мають ціну приватності. Той, хто знає адресу фінансування користувача, може спостерігати, що вона взаємодіяла зі сховищем. Вони можуть не бачити, за яку сесію API було сплачено, але вони бачать участь і суми. Якщо той самий користувач швидко виводить незвичайну суму на адресу, вже пов’язану з ним, частина навколишньої анонімності може зменшитися. Приватна нота розриває детермінований білінговий зв’язок; вона не стирає публічну транзакцію фінансування.

Проєкт бере початок з дизайну Ethereum Research для кредитів API з нульовим розголошенням, який Фонд визначає як роботу Davide Crapis і Vitalik Buterin. Дослідницька пропозиція та виробнича система відповідають на різні питання. Перша окреслює конструкцію; друга повинна враховувати зберігання ключів, поведінку фронтенду, збої, суперечки щодо квитанцій, оновлення та реальних супротивників. Реліз 1 жовтня переводить ідею в тестоване розгортання, і це відповідний свіжий гачок.

Ширші зусилля Ethereum щодо приватності не є тим самим продуктом. Висвітлення Crypto.news запропонованого нативного дизайну приватності стосується проєкту зміни протоколу, тоді як zkAPI — це застосунок, що працює зараз. Нещодавній запуск гаманця zk.money стосується приватних переказів в іншому середовищі. Жодне з них не слід наводити як доказ того, що запит ШІ, надісланий через zkAPI, прихований від його постачальника моделі.

Заяви про приватність повинні витримувати відтворюваний тест

Незалежний рецензент міг би створити дві профінансовані ноти з не пов’язаних адрес, провести короткі сесії з тим самим постачальником моделі та перевірити кожен пакет і журнал, видимий клієнту, платіжному серверу та постачальнику. Рецензент повинен окремо перевірити прямий режим і режим проксі. Якщо платіжний сервер у прямому режимі отримує запит, це суперечить описаному розділенню. Якщо постачальник отримує адресу депозиту або довготривалий ідентифікатор білінгового облікового запису, передбачувана незв’язність зазнала невдачі на рівні інтеграції, навіть якщо схема доказу є надійною.

Складніший тест є статистичним. Проведіть багато сесій з різними сумами та часом, а потім запитайте, чи може сторона, яка має лише публічні дані ланцюга та журнали сервера, співвіднести фінансування та використання краще, ніж випадково. Еталон залежить від фактичного набору анонімності та того, які допоміжні дані має супротивник. Успішна невелика лабораторна демонстрація не встановлює приватність за крихітної виробничої бази користувачів, але вона створює метод для вимірювання того, чи розгортання покращуються з часом.

Тест вмісту є простим і тверезим. Надішліть той самий характерний документ під двома свіжими ключами сесії. Якщо постачальник може розпізнати його в обох, незв’язність платежу не дала користувачеві незв’язності розмови. Заяву про платіж слід оцінювати за першими двома тестами; заява про анонімне використання ШІ також повинна витримати третій. Публікація режиму, моделі загроз і результатів дозволила б користувачам вибрати правильний інструмент для їхньої фактичної проблеми.

Найсильніший аргумент — відокремити білінг від корисного вмісту

Є багато законних причин поставити постачальнику ШІ делікатне питання, не створюючи постійного досьє використання, пов’язаного з обліковим записом. Журналіст, який тестує публічний документ, дослідник, який вивчає суперечливу гіпотезу, або розробник, який використовує API всередині агента, можуть хотіти, щоб постачальник бачив поточний запит, але розірвав довготривалі білінгові відносини. Дизайн zkAPI відповідає цій вужчій потребі. Він також дозволяє машині платити за послуги з вимірюванням, не керуючи довготривалим особистим обліковим записом для кожного запиту.

Аргумент проти надмірних заяв є однаково сильним. Постачальники все ще бачать запити, і деякі запити неминуче розкривають особу. Підприємство з суворими вимогами конфіденційності може потребувати договірних засобів контролю, локальних моделей або конфіденційних обчислень, а також незв’язності платежів. Деякі користувачі можуть віддати перевагу звичайному обліковому запису з налагодженою підтримкою та поверненнями коштів, а не криптографічному платіжному шару, механізми вирішення спорів якого ще незрілі. Вибір залежить від фактичної моделі загроз.

Дорожня карта конфіденційності Ethereum, обговорена crypto.news, окреслює конфіденційність як ширшу мету. Дорожня карта не надає цьому застосунку своїх майбутніх засобів захисту вже сьогодні. Користувач ШІ повинен оцінювати актуальний шлях клієнта та постачальника, який фактично обробляє запит.

Crypto.news пояснив вужчу механіку доказів з нульовим розголошенням в окремому вступі. Доказ розкриває визначений факт, не розкриваючи свідчення; це не універсальна мантія невидимості. Його інтерв'ю про інфраструктуру Ethereum, орієнтовану на конфіденційність, підкреслює, як різні продукти захищають різні дані. Корисне питання для zkAPI полягає в тому, яка сторона бачить який запис на кожному кроці, а не в тому, чи відповідає проєкт широкому слову «приватний».

Найкращим контрдоказом скептичного прочитання було б виміряне використання без постійного зв'язку з ідентичністю, чіткі позначки режимів, незалежний аудит безпеки та опублікована модель загроз, що охоплює IP, телеметрію браузера та квитанції. Найкращий контрдоказ розширеного маркетингового твердження вже міститься в дописі Фонду: постачальник бачить запит. Обидва спостереження можуть бути правдивими одночасно.

Фонд перелічує платежі через API між машинами як можливе застосування. Автономний агент може надіслати сотні викликів, використовуючи одну профінансовану ноту або багато коротких сесій. Якщо його завдання містять записи клієнтів, постачальник моделі може дізнатися про цих клієнтів, навіть якщо джерело платежу агента залишається приватним. Перевага конфіденційності належить платіжному зв'язку; її не слід переносити на кожного суб'єкта, названого в запиті.

Агенту також потрібні засоби контролю бюджету. Ліміт на ключ обмежує одну сесію, але цикл може отримувати повторні ключі, доки нота не буде вичерпана, якщо клієнт не застосовує ширшу політику витрат. Оператор повинен визначити денний ліміт або ліміт на рівні завдання, сповіщення та контроль паузи, окремий від криптографічного доказу. Доказ підтверджує авторизований кредит, а не те, чи був виклик агента необхідним або економічним.

Коли кілька агентів спільно використовують один пул кредитів, внутрішній облік може стати прихованою системою виставлення рахунків. Оператору може знадобитися розподіляти витрати між командами або клієнтами, не експортуючи їхні ідентичності постачальнику API. Це можна зробити за допомогою локального реєстру, але це створює ще один чутливий набір даних, який потрібно захищати. Перехід від виставлення рахунків за обліковим записом до виставлення рахунків за нотами не скасовує звірки; він її переміщує.

Нарешті, агент може викрити себе через поведінку. Повторні виклики за однаковим розкладом, однакові заголовки інструментів і однакові фрази, специфічні для завдання, можуть зробити окремі короткочасні ключі легкими для кластеризації. Приховування ончейн-ноти фінансування корисне проти платіжного нагляду. Це не захист від поведінкового відбитка, який агент надсилає з кожним запитом.

Розгортання все ще потребує аудиту моделі загроз

Станом на 2 жовтня Фонд повідомляє, що код, сервер, клієнт і сховище працюють. Допис посилається на контракт у головній мережі та репозиторій. Він не публікує в оголошенні остаточної кількості користувачів, перевіреної загальної вартості, усіх сторонніх інтеграцій або гарантії, що кожна конфігурація клієнта використовує режим прямих ключів виконання. Ця стаття не заявляє про порушення або неналежну поведінку з боку названого постачальника. Вона визначає інформацію, яку кожна сторона має отримувати, та додаткові витоки, які визнають автори проєкту.

Зовнішня оцінка повинна перевірити налаштування клієнта за замовчуванням і вихідні з'єднання. Чи надсилає браузерна демонстрація телеметрію на не пов'язані домени? Чи зберігає локальний клієнт ключі або журнали запитів? Чи може платіжний сервер поєднати часові мітки випуску з мережевими адресами? Чи можна пов'язати квитанції між сесіями? Як керуються оновлення схем і контрактів? Доказ може бути математично обґрунтованим, тоді як інтерфейс користувача випадково розкриває ідентичність, яку він мав відокремити.

Та сама оцінка повинна перевірити погляд постачальника ШІ. Він бачитиме вміст, який обробляє, та сесійний обліковий дані. Він може збирати метадані пристрою або мережі залежно від шляху запиту. Політика збереження даних постачальника та будь-які договірні умови залишаються ключовими. Платіжний рівень може зменшити одне джерело ідентифікуючої інформації, не обмежуючи всі інші.

zkAPI робить справжній прорив, якщо він надійно перешкоджає постачальнику моделі прив’язувати корисні запити до платіжного облікового запису, зберігаючи при цьому можливість користувача повернути кошти. Він розчарує будь-кого, хто очікує приватної розмови лише тому, що платіж було доведено з нульовим розголошенням. Ці два твердження слід оцінювати окремо.

На що звернути увагу

• Маркування режиму: Перевірте, чи кожен клієнт робить видимим прямий режим із ключем виконання або проксі-маршрутизацію, перш ніж користувач надішле запити.
• Активність у головній мережі: Шукайте датовані підрахунки профінансованих нот і використання, опубліковані без порушення анонімності користувачів.
• Огляди безпеки: Ознайомтеся з обсягом незалежних оцінок, що охоплюють вихід із контракту, схеми доказів, зберігання даних клієнта та розрахунок за квитанціями.
• Контроль метаданих: Перевірте обробку IP, телеметрію, час життя ключів і збереження даних постачальником у реальних інтеграціях.
• Спори щодо оплати: Перевірте, як обробляються невдалі запити, вивільнення ліміту та оскаржені квитанції без примусового розкриття особи.

Часті запитання