zkAPI на Ethereum скрывает, кто платит за ИИ. Но модель всё равно видит запрос

Фонд Ethereum и проект Open Anonymity запустили zkAPI в основной сети Ethereum 1 октября. Пользователь может внести кредиты и доказать, что последующий запрос к API ИИ оплачен, не раскрывая платёжному серверу свою личность, а поставщику модели — адрес финансирования. Поставщик по-прежнему получает запрос. Такое разделение полезно, но это более узкое заявление о приватности, чем анонимный разговор с моделью.

Техническое объявление Фонда Ethereum необычно чётко обозначает границу. Доказательство скрывает, какая нота оплачивает использование, в то время как поставщик управляет моделью и видит запрос. В нём также указываются сетевые метаданные и содержимое запроса как остающиеся источники корреляции. Это важно, потому что фразу «приватные платежи за ИИ» легко воспринять как «приватное использование ИИ».

По словам Фонда, проект работает: есть публичный репозиторий GitHub, хранилище в основной сети с кредитами USDC и демонстрационный интерфейс чата, ссылка на который есть в объявлении. Живое развёртывание подтверждает наличие кода и контракта для проверки. Оно не подтверждает принятие пользователями, объём аудита безопасности, анонимность в любой конфигурации клиента или защиту от поставщика, который узнаёт стиль письма и документы пользователя.

Один депозит заменяет вереницу счетов за API

Большинство коммерческих API ИИ связывают ключ с учётной записью и способом оплаты. Поставщик может сопоставлять запросы с платёжной идентификацией, даже если пользователь никогда не подписывает запрос именем. zkAPI вводит финансируемое хранилище и приватную ноту. Пользователь вносит поддерживаемые активы, такие как USDC, в контракт; программное обеспечение на машине пользователя затем создаёт доказательство с нулевым разглашением того, что действительная профинансированная нота может оплатить ограниченное использование, не раскрывая, какая это нота.

Платёжный сервер проверяет доказательство и выдаёт краткосрочный ключ API с ограничением по сумме в долларах. В режиме прямого ключа времени выполнения, описанном Фондом, запросы идут с устройства пользователя к поставщику ИИ с этим ключом. После сессии подписанная квитанция фиксирует измеренное использование, и приватный баланс списывается за использованную сумму, а не просто за зарезервированный лимит. Одно доказательство может покрывать сессию из нескольких запросов.

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

Существует более простой прокси-режим. В нём сервер zkAPI перенаправляет запрос пользователя поставщику модели. По словам Фонда, этот сервер может видеть трафик. Человеку, выбирающему между режимами, следует спросить, какой стороне он доверяет контент, а какой нужно только проверить доказательство оплаты. Локальный интерфейс, который выглядит одинаково, может под капотом маршрутизировать запросы по-разному.

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

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

Пользователь не получает бесплатного использования, скрывая личность. Сервер должен проверить доказательство траты и зарезервировать лимит, прежде чем выдать временный ключ. Провайдер измеряет использование. Квитанция урегулирует фактическую сумму после истечения срока действия ключа. Если зарезервирован лимит в $10, а услуги потреблено на $3, система должна списать $3, а не $10. Этот пример иллюстрирует логику резервирования, а не опубликованную цену или гарантированный минимум. Оставшийся баланс остаётся в приватной записке в соответствии с правилами реализации.

Нуллификатор решает конкретную проблему: попытку потратить одну записку дважды. Он не доказывает, что модель ИИ ответила точно, не сохраняет конфиденциальность запроса и не мешает провайдеру записывать запросы. Доказательство с нулевым разглашением — это утверждение о действительности транзакции в рамках определённой схемы. Его гарантии не распространяются автоматически на другие данные, сопровождающие транзакцию.

Путь выхода из контракта также важен. Фонд утверждает, что пользователь может закрыть баланс хранилища и вывести средства в сети, даже если серверы zkAPI исчезнут. Это позволяет избежать того, чтобы платёжный сервер был единственным способом вернуть средства. Это не делает выходы невидимыми: Ethereum записывает соответствующие транзакции. Возможность выхода пользователя зависит от контракта и владения необходимым секретом, и благоразумный пользователь должен проверить адреса развёртывания, разрешения и любые независимые проверки, прежде чем доверять механизму большую ценность.

Провайдер может распознать то, что доказательство не может раскрыть

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

Сетевые метаданные предоставляют другой путь. В режиме runtime-key провайдер может видеть IP-адрес, с которого подключается устройство. В режиме прокси посредник может видеть трафик и, возможно, информацию об исходной сети. Фонд явно заявляет, что стабильный IP и коррелированное время могут ослабить приватность, и предлагает инструменты сетевой анонимности для пользователей, ищущих более сильную защиту. VPN или Tor могут изменить сетевой путь, но ни один из них не удаляет имя, введённое в запрос.

