Перейти к основному контенту

Программируемая конфиденциальность в блокчейне: внесетевые вычисления с ончейн-верификацией

· 44 мин чтения
Dora Noda
Dora Noda
Software Engineer

Публичные блокчейны обеспечивают прозрачность и целостность ценой конфиденциальности — каждая транзакция и состояние контракта открыты для всех участников. Такая открытость создает проблемы, такие как MEV-атаки (Maximum Extractable Value — максимально извлекаемая стоимость), копи-трейдинг и утечка конфиденциальной бизнес-логики. Программируемая конфиденциальность призвана решить эти проблемы, позволяя выполнять вычисления над частными данными без раскрытия самих данных. Это становится возможным благодаря двум развивающимся криптографическим парадигмам: виртуальным машинам с полностью гомоморфным шифрованием (FHE-VM) и копроцессорам с нулевым разглашением (ZK-копроцессорам). Эти подходы позволяют выполнять вычисления вне сети или в зашифрованном виде с верификацией в сети, сохраняя конфиденциальность и обеспечивая бездоверительную корректность. В этом отчете мы подробно рассмотрим архитектуры FHE-VM и ZK-копроцессоров, сравним их компромиссы и изучим варианты использования в финансах, идентификации, здравоохранении, на рынках данных и в децентрализованном машинном обучении.

Виртуальная машина с полностью гомоморфным шифрованием (FHE-VM)​

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

Архитектура и дизайн FHE-VM​

Типичная FHE-VM расширяет стандартную среду выполнения смарт-контрактов (такую как Ethereum Virtual Machine) встроенной поддержкой зашифрованных типов данных и операций. Например, FHEVM от Zama вводит зашифрованные целые числа (euint8, euint32 и т. д.), зашифрованные логические значения (ebool) и даже зашифрованные массивы в качестве первоклассных типов. Языки смарт-контрактов, такие как Solidity, дополняются библиотеками или новыми кодами операций (opcodes), чтобы разработчики могли выполнять арифметические (add, mul и т. д.), логические операции и сравнения непосредственно над шифротекстами. Внутри эти операции вызывают примитивы FHE (например, с использованием библиотеки TFHE) для управления зашифрованными битами и получения зашифрованных результатов.

Хранение зашифрованного состояния поддерживается таким образом, что переменные контракта остаются зашифрованными в состоянии блокчейна. Процесс выполнения обычно выглядит так:

  1. Шифрование на стороне клиента: Пользователи шифруют свои входные данные локально, используя публичный ключ FHE, перед отправкой транзакций. Ключ шифрования является публичным (для шифрования и вычислений), в то время как ключ дешифрования остается в секрете. В некоторых моделях каждый пользователь управляет собственным ключом; в других используется единый глобальный ключ FHE (рассмотрено ниже).
  2. Гомоморфные вычисления в сети: Майнеры/валидаторы выполняют контракт с использованием зашифрованных кодов операций. Они выполняют одни и те же детерминированные гомоморфные операции над шифротекстами, что позволяет достичь консенсуса относительно нового зашифрованного состояния. Важно то, что валидаторы никогда не видят открытых данных — они видят только «бессмысленный» шифротекст, но при этом могут последовательно его обрабатывать.
  3. Дешифрование (опционально): Если результат необходимо раскрыть или использовать вне сети, авторизованная сторона с закрытым ключом может расшифровать выходной шифротекст. В противном случае результаты остаются зашифрованными и могут быть использованы в качестве входных данных для последующих транзакций (что позволяет проводить последовательные вычисления над постоянным зашифрованным состоянием).

Важным аспектом проектирования является управление ключами. Один из подходов — ключи для каждого пользователя, где каждый пользователь хранит свой секретный ключ, и только он может расшифровать относящиеся к нему выходные данные. Это максимизирует конфиденциальность (никто другой не сможет расшифровать ваши данные), но гомоморфные операции не могут смешивать данные, зашифрованные разными ключами, без сложных протоколов с несколькими ключами. Другой подход, используемый в FHEVM от Zama, — глобальный ключ FHE: единый публичный ключ шифрует все данные контракта, а распределенный набор валидаторов владеет долями ключа пороговой дешифровки. Публичные ключи шифрования и вычислений публикуются в сети, поэтому любой может зашифровать данные для сети; закрытый ключ разделен между валидаторами, которые могут коллективно выполнить дешифрование при достижении порога, если это необходимо. Чтобы предотвратить сговор валидаторов, Zama использует протокол порогового FHE (основанный на их исследовании Noah’s Ark) с механизмом «зашумления» (noise flooding) для обеспечения безопасности частичных дешифровок. Открытый текст может быть восстановлен только в том случае, если кооперируется достаточное количество валидаторов, например, для обслуживания запроса на чтение. Однако при обычной работе ни один узел никогда не видит открытый текст — данные всегда остаются зашифрованными в сети.

Контроль доступа — еще один важный компонент. Реализации FHE-VM включают детализированные средства управления тем, кто (если вообще кто-либо) может инициировать дешифрование или получать доступ к определенным зашифрованным полям. Например, fhEVM от Cypher поддерживает списки контроля доступа (ACL) для шифротекстов, позволяя разработчикам указывать, какие адреса или контракты могут взаимодействовать с определенными данными или перешифровывать их. Некоторые фреймворки поддерживают перешифрование (re-encryption): возможность передачи зашифрованного значения от ключа одного пользователя к ключу другого без раскрытия открытого текста. Это полезно для таких вещей, как рынки данных, где владелец данных может зашифровать набор данных своим ключом, а после покупки перешифровать его ключом покупателя — и все это в сети, без публичного раскрытия данных.

Обеспечение корректности и конфиденциальности​

Возникает вопрос: если все данные зашифрованы, как обеспечить корректность логики контракта? Как сеть может предотвратить недопустимые операции, если она не «видит» значения? FHE сам по себе не предоставляет доказательства корректности — валидаторы могут выполнять гомоморфные шаги, но они не могут изначально определить, были ли зашифрованные входные данные пользователя действительными или следует ли переходить к условной ветке без дешифрования. Доказательства с нулевым разглашением (ZKP) могут дополнить FHE для решения этой проблемы. В FHE-VM пользователи обычно должны предоставлять ZK-доказательство, подтверждающее определенные условия открытого текста, когда это необходимо. Например, в дизайне Zama используется ZK-доказательство знания открытого текста (ZKPoK) для каждого зашифрованного ввода. Это доказывает, что пользователь знает открытый текст, соответствующий его шифротексту, и что он соответствует ожидаемым критериям, не раскрывая сам открытый текст. Такие «сертифицированные шифротексты» не позволяют злоумышленнику отправить некорректное шифрование или значение, выходящее за допустимые пределы. Аналогично, для операций, требующих принятия решения (например, проверка условия «баланс счета ≥ сумма вывода»), пользователь может предоставить ZK-доказательство того, что это условие истинно для открытых текстов, прежде чем будет выполнена зашифрованная операция. Таким образом, сеть не расшифровывает и не видит значения, но получает уверенность в том, что зашифрованные транзакции следуют правилам.

