Введение: Необходимость проверяемого ИИ в блокчейне
По мере роста влияния систем ИИ, обеспечение достоверности их результатов становится критически важным. Традиционные методы полагаются на институциональные гарантии (по сути, «просто доверьтесь нам»), которые не предлагают криптографических подтверждений. Это особенно проблематично в децентрализованных контекстах, таких как блокчейны, где смарт-контракт или пользователь должны доверять результату, по лученному ИИ, не имея возможности повторно запустить тяжелую модель ончейн. Машинное обучение с нулевым разглашением (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 вскоре может превратиться из нишевых демонстраций в неотъемлемый компонент доверенной инфраструктуры ИИ, гарантируя, что по мере повсеместного распространения ИИ он будет делать это таким образом, чтобы быть проверяемым, децентрализованным и соответствующим конфиденциальности и безопасности пользователей.
