3 поста с тегом "cryptographic proofs"

Каждый раз, когда вы обращаетесь к ChatGPT, Claude или Gemini, вы доверяете невидимому черному ящику. Версия модели? Неизвестна. Точные веса? Проприетарны. Был ли результат сгенерирован той моделью, о которой вы думаете, или незаметно обновленным вариантом? Проверить невозможно. Для обычных пользователей, спрашивающих о рецептах или фактах, эта непрозрачность просто досадна. Для высокорискового принятия решений с помощью ИИ — алгоритмов финансовой торговли, медицинской диагностики, анализа юридических контрактов — это фундаментальный кризис доверия.

Gensyn's Judge, запущенный в конце 2025 года и выходящий в промышленную эксплуатацию в 2026 году, предлагает радикальную альтернативу: криптографически проверяемую оценку ИИ, где каждый инференс воспроизводим с точностью до бита. Вместо того чтобы доверять OpenAI или Anthropic в предоставлении верной модели, Judge позволяет любому проверить, что конкретная, заранее согласованная модель ИИ была выполнена детерминированно на реальных входных данных — с использованием криптографических доказательств, гарантирующих, что результаты не могут быть подделаны.

Техническим прорывом стала Verde, система верификации Gensyn, которая устраняет недетерминированность вычислений с плавающей точкой — бич воспроизводимости ИИ. Обеспечивая побитово-точные вычисления на разных устройствах, Verde гарантирует, что запуск одной и той же модели на NVIDIA A100 в Лондоне и на AMD MI250 в Токио даст идентичные результаты, доказуемые ончейн. Это открывает возможности для проверяемого ИИ в децентрализованных финансах, автономных агентах и любых приложениях, где прозрачность не является опцией — это вопрос выживания.

Проблема непрозрачных API: доверие без проверки​

Индустрия ИИ работает на API. Разработчики интегрируют GPT-4 от OpenAI, Claude от Anthropic или Gemini от Google через REST-эндпоинты, отправляя промпты и получая ответы. Но эти API фундаментально непрозрачны:

Неопределенность версии: когда вы вызываете gpt-4, какую именно версию вы получаете? GPT-4-0314? GPT-4-0613? Незаметно обновленный вариант? Провайдеры часто выпускают патчи без публичных анонсов, меняя поведение модели в одночасье.

Отсутствие аудиторского следа: ответы API не содержат криптографического доказательства того, какая модель их сгенерировала. Если OpenAI предоставляет цензурированный или предвзятый вариант для определенных регионов или клиентов, у пользователей нет способа это обнаружить.

Скрытая деградация: провайдеры могут «лоботомизировать» модели для снижения затрат — ухудшая качество инференса при сохранении того же контракта API. Пользователи сообщают, что GPT-4 со временем становится «глупее», но без прозрачного версионирования такие утверждения остаются лишь предположениями.

Недетерминированные выходные данные: даже два запроса к одной и той же модели с идентичными входными данными могут дать разные результаты из-за настроек температуры, батчинга или аппаратных ошибок округления чисел с плавающей точкой. Это делает аудит невозможным — как проверить корректность, если результаты невоспроизводимы?

Для повседневных приложений эти проблемы — лишь неудобства. Для принятия высокорисковых решений они являются блокирующими факторами. Рассмотрим примеры:

Алгоритмическая торговля: хедж-фонд развертывает ИИ-агента, управляющего позициями в DeFi на сумму 50 миллионов долларов. Агент полагается на GPT-4 для анализа рыночных настроений на основе постов в X. Если модель незаметно обновится в середине торговой сессии, показатели настроений изменятся непредсказуемо, что приведет к непреднамеренным ликвидациям. У фонда нет доказательств некорректного поведения модели; логи OpenAI не подлежат публичному аудиту.

Медицинская диагностика: больница использует модель ИИ для назначения лечения рака. Регламенты требуют, чтобы врачи документировали процессы принятия решений. Но если версию модели ИИ невозможно проверить, аудиторский след будет неполным. Иск о врачебной ошибке может зависеть от доказательства того, какая именно модель сгенерировала рекомендацию — что невозможно в случае с непрозрачными API.

Управление DAO: децентрализованная организация использует ИИ-агента для голосования по предложениям казначейства. Члены сообщества требуют доказательств того, что агент использовал утвержденную модель, а не модифицированный вариант, способствующий определенным результатам. Без криптографической проверки голосование не обладает легитимностью.

Это тот самый разрыв доверия, на который нацелен Gensyn: поскольку ИИ становится неотъемлемой частью процесса принятия критически важных решений, невозможность проверить подлинность и поведение модели становится «фундаментальным препятствием для развертывания агентного ИИ в средах с высокими рисками».

Judge: протокол верифицируемой оценки ИИ​

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

1. Фиксация модели: участники согласовывают модель ИИ — её архитектуру, веса и конфигурацию инференса. Эта модель хешируется и фиксируется ончейн. Хеш служит криптографическим отпечатком: любое отклонение от согласованной модели дает другой хеш.

2. Детерминированное выполнение: Judge запускает модель, используя Gensyn's Reproducible Runtime, который гарантирует побитово-точную воспроизводимость на разных устройствах. Это устраняет недетерминированность вычислений с плавающей точкой — критически важную инновацию, которую мы рассмотрим чуть позже.

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

4. Период оспаривания: любой может оспорить результат, повторно выполнив модель независимо. Если результат отличается, подается доказательство мошенничества (fraud proof). Механизм делегирования с арбитражем (refereed delegation mechanism) системы Verde точно определяет оператора в вычислительном графе, на котором разошлись результаты.

5. Слэшинг за мошенничество: если оспаривающий докажет, что Judge выдал неверные результаты, первоначальный исполнитель штрафуется (слэшинг застейканных токенов). Это выстраивает экономические стимулы: исполнители максимизируют прибыль, выполняя модели корректно.

Judge превращает оценку ИИ из принципа «доверьтесь поставщику API» в принцип «проверьте криптографическое доказательство». Поведение модели становится публичным, проверяемым и обязательным к исполнению — оно больше не скрыто за проприетарными эндпоинтами.

Verde: Устранение недетерминизма вычислений с плавающей точкой​

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

Неассоциативность: Сложение с плавающей точкой не является ассоциативным. (a + b) + c может дать результат, отличный от a + (b + c), из-за ошибок округления. GPU параллельно суммируют данные на тысячах ядер, и порядок накопления промежуточных сумм варьируется в зависимости от оборудования и версии драйвера.

Вариативность планирования ядер: Ядра GPU (например, для матричного умножения или механизма внимания) могут выполняться в разном порядке в зависимости от рабочей нагрузки, оптимизаций драйвера или архитектуры оборудования. Даже запуск одной и той же модели на одном и том же GPU дважды может дать разные результаты, если планирование ядер отличается.

Зависимость от размера пакета (batch size): Исследования показали, что инференс LLM является недетерминированным на системном уровне, поскольку результат зависит от размера пакета. Многие ядра (matmul, RMSNorm, attention) меняют числовой результат в зависимости от того, сколько образцов обрабатывается одновременно — инференс с размером пакета 1 дает иные значения, чем те же входные данные в пакете из 8.

Эти проблемы делают стандартные модели ИИ непригодными для проверки в блокчейне. Если два валидатора повторно запустят один и тот же инференс и получат немного разные результаты, кто из них прав? Без детерминизма консенсус невозможен.

Verde решает эту проблему с помощью RepOps (Reproducible Operators) — библиотеки, которая устраняет аппаратный недетерминизм путем контроля порядка операций с плавающей точкой на всех устройствах. Вот как это работает:

Канонический порядок редукции: RepOps обеспечивает детерминированный порядок суммирования частичных результатов в таких операциях, как матричное умножение. Вместо того чтобы позволять планировщику GPU принимать решение, RepOps явно указывает: «суммировать столбец 0, затем столбец 1, затем столбец 2...» на любом оборудовании. Это гарантирует, что (a + b) + c всегда вычисляется в одной и той же последовательности.

Кастомные ядра CUDA: Gensyn разработала оптимизированные ядра, в которых воспроизводимость приоритетнее чистой скорости. Матричные умножения RepOps требуют менее 30% накладных расходов по сравнению со стандартным cuBLAS — разумный компромисс ради детерминизма.

Фиксация версий драйверов: Verde использует GPU-драйверы с фиксированными версиями и канонические конфигурации, гарантируя, что одна и та же модель, исполняемая на разном оборудовании, выдает идентичные побитовые результаты. Модель, работающая на NVIDIA A100 в одном дата-центре, побитово совпадает с результатом AMD MI250 в другом.

Это прорыв, который делает возможной проверку в системе Judge: побитовая воспроизводимость означает, что валидаторы могут независимо подтверждать результаты, не доверяя исполнителям. Если хеш совпадает, инференс верен — это математически доказуемо.

Арбитражное делегирование: эффективная проверка без полного пересчета​

Даже при детерминированном исполнении наивная проверка инференса ИИ обходится дорого. Модели с 70 миллиардами параметров, генерирующей 1 000 токенов, может потребоваться 10 GPU-часов. Если валидаторы должны заново запускать каждый инференс для проверки правильности, стоимость проверки будет равна стоимости исполнения, что лишает децентрализацию смысла.

Механизм арбитражного делегирования Verde делает проверку экспоненциально дешевле:

Несколько недоверенных исполнителей: Вместо одного исполнителя Judge назначает задачи нескольким независимым провайдерам. Каждый запускает один и тот же инференс и отправляет результаты.

Расхождения инициируют расследование: Если все исполнители согласны, результат принимается — дальнейшая проверка не требуется. Если результаты расходятся, Verde инициирует состязательную игру (challenge game).

Бинарный поиск по графу вычислений: Verde не пересчитывает весь инференс. Вместо этого выполняется бинарный поиск по вычислительному графу модели, чтобы найти первый оператор, где результаты расходятся. Это позволяет точно определить конкретный слой (например, «слой внимания 47, голова 8»), вызвавший расхождение.

Минимальные вычисления арбитра: Арбитр (которым может быть смарт-контракт или валидатор с ограниченными вычислительными ресурсами) проверяет только спорный оператор, а не весь прямой проход. Для модели с 70 млрд параметров и 80 слоями это сокращает проверку до анализа примерно 7 слоев (log₂ 80) в худшем случае.

Этот подход более чем на 1 350% эффективнее, чем наивная репликация (где каждый валидатор пересчитывает всё). Gensyn объединяет криптографические доказательства, теорию игр и оптимизированные процессы, чтобы гарантировать правильное исполнение без избыточных вычислений.

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

Принятие решений в ИИ с высокими ставками: почему важна прозрачность​

Целевой рынок Judge — это не простые чат-боты, а приложения, где верифицируемость является не просто приятным дополнением, а нормативным или экономическим требованием. Вот сценарии, в которых непрозрачные API терпят катастрофический крах:

Децентрализованные финансы (DeFi): Автономные торговые агенты управляют активами на миллиарды долларов. Если агент использует модель ИИ для принятия решения о ребалансировке портфеля, пользователям нужны доказательства того, что модель не была подделана. Judge обеспечивает ончейн-проверку: агент фиксирует хеш конкретной модели, совершает сделки на основе её результатов, и любой может оспорить логику принятия решений. Такая прозрачность предотвращает рагпуллы (rug pulls), когда злоумышленники заявляют: «ИИ приказал мне ликвидировать средства», не имея доказательств.