Другой подход в FHE-роллапах заключается в выполнении проверки вне сети с помощью ZKP. Fhenix (L2-роллап на базе FHE) выбирает оптимистичную модель, в которой отдельный сетевой компонент, называемый Threshold Service Network, может расшифровывать или проверять зашифрованные результаты, а любое неверное вычисление может быть оспорено с помощью доказательства мошенничества (fraud-proof). В целом, сочетание FHE + ZK или доказательств мошенничества гарантирует, что зашифрованное исполнение остается бездоверительным. Валидаторы либо коллективно расшифровывают данные только при наличии полномочий, либо проверяют доказательства того, что каждый зашифрованный переход состояния был валидным, без необходимости видеть открытый текст.

Вопросы производительности: FHE-операции требуют больших вычислительных ресурсов — они на много порядков медленнее обычных арифметических операций. Например, простое 64-битное сложение в Ethereum стоит около 3 единиц газа, тогда как сложение зашифрованного 64-битного целого числа (euint64) в FHEVM от Zama стоит примерно 188 000 единиц газа. Даже 8-битное сложение может стоить около 94 000 газа. Такие огромные накладные расходы означают, что прямая реализация на существующих узлах была бы практически невозможной из-за медлительности и стоимости. Проекты FHE-VM решают эту проблему с помощью оптимизированных криптографических библиотек (таких как библиотека TFHE-rs от Zama для бутстраппинга бинарных вентилей) и кастомных модификаций EVM для повышения производительности. Например, модифицированный клиент Geth от Cypher добавляет новые коды операций и оптимизирует выполнение гомоморфных инструкций на C++/ассемблере для минимизации задержек. Тем не менее, для достижения приемлемой пропускной способности требуется аппаратное ускорение. Текущая работа включает использование графических процессоров (GPU), программируемых логических интегральных схем (FPGA) и даже специализированных фотонных чипов для ускорения вычислений FHE. Zama сообщает, что производительность их FHE улучшилась в 100 раз с 2024 года, и целью является достижение тысяч транзакций в секунду (TPS) с ускорением на GPU/FPGA. Специализированные серверы-копроцессоры FHE (такие как узел LightLocker от Optalysys) могут подключаться к узлам валидаторов для разгрузки зашифрованных операций на аппаратное обеспечение, поддерживая более 100 зашифрованных переводов ERC-20 в секунду на один узел. По мере совершенствования оборудования и алгоритмов разрыв между FHE и обычными вычислениями будет сокращаться, что позволит приватным контрактам достичь практически значимых скоростей.

Совместимость: Ключевой целью разработок FHE-VM является сохранение совместимости с существующими рабочими процессами разработки. Реализации fhEVM от Cypher и Zama позволяют разработчикам писать контракты на Solidity с минимальными изменениями, используя библиотеку для объявления зашифрованных типов и операций. Остальную часть инструментария Ethereum (Remix, Hardhat и т. д.) по-прежнему можно использовать, поскольку основные модификации происходят на уровне клиента/узла. Это снижает порог входа: разработчикам не нужно быть экспертами в криптографии для написания конфиденциального смарт-контракта. Например, простое сложение двух чисел может быть записано как euint32 c = a + b;, и FHEVM обработает специфические детали шифрования в фоновом режиме. Контракты могут даже взаимодействовать с обычными контрактами — например, зашифрованный контракт может передавать расшифрованный результат в стандартный контракт, что позволяет смешивать приватные и публичные части в рамках одной экосистемы.

Текущие проекты FHE-VM: Несколько проектов являются первопроходцами в этой области. Zama (парижский стартап в области FHE) разработала концепцию FHEVM и библиотеки (TFHE-rs и библиотеку fhevm-solidity). Они не планируют запускать собственную сеть, а предоставляют инфраструктуру другим. Inco — это L1-блокчейн (построенный на Cosmos SDK с использованием Evmos), который интегрировал FHEVM от Zama для создания модульной конфиденциальной сети. Их тестовые сети (Gentry и Paillier) демонстрируют зашифрованные переводы ERC-20 и другие приватные примитивы DeFi. Fhenix — это оптимистичный роллап второго уровня (L2) для Ethereum, использующий FHE для обеспечения конфиденциальности. Они выбрали оптимистичный подход (с доказательствами мошенничества), а не ZK-роллап, из-за высокой стоимости одновременного выполнения FHE и ZK для каждого блока. Fhenix использует ту же библиотеку TFHE-rs (с некоторыми модификациями) и внедряет Threshold Service Network для децентрализованной обработки дешифрования. Также существуют независимые команды, такие как Fhenix (после ребрендинга), и стартапы, исследующие гибриды MPC + FHE. Кроме того, Cypher (от Z1 Labs) строит сеть третьего уровня (L3), ориентированную на ИИ и конфиденциальность, используя fhEVM с такими функциями, как секретные хранилища и поддержка федеративного обучения. Экосистема находится на начальном этапе, но быстро растет, подкрепляемая значительным финансированием — например, Zama стала «единорогом», привлев более 130 млн долларов к 2025 году для развития технологий FHE.

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

ZK-копроцессоры (Zero-Knowledge Coprocessors)​

ZK-копроцессор — это новый паттерн архитектуры блокчейна, при котором ресурсоемкие вычисления выполняются вне сети (off-chain), а лаконичное доказательство с нулевым разглашением их правильности проверяется в сети (on-chain). Это позволяет смарт-контрактам задействовать гораздо большие вычислительные мощности и объемы данных, чем позволяло бы ончейн-выполнение, без ущерба для децентрализации (trustlessness). Термин копроцессор используется по аналогии с аппаратными сопроцессорами (такими как математический сопроцессор или GPU), которые обрабатывают специализированные задачи для центрального процессора. В данном случае «процессор» блокчейна (нативная виртуальная машина, такая как EVM) делегирует определенные задачи системе доказательств с нулевым разглашением, которая выступает в роли криптографического сопроцессора. ZK-копроцессор возвращает результат и доказательство того, что результат был вычислен верно, которое ончейн-контракт может проверить и затем использовать.

Архитектура и рабочий процесс​

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

  1. Запрос (Request) — ончейн-контракт инициирует запрос на выполнение определенных вычислений вне сети. Это может быть инициировано транзакцией пользователя или вызовом интерфейса ZK-копроцессора другим контрактом. Например, DeFi-контракт может вызвать «proveInterestRate(currentState)», или пользователь может вызвать «queryHistoricalData(query)».
  2. Внечейновое выполнение и генерация доказательства (Off-Chain Execution & Proving) — внечейновая служба (которая может быть децентрализованной сетью пруверов или доверенным сервисом, в зависимости от дизайна) принимает запрос. Она собирает все необходимые данные (состояние блокчейна, внечейновые входные данные и т. д.) и выполняет вычисления в специальной ZK-виртуальной машине (ZKVM) или схеме. Во время выполнения генерируется трассировка доказательства. В конце служба выдает лаконичное доказательство (например, SNARK или STARK), подтверждающее, что «Вычисление функции F на входных данных X дает результат Y», и, опционально, подтверждающее целостность данных (подробнее об этом ниже).
  3. Ончейн-верификация (On-Chain Verification) — доказательство и результат возвращаются в блокчейн (часто через функцию обратного вызова — callback). Контракт-верификатор проверяет валидность доказательства, используя эффективную криптографическую проверку (проверки спаривания и т. д.). Если доказательство валидно, контракт может доверять результату Y как верному. Результат может быть сохранен в состоянии, передан в виде события или использован в дальнейшей логике контракта. Если доказательство недействительно или не предоставлено в течение определенного времени, запрос считается неудачным (и потенциально срабатывает логика резервного копирования или тайм-аута).

