zkML (zero-knowledge ML): верифицируемый ИИ без раскрытия данных и весов

Зачем нужен zkML (zero-knowledge Machine Learning)

• Доверие без доверия: потребитель результата не обязан верить провайдеру инфраструктуры или разработчику модели — корректность подтверждена формально.
• Приватность: можно доказать правильный вывод по чувствительным данным, не показывая их (медицина, финансы).
• Ончейн-исполнение: смарт-контракты принимают решения, опираясь на краткие доказательства, а не на большие массивы данных или внешние оракулы «на вере».
• Маркетплейсы вычислений: исполнитель (prover) доказывает, что действительно прогнал модель над входом, — базис для «оборота» верифицируемых ML-услуг.
• Аудит и комплаенс: доказуемая корректность шагов (инференс, пост-процессинг) облегчает аудит.

Базовая архитектура zkML

Типичный pipeline:

1. Модель → арифметическая схема: граф слоёв переводится в ограничения (R1CS/Plonkish/иное) над конечным полем.
2. Квантизация/фикспойнт: вещественные вычисления аппроксимируются фиксированной точкой (n/м бит), подбирается шкала и допуски ошибки.
3. Нелинейности: ReLU, GELU, Sigmoid реализуются таблицами соответствия (lookup), кусочно-линейными аппроксимациями или полиномиальными приближениями.
4. Доказательство (proving): на вход подаются приватные/публичные данные, исполнение схемы «сворачивается» в доказательство.
5. Проверка (verifying): проверяющая сторона быстро убеждается, что все ограничения соблюдены (ончейн/оффчейн).

Ключевые роли:

• Prover — исполняет модель и генерирует ZK-доказательство.
• Verifier — дешёво проверяет корректность.
• Circuit/IR — промежуточное представление модели для аритметизации.

Выбор доказательной системы

Выбор зависит от ограничений продукта: цена проверки (ончейн), время prover, размер модели, требования к setup и крипто-устойчивости.

Как «упаковать» слои нейросети в ZK

• Матрица-вектор (FC/Conv как GEMM): аритметизируется как набор умножений/сумм с фиксированной точностью; полезны оптимизации сжатия матриц (sparsity, low-rank).
• Свертки (Conv2D/Depthwise): выкладка в im2col или прямое свёртывание; trade-off между числом ограничений и памятью.
• Нелинейности:
  1. ReLU: проверка знака через вспомогательные переменные/таблицы;
  2. GELU/Sigmoid/Tanh: полиномиальные аппроксимации или табличные lookup с малой ошибкой.
• Нормализации/softmax: часто заменяются эквивалентами/аппроксимациями (log-домен, клиппинг).
• Attention: разбиение на блоки, low-rank/скудность, приближения softmax; возможны спец-схемы для Q·Kᵀ, масштабирования и маскирования.
• Арифметические поля и шкала: выбирается поле (например, 2²⁵⁴−ε) и диапазоны, чтобы минимизировать переполнения при фикспойнте.

Инженерные трюки для снижения стоимости

• Квантизация 8-бит и ниже (вплоть до 4-бит с калибровкой) — меньше ограничений, но аккуратнее с точностью.
• Sparsity/Pruning — обнуление слабых весов уменьшает число умножений.
• Low-rank/Adapter-слои — замена тяжёлых линейных блоков на низкоранговые факторы.
• Lookup-аргументы (таблицы) — дешёвая проверка «сложных» функций.
• Параллельный prover — GPU/FPGA, распределённая генерация.
• Рекурсивная агрегация — «сшивка» доказательств по частям/батчам.

Модели: что проще/сложнее доказать

• Лёгкие CNN/MLP — хорошие кандидаты: мало нелинейностей, простые операции.
• Сжатые трансформеры — возможны с квантизацией, ограничением seq-len и аппроксимациями softmax.
• Giant-LLM «как есть» — экономически тяжело: доказательство вывода целой большой модели часто дороже самого вывода; применяют гибридные схемы (частичный ZK, доверенная зона и т. п.).