Соблюдение нормативных требований: Финансовые институты, использующие ИИ для кредитного скоринга, обнаружения мошенничества или борьбы с отмыванием денег (AML), проходят аудит. Регуляторы требуют объяснений: «Почему модель отметила эту транзакцию?». Непрозрачные API не оставляют аудиторского следа. Judge создает неизменяемую запись версии модели, входных и выходных данных, удовлетворяя требования комплаенса.

Алгоритмическое управление: Децентрализованные автономные организации (DAO) используют агентов ИИ для предложения или голосования по решениям управления. Члены сообщества должны убедиться, что агент использовал утвержденную модель, а не взломанный вариант. С помощью Judge DAO кодирует хеш модели в своем смарт-контракте, и каждое решение включает криптографическое доказательство правильности.

Медицинский и юридический ИИ: Системы здравоохранения и права требуют подотчетности. Врачу, диагностирующему рак с помощью ИИ, необходимо задокументировать точную версию используемой модели. Юристу, составляющему контракты с ИИ, нужно доказать, что результат получен от проверенной, непредвзятой модели. Ончейн-аудит Judge предоставляет такие доказательства.

Рынки предсказаний и оракулы: Проекты вроде Polymarket используют ИИ для разрешения исходов пари (например, «Произойдет ли это событие?»). Если решение зависит от модели ИИ, анализирующей новостные статьи, участникам нужны доказательства того, что моделью не манипулировали. Judge верифицирует инференс ИИ-оракула, предотвращая споры.

В каждом из этих случаев общая нить такова: доверия без прозрачности недостаточно. Как отмечает VeritasChain, системам ИИ нужны «криптографические бортовые самописцы» — неизменяемые логи, доказывающие произошедшее в случае возникновения споров.

Альтернатива на основе доказательств с нулевым разглашением: сравнение Verde и ZKML​

Judge — не единственный подход к верифицируемому ИИ. Машинное обучение с нулевым разглашением (ZKML) достигает аналогичных целей с помощью zk-SNARKs: криптографических доказательств того, что вычисление было выполнено правильно, без раскрытия входных данных или весов модели.

Как Verde соотносится с ZKML?

Стоимость верификации: ZKML требует примерно в 1 000 раз больше вычислений, чем исходный инференс, для генерации доказательств (оценки исследователей). Модели с 70 миллиардами параметров, требующей 10 GPU-часов для инференса, может потребоваться 10 000 GPU-часов для создания доказательства. Арбитражное делегирование Verde логарифмично: проверка примерно 7 слоев вместо 80 дает 10-кратное сокращение, а не 1 000-кратное увеличение.

Сложность прувера: ZKML требует специализированного оборудования (например, кастомных ASIC для схем zk-SNARK) для эффективной генерации доказательств. Verde работает на стандартных GPU — участвовать может любой майнер с игровым ПК.

Компромиссы в конфиденциальности: Сильной стороной ZKML является приватность — доказательства ничего не раскрывают о входных данных или весах модели. Детерминированное выполнение Verde прозрачно: входные и выходные данные являются публичными (хотя веса могут быть зашифрованы). Для принятия важных решений прозрачность часто желательна. DAO, голосующее за распределение средств казначейства, хочет иметь публичные аудиторские следы, а не скрытые доказательства.

Масштаб доказательства: ZKML практически ограничен инференсом — доказательство обучения неосуществимо при текущих вычислительных затратах. Verde поддерживает верификацию как инференса, так и обучения (более широкий протокол Gensyn верифицирует распределенное обучение).

Реальное внедрение: Проекты ZKML, такие как Modulus Labs, добились прорывов (верификация моделей с 18 млн параметров ончейн), но остаются ограниченными небольшими моделями. Детерминированная среда выполнения Verde обрабатывает модели с более чем 70 млрд параметров в промышленной эксплуатации.

ZKML превосходит в тех случаях, когда конфиденциальность имеет первостепенное значение — например, при верификации биометрической аутентификации (Worldcoin) без раскрытия сканов радужной оболочки глаза. Verde лучше подходит там, где целью является прозрачность — доказательство того, что конкретная публичная модель была выполнена правильно. Оба подхода дополняют друг друга, а не конкурируют.

Экосистема Gensyn: от Judge до децентрализованного обучения​

Judge является одним из компонентов более широкого видения Gensyn: децентрализованной сети для вычислений машинного обучения. Протокол включает в себя:

Уровень исполнения: Согласованное выполнение ML на гетерогенном оборудовании (потребительские GPU, корпоративные кластеры, граничные устройства). Gensyn стандартизирует рабочие нагрузки инференса и обучения, обеспечивая совместимость.

Уровень верификации (Verde): Проверка без доверия (trustless) с использованием арбитражного делегирования. Нечестные исполнители обнаруживаются и штрафуются.

Peer-to-peer коммуникация: Распределение рабочей нагрузки между устройствами без централизованной координации. Майнеры получают задачи, выполняют их и отправляют доказательства напрямую в блокчейн.

Децентрализованная координация: Смарт-контракты на роллапе Ethereum идентифицируют участников, распределяют задачи и обрабатывают платежи без необходимости получения разрешений (permissionless).

Публичный тестнет Gensyn был запущен в марте 2025 года, а запуск мейннета запланирован на 2026 год. Публичная продажа токенов $AI состоялась в декабре 2025 года, установив экономические стимулы для майнеров и валидаторов.

Judge вписывается в эту экосистему как уровень оценки: в то время как основной протокол Gensyn отвечает за обучение и инференс, Judge гарантирует верифицируемость этих результатов. Это создает «маховик»:

Разработчики обучают модели в децентрализованной сети Gensyn (что дешевле, чем AWS, благодаря использованию недоиспользуемых потребительских GPU).

Модели развертываются с использованием Judge, гарантирующим целостность оценки. Приложения потребляют инференс через API Gensyn, но, в отличие от OpenAI, каждый результат включает криптографическое доказательство.

Валидаторы зарабатывают вознаграждения, проверяя доказательства и выявляя мошенничество, что согласовывает экономические стимулы с безопасностью сети.

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

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

Проблемы и открытые вопросы​

Подход Judge является революционным, но остается ряд проблем:

Накладные расходы на производительность: Замедление RepOps на 30 % приемлемо для верификации, но если каждый инференс должен выполняться детерминированно, приложения, чувствительные к задержкам (высокочастотная торговля, автономные транспортные средства), могут предпочесть более быстрые, неверифицируемые альтернативы. Дорожная карта Gensyn, вероятно, включает дальнейшую оптимизацию RepOps, но существует фундаментальный компромисс между скоростью и детерминизмом.

Фрагментация версий драйверов: Verde предполагает использование драйверов фиксированных версий, но производители GPU постоянно выпускают обновления. Если одни майнеры используют CUDA 12.4, а другие — 12.5, побитовая воспроизводимость нарушается. Gensyn должна обеспечить строгое управление версиями, что усложняет процесс подключения майнеров.

Секретность весов модели: Прозрачность Judge является преимуществом для публичных моделей, но недостатком для проприетарных. Если хедж-фонд обучает ценную торговую модель, ее развертывание на Judge раскрывает веса конкурентам (через ончейн-обязательство). Альтернативы на базе ZKML могут быть предпочтительнее для секретных моделей, что говорит о том, что Judge ориентирован на открытые или полуоткрытые приложения ИИ.

Задержка разрешения споров: Если челленджер заявляет о мошенничестве, разрешение спора с помощью бинарного поиска требует нескольких ончейн-транзакций (каждый раунд сужает область поиска). Высокочастотные приложения не могут ждать финализации часами. Gensyn может внедрить оптимистичную верификацию (предположение о правильности, если нет оспаривания в течение определенного окна), чтобы сократить задержки.

Устойчивость к атаке Сивиллы при арбитражном делегировании: Если несколько исполнителей должны прийти к согласию, что мешает одной организации контролировать всех исполнителей через подставные личности? Gensyn, вероятно, использует выбор на основе стейка (валидаторы с высокой репутацией выбираются предпочтительно) в сочетании со слэшингом для предотвращения сговора, но экономические пороги должны быть тщательно откалиброваны.

Это не непреодолимые препятствия, а инженерные задачи. Основная инновация (детерминированный ИИ + криптографическая верификация) надежна. Детали реализации будут совершенствоваться по мере перехода от тестнета к мейннету.

Путь к верифицируемому ИИ: пути внедрения и соответствие рынку​

Успех Judge зависит от принятия. Какие приложения первыми внедрят верифицируемый ИИ?

DeFi-протоколы с автономными агентами: DAO Aave, Compound или Uniswap могли бы интегрировать агентов, верифицированных с помощью Judge, для управления казначейством. Сообщество голосует за утверждение хэша модели, и все решения агентов включают доказательства. Такая прозрачность укрепляет доверие, что критически важно для легитимности DeFi.

Рынки предсказаний и оракулы: Платформы вроде Polymarket или Chainlink могли бы использовать Judge для разрешения ставок или предоставления ценовых фидов. Модели ИИ, анализирующие настроения, новости или ончейн-активность, будут выдавать верифицируемые результаты, что исключит споры о манипулировании оракулами.

Децентрализованная идентификация и KYC: Проекты, требующие верификации личности на базе ИИ (оценка возраста по селфи, проверка подлинности документов), получают выгоду от аудиторского следа Judge. Регуляторы принимают криптографические доказательства соответствия, не доверяя централизованным провайдерам идентификации.

Модерация контента для социальных сетей: Децентрализованные социальные сети (Farcaster, Lens Protocol) могли бы развернуть модераторов на базе ИИ, верифицированных Judge. Члены сообщества смогут убедиться, что модель модерации не является предвзятой или подверженной цензуре, что гарантирует нейтральность платформы.

Платформы AI-as-a-Service (ИИ как услуга): Разработчики, создающие ИИ-приложения, могут предлагать «верифицируемый инференс» как премиальную функцию. Пользователи будут доплачивать за доказательства, что позволит отличать такие сервисы от непрозрачных альтернатив.

Общая черта: приложения, в которых доверие обходится дорого (из-за регулирования, децентрализации или высоких ставок), а стоимость верификации приемлема (по сравнению с ценностью определенности).

Judge не заменит OpenAI для потребительских чат-ботов — пользователям не важно, верифицируем ли GPT-4, когда они ищут идеи для рецептов. Но для финансовых алгоритмов, медицинских инструментов и систем управления верифицируемый ИИ — это будущее.

Верифицируемость как новый стандарт​

Judge от Gensyn представляет собой смену парадигмы: оценка ИИ переходит от принципа «доверяй провайдеру» к принципу «проверяй доказательство». Технический фундамент — побитово точная воспроизводимость через Verde, эффективная проверка через реферируемое делегирование и ончейн-журналы аудита — делает этот переход практическим, а не просто амбициозным.

Последствия выходят далеко за пределы Gensyn. Если верифицируемый ИИ станет стандартом, централизованные провайдеры потеряют свои конкурентные преимущества. Ценностное предложение OpenAI — это не только возможности GPT-4, но и удобство отсутствия необходимости управлять инфраструктурой. Но если Gensyn докажет, что децентрализованный ИИ может сравниться с централизованным по производительности, обладая при этом дополнительной верифицируемостью, у разработчиков не будет причин привязываться к проприетарным API.