Рисунок 1 : Архитектура ZK-копроцессора (на примере RISC Zero Bonsai). Вне сети программа запускается на ZKVM с входными данными из вызова смарт-контракта. Доказательство выполнения возвращается в сеть через реле-контракт, который инициирует обратный вызов с верифицированными результатами.

Крайне важно, что затраты газа в сети на верификацию являются постоянными (или растут очень медленно) независимо от того, насколько сложными были внечейновые вычисления. Верификация лаконичного доказательства может стоить порядка нескольких сотен тысяч единиц газа (небольшая часть блока Ethereum), но это доказательство может представлять миллионы вычислительных шагов, выполненных вне сети. Как пошутил один разработчик : «Хотите доказать одну цифровую подпись? ~ $15. Хотите доказать миллион подписей? Тоже ~ $15». Такая масштабируемость — огромный плюс : dApps могут предлагать сложные функции (аналитика больших данных, сложные финансовые модели и т. д.), не перегружая блокчейн.

Основными компонентами системы ZK-копроцессора являются :

  • Среда генерации доказательств (Proof Generation Environment) : это может быть ZKVM общего назначения (способная запускать произвольные программы) или кастомные схемы, адаптированные для конкретных вычислений. Подходы различаются :

    • Некоторые проекты используют созданные вручную схемы (handcrafted circuits) для каждого поддерживаемого запроса или функции (максимизируя эффективность для этой функции).
    • Другие предоставляют предметно-ориентированный язык (DSL) или встроенный DSL (Embedded DSL), который разработчики используют для написания своей внечейновой логики, которая затем компилируется в схемы (балансируя между простотой использования и производительностью).
    • Самым гибким подходом является zkVM : виртуальная машина (часто на основе архитектур RISC), где программы могут быть написаны на стандартных языках (Rust, C и т. д.) и автоматически доказаны. Это требует определенных жертв в производительности (симуляция процессора в схеме добавляет накладные расходы) ради максимального удобства для разработчиков.

  • Доступ к данным и их целостность : уникальной задачей является предоставление внечейновым вычислениям корректных данных, особенно если эти данные находятся в блокчейне (прошлые блоки, состояния контрактов и т. д.). Наивное решение — заставить прувера читать данные из архивного узла и доверять ему, но это вводит допущения о доверии. Вместо этого ZK-копроцессоры обычно доказывают, что любые используемые ончейн-данные действительно были аутентичными, связывая их с доказательствами Меркла или обязательствами по состоянию (state commitments). Например, программа запроса может принимать номер блока и доказательство Меркла для слота хранения или транзакции, а схема проверит это доказательство на соответствие известному хешу заголовка блока. Существует три паттерна :

    1. Встроенные данные (Inline Data) : поместить необходимые данные в блокчейн (как входные данные для верификатора), чтобы их можно было проверить напрямую. Это очень дорого для больших объемов данных и сводит на нет весь смысл использования копроцессора.
    2. Доверие оракулу : использовать сервис оракула для передачи данных в доказательство и поручительства за них. Это проще, но снова вводит доверие к третьей стороне.
    3. Доказательство включения данных через ZK : включить доказательства включения данных в историю блокчейна в саму схему с нулевым разглашением. Это использует тот факт, что каждый заголовок блока Ethereum фиксирует все предшествующее состояние (через корень состояния) и историю транзакций. Проверяя доказательства Merkle Patricia для данных внутри схемы, выходное доказательство гарантирует контракту, что «это вычисление использовало подлинные данные блокчейна из блока N» без необходимости в дополнительном доверии.

    Третий подход является наиболее бездоверительным (trustless) и используется продвинутыми ZK-копроцессорами, такими как Axiom и Xpansion (это увеличивает стоимость доказательства, но предпочтительнее с точки зрения безопасности). Например, система Axiom моделирует структуру блоков Ethereum, дерево состояний и дерево транзакций внутри своих схем, поэтому она может доказывать утверждения типа «аккаунт X имел баланс Y в блоке N» или «транзакция с определенными свойствами произошла в блоке N». Это позволяет, имея недавний доверенный хеш блока, рекурсивно доказывать включение исторических данных без доверия к какой-либо внешней стороне.

  • Контракт-верификатор (Verifier Contract) : этот ончейн-контракт содержит ключ верификации и логику для принятия или отклонения доказательств. Для SNARK, таких как Groth16 или PLONK, верификатор может выполнять несколько спариваний на эллиптических кривых ; для STARK он может выполнять вычисления хешей. Оптимизация производительности, такая как агрегация и рекурсия, может минимизировать нагрузку на сеть. Например, Bonsai от RISC Zero использует STARK-to-SNARK обертку : он запускает VM на базе STARK вне сети для скорости, но затем генерирует небольшое доказательство SNARK, подтверждающее валидность STARK. Это уменьшает размер доказательства с сотен килобайт до нескольких сотен байт, что делает ончейн-верификацию осуществимой и дешевой. Верификатор на Solidity затем просто проверяет SNARK (что является операцией с константным временем).

С точки зрения развертывания, ZK-копроцессоры могут функционировать как сети, подобные L2, или как чистые внечейновые сервисы. Некоторые, как Axiom, начинались как специализированный сервис для Ethereum (при поддержке Paradigm), где разработчики отправляют запросы в сеть пруверов Axiom и получают доказательства в сети. Слоган Axiom заключался в предоставлении контрактам Ethereum «бездоверительного доступа ко всем ончейн-данным и произвольных выразительных вычислений над ними». Фактически он действует как оракул запросов, где ответы проверяются с помощью ZKP вместо доверия. Другие, такие как RISC Zero Bonsai, предлагают более открытую платформу : любой разработчик может загрузить программу (скомпилированную в ZKVM, совместимую с RISC-V) и использовать сервис доказательства Bonsai через реле-контракт (relay contract). Паттерн реле, как показано на рисунке 1, включает контракт, который опосредует запросы и ответы : контракт dApp вызывает реле, чтобы запросить доказательство, внечейновая служба отслеживает это (например, через событие или прямой вызов), вычисляет доказательство, а затем реле вызывает функцию обратного вызова в контракте dApp с результатом и доказательством. Эта асинхронная модель необходима, поскольку генерация доказательства может занимать от секунд до минут в зависимости от сложности. Это вносит задержку (latency) (и предположение о живучести, что прувер ответит), в то время как вычисления FHE-VM происходят синхронно внутри блока. Проектирование приложения для обработки этого асинхронного рабочего процесса (возможно, аналогично ответам оракулов) является частью использования ZK-копроцессора.