Существует трёхуровневый тест приватности. Приватность платежа спрашивает, можно ли связать счёт с запиской о финансировании или человеком. Сетевая приватность спрашивает, может ли сервис идентифицировать соединение по IP, времени или характеристикам устройства. Приватность содержимого спрашивает, может ли кто-либо, управляющий моделью, прочитать запрос. zkAPI предназначен главным образом для первого уровня. Он может уменьшить связь на уровне аккаунта между журналом использования провайдера модели и источником платежа пользователя. Он не обеспечивает два других уровня сам по себе.

Это не дефект, скрытый в мелком шрифте. В собственном объявлении проекта сказано, что провайдер видит запросы. Честное описание сильнее, чем раздутый лозунг об анонимности, потому что оно говорит пользователям, на чём сосредоточить дополнительные меры предосторожности. Человек, использующий сервис для общих вопросов, может получить значительную несвязываемость платежей. Человек, вставляющий подписанный контракт и полное имя, раскрыл личность в содержимом независимо от платёжного маршрута.

Множество анонимности может быть малым даже при надёжных доказательствах

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

Дерево из 32 уровней — это параметр ёмкости в дизайне, а не доказательство того, что миллиарды различных пользователей сегодня смешивают свои кредиты. У недавно запущенного сервиса может быть небольшой набор профинансированных записок. Чтобы оценить анонимность на практике, нужно было бы иметь датированные подсчёты депозитов, различных активных записок и моделей вывода средств с агрегацией, учитывающей приватность. Репозиторий или теоретический размер дерева не дают этих чисел.

Предположим, что для сессии доступны десять нот, и публичные факты исключают девять из них. Математическое доказательство всё ещё может идеально скрывать своего свидетеля, в то время как окружающая информация указывает на десятую. Этот игрушечный пример объясняет, почему размер и разнообразие правдоподобного множества важнее, чем необработанное количество транзакций в хранилище. Стандартизация сумм, отложенная активность и регулярное использование могут помочь, но поведение пользователя и дизайн сервиса определяют, что доступно для корреляции.

У поставщика ИИ существует второй вид множества: группа запросов, использующих краткосрочный ключ. Ключ может связывать запросы в рамках своей ограниченной сессии, даже если он не может идентифицировать депозит. Это присуще измерению сессии. Если клиент повторно отправляет одни и те же документы в последующих сессиях, поставщик может связать их и через разные ключи. Скрытие платёжного аккаунта ценно, но оно не заставляет поставщика забыть то, что он прочитал.

Нарисуйте записи для одной сессии, не предполагая, что кто-то жульничает. Ethereum записывает транзакцию депозита и адрес её финансирования. Устройство пользователя хранит секрет ноты и отправляет доказательство на платёжный сервер. Сервер записывает действительность доказательства, нуллификатор и событие выпуска для ограниченного ключа. Поставщик модели записывает этот ключ, запросы и использование, за которое он выставил счёт. Подписанная квитанция связывает ключ с измеренной суммой. При закрытии контракт может записать выход. У каждой стороны есть частичный реестр.

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

Упражнение с реестром также выявляет важность времени жизни ключей. Учётные данные сессии намеренно группируют все запросы, которые они авторизуют, чтобы поставщик мог их измерить. Лимит в $50 может позволить множество подсказок под одним ключом. Более низкие лимиты и более короткие сессии могут уменьшить объём контента, связываемого в рамках одних учётных данных, но они требуют более частых доказательств и могут увеличить задержку или расходы. Не существует универсально приватной настройки; пользователь и поставщик выбирают между удобством, стоимостью и возможностью связывания.

Публичная модель угроз должна точно указывать, какие записи сохраняются и как долго. Она должна сообщать, регистрирует ли сервер исходные IP-адреса во время подачи доказательства, хранит ли он нуллификаторы бессрочно и может ли поставщик связать идентификаторы квитанций с содержимым запроса после расчёта. Удаление платёжного имени из базы данных полезно. Этого недостаточно, если постоянный идентификатор устройства тихо воссоздаёт тот же профиль.

Подписанная квитанция об использовании переносит доверие в измерение

Поставщику или серверу нужен способ взимать плату за фактически выполненную работу. В дизайне используется подписанная квитанция, связанная с краткосрочным ключом и его использованием. Это переносит центральный коммерческий вопрос на точность измерения. Если поставщик завышает количество токенов, запросов или времени, действительное доказательство оплаты не может исправить основной счёт. Подпись делает заявленную сумму трудно переписываемой впоследствии; она не устанавливает, что заявленное использование было справедливым в соответствии с тарифной сеткой поставщика.

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

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