Гонка началась. ZKML-проекты (Modulus Labs, биометрическая система Worldcoin) делают ставку на доказательства с нулевым разглашением. Детерминированные среды выполнения (Verde от Gensyn, EigenAI) ставят на воспроизводимость. Оптимистичные подходы (блокчейн ИИ-оракулы) полагаются на доказательства мошенничества (fraud proofs). У каждого пути есть свои компромиссы, но цель одна: системы ИИ, в которых результаты доказуемы, а не просто правдоподобны.

Для принятия решений с высокими ставками это не опция, а необходимость. Регуляторы не примут аргумент «просто поверьте нам» от поставщиков ИИ в финансах, здравоохранении или юриспруденции. DAO не будут делегировать управление казначейством агентам, работающим по принципу «черного ящика». И по мере того как автономные системы ИИ становятся мощнее, общественность будет требовать прозрачности.

Judge — это первая готовая к эксплуатации система, выполняющая это обещание. Тестнет запущен. Криптографические основы надежны. Рынок — с 27 млрд $ в крипто-активах ИИ-агентов, миллиардами активов в DeFi под управлением алгоритмов и растущим регуляторным давлением — готов.

Эра непрозрачных ИИ-API заканчивается. Начинается эпоха верифицируемого интеллекта. И Judge от Gensyn указывает путь.

---

Источники:

• Introducing Judge | Gensyn Blog
• Gensyn launches verifiable AI evaluation system Judge | Bitget News
• Verde Verification System In Production | Gensyn
• Verde: a verification system for machine learning over untrusted nodes | Gensyn
• Verde: Verification via Refereed Delegation for Machine Learning Programs | arXiv
• EigenAI: Deterministic Inference, Verifiable Results | arXiv
• Deterministic Verification Architecture for AI Systems | Medium
• The Gensyn Protocol | Gensyn Docs
• Gensyn | the network for machine intelligence
• Gensyn Public Testnet | Gensyn Docs
• ZKML: Verifiable Machine Learning using Zero-Knowledge Proof | Kudelski Security
• The Verification Imperative: Why AI Trading Systems Need Cryptographic Flight Recorders | Medium
• Verifiable AI Agents: A Cryptographic Approach to Creating a Transparent Financial Ecosystem | CoinCentral
• A Framework for Cryptographic Verifiability of End-to-End AI Pipelines | arXiv

2 февраля 2026 года экономика ИИ-агентов сделала важный шаг вперед. Компания Nillion запустила Blacklight — уровень верификации, реализующий стандарт ERC-8004, чтобы решить один из самых насущных вопросов блокчейна: как доверять ИИ-агенту, которого вы никогда не встречали?

Ответом является не просто показатель репутации или централизованный реестр. Это пятиэтапный процесс верификации, подкрепленный криптографическими доказательствами, программируемым аудитом и сетью узлов, управляемых сообществом. Поскольку автономные агенты все чаще совершают сделки, управляют казначействами и координируют кроссчейн-активность, Blacklight представляет собой инфраструктуру, обеспечивающую координацию ИИ без доверия (trustless) в масштабе.

Проблема доверия, которую ИИ-агенты не могут решить в одиночку​

Цифры говорят сами за себя. На долю ИИ-агентов сейчас приходится 30% объема торгов на Polymarket, они управляют стратегиями доходности DeFi в нескольких протоколах и автономно выполняют сложные рабочие процессы. Но существует фундаментальное препятствие: как агенты могут проверять надежность друг друга без предварительно установленных отношений?

Традиционные системы полагаются на централизованные органы, выдающие учетные данные. Обещание Web3 иное — верификация без доверия с помощью криптографии и консенсуса. Тем не менее, до появления ERC-8004 не существовало стандартизированного способа для агентов доказывать свою подлинность, отслеживать свое поведение или подтверждать логику принятия решений в блокчейне (on-chain).

Это не просто теоретическая проблема. Как объясняет Давиде Крапис, «ERC-8004 обеспечивает децентрализованное взаимодействие ИИ-агентов, устанавливает коммерцию без доверия и улучшает системы репутации на Ethereum». Без этого торговля между агентами остается ограниченной закрытыми экосистемами или требует ручного контроля, что сводит на нет саму суть автономии.

ERC-8004: Инфраструктура доверия из трех реестров​

Стандарт ERC-8004, который был запущен в основной сети Ethereum 29 января 2026 года, устанавливает модульный уровень доверия через три ончейн-реестра:

Identity Registry (Реестр идентификации): Использует ERC-721 для предоставления переносимых идентификаторов агентов. Каждый агент получает невзаимозаменяемый токен (NFT), представляющий его уникальную личность в сети, что обеспечивает узнаваемость на разных платформах и предотвращает подмену личности.

Reputation Registry (Реестр репутации): Собирает стандартизированные отзывы и рейтинги. В отличие от централизованных систем отзывов, фидбек записывается в блокчейне с криптографическими подписями, создавая неизменяемый аудиторский след. Любой желающий может просмотреть эту историю и создать собственные алгоритмы репутации.

Validation Registry (Реестр валидации): Поддерживает криптографическую и экономическую проверку работы агента. Именно здесь происходит программируемый аудит — валидаторы могут повторно выполнять вычисления, проверять доказательства с нулевым разглашением или использовать доверенные среды исполнения (TEE) для подтверждения правильности действий агента.

Гениальность ERC-8004 заключается в его универсальном дизайне. Как отмечается в технической спецификации, стандарт поддерживает различные методы валидации: «повторное выполнение задач с обеспечением залогом (вдохновленное такими системами, как EigenLayer), проверка доказательств машинного обучения с нулевым разглашением (zkML) и аттестации из доверенных сред исполнения (TEE)».

Эта гибкость имеет значение. Арбитражный агент DeFi может использовать доказательства zkML для проверки своей торговой логики, не раскрывая стратегию. Агент цепочки поставок может использовать аттестации TEE, чтобы доказать, что он правильно получил доступ к реальным данным. Агент кроссчейн-моста может полагаться на криптоэкономическую валидацию со слэшингом (slashing) для обеспечения честного исполнения.

Пятиэтапный процесс верификации Blacklight​

Реализация ERC-8004 от Nillion в Blacklight добавляет важный уровень: узлы верификации, управляемые сообществом. Вот как работает этот процесс:

1. Регистрация агента: Агент регистрирует свою личность в Identity Registry, получая NFT стандарта ERC-721. Это создает уникальный ончейн-идентификатор, привязанный к публичному ключу агента.

2. Инициация запроса на верификацию: Когда агент совершает действие, требующее подтверждения (например, выполнение сделки, перевод средств или обновление состояния), он отправляет запрос на верификацию в Blacklight.

3. Назначение комитета: Протокол Blacklight случайным образом назначает комитет узлов верификации для аудита запроса. Эти узлы управляются членами сообщества, которые вносят в стейкинг 70 000 токенов NIL, что согласовывает их интересы с целостностью сети.

4. Проверки узлов: Члены комитета повторно выполняют вычисления или проверяют криптографические доказательства. Если валидаторы обнаруживают некорректное поведение, они могут применить слэшинг к стейку агента (в системах с криптоэкономической валидацией) или пометить идентификатор в Reputation Registry.

5. Ончейн-отчетность: Результаты публикуются в блокчейне. Validation Registry фиксирует, была ли подтверждена работа агента, создавая постоянное доказательство исполнения. Реестр репутации обновляется соответствующим образом.

Этот процесс происходит асинхронно и без блокировок, что означает, что агенты не ждут завершения верификации для выполнения рутинных задач, но операции с высокими ставками (крупные переводы, кроссчейн-операции) могут требовать предварительной валидации.

Программируемый аудит: за пределами бинарного доверия​

Самая амбициозная функция Blacklight — это «программируемая верификация», возможность проверять то, как агент принимает решения, а не только то, что он делает.

Рассмотрим DeFi-агента, управляющего казначейством. Традиционные аудиты подтверждают, что средства были перемещены корректно. Программируемые аудиты проверяют:

• Логическую последовательность принятия решений: следовал ли агент заявленной инвестиционной стратегии или отклонился от нее?
• Выполнение многоэтапных рабочих процессов: если агент должен был провести ребалансировку портфелей в трех сетях, завершил ли он все этапы?
• Ограничения безопасности: соблюдал ли агент лимиты газа, допуски на проскальзывание (slippage) и ограничения по рискам (exposure caps)?

Это стало возможным благодаря тому, что реестр валидации (Validation Registry) стандарта ERC-8004 поддерживает произвольные системы доказательств. Агент может зафиксировать алгоритм принятия решений в блокчейне (например, хеш весов своей нейронной сети или схему zk-SNARK, представляющую его логику), а затем доказывать, что каждое действие соответствует этому алгоритму, не раскрывая при этом конфиденциальные детали.

Дорожная карта Nillion напрямую нацелена на эти сценарии использования: «Nillion планирует расширить возможности Blacklight до „программируемой верификации“, обеспечивая децентрализованный аудит сложных действий, таких как логическая последовательность принятия решений агентом, выполнение многоэтапных рабочих процессов и соблюдение ограничений безопасности».

Это переводит верификацию из реактивной формы (выявление ошибок постфактум) в проактивную (обеспечение правильного поведения на уровне архитектуры).

Слепые вычисления: когда приватность встречается с верификацией​

Лежащая в основе Nillion технология — Nil Message Compute (NMC) — добавляет аспект приватности в процесс верификации агентов. В отличие от традиционных блокчейнов, где все данные публичны, «слепые вычисления» Nillion позволяют выполнять операции над зашифрованными данными без их расшифровки.

Вот почему это важно для агентов: ИИ-агенту может потребоваться подтвердить свою торговую стратегию, не раскрывая конкурентам свои преимущества (alpha). Или доказать, что он корректно получил доступ к конфиденциальным медицинским записям, не раскрывая данных пациентов. Или продемонстрировать соблюдение нормативных требований, не разглашая проприетарную бизнес-логику.

NMC от Nillion достигает этого с помощью многосторонних вычислений (MPC), где узлы совместно генерируют «ослепляющие факторы» (blinding factors) — коррелированную случайность, используемую для шифрования данных. Как объясняет DAIC Capital: «Узлы генерируют ключевой сетевой ресурс, необходимый для обработки данных — тип коррелированной случайности, называемый ослепляющим фактором, — при этом каждый узел надежно хранит свою долю ослепляющего фактора, распределяя доверие по сети квантово-безопасным способом».

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

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

Инфраструктурная ставка на экономику агентов стоимостью 4,3 миллиарда долларов​

Запуск Blacklight происходит в тот момент, когда сектор блокчейна и ИИ вступает в фазу гиперроста. Прогнозируется, что рынок вырастет с 680 миллионов долларов (2025 г.) до 4,3 миллиарда долларов (2034 г.) со среднегодовым темпом роста 22,9 %, в то время как более широкий рынок конфиденциальных вычислений достигнет 350 миллиардов долларов к 2032 году.

Но Nillion не просто делает ставку на расширение рынка — она позиционирует себя как критически важную инфраструктуру. «Узким местом» экономики агентов являются не вычисления или хранение данных, а масштабируемое доверие. Как отмечается в прогнозе KuCoin на 2026 год, три ключевых тренда меняют идентичность ИИ и потоки создания ценности:

Системы «агент-оболочка-агента» (Agent-Wrapping-Agent): агенты, координирующиеся с другими агентами для выполнения сложных многоэтапных задач. Это требует стандартизированной идентификации и верификации — именно того, что обеспечивает ERC-8004.

KYA (Know Your Agent): финансовая инфраструктура, требующая учетных данных агентов. Регуляторы не одобрят автономных агентов, управляющих средствами, без доказательств их корректного поведения. Программируемые аудиты Blacklight напрямую решают эту задачу.

Наноплатежи: агентам необходимо эффективно проводить микроплатежи. Протокол платежей x402, который обработал более 20 миллионов транзакций в январе 2026 года, дополняет ERC-8004, беря на себя расчеты, в то время как Blacklight обеспечивает доверие.

Вместе эти стандарты достигли готовности к промышленной эксплуатации с разницей в несколько недель — прорыв в координации, сигнализирующий о зрелости инфраструктуры.

Ориентированное на агентов будущее Ethereum​

Внедрение ERC-8004 выходит далеко за пределы Nillion. По состоянию на начало 2026 года стандарт интегрировали несколько проектов:

• Oasis Network: внедрение ERC-8004 для конфиденциальных вычислений с валидацией на основе TEE.
• The Graph: поддержка ERC-8004 и x402 для обеспечения проверяемого взаимодействия агентов в децентрализованном индексировании.
• MetaMask: изучение кошельков для агентов со встроенной идентификацией ERC-8004.
• Coinbase: интеграция ERC-8004 для институциональных решений по хранению (custody) активов агентов.

Такое быстрое внедрение отражает более широкий сдвиг в дорожной карте Ethereum. Виталик Бутерин неоднократно подчеркивал, что роль блокчейна становится «просто связующим звеном» для ИИ-агентов — не уровнем, ориентированным на пользователя, а инфраструктурой доверия, обеспечивающей автономную координацию.

Blacklight от Nillion ускоряет реализацию этого видения, делая верификацию программируемой, конфиденциальной и децентрализованной. Вместо того чтобы полагаться на централизованных оракулов или экспертов, агенты могут криптографически доказать свою корректность.

Что дальше: интеграция с мейннетом и расширение экосистемы​

Дорожная карта Nillion на 2026 год отдает приоритет совместимости с Ethereum и устойчивой децентрализации. Мост к Ethereum был запущен в феврале 2026 года, за ним последовали нативные смарт-контракты для стейкинга и приватных вычислений.

Участники сообщества, застейкавшие 70 000 токенов NIL, могут управлять узлами верификации Blacklight, получая вознаграждения и поддерживая целостность сети. Эта модель отражает экономику валидаторов Ethereum, но добавляет специфическую роль верификации.

Следующие этапы включают:

• Расширенная поддержка zkML: интеграция с такими проектами, как Modulus Labs, для верификации выводов ИИ ончейн
• Кроссчейн-верификация: возможность Blacklight верифицировать агентов, работающих в сетях Ethereum, Cosmos и Solana
• Институциональное партнерство: сотрудничество с Coinbase и Alibaba Cloud для развертывания корпоративных агентов
• Инструменты для соблюдения нормативных требований: создание фреймворков KYA для внедрения в финансовые услуги

Возможно, самое важное — Nillion разрабатывает nilGPT — полностью приватный ИИ-чат-бот, демонстрирующий, как слепые вычисления (blind computation) обеспечивают конфиденциальное взаимодействие агентов. Это не просто демо-версия; это проект для агентов, работающих с конфиденциальными данными в здравоохранении, финансах и государственном секторе.

Конечная цель бездоверительной координации​

Запуск Blacklight знаменует собой поворотный момент для экономики агентов. До ERC-8004 агенты работали изолированно — им доверяли внутри их собственных экосистем, но они не могли координироваться между платформами без участия посредников-людей. После появления ERC-8004 агенты могут проверять личности друг друга, проводить аудит поведения и проводить расчеты автономно.

Это открывает совершенно новые категории приложений:

• Децентрализованные хедж-фонды: агенты, управляющие портфелями в разных сетях с верифицируемыми инвестиционными стратегиями и прозрачным аудитом эффективности
• Автономные цепочки поставок: агенты, координирующие логистику, платежи и комплаенс без централизованного надзора
• DAO на базе ИИ: организации, управляемые агентами, которые голосуют, вносят предложения и исполняют решения на основе криптографически подтвержденной логики принятия решений
• Кросс-протокольное управление ликвидностью: агенты, проводящие ребалансировку активов в DeFi-протоколах с программируемыми ограничениями рисков

Что их объединяет? Всем им требуется бездоверительная координация (trustless coordination) — способность агентов работать вместе без предварительных отношений или централизованных якорей доверия.

Blacklight от Nillion обеспечивает именно это. Сочетая инфраструктуру идентификации и репутации ERC-8004 с программируемой верификацией и слепыми вычислениями, он создает слой доверия, достаточно масштабируемый для экономики из триллиона агентов, маячащей на горизонте.

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

Эра автономных ончейн-акторов наступила. Инфраструктура запущена. Единственный оставшийся вопрос — что будет построено на ее основе.

---

Источники:

• Nillion запускает верификацию ERC-8004 в Blacklight | Phemex News
• ERC-8004: Бездоверительные агенты | Ethereum Improvement Proposals
• ERC-8004: Инфраструктура для автономных ИИ-агентов | QuillAudits
• Давиде Крапис: ERC-8004 обеспечивает взаимодействие децентрализованных ИИ-агентов | Unchained
• Слепой компьютер Nillion исправляет интернет | Nillion
• Nillion (NIL): Первая в мире сеть слепых вычислений | DAIC Capital
• Прогноз экономики ИИ-агентов на 2026 год | KuCoin
• The Graph поддерживает стандарты x402 и ERC-8004 для экономики ИИ-агентов | Blockchain News
• ERC-8004: Стандарт для бездоверительных агентов | Oasis Network
• Nillion 2.0 запущен на Ethereum | MEXC News
• Nillion: Слепые вычисления прорвались в 2025 году | Medium
• 2026: Когда блокчейн становится просто «трубопроводом» для ИИ-агентов | Blockmanity

Введение: Необходимость проверяемого ИИ в блокчейне​

По мере роста влияния систем ИИ, обеспечение достоверности их результатов становится критически важным. Традиционные методы полагаются на институциональные гарантии (по сути, «просто доверьтесь нам»), которые не предлагают криптографических подтверждений. Это особенно проблематично в децентрализованных контекстах, таких как блокчейны, где смарт-контракт или пользователь должны доверять результату, полученному ИИ, не имея возможности повторно запустить тяжелую модель ончейн. Машинное обучение с нулевым разглашением (zkML) решает эту проблему, позволяя криптографически проверять вычисления ML. По сути, zkML позволяет доказывающему сгенерировать краткое доказательство того, что «выход $Y$ был получен в результате запуска модели $M$ на входе $X$» – без раскрытия $X$ или внутренних деталей $M$. Эти доказательства с нулевым разглашением (ZKP) могут быть эффективно проверены любым лицом (или любым контрактом), переводя доверие к ИИ от «политики к доказательству».

Проверяемость ИИ ончейн означает, что блокчейн может включать расширенные вычисления (такие как инференсы нейронных сетей) путем проверки доказательства правильного выполнения вместо самостоятельного выполнения вычислений. Это имеет широкие последствия: смарт-контракты могут принимать решения на основе прогнозов ИИ, децентрализованные автономные агенты могут доказывать, что они следовали своим алгоритмам, а кроссчейн или оффчейн вычислительные сервисы могут предоставлять проверяемые результаты вместо непроверяемых оракулов. В конечном итоге, zkML предлагает путь к безопасному и конфиденциальному ИИ – например, доказывая, что решения модели ИИ верны и авторизованы без раскрытия частных данных или проприетарных весов модели. Это ключ к приложениям, от безопасной аналитики в здравоохранении до блокчейн-игр и оракулов DeFi.

Как работает zkML: сжатие инференса ML в краткие доказательства​

На высоком уровне zkML объединяет криптографические системы доказательств с инференсом ML, так что сложная оценка модели может быть «сжата» в небольшое доказательство. Внутри модель ML (например, нейронная сеть) представляется как схема или программа, состоящая из множества арифметических операций (умножение матриц, функции активации и т. д.). Вместо раскрытия всех промежуточных значений, доказывающий выполняет полное вычисление оффчейн, а затем использует протокол доказательства с нулевым разглашением, чтобы подтвердить, что каждый шаг был выполнен правильно. Верификатор, имея только доказательство и некоторые публичные данные (например, конечный результат и идентификатор модели), может быть криптографически убежден в правильности без повторного выполнения модели.

Для достижения этого фреймворки zkML обычно преобразуют вычисление модели в формат, подходящий для ZKP:

• Компиляция схемы: В подходах, основанных на SNARK, граф вычислений модели компилируется в арифметическую схему или набор полиномиальных ограничений. Каждый слой нейронной сети (свертки, умножения матриц, нелинейные активации) становится подсхемой с ограничениями, обеспечивающими правильность выходных данных при заданных входных данных. Поскольку нейронные сети включают нелинейные операции (ReLU, Sigmoid и т. д.), которые не подходят для полиномов, для их эффективной обработки используются такие методы, как таблицы поиска. Например, ReLU (выход = max(0, вход)) может быть реализован с помощью пользовательского ограничения или поиска, который проверяет, что выход равен входу, если вход≥0, иначе нулю. Конечным результатом является набор криптографических ограничений, которые должен удовлетворить доказывающий, что неявно доказывает правильность работы модели.
• Трассировка выполнения и виртуальные машины: Альтернативой является рассмотрение инференса модели как трассировки программы, как это делается в подходах zkVM. Например, JOLT zkVM ориентирован на набор инструкций RISC-V; можно скомпилировать модель ML (или код, который ее вычисляет) в RISC-V, а затем доказать, что каждая инструкция ЦП была выполнена правильно. JOLT вводит технику «сингулярности поиска», заменяя дорогостоящие арифметические ограничения быстрыми табличными поисками для каждой допустимой операции ЦП. Каждая операция (сложение, умножение, побитовая операция и т. д.) проверяется с помощью поиска в гигантской таблице предварительно вычисленных допустимых результатов, используя специализированный аргумент (Lasso/SHOUT) для поддержания эффективности. Это значительно снижает нагрузку на доказывающего: даже сложные 64-битные операции становятся одним табличным поиском в доказательстве вместо множества арифметических ограничений.
• Интерактивные протоколы (GKR Sum-Check): Третий подход использует интерактивные доказательства, такие как GKR (Goldwasser–Kalai–Rotblum), для проверки многослойных вычислений. Здесь вычисление модели рассматривается как многослойная арифметическая схема (каждый слой нейронной сети является одним слоем графа схемы). Доказывающий запускает модель в обычном режиме, но затем участвует в протоколе проверки суммы, чтобы доказать, что выходные данные каждого слоя верны при заданных входных данных. В подходе Лагранжа (DeepProve, подробно описанном далее) доказывающий и верификатор выполняют интерактивный полиномиальный протокол (сделанный неинтерактивным с помощью Fiat-Shamir), который проверяет согласованность вычислений каждого слоя без их повторного выполнения. Этот метод проверки суммы позволяет избежать генерации монолитной статической схемы; вместо этого он проверяет согласованность вычислений пошагово с минимальными криптографическими операциями (в основном хешированием или оценкой полиномов).