Известные проекты ZK-копроцессоров​

  • Axiom : Axiom — это ZK-копроцессор, адаптированный для Ethereum, изначально ориентированный на доказательство запросов к историческим ончейн-данным. Он использует фреймворк доказательства Halo2 (SNARK типа Plonk) для создания доказательств, включающих криптографические структуры Ethereum. В системе Axiom разработчик может запрашивать такие вещи, как «каким было состояние контракта X в блоке N?» или выполнять вычисления по всем транзакциям в диапазоне. «Под капотом» схемы Axiom должны были реализовывать логику состояния/дерева Ethereum, даже выполняя операции на эллиптических кривых и верификацию SNARK внутри схемы для поддержки рекурсии. Trail of Bits в ходе аудита отметили сложность схем Halo2 от Axiom, моделирующих целые блоки и состояния. После аудита Axiom обобщили свою технологию в OpenVM, позволяющую доказывать произвольный код на Rust с использованием той же инфраструктуры на базе Halo2. (Это отражает тенденцию перехода от специализированных схем к более общему подходу ZKVM.) Команда Axiom продемонстрировала ZK-запросы, которые Ethereum нативно выполнять не может, обеспечивая безоборотный доступ (stateless access) к любым историческим данным с криптографической целостностью. Они также уделяли большое внимание безопасности, обнаруживая и исправляя ошибки в недостаточно ограниченных схемах (under-constrained circuits) и обеспечивая обоснованность (soundness). Хотя первоначальный продукт Axiom был закрыт во время их перехода на новую модель, их подход остается вехой в области ZK-копроцессоров.

  • RISC Zero Bonsai : RISC Zero — это ZKVM на базе архитектуры RISC-V. Их zkVM может выполнять произвольные программы (написанные на Rust, C++ и других языках, скомпилированных в RISC-V) и генерировать STARK-доказательство выполнения. Bonsai — это облачный сервис RISC Zero, который предоставляет такие доказательства по запросу, выступая в роли копроцессора для смарт-контрактов. Чтобы использовать его, разработчик пишет программу (скажем, функцию, которая выполняет сложные математические вычисления или проверяет ответ внечейнового API), загружает ее в сервис Bonsai и развертывает соответствующий контракт-верификатор. Когда контракту требуется это вычисление, он вызывает реле Bonsai, которое запускает генерацию доказательства и возвращает результат через callback. Одним из продемонстрированных примеров применения стали внечейновые вычисления для управления (governance) : RISC Zero показали, как DAO использует Bonsai для подсчета голосов и вычисления сложных метрик голосования вне сети, а затем публикует доказательство, чтобы ончейн-контракт Governor мог доверять результату с минимальными затратами газа. Технология RISC Zero подчеркивает, что разработчики могут использовать знакомые парадигмы программирования — например, написание функции на Rust для чего-либо — а тяжелая работа по созданию схем берется на себя zkVM. Однако доказательства могут быть большими, поэтому, как отмечалось ранее, они реализовали сжатие SNARK для ончейн-верификации. В августе 2023 года они успешно верифицировали доказательства RISC Zero в тестовой сети Ethereum Sepolia, что стоило порядка 300 тысяч газа за одно доказательство. Это открывает двери для dApps в Ethereum для использования Bonsai уже сегодня в качестве решения для масштабируемости и приватности. (Bonsai все еще находится в стадии альфа-тестирования, не готов к промышленной эксплуатации и использует временную настройку SNARK без церемонии доверенной установки.)

  • Другие : существует множество других игроков и исследовательских инициатив. Expansion/Xpansion (как упоминалось в одном из блогов) использует подход со встроенным DSL, где разработчики могут писать запросы к ончейн-данным на специализированном языке, а генерация доказательств происходит внутри системы. Cairo от StarkWare и zkEVM от Polygon — это более общие виртуальные машины ZK-rollup, но их технологии могут быть перепрофилированы для использования в качестве копроцессоров путем верификации доказательств в контрактах L1. Мы также видим проекты в области ZKML (ZK Machine Learning), которые фактически действуют как копроцессоры для верификации вывода моделей машинного обучения или результатов обучения в сети. Например, установка zkML может доказать, что «вывод нейронной сети на частных входных данных дал классификацию X» без раскрытия входных данных и без выполнения вычислений ончейн. Это частные случаи концепции копроцессора, применимые к ИИ.

Допущения о доверии : ZK-копроцессоры полагаются на обоснованность (soundness) криптографических доказательств. Если система доказательств безопасна (и любая доверенная установка выполнена честно), то принятое доказательство гарантирует правильность вычислений. Никакого дополнительного доверия к пруверу не требуется — даже злонамеренный прувер не сможет убедить верификатора в ложном утверждении. Однако существует предположение о живучести (liveness) : кто-то должен фактически выполнить внечейновое вычисление и создать доказательство. На практике это может быть децентрализованная сеть (со стимулами или комиссиями за работу) или оператор одного сервиса. Если никто не предоставит доказательство, ончейн-запрос может остаться нерешенным. Другим тонким аспектом доверия является доступность данных для внечейновых входных данных, которых нет в блокчейне. Если вычисление зависит от каких-то частных или внешних данных, верификатор не может знать, были ли эти данные предоставлены честно, если не используются дополнительные меры (такие как обязательства по данным или подписи оракулов). Но для вычислений на чисто ончейн-данных описанные механизмы обеспечивают бездоверительность, эквивалентную самой сети (Axiom утверждали, что их доказательства обеспечивают «безопасность, криптографически эквивалентную Ethereum» для исторических запросов).

Приватность : доказательства с нулевым разглашением также по своей природе поддерживают приватность — прувер может скрывать входные данные, доказывая утверждения о них. В контексте копроцессора это означает, что доказательство может позволить контракту использовать результат, полученный на основе частных данных. Например, доказательство может показать, что «кредитный рейтинг пользователя > 700, поэтому одобрить кредит» без раскрытия фактического кредитного рейтинга или исходных данных. Вариант использования Axiom был больше связан с общедоступными данными (историей блокчейна), поэтому приватность там не была в центре внимания. Но zkVM от RISC Zero можно использовать для доказательства утверждений о секретных данных, предоставленных пользователем : данные остаются вне сети, и в сеть попадает только необходимый результат. Стоит отметить, что, в отличие от FHE, ZK-доказательство обычно не обеспечивает постоянную конфиденциальность состояния — это разовое доказательство. Если рабочий процесс требует сохранения секретного состояния между транзакциями, его можно построить так, чтобы контракт хранил обязательство (commitment) к состоянию, а каждое доказательство показывало валидный переход из старого обязательства в новое с сохранением секретов в тайне. Именно так работают zk-роллапы для частных транзакций (такие как Aztec или Zcash). Таким образом, ZK-копроцессоры могут способствовать созданию полностью приватных машин состояний, но реализация этого нетривиальна ; часто они используются для разовых вычислений, где либо входные, либо выходные данные (или и то, и другое) могут быть приватными по мере необходимости.