Одним из практических тестов является намеренно прерванная сессия. Клиент получает ограниченный ключ, делает несколько запросов, теряет доступ к сети и позже переподключается. Отражает ли квитанция только доставленное использование? Может ли пользователь проверить измеренную сумму локально, не отправляя подсказку на платёжный сервер? Если сервер исчезнет, может ли пользователь получить неиспользованный баланс через контракт, как было обещано? Эти тесты выходят за рамки того, проверяется ли доказательство, и касаются того, сохраняет ли продукт обещанное разделение при сбое.

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

Согласно Фонду, контракт хранилища может проверять доказательства для операций депозита, закрытия и выхода. Ончейн-маршрут выхода важен, потому что отключение провайдера не должно оставлять средства пользователей в базе данных оператора. Контракт заменяет часть институционального доверия риском смарт-контракта. Ошибка в проверке доказательств, учёте или логике вывода может повлиять на средства, несмотря на обоснованную концепцию приватности. Работающий адрес — это доказательство развёртывания, а не аудиторский сертификат.

Публичные депозиты и выводы также имеют цену для приватности. Тот, кто знает адрес финансирования пользователя, может наблюдать, что он взаимодействовал с хранилищем. Он может не видеть, за какую сессию API было заплачено, но он видит участие и суммы. Если тот же пользователь быстро выводит необычную сумму на адрес, уже связанный с ним, часть окружающей анонимности может сократиться. Приватная заметка разрывает детерминированную связь с выставлением счетов; она не стирает публичную транзакцию финансирования.

Проект берёт начало в дизайне Ethereum Research для кредитов API с нулевым разглашением, который Фонд определяет как работу Давиде Краписа и Виталика Бутерина. Исследовательское предложение и производственная система отвечают на разные вопросы. Первое задаёт конструкцию; вторая должна обрабатывать хранение ключей, поведение фронтенда, сбои, споры по квитанциям, обновления и реальных противников. Релиз 1 октября переводит идею в тестируемое развёртывание, и это и есть соответствующий свежий крючок.

Более широкие усилия Ethereum по приватности — это не тот же продукт. Освещение Crypto.news предложенного нативного дизайна приватности касается черновика изменения протокола, тогда как zkAPI — это приложение, работающее сейчас. Недавний запуск кошелька zk.money касается приватных переводов в другой среде. Ни то, ни другое не следует приводить как доказательство того, что AI-запрос, отправленный через zkAPI, скрыт от его провайдера модели.

Заявления о приватности должны выдерживать воспроизводимый тест

Независимый рецензент мог бы создать две профинансированные заметки с несвязанных адресов, провести короткие сессии с одним и тем же провайдером модели и проверить каждый пакет и журнал, видимые клиенту, платёжному серверу и провайдеру. Рецензент должен тестировать прямые и прокси-режимы отдельно. Если платёжный сервер в прямом режиме получает запрос, это противоречит описанному разделению. Если провайдер получает адрес депозита или долговременный идентификатор платёжного аккаунта, предполагаемая несвязываемость не удалась на уровне интеграции, даже если схема доказательства корректна.

Более сложный тест — статистический. Проведите множество сессий с разными суммами и временем, затем спросите, может ли сторона, располагающая только публичными данными блокчейна и серверными журналами, соотнести финансирование и использование лучше, чем случайно. Эталон зависит от фактического набора анонимности и того, какие вспомогательные данные есть у противника. Успешная небольшая лабораторная демонстрация не устанавливает приватность при крошечной производственной базе пользователей, но она создаёт метод для измерения того, улучшаются ли развёртывания со временем.

Тест содержимого прост и отрезвляющ. Отправьте один и тот же характерный документ под двумя свежими ключами сессии. Если провайдер может распознать его в обоих, несвязываемость платежа не дала пользователю несвязываемости разговора. Заявление о платеже следует оценивать по первым двум тестам; заявление об анонимном использовании AI также должно выдерживать третий. Публикация режима, модели угроз и результатов позволила бы пользователям выбрать правильный инструмент для их фактической проблемы.

Самый сильный аргумент — отвязать выставление счетов от полезного содержимого

Есть много законных причин задать AI-провайдеру чувствительный вопрос, не создавая постоянное досье использования, привязанное к аккаунту. Журналист, тестирующий публичный документ, исследователь, изучающий спорную гипотезу, или разработчик, использующий API внутри агента, могут хотеть, чтобы провайдер видел текущий запрос, но при этом разорвать долговременную платёжную связь. Дизайн zkAPI отвечает на эту более узкую потребность. Он также позволяет машине платить за измеряемые услуги без управления долгоживущим личным аккаунтом для каждого запроса.