Независимо от подхода, результатом является краткое доказательство (обычно от нескольких килобайт до нескольких десятков килобайт), которое подтверждает правильность всего инференса. Доказательство является доказательством с нулевым разглашением, что означает, что любые секретные входные данные (частные данные или параметры модели) могут оставаться скрытыми – они влияют на доказательство, но не раскрываются верификаторам. Раскрываются только предполагаемые публичные выходные данные или утверждения. Это позволяет реализовать такие сценарии, как «доказать, что модель $M$ при применении к данным пациента $X$ дает диагноз $Y$, не раскрывая $X$ или веса модели».

Включение ончейн-верификации: После генерации доказательства оно может быть опубликовано в блокчейне. Смарт-контракты могут включать логику верификации для проверки доказательства, часто используя предварительно скомпилированные криптографические примитивы. Например, Ethereum имеет предварительные компиляции для операций спаривания BLS12-381, используемых во многих верификаторах zk-SNARK, что делает ончейн-верификацию доказательств SNARK эффективной. STARK (доказательства, основанные на хешировании) больше, но все еще могут быть проверены ончейн с тщательной оптимизацией или, возможно, с некоторыми предположениями о доверии (например, L2 StarkWare проверяет доказательства STARK в Ethereum с помощью ончейн-контракта верификатора, хотя и с более высокой стоимостью газа, чем SNARK). Ключевым моментом является то, что цепочке не нужно выполнять модель ML – она выполняет только верификацию, которая намного дешевле, чем исходные вычисления. В итоге, zkML сжимает дорогостоящий инференс ИИ в небольшое доказательство, которое блокчейны (или любой верификатор) могут проверить за миллисекунды или секунды.

Lagrange DeepProve: Архитектура и производительность прорыва в zkML​

DeepProve от Lagrange Labs – это передовой фреймворк инференса zkML, ориентированный на скорость и масштабируемость. Запущенный в 2025 году, DeepProve представил новую систему доказательств, которая значительно быстрее предыдущих решений, таких как Ezkl. Его дизайн основан на интерактивном протоколе доказательства GKR с проверкой суммы и специализированных оптимизациях для схем нейронных сетей. Вот как работает DeepProve и как он достигает своей производительности:

• Одноразовая предварительная обработка: Разработчики начинают с обученной нейронной сети (в настоящее время поддерживаются многослойные перцептроны и популярные архитектуры CNN). Модель экспортируется в формат ONNX, стандартное графическое представление. Инструмент DeepProve затем анализирует модель ONNX и квантует ее (преобразует веса в форму с фиксированной точкой/целочисленную форму) для эффективной полевой арифметики. На этом этапе он также генерирует ключи доказательства и верификации для криптографического протокола. Эта настройка выполняется один раз для каждой модели и не требует повторения для каждого инференса. DeepProve подчеркивает простоту интеграции: «Экспортируйте свою модель в ONNX → одноразовая настройка → генерируйте доказательства → проверяйте где угодно».

• Доказательство (инференс + генерация доказательства): После настройки доказывающий (который может быть запущен пользователем, сервисом или децентрализованной сетью доказывающих Lagrange) принимает новый вход $X$ и запускает на нем модель $M$, получая выход $Y$. Во время этого выполнения DeepProve записывает трассировку выполнения вычислений каждого слоя. Вместо того, чтобы заранее преобразовывать каждое умножение в статическую схему (как это делают подходы SNARK), DeepProve использует протокол GKR с линейным временем для проверки каждого слоя на лету. Для каждого слоя сети доказывающий фиксирует входные и выходные данные слоя (например, с помощью криптографических хешей или полиномиальных обязательств) и затем участвует в аргументе проверки суммы, чтобы доказать, что выходные данные действительно являются результатом входных данных в соответствии с функцией слоя. Протокол проверки суммы итеративно убеждает верификатора в правильности суммы оценок полинома, который кодирует вычисление слоя, не раскрывая фактических значений. Нелинейные операции (такие как ReLU, softmax) эффективно обрабатываются с помощью аргументов поиска в DeepProve – если выход активации был вычислен, DeepProve может доказать, что каждый выход соответствует действительной паре вход-выход из предварительно вычисленной таблицы для этой функции. Слой за слоем генерируются доказательства, а затем агрегируются в одно краткое доказательство, охватывающее весь прямой проход модели. Тяжелая работа криптографии минимизирована – доказывающий DeepProve в основном выполняет обычные числовые вычисления (фактический инференс) плюс некоторые легкие криптографические обязательства, а не решает гигантскую систему ограничений.

• Верификация: Верификатор использует окончательное краткое доказательство вместе с несколькими публичными значениями – обычно это зафиксированный идентификатор модели (криптографическое обязательство по весам $M$), вход $X$ (если он не является приватным) и заявленный выход $Y$ – для проверки правильности. Верификация в системе DeepProve включает проверку транскрипта протокола проверки суммы и окончательных полиномиальных или хеш-обязательств. Это более сложно, чем верификация классического SNARK (который может состоять из нескольких спариваний), но значительно дешевле, чем повторный запуск модели. В тестах Lagrange верификация доказательства DeepProve для средней CNN занимает порядка 0,5 секунды в программном обеспечении. То есть, ~0,5 с для подтверждения, например, того, что сверточная сеть с сотнями тысяч параметров работала правильно – более чем в 500 раз быстрее, чем наивное повторное вычисление этой CNN на GPU для верификации. (Фактически, DeepProve показал верификацию до 521 раза быстрее для CNN и 671 раза для MLP по сравнению с повторным выполнением.) Размер доказательства достаточно мал для передачи ончейн (десятки КБ), и верификация может быть выполнена в смарт-контракте при необходимости, хотя 0,5 с вычислений могут потребовать тщательной оптимизации газа или выполнения на уровне 2.

Архитектура и инструментарий: DeepProve реализован на Rust и предоставляет набор инструментов (библиотеку zkml) для разработчиков. Он нативно поддерживает графы моделей ONNX, что делает его совместимым с моделями из PyTorch или TensorFlow (после экспорта). Процесс доказательства в настоящее время ориентирован на модели до нескольких миллионов параметров (тесты включают плотную сеть с 4 миллионами параметров). DeepProve использует комбинацию криптографических компонентов: многолинейное полиномиальное обязательство (для фиксации выходных данных слоя), протокол проверки суммы для верификации вычислений и аргументы поиска для нелинейных операций. Примечательно, что открытый репозиторий Lagrange признает, что он основан на предыдущих работах (реализация проверки суммы и GKR из проекта Ceno от Scroll), что указывает на пересечение zkML с исследованиями в области роллапов с нулевым разглашением.

Для достижения масштабируемости в реальном времени Lagrange объединяет DeepProve со своей Сетью Доказывающих – децентрализованной сетью специализированных ZK-доказывающих. Тяжелая генерация доказательств может быть перенесена в эту сеть: когда приложению требуется доказательство инференса, оно отправляет задачу в сеть Lagrange, где множество операторов (застейканных на EigenLayer для безопасности) вычисляют доказательства и возвращают результат. Эта сеть экономически стимулирует надежную генерацию доказательств (злонамеренные или неудачные задания приводят к штрафу оператора). Распределяя работу между доказывающими (и потенциально используя GPU или ASIC), Сеть Доказывающих Lagrange скрывает сложность и стоимость от конечных пользователей. Результатом является быстрый, масштабируемый и децентрализованный сервис zkML: «проверяемые инференсы ИИ быстро и доступно».

Этапы производительности: Заявления DeepProve подкреплены бенчмарками по сравнению с предыдущим передовым решением, Ezkl. Для CNN с ~264 тыс. параметров (модель масштаба CIFAR-10) время доказательства DeepProve составило ~1,24 секунды против ~196 секунд для Ezkl – примерно в 158 раз быстрее. Для более крупной плотной сети с 4 миллионами параметров DeepProve доказал инференс за ~2,3 секунды против ~126,8 секунды для Ezkl (в ~54 раза быстрее). Время верификации также сократилось: DeepProve проверил доказательство CNN с 264 тыс. параметров за ~0,6 с, тогда как верификация доказательства Ezkl (на основе Halo2) заняла более 5 минут на ЦП в этом тесте. Ускорение обусловлено почти линейной сложностью DeepProve: его доказывающий масштабируется примерно O(n) с количеством операций, тогда как доказывающие SNARK на основе схем часто имеют сверхлинейные накладные расходы (масштабирование FFT и полиномиальных обязательств). Фактически, пропускная способность доказывающего DeepProve может быть в пределах одного порядка величины от времени выполнения обычного инференса – недавние системы GKR могут быть <10 раз медленнее, чем чистое выполнение для больших матричных умножений, что является впечатляющим достижением в ZK. Это делает доказательства в реальном времени или по требованию более осуществимыми, открывая путь для проверяемого ИИ в интерактивных приложениях.

Сценарии использования: Lagrange уже сотрудничает с проектами Web3 и ИИ для применения zkML. Примеры сценариев использования включают: проверяемые характеристики NFT (доказательство того, что эволюция игрового персонажа или коллекционного предмета, сгенерированная ИИ, вычислена авторизованной моделью), происхождение контента ИИ (доказательство того, что изображение или текст были сгенерированы определенной моделью, для борьбы с дипфейками), модели рисков DeFi (доказательство выходных данных модели, оценивающей финансовый риск, без раскрытия проприетарных данных) и приватный инференс ИИ в здравоохранении или финансах (где больница может получать прогнозы ИИ с доказательством, обеспечивая правильность без раскрытия данных пациентов). Делая выходные данные ИИ проверяемыми и конфиденциальными, DeepProve открывает дверь для «ИИ, которому можно доверять» в децентрализованных системах – переходя от эпохи «слепого доверия к моделям-черным ящикам» к эпохе «объективных гарантий».

zkML на основе SNARK: Ezkl и подход Halo2​

Традиционный подход к zkML использует zk-SNARK (Succinct Non-interactive Arguments of Knowledge – краткие неинтерактивные аргументы знания) для доказательства инференса нейронных сетей. Ezkl (от ZKonduit/Modulus Labs) является ведущим примером этого подхода. Он основан на системе доказательств Halo2 (SNARK в стиле PLONK с полиномиальными обязательствами над BLS12-381). Ezkl предоставляет цепочку инструментов, где разработчик может взять модель PyTorch или TensorFlow, экспортировать ее в ONNX, и Ezkl автоматически скомпилирует ее в пользовательскую арифметическую схему.

Как это работает: Каждый слой нейронной сети преобразуется в ограничения:

• Линейные слои (плотные или сверточные) становятся наборами ограничений умножения-сложения, которые обеспечивают скалярные произведения между входами, весами и выходами.
• Нелинейные слои (такие как ReLU, сигмоида и т. д.) обрабатываются с помощью таблиц поиска или кусочно-заданных ограничений, поскольку такие функции не являются полиномиальными. Например, ReLU может быть реализован с помощью булевого селектора $b$ с ограничениями, обеспечивающими $y = x \cdot b$ и $0 \le b \le 1$, а также $b=1$ если $x>0$ (один из способов), или более эффективно с помощью таблицы поиска, отображающей $x \mapsto \max(0,x)$ для диапазона значений $x$. Аргументы поиска Halo2 позволяют отображать 16-битные (или меньшие) фрагменты значений, поэтому большие домены (например, все 32-битные значения) обычно «разбиваются» на несколько меньших поисков. Это разбиение увеличивает количество ограничений.
• Операции с большими целыми числами или деления (если таковые имеются) аналогично разбиваются на мелкие части. Результатом является большой набор ограничений R1CS/PLONK, адаптированных к конкретной архитектуре модели.