Опыт разработчиков : использование ZK-копроцессора обычно требует освоения новых инструментов. Написание кастомных схем (вариант (1) выше) довольно сложно и обычно делается только для узких целей. Варианты более высокого уровня, такие как DSL или zkVM, облегчают жизнь, но все равно добавляют накладные расходы : разработчик должен написать и развернуть внечейновый код и управлять взаимодействием. В отличие от FHE-VM, где шифрование в основном обрабатывается «за кулисами» и разработчик пишет обычный код смарт-контракта, здесь разработчику нужно разделить свою логику и, возможно, писать на другом языке (Rust и т. д.) для внечейновой части. Тем не менее, такие инициативы, как DSL Noir, Leo, Circom или подход RISC Zero, быстро улучшают доступность. Например, RISC Zero предоставляет шаблоны и интеграцию с Foundry, благодаря чему разработчик может симулировать свой внечейновый код локально (для проверки правильности), а затем беспрепятственно подключить его к тестам на Solidity через callback Bonsai. Со временем можно ожидать появления фреймворков разработки, которые абстрагируют вопрос о том, выполняется ли фрагмент логики через ZK-доказательство или ончейн — компилятор или инструментарий могут принимать решение на основе стоимости.

Сравнение FHE-VM и ZK-копроцессоров​

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

АспектFHE-VM (Зашифрованное ончейн-выполнение)ZK-копроцессор (Внечейновое доказательство)
Где происходят вычисленияНепосредственно ончейн (все узлы выполняют гомоморфные операции над шифротекстами).Вне сети (прувер или сеть выполняют программу ; в сети проверяется только доказательство).
Конфиденциальность данныхПолное шифрование : данные постоянно остаются зашифрованным в сети ; валидаторы никогда не видят открытый текст. Только владельцы ключей дешифрования могут расшифровать результаты.Нулевое разглашение : частные входные данные прувера никогда не раскрываются в сети ; доказательство не раскрывает секретов, кроме тех, что содержатся в публичных результатах. Однако любые данные, используемые в вычислениях, которые должны влиять на состояние сети, должны быть закодированы в выходных данных или обязательствах. Секреты по умолчанию остаются вне сети.
Модель доверияДоверие к консенсусному выполнению и криптографии : если большинство валидаторов следует протоколу, зашифрованное выполнение является детерминированным и правильным. Для корректности вычислений не требуется внешнего доверия (все узлы пересчитывают их). Для приватности необходимо доверять безопасности схемы FHE (обычно основанной на сложности решеток). В некоторых конструкциях также доверяют тому, что сговор достаточного количества валидаторов для неправомерного использования пороговых ключей невозможен.Доверие к безопасности системы доказательств (обоснованность SNARK/STARK). Если доказательство верифицировано, результат верен с криптографической уверенностью. Внечейновые пруверы не могут обмануть математику. Существует предположение о живучести пруверов для фактического выполнения работы. При использовании доверенной установки (например, SNARK SRS) необходимо доверять тому, что она была создана честно, или использовать прозрачные системы без установки.
Ончейн-стоимость и масштабируемостьВысокая стоимость одной транзакции : гомоморфные операции крайне ресурсоемки, и каждый узел должен их выполнять. Затраты газа высоки (например, более 100 000 газа для одного 8-битного сложения). Сложные контракты ограничены тем, что каждый валидатор может вычислить в рамках блока. Пропускная способность намного ниже, чем у обычных смарт-контрактов, если не используется специализированное оборудование. Масштабируемость улучшается за счет более быстрой криптографии и аппаратного ускорения, но фундаментально каждая операция увеличивает нагрузку на сеть.Низкая стоимость верификации : проверка лаконичного доказательства эффективна и имеет постоянный размер, поэтому ончейн-газ умерен (сотни тысяч газа для вычислений любого размера). Это отделяет сложность от ончейн-лимитов ресурсов — крупные вычисления не несут дополнительных затрат газа. Таким образом, это масштабируется с точки зрения нагрузки на сеть. Вне сети время доказательства может быть значительным (минуты или более для огромных задач) и может требовать мощных машин, но это не замедляет блокчейн напрямую. Общая пропускная способность может быть высокой, пока доказательства генерируются вовремя (возможны параллельные сети пруверов).
Задержка (Latency)Результаты доступны немедленно в той же транзакции/блоке, так как вычисления происходят во время выполнения. Нет дополнительных этапов — синхронная работа. Однако длительное время обработки блока может увеличить задержку блокчейна, если операции FHE медленные.По своей природе асинхронны. Обычно требуется одна транзакция для запроса и последующая транзакция (или callback) для предоставления доказательства/результата. Это вносит задержку (возможно, от секунд до часов в зависимости от сложности и оборудования для доказательства). Не подходит для мгновенной финализации одной транзакции — скорее модель асинхронной задачи.
Гарантии приватностиСильные : всё (входные, выходные данные, промежуточное состояние) может оставаться зашифрованным в сети. Можно иметь долгоживущее зашифрованное состояние, которое обновляют несколько транзакций, никогда его не раскрывая. Только авторизованные действия по дешифрованию (если они есть) раскрывают результаты, и их можно контролировать с помощью ключей/ACL. Тем не менее, необходимо управлять аспектами побочных каналов, такими как использование газа или журналы событий, чтобы они не допускали утечки паттернов (дизайны fhEVM стремятся к выполнению, не зависящему от данных, с постоянным газом для операций во избежание утечек).Выборочные : доказательство раскрывает то, что содержится в публичных результатах или необходимо для верификации (например, обязательство к начальному состоянию). Разработчики могут гарантировать, что раскрывается только целевой результат, а все остальные входные данные остаются скрытыми благодаря нулевому разглашению. Но в отличие от FHE, блокчейн обычно не хранит скрытое состояние — приватность достигается за счет того, что данные полностью остаются вне сети. Если требуется постоянное приватное состояние, контракт может хранить его криптографическое обязательство (так что обновления состояния все равно раскрывают новое обязательство каждый раз). Приватность ограничена тем, что вы решите доказать ; у вас есть гибкость доказать, например, что порог был достигнут, не раскрывая точных значений.

| Обеспечение целостности | По конструкции все валидаторы гомоморфно пересчитывают следующее состояние, поэтому если злоумышленник предоставит неверный результат в виде шифротекста, остальные обнаружат несоответствие — консенсус не будет достигнут, пока все не получат одинаковый результат. Таким образом, целостность обеспечивается избыточным выполнением (как в обычном блокчейне, только над зашифрованными данными). Дополнительные ZK-доказательства часто используются для обеспечения соблюдения бизнес-правил (например, что пользователь не нарушил ограничение), так как валидаторы не могут напрямую проверять условия в открытом тексте. | Целостность обеспечивается контрактом-верификатором, проверяющим ZK-доказательство. Пока доказательство проходит проверку, результат гарантированно соответствует некоторому валидному выполнению внечейновой программы. Для корректности не требуется предположение о честном большинстве — достаточно даже одного честного верификатора (самого кода контракта). Ончейновый контракт просто отклонит любое ложное или отсутствующее доказательство (подобно тому, как он отклонил бы недействительную подпись). Один нюанс: если прувер прервет работу или задержит её, контракту может понадобиться резервная логика (или пользователям придется повторить попытку позже), но он не примет неверные результаты. | | Опыт разработчика | Плюсы: Можно в значительной степени использовать знакомые языки смарт-контрактов (Solidity и др.) с расширениями. Конфиденциальность обрабатывается платформой — разработчики беспокоятся в основном о том, что именно шифровать и кто владеет ключами. Возможна композиция зашифрованных и обычных контрактов, что сохраняет компонуемость DeFi (просто с зашифрованными переменными). Минусы: Необходимо понимать ограничения FHE — например, отсутствие прямых условных переходов по секретным данным без специальной обработки, ограниченная глубина схемы (хотя бутстрапинг в TFHE позволяет выполнять вычисления произвольной длины за счет времени). Отладка зашифрованной логики может быть сложной, так как вы не можете легко просматривать значения во время выполнения без ключа. Также управление ключами и распределение прав доступа усложняют проектирование контракта. | Плюсы: Потенциальная возможность использовать любой язык программирования для внечейновой части (особенно с zkVM). Использование существующего кода/библиотек во внечейновой программе (с оговорками относительно ZK-совместимости). Разработчику не требуется специальная криптография при использовании общей zkVM — он пишет обычный код и получает доказательство. Кроме того, тяжелые вычисления могут использовать библиотеки (например, код машинного обучения), которые никогда бы не запустились ончейн. Минусы: Разработчики должны координировать внечейновую инфраструктуру или использовать сервис доказательств. Обработка асинхронных рабочих процессов и их интеграция с ончейн-логикой требуют больше проектной работы (например, хранение ожидающего состояния, ожидание обратного вызова). Написание эффективных схем или кода для zkVM может потребовать изучения новых ограничений (например, отсутствие плавающей запятой, использование фиксированной запятой или специальных примитивов; избегание тяжелого ветвления, которое раздувает время доказательства; оптимизация количества ограничений). Также существует нагрузка, связанная с обработкой сбоев доказательств, таймаутов и т. д., которые не являются проблемой в обычном Solidity. Экосистема инструментов растет, но для многих это новая парадигма. |

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

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

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