Паттерны использования zkML

Ончейн-верификация вывода. Контракт принимает (y, proof) и публичные коммитменты (например, хеш весов), проверяет доказательство и переводит средства/меняет состояние.

Приватные запросы. Пользователь доказывает, что модель посчитала y на приватном x (медицинский снимок, банковская метрика), не раскрывая x.

Приватные веса. Провайдер модели скрывает параметры (коммерческая тайна), но доказывает корректность вывода над открытым входом.

Маркетплейс ML-вычислений. Исполнители продают «доказуемые» инференсы; заказчики платят только за валидные результаты.

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

Сравнение с альтернативами (TEE/MPC/HE)

На практике используют гибриды: TEE для тяжёлых участков, ZK — для публичной верификации результата.

Ограничения и риски

• Точность vs стоимость: агрессивная квантизация/аппроксимации ухудшают метрики модели.
• Размер модели: большие LLM → огромные схемы; без сжатия и трюков prover будет слишком дорогим.
• Trusted setup (для ряда SNARK): операционные риски и требования к церемониям.
• Криптографические допущения: пост-квантовая стойкость актуальна для долгоживущих систем.
• Инженерная зрелость: компиляторы модель→схема, профилировщики ошибок и тулчейны находятся в активной стадии развития.

Проектирование zkML: пошаговый план

1. Определите публичные/приватные части. Что раскрываем (выход, хеш весов), что скрываем (вход, веса).
2. Выберите ZK-систему под требования проверки (ончейн бюджет, газ/время) и политики (нужен ли trusted setup).
3. Сожмите модель: квантизация, sparsity, low-rank, упрощения нелинейностей.
4. Скомпилируйте в схему: проверьте переполнения фикспойнта, подготовьте lookup-таблицы.
5. Замерьте ошибки: отклонение от float-базы на валидации; при необходимости калибруйте шкалы.
6. Спроектируйте рекурсию/агрегацию: как бить на батчи и сшивать доказательства.
7. Внедрите проверку: on-chain верификатор или оффчейн-сервис с криптоподписью результата.
8. Evals: добавьте метрики фактичности/полезности результата (см. evals) и тесты безопасности.

Ончейн-верификация: практические заметки

• SNARK-friendly: Groth16/Plonk дают малые доказательства и дешевую проверку в EVM-подобных сетях.
• STARK-friendly: при выборе STARK учитывайте размер пруфа и стоимость дешифровки на L1; возможен оффчейн-верифай с подписью для L2.
• Коммитменты: фиксируйте хеш веса/схемы (или IPFS-CID) как публичную константу — это защищает от подмены модели.
• Версионирование: явно указывайте версию схемы и параметров — для аудита и совместимости.

Чек-лист качества для zkML

1. Валидация точности (Δ к float-базе) на репрезентативном наборе.
2. Отсутствие переполнений и корректная шкала фикспойнта.
3. Статистика lookup-промахов и граничных значений нелинейностей.
4. Мониторинг времени/стоимости prover; целевые SLO.
5. Стратегия рекурсии/агрегации и лимиты размера пруфа.
6. Поведенческие тесты модели (см. evals), в т. ч. безопасность.
7. Документация публичных параметров (коммитменты, версии, кривые, поля).

Мини-глоссарий

• ZK-доказательство — подтверждение утверждения без раскрытия секретов.
• Prover/Verifier — генератор/проверяющий доказательство.
• R1CS/Plonkish — форматы ограничений для аритметизации вычислений.
• Lookup-аргумент — дешёвая проверка принадлежности значений таблице.
• Рекурсия — проверка одного доказательства внутри другого.
• Коммитмент — криптографическое «закрепление» данных (хеш), позволяющее ссылаться без раскрытия.

См. также

• AI Security Hub
• Децентрализованные вычисления для ИИ
• AI: общий обзор