Затем Ezkl использует Halo2 для генерации доказательства того, что эти ограничения выполняются при заданных секретных входных данных (весах модели, приватных входах) и публичных выходных данных. Инструментарий и интеграция: Одним из преимуществ подхода SNARK является то, что он использует хорошо известные примитивы. Halo2 уже используется в роллапах Ethereum (например, Zcash, zkEVM), поэтому он проверен в боях и имеет готовый ончейн-верификатор. Доказательства Ezkl используют кривую BLS12-381, которую Ethereum может проверять с помощью предварительных компиляций, что делает проверку доказательства Ezkl в смарт-контракте простой. Команда также предоставила удобные API; например, специалисты по данным могут работать со своими моделями на Python и использовать CLI Ezkl для создания доказательств, не имея глубоких знаний о схемах.

Преимущества: Подход Ezkl выигрывает от общности и экосистемы SNARK. Он поддерживает достаточно сложные модели и уже видел «практические интеграции (от моделей рисков DeFi до игрового ИИ)», доказывая реальные задачи ML. Поскольку он работает на уровне графа вычислений модели, он может применять оптимизации, специфичные для ML: например, отсечение незначимых весов или квантование параметров для уменьшения размера схемы. Это также означает, что конфиденциальность модели является естественной – веса могут рассматриваться как частные данные свидетеля, поэтому верификатор видит только то, что некая действительная модель произвела выход, или, в лучшем случае, обязательство по модели. Верификация доказательств SNARK чрезвычайно быстра (обычно несколько миллисекунд или меньше ончейн), а размеры доказательств малы (несколько килобайт), что идеально подходит для использования в блокчейне.

Недостатки: Производительность – это ахиллесова пята. Доказательство на основе схем накладывает большие накладные расходы, особенно по мере роста моделей. Отмечается, что исторически схемы SNARK могли требовать в миллион раз больше работы для доказывающего, чем просто запуск самой модели. Halo2 и Ezkl оптимизируют это, но все же операции, такие как большие матричные умножения, генерируют тонны ограничений. Если модель имеет миллионы параметров, доказывающий должен обработать соответственно миллионы ограничений, выполняя при этом тяжелые FFT и мультиэкспоненциацию. Это приводит к длительному времени доказательства (часто минуты или часы для нетривиальных моделей) и высокому потреблению памяти. Например, доказательство даже относительно небольшой CNN (например, несколько сотен тысяч параметров) может занять десятки минут с Ezkl на одной машине. Команда DeepProve цитировала, что Ezkl требовались часы для доказательств некоторых моделей, которые DeepProve может выполнить за минуты. Крупные модели могут даже не поместиться в память или потребовать разбиения на несколько доказательств (которые затем нуждаются в рекурсивной агрегации). Хотя Halo2 «умеренно оптимизирован», любая необходимость «разбивать» поиски или обрабатывать операции с широким битом приводит к дополнительным накладным расходам. В итоге, масштабируемость ограничена – Ezkl хорошо работает для моделей малого и среднего размера (и действительно превзошел некоторые более ранние альтернативы, такие как наивные VM на основе Stark в бенчмарках), но испытывает трудности по мере роста размера модели за определенный предел.

Несмотря на эти проблемы, Ezkl и аналогичные библиотеки zkML на основе SNARK являются важными шагами. Они доказали, что проверенный инференс ML возможен ончейн и активно используются. В частности, такие проекты, как Modulus Labs, продемонстрировали верификацию модели с 18 миллионами параметров ончейн с использованием SNARK (с серьезной оптимизацией). Стоимость была нетривиальной, но это показывает траекторию. Более того, протокол Mina имеет собственный инструментарий zkML, который использует SNARK, чтобы позволить смарт-контрактам на Mina (которые основаны на Snark) проверять выполнение моделей ML. Это указывает на растущую многоплатформенную поддержку zkML на основе SNARK.

Подходы на основе STARK: Прозрачный и программируемый ZK для ML​

zk-STARK (Scalable Transparent ARguments of Knowledge – масштабируемые прозрачные аргументы знания) предлагают другой путь к zkML. STARK используют криптографию на основе хеширования (например, FRI для полиномиальных обязательств) и избегают какой-либо доверенной настройки. Они часто работают путем симуляции ЦП или VM и доказательства правильности трассировки выполнения. В контексте ML можно либо создать пользовательский STARK для нейронной сети, либо использовать STARK VM общего назначения для запуска кода модели.

Общие STARK VM (RISC Zero, Cairo): Простой подход заключается в написании кода инференса и его запуске в STARK VM. Например, Risc0 предоставляет среду RISC-V, где любой код (например, реализация нейронной сети на C++ или Rust) может быть выполнен и доказан с помощью STARK. Аналогично, язык Cairo от StarkWare может выражать произвольные вычисления (такие как инференс LSTM или CNN), которые затем доказываются доказывающим StarkNet STARK. Преимущество заключается в гибкости – вам не нужно разрабатывать пользовательские схемы для каждой модели. Однако ранние бенчмарки показали, что наивные STARK VM были медленнее по сравнению с оптимизированными схемами SNARK для ML. В одном тесте доказательство на основе Halo2 (Ezkl) было примерно в 3 раза быстрее, чем подход на основе STARK на Cairo, и даже в 66 раз быстрее, чем RISC-V STARK VM в определенном бенчмарке в 2024 году. Этот разрыв обусловлен накладными расходами на симуляцию каждой низкоуровневой инструкции в STARK и большими константами в доказательствах STARK (хеширование быстро, но его нужно много; размеры доказательств STARK больше и т. д.). Однако STARK VM улучшаются и имеют преимущество прозрачной настройки (без доверенной настройки) и постквантовой безопасности. По мере развития STARK-совместимого оборудования и протоколов скорость доказательства будет улучшаться.

Подход DeepProve против STARK: Интересно, что использование GKR и проверки суммы в DeepProve дает доказательство, более похожее по духу на STARK – это интерактивное, хеш-основанное доказательство без необходимости в структурированной эталонной строке. Компромисс заключается в том, что его доказательства больше, а верификация тяжелее, чем у SNARK. Тем не менее, DeepProve показывает, что тщательный дизайн протокола (специализированный для многослойной структуры ML) может значительно превзойти как общие STARK VM, так и схемы SNARK по времени доказательства. Мы можем рассматривать DeepProve как специализированный zkML-доказывающий в стиле STARK (хотя они используют термин zkSNARK для краткости, он не имеет традиционной для SNARK верификации постоянного малого размера, поскольку верификация за 0,5 с больше, чем типичная верификация SNARK). Традиционные доказательства STARK (как у StarkNet) часто включают десятки тысяч полевых операций для верификации, тогда как SNARK верифицирует, возможно, за несколько десятков. Таким образом, очевиден один компромисс: SNARK дают меньшие доказательства и более быстрые верификаторы, тогда как STARK (или GKR) предлагают более легкое масштабирование и отсутствие доверенной настройки ценой размера доказательства и скорости верификации.

Появляющиеся улучшения: JOLT zkVM (обсуждавшийся ранее в разделе JOLTx) фактически выводит SNARK (используя PLONK-подобные обязательства), но он воплощает идеи, которые также могут быть применены в контексте STARK (поиски Lasso теоретически могут использоваться с обязательствами FRI). StarkWare и другие исследуют способы ускорения доказательства общих операций (например, использование пользовательских вентилей или подсказок в Cairo для операций с большими целыми числами и т. д.). Существует также Circomlib-ML от Privacy&Scaling Explorations (PSE), который предоставляет шаблоны Circom для слоев CNN и т. д. – это ориентировано на SNARK, но концептуально аналогичные шаблоны могут быть созданы для языков STARK.

На практике экосистемы, не относящиеся к Ethereum, использующие STARK, включают StarkNet (который мог бы позволить ончейн-верификацию ML, если кто-то напишет верификатор, хотя стоимость высока) и сервис Bonsai от Risc0 (который является оффчейн-сервисом доказательства, выдающим доказательства STARK, которые могут быть проверены в различных цепочках). По состоянию на 2025 год большинство демонстраций zkML на блокчейне отдавали предпочтение SNARK (из-за эффективности верификатора), но подходы STARK остаются привлекательными из-за их прозрачности и потенциала в условиях высокой безопасности или квантовой устойчивости. Например, децентрализованная вычислительная сеть может использовать STARK, чтобы позволить любому проверять работу без доверенной настройки, что полезно для долговечности. Кроме того, некоторые специализированные задачи ML могут использовать структуры, дружественные к STARK: например, вычисления, активно использующие операции XOR/битовые операции, могут быть быстрее в STARK (поскольку они дешевы в булевой алгебре и хешировании), чем в полевой арифметике SNARK.

Сравнение SNARK и STARK для ML:

• Производительность: SNARK (такие как Halo2) имеют огромные накладные расходы на доказательство для каждого вентиля, но выигрывают от мощных оптимизаций и малых констант для верификации; STARK (общие) имеют большие постоянные накладные расходы, но масштабируются более линейно и избегают дорогостоящей криптографии, такой как спаривания. DeepProve показывает, что настройка подхода (проверка суммы) дает почти линейное время доказательства (быстрое), но с доказательством, подобным STARK. JOLT показывает, что даже общая VM может быть ускорена за счет интенсивного использования поисков. Эмпирически, для моделей до миллионов операций: хорошо оптимизированный SNARK (Ezkl) может справиться, но может занять десятки минут, тогда как DeepProve (GKR) может сделать это за секунды. STARK VM в 2024 году, вероятно, были где-то посередине или хуже, чем SNARK, если не были специализированными (Risc0 был медленнее в тестах, Cairo был медленнее без пользовательских подсказок).
• Верификация: Доказательства SNARK проверяются быстрее всего (миллисекунды, и минимальные данные ончейн ~ от нескольких сотен байт до нескольких КБ). Доказательства STARK больше (десятки КБ) и требуют больше времени (от десятков мс до секунд) для верификации из-за множества шагов хеширования. В терминах блокчейна, верификация SNARK может стоить, например, ~200 тыс. газа, тогда как верификация STARK может стоить миллионы газа – часто слишком дорого для L1, приемлемо на L2 или со схемами краткой верификации.
• Настройка и безопасность: SNARK, такие как Groth16, требуют доверенной настройки для каждой схемы (неудобно для произвольных моделей), но универсальные SNARK (PLONK, Halo2) имеют одноразовую настройку, которая может быть повторно использована для любой схемы до определенного размера. STARK не требуют настройки и используют только хеш-предположения (плюс классические предположения о полиномиальной сложности), и являются постквантово-устойчивыми. Это делает STARK привлекательными для долговечности – доказательства остаются безопасными, даже если появятся квантовые компьютеры, тогда как текущие SNARK (на основе BLS12-381) будут взломаны квантовыми атаками.

Мы вскоре сведем эти различия в сравнительную таблицу.

FHE для ML (FHE-o-ML): Приватные вычисления против проверяемых вычислений​