Конфиденциальный DeFi и финансы​

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

  • Приватные транзакции и скрытые балансы: С помощью FHE можно реализовать конфиденциальные переводы токенов (зашифрованные балансы ERC-20 и транзакции) или экранированные пулы на L1 блокчейне. Ни один наблюдатель не сможет увидеть, сколько токенов вы храните или перевели, что устраняет риск целевых атак на основе ваших активов. ZK-доказательства могут гарантировать синхронизацию балансов и отсутствие двойных трат (аналогично Zcash, но на платформах смарт-контрактов). Примером является конфиденциальный AMM (автоматизированный маркет-мейкер), где резервы пула и сделки зашифрованы ончейн. Арбитражники или фронтраннеры не могут эксплуатировать пул, так как они не видят проскальзывание цены до завершения сделки, что снижает MEV. Только после некоторой задержки или через механизм контроля доступа часть данных может быть раскрыта для аудита.

  • Аукционы и торговля, устойчивые к MEV: Майнеры и боты используют прозрачность транзакций для фронтраннинга сделок. С помощью шифрования можно создать зашифрованный мемпул или пакетные аукционы, где ордера подаются в виде шифротекста. Сделки дешифруются только после закрытия аукциона. Эта концепция, иногда называемая Fair Order Flow (справедливый поток ордеров), может быть реализована с помощью пороговой дешифровки (несколько валидаторов коллективно расшифровывают пакет) или путем доказательства результатов аукциона через ZK без раскрытия индивидуальных ставок. Например, ZK-копроцессор может принять пакет запечатанных ставок вне сети, вычислить цену закрытия аукциона и выдать только эту цену и список победителей с доказательствами. Это сохраняет справедливость и конфиденциальность проигравших ставок.

  • Конфиденциальное кредитование и деривативы: В DeFi-кредитовании пользователи могут не хотеть раскрывать размер своих займов или залога (это может повлиять на рыночные настроения или спровоцировать эксплуатацию). FHE-VM может поддерживать зашифрованную книгу займов, где детали каждого кредита зашифрованы. Логика смарт-контракта по-прежнему может обеспечивать соблюдение правил, таких как условия ликвидации, оперируя зашифрованными показателями здоровья займа. Если коэффициент обеспечения займа падает ниже порогового значения, контракт (с помощью ZK-доказательств) может пометить его для ликвидации, не раскрывая точных значений — он может просто выдать флаг "да/нет" в открытом тексте. Аналогично, секретные позиции по деривативам или опционам могут управляться ончейн с раскрытием только агрегированных показателей риска. Это предотвратит копитрейдинг и защитит проприетарные стратегии, стимулируя участие институционалов.

  • Соответствие регуляторным нормам при сохранении приватности: Не во всех финансовых контекстах нужна полная анонимность; иногда для регулирования требуется избирательное раскрытие. С помощью этих инструментов мы можем достичь регулируемой приватности: например, сделки приватны для общественности, но регулируемая биржа может расшифровать или получить доказательства определенных свойств. Можно доказать через ZK, что "эта сделка не связана с адресом из черного списка и обе стороны прошли проверку KYC", не раскрывая личности в сети. Этот баланс может удовлетворить правила по борьбе с отмыванием денег (AML), сохраняя при этом личности и позиции пользователей в секрете от всех остальных. FHE может позволить ончейн-контракту офицера по комлпаенсу сканировать зашифрованные транзакции на наличие сигналов риска (с ключом расшифровки, доступным, например, только по решению суда).

Цифровая идентичность и персональные данные​

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

  • Учетные данные с нулевым разглашением: Используя ZK-доказательства (уже распространенные в некоторых проектах идентификации), пользователь может доказать такие утверждения, как "мне больше 18 лет", "у меня есть действующие водительские права" или "мой доход превышает 50 000 долларов (для кредитного скоринга)", не раскрывая никакой другой личной информации. ZK-копроцессоры могут расширить это, обрабатывая более сложные проверки вне сети, например, доказывая, что кредитный рейтинг пользователя выше порога, путем запроса к приватной кредитной базе данных в стиле Axiom, выдавая блокчейну только ответ "да/нет".

  • Конфиденциальный KYC в DeFi: Представьте себе DeFi-протокол, который по закону должен гарантировать, что пользователи прошли KYC. С помощью FHE-VM учетные данные пользователя могут храниться в зашифрованном виде ончейн (или по ссылке через DID), а смарт-контракт может выполнять FHE-вычисления для проверки соответствия KYC требованиям. Например, контракт может гомоморфно проверить, совпадают ли имя и номер социального страхования в зашифрованном профиле пользователя со списком санкционных лиц (также зашифрованным), или что страна пользователя не ограничена. Контракт получит только зашифрованный результат "пройдено/не пройдено", который может быть расшифрован валидаторами сети в логический флаг. Раскрывается только факт допуска пользователя, сохраняя конфиденциальность PII (персонально идентифицируемой информации) и соблюдая принципы GDPR. Такое избирательное раскрытие обеспечивает и комлпаенс, и приватность.

  • Доступ на основе атрибутов и избирательное раскрытие: Пользователи могут хранить множество верифицируемых учетных данных (возраст, гражданство, навыки и т. д.) как зашифрованные атрибуты. Они могут разрешать определенным dApps выполнять вычисления над ними без раскрытия всего объема данных. Например, децентрализованное приложение для рекрутинга может фильтровать кандидатов, выполняя поиск по зашифрованным резюме (используя FHE) — например, подсчитать годы опыта, проверить наличие сертификата — и только если соответствие найдено, связаться с кандидатом вне сети. Личные данные кандидата остаются зашифрованными, пока он сам не решит их раскрыть. ZK-доказательства также позволяют пользователям выборочно доказывать, что они обладают комбинацией атрибутов (например, старше 21 года и проживают в определенном почтовом индексе) без раскрытия самих значений.

  • Многосторонняя проверка личности: Иногда личность пользователя должна быть проверена несколькими сторонами (например, проверка биографии компанией А, кредитная проверка компанией Б). С помощью гомоморфных и ZK-инструментов каждый проверяющий может внести зашифрованный балл или одобрение, а смарт-контракт может агрегировать их для принятия окончательного решения, не раскрывая отдельные вклады. Например, три агентства предоставляют зашифрованные биты "пройдено/не пройдено", и контракт выдает одобрение, если все три — "пройдено". Пользователь или полагающаяся сторона видят только конечный результат, а не то, какое конкретно агентство могло отказать, что сохраняет приватность записей пользователя в каждом агентстве. Это может снизить предвзятость и стигматизацию.