Аргумент против чрезмерных заявлений столь же силён. Провайдеры по-прежнему видят запросы, и некоторые запросы неизбежно раскрывают личность. Предприятию со строгими требованиями к конфиденциальности могут понадобиться договорные меры контроля, локальные модели или конфиденциальные вычисления, а также несвязываемость платежей. Некоторые пользователи могут предпочесть обычный аккаунт с устоявшейся поддержкой и возвратами вместо криптографического платёжного слоя, механизмы разрешения споров которого всё ещё незрелы. Выбор зависит от фактической модели угроз.

Обсуждаемая crypto.news дорожная карта Ethereum по конфиденциальности рассматривает конфиденциальность как более широкую цель. Дорожная карта не дарует свои будущие средства защиты этому приложению сегодня. Пользователь ИИ должен оценивать действующий путь клиента и провайдера, который фактически обрабатывает запрос.

Crypto.news объяснил более узкую механику доказательств с нулевым разглашением в отдельном вводном материале. Доказательство раскрывает определённый факт, не раскрывая свидетеля; это не универсальный плащ-невидимка. Его интервью об инфраструктуре Ethereum, ориентированной на конфиденциальность, подчёркивает, как разные продукты защищают разные данные. Полезный вопрос для zkAPI — какая сторона видит какую запись на каждом шаге, а не то, соответствует ли проект широкому слову «приватный».

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

Фонд перечисляет платежи API между машинами как возможное применение. Автономный агент может отправить сотни вызовов, используя одну финансируемую ноту или множество коротких сессий. Если его задачи содержат записи клиентов, поставщик модели может узнать об этих клиентах, даже пока источник платежей агента остаётся приватным. Выгода конфиденциальности принадлежит платёжной связи; её не следует передавать каждому субъекту, указанному в запросе.

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

Когда несколько агентов совместно используют один пул кредитов, внутренний учёт может стать скрытой системой выставления счетов. Оператору может потребоваться распределять расходы между командами или клиентами, не экспортируя их идентификационные данные поставщику API. Это можно сделать с помощью локального реестра, но он создаёт ещё один конфиденциальный набор данных, который нужно защищать. Переход от выставления счетов по аккаунту к выставлению счетов по ноте не отменяет сверку; он перемещает её.

Наконец, агент может выдать себя своим поведением. Повторяющиеся вызовы по одному и тому же расписанию, с одними и теми же заголовками инструментов и одними и теми же фразами, специфичными для задачи, могут сделать отдельные недолговечные ключи легко кластеризуемыми. Скрытие ончейн-ноты финансирования полезно против наблюдения за платежами. Это не защита от поведенческого отпечатка, который агент отправляет с каждым запросом.

Развёртывание всё ещё нуждается в аудите модели угроз

По состоянию на 2 октября Фонд заявляет, что код, сервер, клиент и хранилище работают. В посте указаны контракт в основной сети и репозиторий. В объявлении не публикуется окончательное число пользователей, проверенная общая стоимость, все сторонние интеграции или гарантия того, что каждая конфигурация клиента использует режим прямого ключа времени выполнения. Эта функция не заявляет о нарушении или неправомерном поведении со стороны названного провайдера. Она определяет информацию, которую каждая сторона должна получить, и дополнительные утечки, которые признают авторы проекта.

Внешняя оценка должна проверить настройки клиента по умолчанию и исходящие соединения. Отправляет ли браузерная демонстрация телеметрию на несвязанные домены? Сохраняет ли локальный клиент ключи или журналы запросов? Может ли платёжный сервер объединить временные метки выпуска с сетевыми адресами? Связываются ли квитанции между сессиями? Как управляются обновления схем и контрактов? Доказательство может быть математически безупречным, в то время как пользовательский интерфейс случайно выдаёт личность, которую он должен был разделить.

Та же оценка должна проверить точку зрения поставщика ИИ. Он увидит обрабатываемое содержимое и учётные данные сессии. Он может собирать метаданные устройства или сети в зависимости от пути запроса. Политика хранения данных провайдера и любые договорные условия остаются центральными. Платёжный уровень может уменьшить один источник идентифицирующей информации, не ограничивая все остальные.

zkAPI делает реальный шаг вперёд, если он надёжно предотвращает привязку полезных запросов поставщиком модели к платёжному аккаунту, сохраняя при этом возможность пользователя вернуть средства. Он разочарует тех, кто ожидает конфиденциального разговора только потому, что платёж был подтверждён с нулевым разглашением. Эти два утверждения следует оценивать отдельно.

На что обратить внимание

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

Часто задаваемые вопросы