Полностью гомоморфное шифрование (FHE) – это криптографическая техника, которая позволяет выполнять вычисления непосредственно над зашифрованными данными. В контексте ML FHE может обеспечить форму инференса, сохраняющего конфиденциальность: например, клиент может отправить зашифрованный ввод хосту модели, хост запускает нейронную сеть на зашифрованном тексте, не расшифровывая его, и отправляет обратно зашифрованный результат, который клиент может расшифровать. Это обеспечивает конфиденциальность данных – владелец модели ничего не узнает о вводе (и потенциально клиент узнает только вывод, а не внутренности модели, если он получает только вывод). Однако FHE само по себе не создает доказательства правильности так, как это делают ZKP. Клиент должен доверять тому, что владелец модели действительно выполнил вычисления честно (зашифрованный текст мог быть изменен). Обычно, если у клиента есть модель или он ожидает определенного распределения выходных данных, явное мошенничество может быть обнаружено, но тонкие ошибки или использование неправильной версии модели не будут очевидны только из зашифрованного вывода.

Компромиссы в производительности: FHE, как известно, очень требовательно к вычислениям. Запуск инференса глубокого обучения под FHE приводит к замедлению на порядки. Ранние эксперименты (например, CryptoNets в 2016 году) занимали десятки секунд для оценки крошечной CNN на зашифрованных данных. К 2024 году улучшения, такие как CKKS (для приближенной арифметики) и лучшие библиотеки (Microsoft SEAL, Zama’s Concrete), сократили эти накладные расходы, но они остаются значительными. Например, пользователь сообщил, что использование Concrete-ML от Zama для запуска классификатора CIFAR-10 занимало 25–30 минут на инференс на их оборудовании. После оптимизаций команда Zama достигла ~40 секунд для этого инференса на 192-ядерном сервере. Даже 40 секунд – это чрезвычайно медленно по сравнению с инференсом в открытом виде (который может занимать 0,01 с), что показывает накладные расходы в ~$10^3$–$10^4\times$. Более крупные модели или более высокая точность еще больше увеличивают стоимость. Кроме того, операции FHE потребляют много памяти и требуют периодической бустрапизации (шага снижения шума), что является вычислительно дорогим. В итоге, масштабируемость является серьезной проблемой – современное FHE может обрабатывать небольшую CNN или простую логистическую регрессию, но масштабирование до больших CNN или трансформеров выходит за рамки текущих практических ограничений.

Преимущества конфиденциальности: Главная привлекательность FHE – это конфиденциальность данных. Входные данные могут оставаться полностью зашифрованными на протяжении всего процесса. Это означает, что недоверенный сервер может выполнять вычисления над частными данными клиента, ничего о них не узнавая. И наоборот, если модель является конфиденциальной (проприетарной), можно представить шифрование параметров модели и выполнение клиентом инференса FHE на своей стороне – но это менее распространено, потому что если клиенту приходится выполнять тяжелые вычисления FHE, это сводит на нет идею разгрузки на мощный сервер. Обычно модель является публичной или хранится сервером в открытом виде, а данные шифруются ключом клиента. Конфиденциальность модели в этом сценарии не обеспечивается по умолчанию (сервер знает модель; клиент узнает выходные данные, но не веса). Существуют более экзотические настройки (например, безопасные двухсторонние вычисления или FHE с несколькими ключами), где и модель, и данные могут быть скрыты друг от друга, но они влекут за собой еще большую сложность. В отличие от этого, zkML через ZKP может обеспечить конфиденциальность модели и конфиденциальность данных одновременно – доказывающий может иметь как модель, так и данные в качестве секретного свидетеля, раскрывая верификатору только то, что необходимо.

Ончейн-верификация не требуется (и невозможна): С FHE результат приходит клиенту в зашифрованном виде. Затем клиент расшифровывает его, чтобы получить фактическое предсказание. Если мы хотим использовать этот результат ончейн, клиент (или тот, кто владеет ключом дешифрования) должен будет опубликовать результат в открытом виде и убедить других в его правильности. Но в этот момент доверие снова возвращается в цикл – если только это не сочетается с ZKP. В принципе, можно было бы объединить FHE и ZKP: например, использовать FHE для сохранения конфиденциальности данных во время вычислений, а затем сгенерировать ZK-доказательство того, что результат в открытом виде соответствует правильным вычислениям. Однако их объединение означает, что вы платите штраф за производительность FHE и ZKP – что крайне непрактично с сегодняшними технологиями. Таким образом, на практике FHE-of-ML и zkML служат для разных сценариев использования:

• FHE-of-ML: Идеально, когда целью является конфиденциальность между двумя сторонами (клиентом и сервером). Например, облачный сервис может размещать модель ML, и пользователи могут запрашивать ее со своими конфиденциальными данными, не раскрывая данные облаку (и если модель конфиденциальна, возможно, развернуть ее с помощью FHE-совместимых кодировок). Это отлично подходит для ML-сервисов, сохраняющих конфиденциальность (медицинские прогнозы и т. д.). Пользователь по-прежнему должен доверять сервису в добросовестном выполнении модели (поскольку нет доказательства), но, по крайней мере, предотвращается любая утечка данных. Некоторые проекты, такие как Zama, даже исследуют «EVM с поддержкой FHE (fhEVM)», где смарт-контракты могли бы работать с зашифрованными входными данными, но верификация этих вычислений ончейн потребовала бы от контракта каким-то образом обеспечить правильность вычислений – открытая проблема, вероятно, требующая ZK-доказательств или специализированного защищенного оборудования.
• zkML (ZKP): Идеально, когда целью является проверяемость и публичная аудируемость. Если вы хотите, чтобы любой (или любой контракт) был уверен, что «Модель $M$ была правильно оценена на $X$ и произвела $Y$», ZKP являются решением. Они также обеспечивают конфиденциальность в качестве бонуса (вы можете скрыть $X$ или $Y$ или $M$ при необходимости, рассматривая их как частные входные данные для доказательства), но их основная функция – это доказательство правильного выполнения.

Взаимодополняющие отношения: Стоит отметить, что ZKP защищают верификатора (они ничего не узнают о секретах, только то, что вычисление было выполнено правильно), тогда как FHE защищает данные доказывающего от вычисляющей стороны. В некоторых сценариях их можно было бы объединить – например, сеть недоверенных узлов могла бы использовать FHE для вычислений над частными данными пользователей, а затем предоставлять ZK-доказательства пользователям (или блокчейну) о том, что вычисления были выполнены в соответствии с протоколом. Это охватило бы как конфиденциальность, так и правильность, но стоимость производительности огромна с сегодняшними алгоритмами. Более осуществимыми в ближайшей перспективе являются гибриды, такие как Trusted Execution Environments (TEE) плюс ZKP или функциональное шифрование плюс ZKP – они выходят за рамки нашего обсуждения, но их цель – предоставить нечто подобное (TEE сохраняют данные/модель в секрете во время вычислений, затем ZKP может подтвердить, что TEE сделала все правильно).

В итоге, FHE-of-ML отдает приоритет конфиденциальности входов/выходов, тогда как zkML отдает приоритет проверяемой правильности (с возможной конфиденциальностью). Таблица 1 ниже сопоставляет ключевые свойства:

Подход	Производительность доказывающего (инференс и доказательство)	Размер доказательства и верификация	Функции конфиденциальности	Доверенная настройка?	Постквантовая устойчивость?
zk-SNARK (Halo2, Groth16, PLONK и др.)	Тяжелые накладные расходы доказывающего (до 10^6× обычного времени выполнения без оптимизаций; на практике 10^3–10^5×). Оптимизировано для конкретной модели/схемы; время доказательства в минутах для средних моделей, часы для больших. Недавние zkML SNARK (DeepProve с GKR) значительно улучшают это (почти линейные накладные расходы, например, секунды вместо минут для моделей с миллионами параметров).	Очень маленькие доказательства (часто < 100 КБ, иногда ~несколько КБ). Верификация быстрая: несколько спариваний или полиномиальных оценок (обычно < 50 мс ончейн). Доказательства DeepProve на основе GKR больше (десятки–сотни КБ) и верифицируются за ~0,5 с (все еще намного быстрее, чем повторный запуск модели).	Конфиденциальность данных: Да – входные данные могут быть приватными в доказательстве (не раскрываются). Конфиденциальность модели: Да – доказывающий может зафиксировать веса модели и не раскрывать их. Скрытие вывода: Опционально – доказательство может быть утверждением без раскрытия вывода (например, «вывод имеет свойство P»). Однако, если сам вывод нужен ончейн, он обычно становится публичным. В целом, SNARK предлагают полную гибкость нулевого разглашения (скрывайте любые части, которые хотите).	Зависит от схемы. Groth16/EZKL требуют доверенной настройки для каждой схемы; PLONK/Halo2 используют универсальную настройку (одноразовую). GKR DeepProve с проверкой суммы прозрачен (без настройки) – это бонус такого дизайна.	Классические SNARK (кривые BLS12-381) не являются PQ-безопасными (уязвимы для квантовых атак на дискретный логарифм эллиптической кривой). Некоторые новые SNARK используют PQ-безопасные обязательства, но Halo2/PLONK, используемые в Ezkl, не являются PQ-безопасными. GKR (DeepProve) использует хеш-обязательства (например, Poseidon/Merkle), которые, как предполагается, являются PQ-безопасными (опираясь на устойчивость к поиску прообраза хеша).
zk-STARK (FRI, доказательство на основе хеширования)	Накладные расходы доказывающего высоки, но масштабирование более линейное. Обычно в 10^2–10^4 раза медленнее, чем нативное выполнение для больших задач, с возможностью распараллеливания. Общие STARK VM (Risc0, Cairo) показали более низкую производительность по сравнению с SNARK для ML в 2024 году (например, в 3–66 раз медленнее, чем Halo2 в некоторых случаях). Специализированные STARK (или GKR) могут приближаться к линейным накладным расходам и превосходить SNARK для больших схем.	Доказательства больше: часто десятки КБ (растут с размером схемы/log(n)). Верификатор должен выполнять множество проверок хеширования и FFT – время верификации ~O(n^ε) для малого ε (например, ~50 мс до 500 мс в зависимости от размера доказательства). Ончейн это дороже (верификатор L1 StarkWare может занимать миллионы газа на доказательство). Некоторые STARK поддерживают рекурсивные доказательства для сжатия размера, ценой времени доказывающего.	Конфиденциальность данных и модели: STARK может быть сделан доказательством с нулевым разглашением путем рандомизации данных трассировки (добавление ослепления к оценкам полинома), поэтому он может скрывать частные входные данные аналогично SNARK. Многие реализации STARK сосредоточены на целостности, но варианты zk-STARK допускают конфиденциальность. Так что да, они могут скрывать входные данные/модели, как SNARK. Скрытие вывода: также возможно в теории (доказывающий не объявляет вывод публичным), но редко используется, поскольку обычно вывод – это то, что мы хотим раскрыть/проверить.	Без доверенной настройки. Прозрачность – отличительная черта STARK – требуется только общая случайная строка (которую Fiat-Shamir может вывести). Это делает их привлекательными для открытого использования (любая модель, в любое время, без церемонии для каждой модели).	Да, STARK полагаются на хеш- и информационно-теоретические предположения безопасности (такие как случайный оракул и сложность определенного декодирования кодовых слов в FRI). Считается, что они устойчивы к квантовым атакам. Таким образом, доказательства STARK являются PQ-устойчивыми, что является преимуществом для обеспечения долговечности проверяемого ИИ.
FHE для ML (Полностью гомоморфное шифрование, примененное к инференсу)	Доказывающий = сторона, выполняющая вычисления над зашифрованными данными. Время вычислений чрезвычайно велико: замедление в 10^3–10^5 раз по сравнению с инференсом в открытом виде является обычным явлением. Высокопроизводительное оборудование (многоядерные серверы, FPGA и т. д.) может смягчить это. Некоторые оптимизации (инференс с низкой точностью, многоуровневые параметры FHE) могут уменьшить накладные расходы, но фундаментальный удар по производительности остается. FHE в настоящее время практично для небольших моделей или простых линейных моделей; глубокие сети остаются сложными за пределами игрушечных размеров.	Доказательство не генерируется. Результатом является зашифрованный вывод. Верификация в смысле проверки правильности не обеспечивается одним только FHE – приходится доверять вычисляющей стороне, что она не обманывает. (Если в сочетании с защищенным оборудованием, можно получить аттестацию; в противном случае вредоносный сервер может вернуть некорректный зашифрованный результат, который клиент расшифрует в неправильный вывод, не зная разницы).	Конфиденциальность данных: Да – входные данные зашифрованы, поэтому вычисляющая сторона ничего о них не узнает. Конфиденциальность модели: Если владелец модели выполняет вычисления над зашифрованными входными данными, модель находится в открытом виде на его стороне (не защищена). Если роли меняются местами (клиент хранит модель зашифрованной, а сервер выполняет вычисления), модель может оставаться зашифрованной, но этот сценарий менее распространен. Существуют методы, такие как безопасное двухстороннее ML, которые объединяют FHE/MPC для защиты обеих сторон, но они выходят за рамки простого FHE. Скрытие вывода: По умолчанию вывод вычисления зашифрован (расшифровать его может только сторона с секретным ключом, обычно владелец входных данных). Таким образом, вывод скрыт от вычисляющего сервера. Если мы хотим, чтобы вывод был публичным, клиент может его расшифровать и раскрыть.	Настройка не требуется. Каждый пользователь генерирует свою пару ключей для шифрования. Доверие основано на том, что ключи остаются секретными.	Безопасность схем FHE (например, BFV, CKKS, TFHE) основана на решеточных проблемах (Learning With Errors), которые, как считается, устойчивы к квантовым атакам (по крайней мере, не известно эффективного квантового алгоритма). Таким образом, FHE обычно считается постквантово-устойчивым.