Здравоохранение и обмен конфиденциальными данными​

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

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

  • Страховые выплаты с сохранением приватности: Обработка претензий по медицинскому страхованию может быть автоматизирована с помощью смарт-контрактов, которые проверяют условия на медицинских данных, не раскрывая их страховщику. Претензия может включать зашифрованный код диагноза и зашифрованную стоимость лечения; контракт, используя FHE, проверяет правила полиса (например, покрытие, франшизу) на этих зашифрованных данных. Он может выдать одобрение и сумму выплаты, так и не раскрыв фактический диагноз в блокчейне страховщика (ключ есть только у пациента и врача). ZK-доказательства могут использоваться для подтверждения того, что данные пациента поступили из сертифицированных записей больницы (используя что-то вроде Axiom для проверки подписи больницы), не раскрывая саму запись. Это обеспечивает приватность пациента при предотвращении мошенничества.

  • Вычисления над геномными и персональными данными: Геномные данные чрезвычайно чувствительны (это буквально ДНК-чертеж человека). Однако анализ геномов может дать ценную информацию о здоровье. Компании могут использовать FHE-VM для выполнения вычислений над зашифрованными геномами, загруженными пользователями. Например, смарт-контракт может запустить модель оценки риска "гены-среда" на зашифрованных геномных данных и зашифрованных данных об окружающей среде (возможно, с носимых устройств), выдавая оценку риска, которую может расшифровать только пользователь. Логика (возможно, алгоритм полигенной оценки риска) закодирована в контракте и выполняется гомоморфно, поэтому геномные данные никогда не появляются в открытом виде. Таким образом, пользователи получают ценные сведения, не передавая компаниям необработанные данные ДНК, что снимает опасения как по поводу приватности, так и владения данными.

  • Эпидемиология и общественное здравоохранение: В таких ситуациях, как пандемии, обмен данными жизненно важен для моделирования распространения болезней, но законы о приватности могут этому мешать. ZK-копроцессоры могут позволить органам здравоохранения отправлять запросы типа "Сколько людей в регионе X получили положительный результат теста за последние 24 часа?" к сети данных больниц через доказательства. Каждая больница хранит записи тестов пациентов вне сети, но может доказать контракту ведомства количество положительных случаев, не раскрывая имен. Аналогично, отслеживание контактов может выполняться путем сопоставления зашифрованных маршрутов перемещения: контракты могут вычислять пересечения зашифрованных историй местоположений пациентов для выявления очагов, выдавая только координаты очагов (и, возможно, зашифрованный список затронутых ID, который может расшифровать только минздрав). Исходные маршруты перемещения отдельных лиц остаются приватными.

Рынки данных и сотрудничество​

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

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

  • Федеративное обучение и децентрализованный ИИ: В децентрализованном машинном обучении несколько сторон (например, разные компании или устройства) хотят совместно обучить модель на своих объединенных данных, не делясь ими друг с другом. FHE-VM здесь незаменимы: они позволяют реализовать федеративное обучение, где обновления моделей каждой стороны гомоморфно агрегируются контрактом. Поскольку обновления зашифрованы, ни один участник не узнает вклад других. Контракт может даже выполнять части цикла обучения (например, шаги градиентного спуска) ончейн под шифрованием, создавая обновленную модель, которую могут расшифровать только авторизованные стороны. ZK может дополнить это, доказывая, что обновление каждой стороны было вычислено в соответствии с алгоритмом обучения (предотвращая отравление модели вредоносным участником). Это означает, что глобальная модель может быть обучена с полной возможностью аудита ончейн, но обучающие данные каждого участника остаются приватными. Примеры использования включают совместное обучение моделей обнаружения мошенничества в разных банках или улучшение ИИ-ассистентов без централизации необработанных данных.

  • Межорганизационная аналитика: Рассмотрим две компании, которые хотят найти пересечение своих клиентов для партнерской кампании, не раскрывая друг другу полные списки клиентов. Они могут зашифровать свои списки идентификаторов клиентов и загрузить обязательство (commitment). Контракт с поддержкой FHE может вычислить пересечение на зашифрованных наборах (используя методы приватного пересечения множеств через FHE). Результатом может быть зашифрованный список общих ID клиентов, который может расшифровать только доверенная третья сторона (или сами клиенты через определенный механизм). Альтернативно, подход ZK: одна сторона доказывает другой с нулевым разглашением, что "у нас есть N общих клиентов, и вот шифрование этих ID" с доказательством того, что шифрование действительно соответствует общим записям. Таким образом, они могут начать кампанию для этих N клиентов, не обмениваясь полными списками в открытом виде. Аналогичные сценарии: вычисление метрик цепочки поставок между конкурентами без раскрытия данных о конкретных поставщиках или объединение кредитной информации банками без обмена полными данными о клиентах.

  • Безопасные многосторонние вычисления (MPC) на блокчейне: FHE и ZK, по сути, переносят концепции MPC ончейн. Сложная бизнес-логика, охватывающая несколько организаций, может быть закодирована в смарт-контракте так, что входные данные каждой организации будут секретно распределены или зашифрованы. Контракт (как фасилитатор MPC) выдает результаты, такие как разделение прибыли, расчет затрат или совместная оценка рисков, которым все могут доверять. Например, несколько энергетических компаний хотят провести расчеты на рынке торговли электроэнергией. Они могут подать свои зашифрованные заявки и предложения в аукционный смарт-контракт; контракт вычисляет цены закрытия и распределение на основе зашифрованных заявок и выдает каждой компании её распределение и стоимость только этой компании (путем шифрования на её публичный ключ). Ни одна компания не видит заявок других, что защищает конкурентную информацию, но результат аукциона честен и верифицируем. Эта комбинация прозрачности блокчейна и приватности MPC может произвести революцию в консорциумах и корпоративных объединениях, которые сейчас полагаются на доверенных посредников.

Децентрализованное машинное обучение (ZKML и FHE-ML)​

Внедрение машинного обучения в блокчейны верифицируемым и приватным способом — это новый рубеж:

  • Верифицируемый вывод (инференс) ML: Используя ZK-доказательства, можно доказать, что "модель машинного обучения f при заданном входе x выдает результат y", не раскрывая либо x (если это приватные данные), либо внутреннюю работу f (если веса модели проприетарны). Это критически важно для ИИ-сервисов на блокчейне — например, для децентрализованного ИИ-оракула, который предоставляет прогнозы или классификации. ZK-копроцессор может запустить модель вне сети (так как модели могут быть большими и дорогими в расчете) и опубликовать доказательство результата. Например, оракул может доказать утверждение: "Предоставленный спутниковый снимок показывает наличие лесного покрова не менее 50%" для поддержки контракта на углеродные кредиты, не раскрывая сам снимок или, возможно, саму модель. Это известно как ZKML, и проекты работают над оптимизацией нейросетей, "дружественных" к схемам доказательств. Это гарантирует целостность выводов ИИ, используемых в смарт-контрактах, и может сохранять конфиденциальность входных данных и параметров модели.

  • Обучение с приватностью и аудитом: Обучение ML-модели требует еще больших вычислительных затрат, но если это станет достижимым, это позволит создать блокчейн-маркетплейсы моделей. Несколько поставщиков данных могли бы участвовать в обучении модели под FHE, чтобы алгоритм обучения работал на зашифрованных данных. Результатом может быть зашифрованная модель, которую может расшифровать только покупатель. На протяжении всего процесса обучения могут периодически предоставляться ZK-доказательства, подтверждающие, что обучение шло по протоколу (предотвращая, например, вставку бэкдора вредоносным тренером). Хотя полностью ончейн-обучение ML пока далеко из-за затрат, гибридный подход может использовать внечейновые вычисления с ZK-доказательствами для критических частей. Можно представить децентрализованное соревнование типа Kaggle, где участники обучают модели на приватных наборах данных и отправляют ZK-доказательства точности модели на зашифрованных тестовых данных для определения победителя — и всё это без раскрытия самих датасетов или тестовых данных.

  • Персонализированный ИИ и владение данными: С помощью этих технологий пользователи смогут сохранять право собственности на свои личные данные и при этом пользоваться преимуществами ИИ. Например, мобильное устройство пользователя может использовать FHE для шифрования данных об использовании и отправлять их в аналитический контракт, который вычисляет персонализированную модель ИИ (например, рекомендательную модель) только для него. Модель зашифрована, и только устройство пользователя может расшифровать и использовать её локально. Платформа (возможно, социальная сеть) никогда не видит необработанные данные или модель, но пользователь получает преимущества ИИ. Если платформа хочет получить агрегированную информацию, она может запросить ZK-доказательства определенных агрегированных паттернов у контракта без доступа к индивидуальным данным.

Дополнительные области​

  • Игры: Ончейн-игры часто сталкиваются с трудностями при скрытии секретной информации (например, скрытые карты в руке, "туман войны" в стратегиях). FHE позволяет создавать игры со скрытым состоянием, где игровая логика работает на зашифрованном состоянии. Например, контракт для игры в покер может тасовать и раздавать зашифрованные карты; игроки получают дешифровку своих собственных карт, но контракт и другие видят только шифротекст. Логика ставок может использовать ZK-доказательства, чтобы гарантировать, что игрок не блефует по поводу действия (или чтобы раскрыть выигрышную руку в конце верифицируемо честным способом). Аналогично, случайные числа для минтинга NFT или игровых исходов могут генерироваться и доказываться как честные без раскрытия исходного значения (seed), что предотвращает манипуляции. Это может значительно улучшить блокчейн-игры, позволяя им поддерживать ту же динамику, что и традиционные игры.

  • Голосование и управление: DAO могут использовать технологии приватности для тайного голосования ончейн, исключая подкуп голосов и давление. FHE-VM может подсчитывать голоса, поданные в зашифрованном виде, и только итоговые суммы будут расшифрованы. ZK-доказательства могут подтвердить, что каждый голос был действительным (поступил от имеющего право голоса участника, который не голосовал дважды), не раскрывая, кто за что проголосовал. Это обеспечивает верифицируемость (каждый может проверить доказательства и подсчет), сохраняя при этом индивидуальные голоса в секрете, что крайне важно для непредвзятого управления.

  • Безопасные цепочки поставок и IoT: В цепочках поставок партнеры могут захотеть поделиться доказательством определенных свойств (происхождение, показатели качества), не раскрывая полных деталей конкурентам. Например, датчик IoT на партии продуктов питания может непрерывно отправлять зашифрованные данные о температуре в блокчейн. Контракт может использовать FHE, чтобы проверить, оставалась ли температура в безопасном диапазоне на протяжении всего пути. Если порог был превышен, это может вызвать оповещение или штраф, но при этом нет необходимости публично раскрывать весь журнал температур — возможно, только доказательство или агрегат, такой как "90-й процентиль температуры". Это укрепляет доверие к автоматизации цепочек поставок при соблюдении конфиденциальности технологических данных.

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

Для разработчиков эти технологии представят новые паттерны проектирования. Мы будем мыслить категориями зашифрованных переменных и верификации доказательств как первоклассных элементов архитектуры dApp. Инструментарий стремительно развивается: языки высокого уровня и SDK абстрагируют криптографические детали (например, библиотеки Zama делают типы FHE такими же простыми, как нативные типы, или шаблоны RISC Zero для запросов на доказательства). Через несколько лет написание конфиденциального смарт-контракта может стать почти таким же простым, как написание обычного, но с конфиденциальностью, «встроенной» по умолчанию.

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

Мы все еще находимся на ранних этапах — текущие прототипы FHE-VM имеют ограничения производительности, а ZK-доказательства, хотя и стали намного быстрее, все еще могут быть узким местом для чрезвычайно сложных задач. Но непрерывные исследования и инженерные усилия (включая специализированное оборудование, например, разработки компаний вроде Optalysys, продвигающих оптическое ускорение FHE) быстро устраняют эти барьеры. Финансирование, вливающееся в это пространство (например, статус «единорога» у Zama, инвестиции Paradigm в Axiom), подчеркивает сильную веру в то, что функции конфиденциальности будут так же фундаментальны для Web3, как прозрачность была для Web1/2.

В заключение, программируемая конфиденциальность на базе FHE-VM и ZK-копроцессоров знаменует появление нового класса dApp, которые являются трастлесс-решениями, децентрализованными и конфиденциальными. От сделок в DeFi, которые не раскрывают деталей, до медицинских исследований, защищающих данные пациентов, и моделей машинного обучения, обучаемых по всему миру без раскрытия исходных данных — возможности безграничны. По мере созревания этих технологий блокчейн-платформы больше не будут вынуждать выбирать между полезностью и конфиденциальностью, что обеспечит более широкое внедрение в отраслях, требующих конфиденциальности. Будущее Web3 — это мир, где пользователи и организации могут уверенно совершать транзакции и проводить вычисления с конфиденциальными данными ончейн, зная, что блокчейн подтвердит их целостность, сохраняя их секреты в безопасности.

Источники: Информация в данном отчете взята из технической документации и недавних блогов разработчиков ведущих проектов в этой области, включая документацию FHEVM от Cypher и Zama, подробные анализы схем Axiom от Trail of Bits, руководства для разработчиков и посты в блогах RISC Zero, а также отраслевые статьи, освещающие варианты использования конфиденциальных блокчейн-технологий. Эти и другие источники цитировались на протяжении всего текста для предоставления дополнительной информации и подтверждения описанных архитектур и приложений.

Share on Twitter