Таблица 1: Сравнение подходов zk-SNARK, zk-STARK и FHE для инференса машинного обучения (компромиссы производительности и конфиденциальности).

Сценарии использования и последствия для приложений Web3​

Конвергенция ИИ и блокчейна через zkML открывает мощные новые паттерны приложений в Web3:

• Децентрализованные автономные агенты и ончейн-принятие решений: Смарт-контракты или DAO могут включать решения, управляемые ИИ, с гарантиями правильности. Например, представьте DAO, которое использует нейронную сеть для анализа рыночных условий перед выполнением сделок. С помощью zkML смарт-контракт DAO может потребовать доказательство zkSNARK того, что авторизованная модель ML (с известным хеш-обязательством) была запущена на последних данных и произвела рекомендованное действие, прежде чем действие будет принято. Это предотвращает внедрение поддельного предсказания злоумышленниками – цепочка проверяет вычисления ИИ. Со временем можно даже иметь полностью ончейн-автономных агентов (контракты, которые запрашивают оффчейн-ИИ или содержат упрощенные модели), принимающих решения в DeFi или играх, при этом все их действия доказываются как правильные и соответствующие политике с помощью zk-доказательств. Это повышает доверие к автономным агентам, поскольку их «мышление» прозрачно и проверяемо, а не является черным ящиком.

• Рынки проверяемых вычислений: Проекты, подобные Lagrange, фактически создают рынки проверяемых вычислений – разработчики могут передавать тяжелый инференс ML сети доказывающих и получать доказательство с результатом. Это аналогично децентрализованным облачным вычислениям, но со встроенным доверием: вам не нужно доверять серверу, только доказательству. Это смена парадигмы для оракулов и оффчейн-вычислений. Протоколы, такие как предстоящий DSC Ethereum (децентрализованный уровень секвенирования) или сети оракулов, могли бы использовать это для предоставления потоков данных или аналитических потоков с криптографическими гарантиями. Например, оракул мог бы предоставить «результат модели X на входе Y», и любой мог бы проверить прикрепленное доказательство ончейн, вместо того чтобы доверять слову оракула. Это могло бы позволить проверяемый ИИ как услугу в блокчейне: любой контракт может запросить вычисление (например, «оценить эти кредитные риски с помощью моей частной модели») и принять ответ только с действительным доказательством. Такие проекты, как Gensyn, исследуют децентрализованные рынки обучения и инференса, используя эти методы верификации.

• NFT и игры – Происхождение и эволюция: В блокчейн-играх или коллекционных NFT zkML может доказывать, что характеристики или игровые ходы были сгенерированы легитимными моделями ИИ. Например, игра может позволить ИИ развивать атрибуты NFT-питомца. Без ZK хитрый пользователь может изменить ИИ или результат, чтобы получить превосходного питомца. С помощью zkML игра может потребовать доказательство того, что «новые характеристики питомца были вычислены официальной моделью эволюции на основе старых характеристик питомца», предотвращая мошенничество. Аналогично для генеративных арт-NFT: художник мог бы выпустить генеративную модель в качестве обязательства; позже, при создании NFT, доказать, что каждое изображение было произведено этой моделью с использованием определенного начального значения, гарантируя подлинность (и даже делая это без раскрытия точной модели публике, сохраняя интеллектуальную собственность художника). Эта проверка происхождения обеспечивает подлинность способом, аналогичным проверяемой случайности – за исключением того, что здесь это проверяемая креативность.

• ИИ, сохраняющий конфиденциальность, в чувствительных областях: zkML позволяет подтверждать результаты без раскрытия входных данных. В здравоохранении данные пациента могут быть пропущены через диагностическую модель ИИ облачным провайдером; больница получает диагноз и доказательство того, что модель (которая может быть частной собственностью фармацевтической компании) была правильно запущена на данных пациента. Данные пациента остаются конфиденциальными (в доказательстве использовалась только зашифрованная или зафиксированная форма), а веса модели остаются проприетарными – тем не менее, результат является доверенным. Регуляторы или страховые компании также могли бы проверить, что использовались только утвержденные модели. В финансах компания могла бы доказать аудитору или регулятору, что ее модель риска была применена к ее внутренним данным и произвела определенные метрики без раскрытия базовых конфиденциальных финансовых данных. Это обеспечивает соответствие и надзор с криптографическими гарантиями, а не ручным доверием.

• Кроссчейн и оффчейн совместимость: Поскольку доказательства с нулевым разглашением по своей сути портативны, zkML может облегчить кроссчейн-ИИ результаты. Одна цепочка может иметь приложение, интенсивно использующее ИИ, работающее оффчейн; оно может опубликовать доказательство результата в другом блокчейне, который бездоверительно примет его. Например, рассмотрим многоцепочечное DAO, использующее ИИ для агрегирования настроений в социальных сетях (оффчейн-данные). Анализ ИИ (сложная НЛП на больших данных) выполняется оффчейн сервисом, который затем публикует доказательство в небольшом блокчейне (или нескольких цепочках) о том, что «анализ был выполнен правильно и выходной показатель настроения = 0,85». Все цепочки могут проверить и использовать этот результат в своей логике управления, без необходимости каждой повторно запускать анализ. Этот вид взаимодействующих проверяемых вычислений – это то, что сеть Lagrange стремится поддерживать, обслуживая несколько роллапов или L1 одновременно. Это устраняет необходимость в доверенных мостах или предположениях оракулов при перемещении результатов между цепочками.

• Согласование и управление ИИ: В более перспективном плане zkML был выделен как инструмент для управления и безопасности ИИ. Заявления о видении Lagrange, например, утверждают, что по мере того, как системы ИИ становятся все более мощными (даже сверхразумными), криптографическая верификация будет необходима для обеспечения их соответствия согласованным правилам. Требуя от моделей ИИ создания доказательств их рассуждений или ограничений, люди сохраняют определенную степень контроля – «вы не можете доверять тому, что не можете проверить». Хотя это спекулятивно и включает в себя как социальные, так и технические аспекты, технология могла бы обеспечить, чтобы автономно работающий агент ИИ по-прежнему доказывал, что он использует утвержденную модель и не был изменен. Децентрализованные сети ИИ могут использовать ончейн-доказательства для верификации вкладов (например, сеть узлов, совместно обучающих модель, может доказать, что каждое обновление было вычислено добросовестно). Таким образом, zkML может сыграть роль в обеспечении подотчетности систем ИИ протоколам, определенным человеком, даже в децентрализованных или неконтролируемых средах.

В заключение, zkML и проверяемый ончейн-ИИ представляют собой конвергенцию передовой криптографии и машинного обучения, которая призвана повысить доверие, прозрачность и конфиденциальность в приложениях ИИ. Сравнивая основные подходы – zk-SNARK, zk-STARK и FHE – мы видим спектр компромиссов между производительностью и конфиденциальностью, каждый из которых подходит для разных сценариев. Фреймворки на основе SNARK, такие как Ezkl, и инновации, такие как DeepProve от Lagrange, сделали возможным доказательство значительных инференсов нейронных сетей с практической эффективностью, открывая двери для реальных развертываний проверяемого ИИ. Подходы на основе STARK и VM обещают большую гибкость и постквантовую безопасность, что станет важным по мере развития области. FHE, хотя и не является решением для проверяемости, решает дополнительную потребность в конфиденциальных вычислениях ML, и в сочетании с ZKP или в конкретных частных контекстах оно может дать пользователям возможность использовать ИИ без ущерба для конфиденциальности данных.

Последствия для Web3 значительны: мы можем предвидеть, как смарт-контракты будут реагировать на предсказания ИИ, зная, что они верны; рынки вычислений, где результаты продаются без доверия; цифровые удостоверения (например, доказательство личности Worldcoin через ИИ радужной оболочки глаза), защищенные zkML для подтверждения того, что кто-то является человеком, без утечки его биометрического изображения; и в целом новый класс «доказуемого интеллекта», который обогащает блокчейн-приложения. Многие проблемы остаются – производительность для очень больших моделей, эргономика для разработчиков и потребность в специализированном оборудовании – но траектория ясна. Как отмечалось в одном отчете, «сегодняшние ZKP могут поддерживать небольшие модели, но модели среднего и большого размера нарушают парадигму»; однако быстрые достижения (ускорение в 50–150 раз с DeepProve по сравнению с предыдущими решениями) расширяют эти границы. Благодаря продолжающимся исследованиям (например, по аппаратному ускорению и распределенному доказательству) мы можем ожидать, что все более крупные и сложные модели ИИ станут доказуемыми. zkML вскоре может превратиться из нишевых демонстраций в неотъемлемый компонент доверенной инфраструктуры ИИ, гарантируя, что по мере повсеместного распространения ИИ он будет делать это таким образом, чтобы быть проверяемым, децентрализованным и соответствующим конфиденциальности и безопасности пользователей.