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

38 постов с тегом "Криптография"

Криптографические протоколы и методы

Посмотреть все теги

MPC-сеть Ika при поддержке Sui Foundation — комплексная техническая и инвестиционная оценка

· 38 мин чтения

Введение

Ika — это параллельная сеть многосторонних вычислений (MPC), стратегически поддерживаемая Sui Foundation. Ранее известная как dWallet Network, Ika разработана для обеспечения кроссчейн-совместимости с нулевым доверием (zero-trust) на высокой скорости и в больших масштабах. Она позволяет смарт-контрактам (особенно в блокчейне Sui) безопасно контролировать и координировать активы в других блокчейнах без использования традиционных мостов. В этом отчете представлен глубокий анализ технической архитектуры и криптографического дизайна Ika с точки зрения основателя, а также бизнес- и инвестиционный анализ, охватывающий команду, финансирование, токеномику, внедрение и конкуренцию. Для контекста также включена сводная таблица сравнения Ika с другими сетями на базе MPC (Lit Protocol, Threshold Network и Zama).

Сеть Ika

Техническая архитектура и особенности (точка зрения основателя)

Архитектура и криптографические примитивы

Основная инновация Ika заключается в новой криптографической схеме «2PC-MPC» — двухсторонних вычислениях в рамках структуры многосторонних вычислений. Простыми словами, процесс подписания всегда вовлекает две стороны: (1) пользователя и (2) сеть Ika. Пользователь сохраняет долю закрытого ключа, а сеть, состоящая из множества независимых узлов, владеет другой долей. Подпись может быть создана только при участии обеих сторон, что гарантирует: сеть сама по себе никогда не сможет подделать подпись без участия пользователя. Сторона сети — это не единая сущность, а распределенные MPC среди N валидаторов, которые коллективно действуют как вторая сторона. Пороговое значение не менее двух третей этих узлов должно прийти к согласию (аналогично консенсусу Byzantine Fault Tolerance) для генерации сетевой доли подписи. Эта структура вложенных MPC (пользователь + сеть) делает Ika защищенной от сговора (non-collusive): даже если все узлы Ika вступят в сговор, они не смогут украсть активы пользователя, поскольку участие пользователя (его доля ключа) всегда криптографически необходимо. Другими словами, Ika обеспечивает безопасность «zero-trust», поддерживая принципы децентрализации и владения пользователями в Web3 — ни одна организация или небольшая группа не может в одностороннем порядке скомпрометировать активы.

Рисунок: Схема архитектуры 2PC-MPC от Ika — пользователь выступает в качестве одной стороны (храня долю приватного ключа), а сеть Ika из N валидаторов формирует другую сторону через пороговый протокол MPC (t-из-N). Это гарантирует, что для создания действительной подписи должны сотрудничать как пользователь, так и квалифицированное большинство децентрализованных узлов.

Технически Ika реализована как автономная блокчейн-сеть, ответвленная от кодовой базы Sui. Она запускает собственный экземпляр высокопроизводительного механизма консенсуса Sui (Mysticeti, протокол BFT на основе DAG) для координации узлов MPC. Примечательно, что в версии Sui от Ika отключены смарт-контракты (цепь Ika существует исключительно для работы протокола MPC) и включены пользовательские модули для алгоритма подписания 2PC-MPC. Mysticeti обеспечивает надежный канал вещания между узлами, заменяя сложную сеть одноранговых сообщений, которую используют традиционные протоколы MPC. Используя консенсус на основе DAG для связи, Ika избегает экспоненциальных накладных расходов на связь, характерных для более ранних схем пороговой подписи, где каждой из n сторон требовалось отправлять сообщения всем остальным. Вместо этого узлы Ika транслируют сообщения через консенсус, достигая линейной сложности коммуникации O(n) и используя методы пакетной обработки и агрегации для поддержания затрат на каждый узел почти постоянными даже при значительном росте N. Это представляет собой значительный прорыв в пороговой криптографии: команда Ika заменила двухточечную связь «unicast» эффективным вещанием (broadcast) и агрегацией, что позволяет протоколу поддерживать сотни или тысячи участников без замедления работы.

Интеграция с нулевым разглашением: В настоящее время безопасность Ika достигается за счет пороговой криптографии и консенсуса BFT, а не явных доказательств с нулевым разглашением. Система не полагается на zk-SNARKs или zk-STARKs в своем основном процессе подписания. Тем не менее, Ika использует ончейн доказательства состояния (доказательства легкого клиента) для проверки событий из других цепочек, что является формой криптографической проверки (например, проверка доказательств Меркла для заголовков блоков или состояния). Дизайн оставляет место для интеграции методов нулевого разглашения в будущем — например, для проверки состояния кроссчейн-активов или условий без раскрытия конфиденциальных данных — но по состоянию на 2025 год ни один конкретный модуль zk-SNARK не является частью опубликованной архитектуры Ika. Основное внимание уделяется принципу «zero-trust» (отсутствие предположений о доверии) через схему 2PC-MPC, а не системам доказательств с нулевым разглашением.

Производительность и масштабируемость

Основная цель Ika — преодолеть узкие места в производительности предыдущих сетей MPC. Устаревшие протоколы пороговой подписи (такие как Lindell 2PC ECDSA или GG20) с трудом поддерживали более нескольких участников, часто затрачивая много секунд или минут на создание одной подписи. В отличие от них, оптимизированный протокол Ika достигает субсекундной задержки при подписании и может обрабатывать очень высокую пропускную способность запросов на подпись параллельно. Данные бенчмарков указывают на то, что Ika может масштабироваться до 10 000 подписей в секунду, сохраняя при этом безопасность в большом кластере узлов. Это стало возможным благодаря вышеупомянутой линейной связи и активному использованию батчинга: сеть может генерировать множество подписей одновременно за один раунд протокола, резко снижая средние затраты. По заявлению команды, Ika может работать в 10 000 раз быстрее, чем существующие сети MPC под нагрузкой. На практике это означает, что высокочастотные транзакции в реальном времени (такие как торговля или кроссчейн-операции DeFi) могут поддерживаться без обычных задержек порогового подписания. Задержка находится на уровне субсекундной финальности, что означает, что подпись (и соответствующая кроссчейн-операция) может быть завершена почти мгновенно после запроса пользователя.

Не менее важно и то, что Ika делает это, масштабируя количество подписантов для усиления децентрализации. Традиционные конфигурации MPC часто использовали фиксированный комитет из 10–20 узлов, чтобы избежать падения производительности. Архитектура Ika может расширяться до сотен или даже тысяч валидаторов, участвующих в процессе подписания без значительного замедления. Такая массовая децентрализация повышает безопасность (злоумышленнику сложнее подкупить большинство) и надежность сети. Лежащий в основе консенсус является византийски отказоустойчивым, поэтому сеть может выдержать компрометацию или отключение до одной трети узлов и продолжать корректно функционировать. В любой конкретной операции подписания только пороговое значение t-из-N узлов (например, 67% от N) должно активно участвовать; по замыслу, если слишком много узлов отключено, подпись может быть задержана, но система спроектирована так, чтобы изящно справляться с типичными сценариями сбоев (аналогично свойствам живучести и безопасности консенсуса блокчейна). В итоге Ika достигает как высокой пропускной способности, так и большого количества валидаторов — комбинация, которая выделяет её на фоне ранних MPC-решений, которым приходилось жертвовать децентрализацией ради скорости.

Инструменты для разработчиков и интеграция

Сеть Ika создана для того, чтобы быть удобной для разработчиков, особенно для тех, кто уже строит на базе Sui. Разработчики не пишут смарт-контракты непосредственно в сети Ika (поскольку сеть Ika не исполняет пользовательские контракты), а вместо этого взаимодействуют с Ika из других сетей. Например, контракт Sui Move может вызывать функции Ika для подписания транзакций во внешних сетях. Для облегчения этого процесса Ika предоставляет надежный инструментарий и SDK:

  • TypeScript SDK: Ika предлагает TypeScript SDK (библиотека Node.js), который повторяет стиль Sui SDK. Этот SDK позволяет разработчикам создавать и управлять dWallets (децентрализованными кошельками) и отправлять запросы на подписание в Ika из своих приложений. Используя TS SDK, разработчики могут генерировать пары ключей, регистрировать доли пользователей и вызывать RPC Ika для координации пороговых подписей — и все это с использованием знакомых паттернов API Sui. SDK абстрагирует сложность протокола MPC, делая процесс таким же простым, как вызов функции для запроса (например) подписи транзакции Bitcoin при наличии соответствующего контекста и одобрения пользователя.

  • CLI и локальная сеть: Для более прямого взаимодействия доступен интерфейс командной строки (CLI) под названием dWallet CLI. Разработчики могут запустить локальный узел Ika или даже локальную тестовую сеть, создав форк открытого репозитория. Это полезно для тестирования и интеграции в среде разработки. Документация содержит руководство по настройке локальной сети разработки (devnet), получению токенов тестнета (DWLT — токен тестовой сети) и созданию первого адреса dWallet.

  • Документация и примеры: Документация Ika включает пошаговые руководства для распространенных сценариев, таких как «Ваш первый dWallet». В них показано, как создать dWallet, соответствующий адресу в другой сети (например, адрес Bitcoin, управляемый ключами Ika), как зашифровать долю ключа пользователя для безопасного хранения и как инициировать кроссчейн-транзакции. Примеры кода охватывают такие варианты использования, как перевод BTC через вызов смарт-контракта Sui или планирование будущих транзакций (функция, которую поддерживает Ika, позволяющая предварительно подписывать транзакции при определенных условиях).

  • Интеграция с Sui (легкие клиенты): Ika «из коробки» тесно интегрирована с блокчейном Sui. Сеть Ika внутренне запускает легкий клиент Sui для бездоверительного чтения данных Sui ончейн. Это означает, что смарт-контракт Sui может инициировать событие или вызов, который Ika распознает (через доказательство состояния) как триггер для выполнения действия. Например, контракт Sui может проинструктировать Ika: «когда произойдет событие X, подпиши и транслируй транзакцию в Ethereum». Узлы Ika проверят событие Sui с помощью доказательства легкого клиента, а затем коллективно создадут подпись для транзакции Ethereum. Подписанная полезная нагрузка может быть доставлена в целевую сеть (возможно, через оффчейн-релейер или самим пользователем) для выполнения желаемого действия. В настоящее время Sui является первой полностью поддерживаемой управляющей сетью (учитывая происхождение Ika на Sui), но архитектура является мультичейн-ориентированной по своей природе. Поддержка доказательств состояния и интеграция с другими сетями включены в дорожную карту — например, команда упоминала расширение Ika для работы с роллапами в экосистеме Polygon Avail (предоставление возможностей dWallet для роллапов с использованием Avail в качестве уровня данных) и другими уровнями L1 в будущем.

  • Поддерживаемые криптографические алгоритмы: Сеть Ika может генерировать ключи и подписи практически для любой схемы подписи блокчейна. Изначально она поддерживает ECDSA (алгоритм на эллиптических кривых, используемый в Bitcoin, аккаунтах Ethereum ECDSA, BNB Chain и т. д.). В ближайшем будущем планируется поддержка EdDSA (Ed25519, используемый в таких сетях, как Solana и некоторых сетях Cosmos) и подписей Шнорра (например, ключи Schnorr в Bitcoin Taproot). Такая широкая поддержка означает, что dWallet в Ika может иметь адрес в Bitcoin, адрес в Ethereum, в Solana и так далее — все они будут управляться одним и тем же базовым распределенным ключом. Таким образом, разработчики на Sui или других платформах могут интегрировать любую из этих сетей в свои dApps через одну унифицированную среду (Ika), вместо того чтобы иметь дело со специфическими для каждой сети мостами или кастодианами.

В итоге Ika предлагает опыт разработки, схожий с взаимодействием с узлом блокчейна или кошельком, абстрагируясь от сложной криптографии. Будь то через TypeScript SDK или напрямую через контракты Move и легкие клиенты, сеть стремится сделать кроссчейн-логику доступной для разработчиков по принципу «plug-and-play».

Безопасность, децентрализация и отказоустойчивость

Безопасность имеет первостепенное значение в архитектуре Ika. Модель нулевого доверия означает, что ни одному пользователю не нужно доверять сети Ika единоличный контроль над активами в любой момент времени. Если пользователь создает dWallet (скажем, адрес BTC под управлением Ika), закрытый ключ этого адреса никогда не удерживается какой-либо одной стороной — даже самим пользователем в одиночку. Вместо этого пользователь владеет секретной долей, а сеть коллективно владеет другой долей. Обе доли необходимы для подписания любой транзакции. Таким образом, даже если произойдет худший сценарий (например, многие узлы Ika будут скомпрометированы злоумышленником), они все равно не смогут переместить средства без секретной доли ключа пользователя. Это свойство устраняет основной риск традиционных мостов, где кворум валидаторов может вступить в сговор для кражи заблокированных активов. Ika устраняет этот риск, фундаментально меняя структуру доступа (порог установлен таким образом, что одной сети никогда не бывает достаточно — порог фактически включает пользователя). В научной литературе это новая парадигма: MPC-сеть без сговора, где владелец актива по определению остается частью кворума подписания.

Со стороны сети Ika использует модель делегированного доказательства доли владения (Delegated Proof-of-Stake), унаследованную от архитектуры Sui, для выбора и стимулирования валидаторов. Держатели токенов IKA могут делегировать стейк узлам валидаторов; лучшие валидаторы (взвешенные по стейку) становятся полномочными органами на время эпохи и обеспечивают византийскую отказоустойчивость (2/3 честных узлов) в каждой эпохе. Это означает, что система предполагает наличие менее 33% вредоносного стейка для поддержания безопасности. Если валидатор ведет себя некорректно (например, пытается создать неверную долю подписи или цензурировать транзакции), протокол консенсуса и MPC обнаружит это — неверные доли подписи могут быть идентифицированы (они не объединятся в валидную подпись), а вредоносный узел может быть зафиксирован в журнале и потенциально подвергнут слэшингу или удален в будущих эпохах. В то же время живучесть сети сохраняется до тех пор, пока участвует достаточное количество узлов (>67%); консенсус может продолжать финализировать операции, даже если многие узлы внезапно выйдут из строя или отключатся. Такая отказоустойчивость гарантирует надежность сервиса — не существует единой точки отказа, так как в процессе участвуют сотни независимых операторов в различных юрисдикциях. Децентрализация дополнительно усиливается за счет огромного количества участников: Ika не ограничивается фиксированным малым комитетом, поэтому она может привлекать больше валидаторов для повышения безопасности без значительной потери производительности. На самом деле протокол Ika был специально разработан, чтобы «преодолеть лимит узлов MPC-сетей» и обеспечить массовую децентрализацию.

Наконец, команда Ika подвергла свою криптографию внешней проверке. В 2024 году они опубликовали подробный технический документ (whitepaper), описывающий протокол 2PC-MPC, и на данный момент прошли как минимум один аудит безопасности от сторонней организации. Например, в июне 2024 года аудит компании Symbolic Software проверил реализацию протокола 2PC-MPC на языке Rust и связанные с ним криптографические библиотеки Ika. Аудит был сосредоточен на проверке корректности криптографических протоколов (обеспечение отсутствия уязвимостей в схеме пороговой подписи ECDSA, генерации ключей или агрегации долей) и поиске потенциальных уязвимостей. Исходный код является открытым (в GitHub dWallet Labs), что позволяет сообществу проверять его и вносить вклад в безопасность. На этапе альфа-тестирования команда также предупреждала, что программное обеспечение все еще является экспериментальным и еще не прошло производственный аудит, однако проведение текущих аудитов и улучшение безопасности были главными приоритетами перед запуском основной сети. В целом, модель безопасности Ika представляет собой сочетание доказуемых криптографических гарантий (из пороговых схем) и децентрализации уровня блокчейна (из консенсуса PoS и большого набора валидаторов), проверенных экспертами для обеспечения надежной защиты как от внешних злоумышленников, так и от внутреннего сговора.

Совместимость и функциональная совместимость экосистем

Ika специально разработана как уровень функциональной совместимости, изначально для Sui, но с возможностью расширения на многие другие экосистемы. С первого дня ее самая тесная интеграция реализована с блокчейном Sui: фактически она выступает как дополнительный модуль для Sui, расширяя возможности Sui dApps мультичейн-функционалом. Такое тесное взаимодействие продумано специально — контракты Move и объектно-ориентированная модель Sui делают его отличным «контроллером» для dWallets от Ika. Например, DeFi-приложение на Sui может использовать Ika для мгновенного привлечения ликвидности из Ethereum или Bitcoin, превращая Sui в хаб для мультичейн-ликвидности. Поддержка Ika со стороны Sui Foundation указывает на стратегию позиционирования Sui как «базовой сети для каждой сети», использующей Ika для подключения к внешним активам. На практике, когда мейннет Ika будет запущен, разработчик на Sui сможет создать контракт Move, который, скажем, принимает депозиты в BTC: за кулисами этот контракт создаст Bitcoin dWallet (адрес) через Ika и будет выдавать инструкции на перемещение BTC при необходимости. Конечный пользователь воспринимает это так, будто Bitcoin — это просто еще один актив внутри приложения Sui, хотя BTC остается нативным в сети Bitcoin до тех пор, пока транзакция с валидной пороговой подписью не переместит его.

Помимо Sui, архитектура Ika поддерживает другие блокчейны уровня Layer-1, Layer-2 и даже офчейн-системы. Сеть может одновременно содержать несколько легких клиентов, поэтому она способна валидировать состояние из Ethereum, Solana, Avalanche или других сетей — позволяя смарт-контрактам на этих чейнах (или их пользователям) также использовать MPC-сеть Ika. Хотя такие возможности могут внедряться постепенно, целью разработки является чейн-агностичность. В промежуточный период, даже без глубокой ончейн-интеграции, Ika можно использовать в более ручном режиме: например, приложение на Ethereum может вызвать API Ika (через оракул или офчейн-сервис), чтобы запросить подпись для транзакции Ethereum или сообщения. Поскольку Ika поддерживает ECDSA, ее можно использовать даже для децентрализованного управления ключами аккаунта Ethereum, подобно тому как работают PKP в Lit Protocol (мы обсудим Lit позже). Ika также продемонстрировала такие варианты использования, как управление Bitcoin на роллапах — примером является интеграция с фреймворком Polygon Avail, позволяющая пользователям роллапов управлять BTC, не доверяя централизованному кастодиану. Это говорит о том, что Ika может сотрудничать с различными экосистемами (Polygon/Avail, роллапы Celestia и т. д.) в качестве поставщика децентрализованной инфраструктуры ключей.

Подводя итог, с технической точки зрения Ika совместима с любой системой, которая полагается на цифровые подписи, — а это практически все блокчейны. Ее первоначальное развертывание на Sui — это только начало; долгосрочное видение заключается в создании универсального уровня MPC, к которому любая сеть или dApp смогут подключиться для безопасных кроссчейн-операций. Поддерживая общие криптографические стандарты (ECDSA, Ed25519, Schnorr) и обеспечивая необходимую проверку легких клиентов, Ika может стать своего рода сетью «MPC-как-сервис» для всего Web3, объединяя активы и действия с минимальным уровнем доверия.

Бизнес-перспективы и инвестиционный потенциал

Команда основателей и их бэкграунд

Ika была основана командой опытных специалистов в области криптографии и блокчейна, базирующихся в основном в Израиле. Создателем и генеральным директором проекта является Омер Садика (Omer Sadika), предприниматель с богатым опытом в сфере криптобезопасности. Ранее Омер был соучредителем Odsy Network, еще одного проекта, сфокусированного на децентрализованной инфраструктуре кошельков, и является основателем/генеральным директором dWallet Labs — компании, стоящей за Ika. Его послужной список включает обучение в Y Combinator (выпускник YC), а основное внимание он уделяет кибербезопасности и распределенным системам. Опыт Омера в Odsy и dWallet Labs напрямую лег в основу концепции Ika: по сути, Ika можно рассматривать как эволюцию концепции «динамического децентрализованного кошелька», над которой работала Odsy, теперь реализованную в виде MPC-сети на Sui.

Техническим директором и соучредителем Ika является Йехонатан Коэн Скали (Yehonatan Cohen Scaly), эксперт по криптографии, который выступил соавтором протокола 2PC-MPC. Йехонатан руководит исследованиями и разработками (R&D) новых криптографических алгоритмов Ika; ранее он работал в сфере кибербезопасности (вероятно, занимаясь академическими исследованиями в области криптографии). Его цитировали при обсуждении ограничений существующих пороговых схем и того, как подход Ika преодолевает их, что отражает глубокий опыт в MPC и распределенных криптографических протоколах. Еще одним соучредителем является Давид Лахмиш (David Lachmish), который курирует разработку продукта. Роль Давида заключается в переводе базовой технологии в удобные для разработчиков продукты и реальные сценарии использования. Трио Омера, Йехонатана и Давида — вместе с другими исследователями, такими как д-р Долев Муцари (Dolev Mutzari, вице-президент по исследованиям в dWallet Labs) — составляет основу руководства Ika. В совокупности компетенции команды включают в себя создание стартапов, вклад в академические исследования и опыт работы на стыке криптографии, безопасности и блокчейна. Именно благодаря такому глубокому опыту говорят, что Ika создана «одними из ведущих мировых экспертов по криптографии».

Помимо основателей, в более широкую команду и состав консультантов Ika, вероятно, входят люди с серьезным бэкграундом в криптографии. Например, Долев Муцари (упомянутый выше) является соавтором технического документа и сыграл важную роль в разработке протокола. Присутствие таких талантов вселяет в инвесторов уверенность в том, что сложная технология Ika находится в надежных руках. Более того, наличие основателя (Омера), который уже успешно привлекал средства и создавал сообщество вокруг концепций Odsy/dWallet, означает, что Ika извлекает выгоду из уроков, извлеченных в ходе предыдущих итераций идеи. Базирование команды в Израиле — стране, известной своим сектором криптографии и кибербезопасности, — также обеспечивает им доступ к богатому кадровому резерву разработчиков и исследователей.

Раунды финансирования и ключевые инвесторы

Ika (и её материнская компания dWallet Labs) привлекла значительное венчурное финансирование и стратегические инвестиции с момента своего основания. На сегодняшний день проект привлек более **21 млн врамкахнесколькихраундов.Начальныйпосевнойраунд(seedround)вавгусте2022годасоставил5млн** в рамках нескольких раундов. Начальный **посевной раунд (seed round) в августе 2022 года** составил 5 млн , что было весьма примечательно, учитывая условия «медвежьего» рынка в то время. В этот посевной раунд вошел широкий круг известных криптоинвесторов и бизнес-ангелов. Среди заметных участников были Node Capital (ведущий инвестор), Lemniscap, Collider Ventures, Dispersion Capital, Lightshift Capital, Tykhe Block Ventures, Liquid2 Ventures, Zero Knowledge Ventures и другие. Также присоединились видные индивидуальные инвесторы, такие как Навал Равикант (сооснователь AngelList и известный технологический инвестор), Марк Бхаргава (сооснователь Tagomi), Рене Рейнсберг (сооснователь Celo) и ряд других деятелей индустрии. Такой список спонсоров подчеркнул высокое доверие к подходу Ika к децентрализованному хранению (custody) еще на стадии идеи.

В мае 2023 года Ika привлекла дополнительные ~ 7,5 млн врамкахтого,что,повсейвидимости,являетсяраундомСерииAилистратегическимраундом,посообщениям,приоценкеоколо250млнв рамках того, что, по всей видимости, является **раундом Серии A или стратегическим раундом**, по сообщениям, при оценке около 250 млн. Этот раунд возглавили Blockchange Ventures и Node Capital (повторно), при участии Insignius Capital, Rubik Ventures и других. К этому моменту тезис о масштабируемых сетях MPC (многосторонних вычислений) набрал обороты, и прогресс Ika, вероятно, побудил этих инвесторов удвоить свои вложения. Оценка в 250 млн $ для сети на относительно ранней стадии отражала ожидания рынка относительно того, что Ika может стать фундаментальной инфраструктурой в Web3 (сопоставимой с блокчейнами L1 или крупными протоколами DeFi с точки зрения ценности).

Самая резонансная инвестиция состоялась в апреле 2025 года, когда Sui Foundation объявила о стратегических инвестициях в Ika. Это партнерство с экосистемным фондом Sui увеличило общее финансирование Ika до более чем 21 млн $ и закрепило тесную связь с блокчейном Sui. Хотя точная сумма инвестиций Sui Foundation не разглашалась, очевидно, что это было значительное одобрение — вероятно, в размере нескольких миллионов долларов США. Поддержка Sui Foundation носит не только финансовый характер; она также означает, что Ika получает мощную помощь в реализации стратегии выхода на рынок (go-to-market) внутри экосистемы Sui (привлечение разработчиков, поддержка интеграции, маркетинг и т. д.). Согласно пресс-релизам, «Ika… объявила о стратегических инвестициях от Sui Foundation, в результате чего её общее финансирование превысило 21 миллион долларов». Этот стратегический раунд, а не традиционный раунд венчурного капитала, подчеркивает, что Sui рассматривает Ika как критически важную инфраструктуру для будущего своего блокчейна (аналогично тому, как Ethereum Foundation может напрямую поддерживать проект Layer-2 или проект по обеспечению интероперабельности, который приносит пользу Ethereum).

Помимо Sui, стоит отметить других спонсоров: Node Capital (базирующийся в Китае криптофонд, известный ранними инвестициями в инфраструктуру), Lemniscap (крипто-венчурный фонд, специализирующийся на ранних инновациях протоколов) и Collider Ventures (израильский венчурный фонд, вероятно, обеспечивающий локальную поддержку). Примечательно лидерство Blockchange Ventures в раунде 2023 года; Blockchange — это венчурный фонд, который поддержал несколько инфраструктурных криптопроектов, и их лидерство предполагает, что они увидели в технологии Ika потенциал для определения категории. Кроме того, Digital Currency Group (DCG) и Node Capital возглавили сбор средств в размере 5 млн $ для dWallet Labs до ребрендинга Ika (согласно сообщению Омера в LinkedIn) — участие DCG (через более ранний раунд для компании) указывает на еще большую поддержку в фоновом режиме.

Подводя итог, можно сказать, что путь финансирования Ika демонстрирует сочетание традиционных венчурных капиталистов и стратегических партнеров. Участие Sui Foundation особенно выделяется, так как оно предоставляет не только капитал, но и интегрированную экосистему для внедрения технологий Ika. Инвесторы, по сути, делают ставку на то, что Ika станет основным решением для децентрализованного управления ключами и мостов (bridging) во многих сетях, и соответствующим образом оценили проект.

Токеномика и экономическая модель

У Ika будет собственный утилитарный токен под названием $IKA, который занимает центральное место в экономике и модели безопасности сети. Примечательно, что токен IKA запускается в блокчейне Sui (как нативный актив SUI), несмотря на то, что сама сеть Ika является отдельной цепочкой. Это означает, что IKA будет существовать как монета, которую можно хранить и передавать в Sui, как и любой другой актив Sui, и она будет использоваться двойным образом: внутри сети Ika для стейкинга и комиссий, и в Sui для управления или доступа в DApps. Токеномику можно охарактеризовать следующим образом:

  • Комиссии за газ: Подобно тому, как ETH является газом в Ethereum, а SUI — газом в Sui, IKA служит газом/платой за операции MPC в сети Ika. Когда пользователь или DApp запрашивает подпись или операцию dWallet, сети выплачивается комиссия в IKA. Эти комиссии компенсируют валидаторам вычислительную и коммуникационную работу по запуску протокола пороговой подписи. В «белой книге» (whitepaper) роль IKA сравнивается с газом Sui, подтверждая, что все кроссчейн-транзакции, фасилитируемые Ika, будут облагаться небольшой комиссией в IKA. График комиссий, скорее всего, пропорционален сложности операции (например, одна подпись может стоить базовую комиссию, в то время как более сложные многоступенчатые рабочие процессы могут стоить дороже).

  • Стейкинг и безопасность: IKA также является токеном стейкинга. Узлам-валидаторам в сети Ika должен быть делегирован стейк в IKA для участия в консенсусе и подписании. Консенсус следует модели делегированного доказательства доли владения (DPoS), аналогичной модели Sui: держатели токенов делегируют IKA валидаторам, а вес каждого валидатора в консенсусе (и, следовательно, в процессах пороговой подписи) определяется стейком. В каждой эпохе выбираются валидаторы, и их право голоса является функцией стейка, при этом весь набор является византийски отказоустойчивым (что означает, что если набор валидаторов имеет общий стейк X,до X, до ~ X/3 стейка может быть злонамеренным без нарушения гарантий сети). Стейкеры (делегаторы) стимулируются вознаграждениями за стейкинг: модель Ika, вероятно, включает распределение собранных комиссий (и, возможно, инфляционных вознаграждений) валидаторам и их делегаторам в конце эпох. Действительно, в документации отмечается, что все собранные комиссии за транзакции распределяются между полномочными узлами (authorities), которые могут делиться частью со своими делегаторами в качестве вознаграждения. Это отражает модель Sui по вознаграждению поставщиков услуг за пропускную способность.

  • Предложение и распределение: По состоянию на текущий момент (2-й квартал 2025 года) подробности об общем предложении IKA, первоначальном распределении и инфляции не являются полностью публичными. Однако, учитывая раунды финансирования, мы можем сделать выводы о некоторой структуре. Вероятно, часть IKA выделяется ранним инвесторам (посевные и последующие раунды) и команде, а большая часть зарезервирована для сообщества и будущих стимулов. Возможно, планируется распродажа для сообщества или аирдроп, тем более что Ika провела заметную NFT-кампанию, собрав 1,4 млн SUI, как упоминалось в новостях (это была кампания NFT-искусства на Sui, установившая рекорд; возможно, участники этой кампании могут получить вознаграждения в IKA или ранний доступ). Кампания NFT предполагает стратегию вовлечения сообщества и ускорения распределения токенов среди пользователей, а не только среди венчурных капиталистов.

  • Сроки запуска токена: Объявление Sui Foundation в октябре 2024 года гласило: «Токен IKA будет запущен нативно на Sui, открывая новые функциональные возможности и утилитарность в децентрализованной безопасности». Запуск основной сети был намечен на декабрь 2024 года, поэтому, предположительно, событие генерации токенов (TGE) должно было совпасть с ним или последовать вскоре за ним. Если основная сеть была запущена по графику, токены IKA могли начать распределяться в конце 2024 или начале 2025 года. Затем токен начал бы использоваться для оплаты газа в сети Ika и для стейкинга. До этого в тестовой сети для газа использовался временный токен (DWLT в тестнете), который не имел реальной ценности.

  • Варианты использования и накопление стоимости: Стоимость IKA как инвестиции зависит от использования сети Ika. Чем больше кроссчейн-транзакций проходит через Ika, тем больше комиссий выплачивается в IKA, что создает спрос. Кроме того, если многие захотят запустить валидаторов или обезопасить сеть, они должны приобрести и застейкать IKA, что блокирует предложение (уменьшая свободное обращение). Таким образом, IKA имеет природу «утилитарность плюс управление» — утилитарность в оплате услуг и стейкинге, и, вероятно, управление (governance) в определении будущего протокола (хотя управление пока явно не упоминается, для таких сетей характерно со временем децентрализовать контроль через голосование токенами). Можно представить, что держатели токенов IKA в будущем будут голосовать за добавление поддержки новых цепочек, настройку параметров комиссий или другие обновления протокола.

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

Бизнес-модель и стратегия выхода на рынок

Бизнес-модель Ika — это модель провайдера инфраструктуры в экосистеме блокчейна. Проект не предлагает продукт для конечного потребителя; вместо этого он предоставляет протокольный сервис (децентрализованное управление ключами и исполнение транзакций), который интегрируют другие проекты. Таким образом, основным механизмом получения дохода (или извлечения ценности) является плата за услуги — то есть комиссии за газ в сети IKA за использование сети. Ika можно сравнить с децентрализованным AWS для подписания ключей: любой разработчик может подключиться и использовать его, оплачивая каждое использование. В долгосрочной перспективе, по мере децентрализации сети, dWallet Labs (компания-основатель) может получать ценность за счет владения долей в сети и роста стоимости токенов, а не за счет взимания комиссий в стиле SaaS вне сети.

Стратегия выхода на рынок (GTM): На ранних этапах Ika ориентируется на разработчиков блокчейнов и проекты, которым требуются кроссчейн-функциональность или кастодиальные решения. Тесная связь с Sui обеспечивает готовый пул таких разработчиков. Сама по себе Sui, будучи новой L1-сетью, нуждается в уникальных функциях для привлечения пользователей — и Ika предлагает кроссчейн-DeFi, доступ к Bitcoin и многое другое на базе Sui, что является убедительными преимуществами. Таким образом, стратегия GTM Ika опирается на растущую экосистему Sui. Примечательно, что еще до запуска мейннета несколько проектов на Sui объявили об интеграции Ika:

  • Такие проекты, как Full Sail, Rhei, Aeon, Human Tech, Covault, Lucky Kat, Native, Nativerse, Atoma и Ekko (все они строят на Sui), «объявили о своих предстоящих запусках с использованием Ika», охватывая сценарии использования от DeFi до гейминга. Например, Full Sail может создавать биржу для торговли BTC через Ika; Lucky Kat (игровая студия) может использовать Ika для создания игровых активов, находящихся в нескольких сетях; Covault, скорее всего, занимается кастодиальными решениями и т. д. Обеспечивая эти партнерства на ранней стадии, Ika гарантирует, что сразу после запуска в сети будет наблюдаться мгновенный объем транзакций и появятся реальные приложения, демонстрирующие её возможности.

  • Ika также делает акцент на институциональных сценариях использования, таких как децентрализованный кастоди для организаций. В пресс-релизах они подчеркивают «непревзойденную безопасность для институциональных и индивидуальных пользователей» в вопросах хранения через Ika. Это говорит о том, что Ika может позиционироваться для криптокастодианов, бирж или даже игроков из сферы TradFi, которым нужен более безопасный способ управления приватными ключами (возможно, как альтернатива или дополнение к Fireblocks или Copper, которые используют MPC, но в централизованной корпоративной среде). Фактически, будучи децентрализованной сетью, Ika может позволить конкурентам в сфере кастоди полагаться на одну и ту же надежную сеть подписания, а не создавать собственные решения. Эта кооперативная модель может привлечь институты, которые предпочитают нейтрального децентрализованного кастодиана для определенных активов.

  • Еще один аспект — интеграция с ИИ: Ika упоминает «защитные барьеры для ИИ-агентов» (AI Agent guardrails) в качестве сценария использования. Это перспективное направление, играющее на тренде автономности ИИ (например, ИИ-агенты, совершающие операции в блокчейне). Ika может гарантировать, что ИИ-агент (например, автономный экономический агент, получивший контроль над средствами) не сможет скрыться с деньгами, поскольку сам агент не является единственным владельцем ключа — ему все равно потребуется доля пользователя или соблюдение условий в Ika. Маркетинг Ika как поставщика механизмов безопасности для ИИ в Web3 — это новаторский подход для привлечения интереса из этого сектора.

Географически присутствие Node Capital и других инвесторов намекает на фокус на Азию в дополнение к западному рынку. У Sui сильное азиатское сообщество (особенно в Китае). NFT-кампания Ika на Sui (арт-кампания, собравшая 1,4 млн SUI) указывает на усилия по созданию сообщества — возможно, привлекая китайских пользователей, которые активны в NFT-пространстве Sui. Проводя продажи NFT или аирдропы для сообщества, Ika может сформировать базу рядовых пользователей, которые владеют токенами IKA и заинтересованы в продвижении проекта.

Со временем бизнес-модель может расшириться до предложения премиум-функций или корпоративных интеграций. Например, в то время как публичная сеть Ika является открытой (permissionless), dWallet Labs может запускать частные инстансы или версии для консорциумов для определенных клиентов или предоставлять консультационные услуги проектам, интегрирующим Ika. Они также могут зарабатывать, запуская часть валидаторов на раннем этапе (фаза начальной загрузки) и, таким образом, собирая часть комиссий.

В целом, стратегия GTM Ika тесно связана с партнерствами внутри экосистемы. Глубоко интегрируясь в дорожную карту Sui (где цели Sui на 2025 год включают кроссчейн-ликвидность и уникальные кейсы), Ika гарантирует себе рост вместе с этой L1-сетью. Одновременно она позиционирует себя как универсальное решение для мультичейн-координации, которое затем может быть предложено проектам в других сетях после того, как успех на Sui будет продемонстрирован. Поддержка со стороны Sui Foundation и объявления о ранних интеграциях дают Ika значительное преимущество в плане доверия и принятия по сравнению с запуском в изоляции.

Принятие экосистемой, партнерства и дорожная карта

Даже на ранней стадии Ika сформировала впечатляющий список взаимодействий в экосистеме:

  • Принятие в экосистеме Sui: Как уже упоминалось, несколько проектов на базе Sui интегрируют Ika. Это означает, что после запуска мейннета Ika мы ожидаем появления в dApps на Sui функций с пометкой «Работает на базе Ika» (Powered by Ika) — например, протокол кредитования на Sui, позволяющий пользователям вносить BTC, или DAO на Sui, использующая Ika для хранения своей казны в нескольких сетях. Тот факт, что такие проекты, как Rhei, Atoma, Nativerse (вероятно, DeFi-проекты) и Lucky Kat (гейминг/NFT), уже участвуют, показывает, что применимость Ika охватывает различные вертикали.

  • Стратегические партнерства: Самым важным партнерством Ika является сотрудничество с Sui Foundation, которая выступает и инвестором, и промоутером. Официальные каналы Sui (блог и т. д.) активно освещают Ika, фактически одобряя её как решение для интероперабельности в Sui. Кроме того, Ika, вероятно, работает с другими поставщиками инфраструктуры. Например, учитывая упоминание zkLogin (функция входа в Sui через Web2) наряду с Ika, возможен комбинированный сценарий использования, где zkLogin отвечает за аутентификацию пользователя, а Ika — за кроссчейн-транзакции, что вместе обеспечивает бесшовный UX. Также упоминание Avail (Polygon) в блогах Ika указывает на партнерство или пилотный проект в этой экосистеме: возможно, с Polygon Labs или командами, строящими роллапы на Avail, для использования Ika при переносе (бриджинге) Bitcoin в эти роллапы. Другая потенциальная область партнерства — кастодианы. Например, интеграция Ika с провайдерами кошельков, такими как Zengo (примечательно, что сооснователь ZenGo был участником предыдущего проекта Омера), или с технологиями институционального кастоди, такими как Fireblocks. Хотя это не подтверждено, такие цели были бы логичными (ведь Fireblocks уже сотрудничает с Sui в других областях; можно представить, как Fireblocks использует Ika для MPC на Sui).

  • Взаимодействие с сообществом и разработчиками: Ika ведет Discord и, вероятно, проводит хакатоны, чтобы привлечь разработчиков к созданию решений с использованием dWallets. Технология новая, поэтому её продвижение через обучение имеет ключевое значение. Наличие разделов «Use cases» (Сценарии использования) и «Builders» (Разработчики) на их сайте, а также посты в блоге, объясняющие основные концепции, указывают на стремление помочь разработчикам освоиться с концепцией dWallets. Чем больше разработчиков поймут, что они могут создавать кроссчейн-логику без мостов (и без ущерба для безопасности), тем активнее будет расти органическое принятие.

  • Дорожная карта: По состоянию на 2025 год дорожная карта Ika включала:

    • Альфа-версия и тестнет (2023–2024): Альфа-тестнет был запущен в 2024 году на Sui, что позволило разработчикам экспериментировать с dWallets и предоставлять обратную связь. Этот этап использовался для доработки протокола, исправления ошибок и проведения внутренних аудитов.
    • Запуск мейннета (декабрь 2024 г.): Ika планировала выйти в мейннет к концу 2024 года. Если это было достигнуто, то к настоящему времени (середина 2025 года) мейннет Ika должен функционировать. Запуск, вероятно, включал первоначальную поддержку набора сетей: как минимум Bitcoin и Ethereum (сети ECDSA) на старте, учитывая, что они активно упоминались в маркетинге.
    • Цели на 2025 год после запуска: В 2025 году ожидается фокус на масштабировании использования (через приложения на Sui и, возможно, расширение на другие сети). Команда будет работать над добавлением поддержки Ed25519 и подписей Шнорра вскоре после запуска, что позволит интегрироваться с Solana, Polkadot и другими экосистемами. Они также внедрят больше легких клиентов (возможно, легкий клиент Ethereum для Ika, легкий клиент Solana и т. д.) для расширения бездоверительного управления (trustless control). Еще один пункт дорожной карты — вероятно, расширение набора публичных валидаторов (permissionless validator expansion), поощрение присоединения независимых валидаторов и дальнейшая децентрализация сети. Поскольку код является форком Sui, запуск валидатора Ika аналогичен запуску узла Sui, что под силу многим операторам.
    • Улучшение функционала: В блогах упоминались две интересные функции: Зашифрованные доли пользователей (Encrypted User Shares) и Подписание будущих транзакций (Future Transaction signing). Зашифрованные доли пользователей означают, что пользователи могут по желанию зашифровать свою приватную долю и сохранить её ончейн (возможно, в Ika или другом месте) так, чтобы только они могли её расшифровать, что упрощает восстановление. Подписание будущих транзакций подразумевает возможность предварительного подписания транзакции в Ika, которая исполнится позже при выполнении определенных условий. Эти функции повышают удобство использования (пользователям не нужно быть в сети для каждого действия, если они заранее одобрили определенную логику, сохраняя при этом некастодиальную безопасность). Реализация этих функций в 2025 году еще больше выделит предложение Ika.
    • Рост экосистемы: К концу 2025 года Ika, вероятно, стремится к тому, чтобы её активно использовали экосистемы нескольких сетей. Мы можем увидеть, например, проект на Ethereum, использующий Ika через оракул (если прямая ончейн-интеграция еще не реализована), или сотрудничество с интерчейн-проектами, такими как Wormhole или LayerZero, где Ika может служить механизмом подписания для безопасной передачи сообщений.

Конкурентная среда также будет определять стратегию Ika. Она не одинока в предложении децентрализованного управления ключами, поэтому часть её дорожной карты будет включать акцент на преимуществах в производительности и уникальной безопасности «двух сторон» в сравнении с другими. В следующем разделе мы сравним Ika с её заметными конкурентами: Lit Protocol, Threshold Network и Zama.

АспектIka (Параллельная сеть MPC)Lit Protocol (PKI и вычисления)Threshold Network (tBTC и TSS)Zama (Сеть FHE)
Запуск и статусОснован в 2022 году; Тестнет в 2024 году; Мейннет запущен на Sui в декабре 2024 года (начало 2025 года). Токен $IKA запущен на Sui.Запущен в 2021 году; сеть узлов Lit работает. Токен $LIT (запущен в 2021 году). Создает роллап «Chronicle» для масштабирования.Сеть запущена в 2022 году после слияния Keep / NuCypher. Токен $T управляет DAO. Запущен tBTC v2 для моста с Bitcoin.В разработке (по состоянию на 2025 год публичная сеть отсутствует). Привлечены крупные раунды венчурного капитала для R & D. Токена пока нет (инструменты FHE на стадии альфа-тестирования).
Основное направление / Вариант использованияКроссчейн-взаимодействие и хранение: пороговая подпись для управления нативными активами в разных сетях (например, BTC, ETH) через dWallets. Обеспечивает работу DeFi, мультичейн-DApps и т. д.Децентрализованное управление ключами и контроль доступа: пороговое шифрование / дешифрование и условное подписание через PKP (программируемые пары ключей). Популярно для ограничения доступа к контенту, кроссчейн-автоматизации с помощью JavaScript «Lit Actions».Услуги пороговой криптографии: например, децентрализованный мост Bitcoin-Ethereum tBTC; пороговая ECDSA для хранения цифровых активов; пороговое прокси-перешифрование (PRE) для конфиденциальности данных.Вычисления с сохранением конфиденциальности: полностью гомоморфное шифрование (FHE) для обеспечения обработки зашифрованных данных и приватных смарт-контрактов. Фокус на конфиденциальности (например, приватные DeFi, ончейн ML), а не на кроссчейн-управлении.
АрхитектураФорк блокчейна Sui (DAG-консенсус Mysticeti), модифицированный для MPC. На Ika нет пользовательских смарт-контрактов; используется протокол 2PC-MPC вне сети среди ~N валидаторов + доля пользователя. Дизайн с высокой пропускной способностью (10 тыс. TPS).Децентрализованная сеть + L2: узлы Lit запускают MPC, а также среду выполнения JS на базе TEE. Роллап «Chronicle» на Arbitrum используется для привязки состояния и координации узлов. Использует порог 2 / 3 для консенсуса по операциям с ключами.Децентрализованная сеть на Ethereum: операторы узлов вносят стейкинг в $T и случайным образом выбираются в группы подписантов (например, 100 узлов для tBTC). Использует оффчейн-протоколы (GG18 и др.) с ончейн-контрактами Ethereum для координации и обработки депозитов.Инструментарии FHE поверх существующих сетей: технологии Zama (например, библиотеки Concrete, TFHE) позволяют использовать FHE на Ethereum (fhEVM). Планируется система управления пороговыми ключами (TKMS) для ключей FHE. Вероятно, будет интегрироваться с L1 или работать как Layer-2 для приватных вычислений.
Модель безопасности2PC-MPC, без сговора: для любой подписи требуется доля ключа пользователя + порог из N валидаторов (2 / 3 BFT). Ни одна сущность никогда не владеет полным ключом. Консенсус BFT допускает <33 % злоумышленников. Аудит проведен Symbolic (2024).Порог + TEE: требуется 2 / 3 узлов Lit для подписания / дешифрования. Использует доверенные среды выполнения (TEE) на каждом узле для безопасного запуска предоставленного пользователем кода (Lit Actions). Безопасность зависит от честности узлов и защиты оборудования.Пороговая многосторонняя система: например, для tBTC случайно выбранная группа из ~100 узлов должна достичь порога (например, 51) для подписания транзакций BTC. Экономические стимулы (стейкинг $T, слэшинг) для поддержания честного большинства. Управляется DAO; инциденты безопасности решаются через управление.На базе FHE: безопасность основана на криптографической сложности FHE (обучение с ошибками и т. д.) — данные всегда остаются зашифрованными. TKMS от Zama указывает на использование пороговой криптографии также для управления ключами FHE. Сеть еще не запущена; безопасность проверяется учеными.
ПроизводительностьЗадержка менее секунды, теоретически ~10 000 подписей / сек. Масштабируется до сотен или тысяч узлов без существенной потери производительности (подход с трансляцией и пакетной обработкой). Подходит для использования в DApps в реальном времени (трейдинг, игры).Умеренная задержка (более высокая из-за накладных расходов TEE и консенсуса). В Lit около 50 узлов; используется «shadow splicing» для масштабирования, но большое количество узлов может снизить производительность. Хорошо подходит для задач средней частоты (открытие доступа, периодическое подписание транзакций). Chronicle L2 помогает с пакетированием.Более низкая пропускная способность, более высокая задержка: минтинг tBTC может занимать минуты (ожидание подтверждений Bitcoin + пороговое подписание) и использует небольшие группы для подписания. Внимание Threshold сосредоточено на качестве (безопасности), а не на количестве — это подходит для мостовых транзакций и контроля доступа, но не рассчитано на тысячи TPS.Высокая задержка вычислений: FHE в настоящее время намного медленнее, чем вычисления в открытом виде (на несколько порядков). Zama оптимизирует процессы, но выполнение приватных контрактов будет медленнее и дороже обычных. Не предназначено для высокочастотных задач; ориентировано на сложные вычисления, где конфиденциальность превыше всего.
ДецентрализацияВысокая — открытый набор валидаторов, возможны сотни валидаторов. Делегированное PoS (в стиле Sui) обеспечивает открытое участие и децентрализованное управление со временем. Пользователь всегда участвует в процессе (его невозможно обойти).Средняя — в настоящее время около 30–50 основных узлов, управляемых командой Lit и партнерами. Планируется дальнейшая децентрализация. Узлы выполняют сложные задачи (MPC + TEE), поэтому масштабирование нетривиально. Управление еще не полностью децентрализовано (Lit DAO существует, но на ранней стадии).Высокая — большой пул стейкеров; однако фактическое подписание выполняется выбранными группами (не всей сетью сразу). Сеть децентрализована настолько, насколько распределен ее стейк. Управляется Threshold DAO (голосование владельцев токенов) — зрелая децентрализация управления.Н / Д (для сети) — Zama сейчас скорее проект, движимый компанией. Если fhEVM или сети будут запущены, изначально они, вероятно, будут централизованными или с ограниченным набором узлов (учитывая сложность). Со временем выполнение транзакций FHE может быть децентрализовано, но в 2025 году это неизведанная территория.
Токен и стимулы$IKA (на базе Sui) для оплаты газа, стейкинга и, потенциально, управления. Стимул: получение комиссионных за работу валидаторов; стоимость токена растет вместе с использованием сети. Поддержка Sui Foundation придает ему экосистемную ценность.Токен **LIT—используетсядляуправленияи,возможно,оплатырасширенныхуслуг.LitActionsвнастоящеевремябесплатныдляразработчиков(безгаза);вдолгосрочнойперспективеможетбытьвведенамоделькомиссий.LIT** — используется для управления и, возможно, оплаты расширенных услуг. Lit Actions в настоящее время бесплатны для разработчиков (без газа); в долгосрочной перспективе может быть введена модель комиссий. LIT стимулирует работу узлов (стейкеров), но токеномика еще развивается.Токен **T—стейкаетсяузлами,управляетказначействомDAOиобновлениямипротокола.УзлызарабатываютвT** — стейкается узлами, управляет казначейством DAO и обновлениями протокола. Узлы зарабатывают в T и комиссиях (в ETH или комиссиях tBTC). $T обеспечивает безопасность сети (слэшинг за недобросовестное поведение). Также используется в программах ликвидности для внедрения tBTC.Нет токена (пока) — Zama финансируется венчурным капиталом; может ввести токен, если запустит сетевой сервис (может использоваться для оплаты приватных вычислений или стейкинга для обеспечения сетей, запускающих контракты FHE). В настоящее время разработчики используют инструменты Zama без токена.
Ключевые инвесторыSui Foundation (стратегический инвестор); венчурные фонды: Node Capital, Blockchange, Lemniscap, Collider; ангелы, такие как Навал Равикант. Сильная поддержка экосистемы Sui.При поддержке 1kx, Pantera, Coinbase Ventures, Framework и др. (привлечено 13 млн $ в 2022 году). Имеет растущее сообщество разработчиков через Lit DAO. Партнерство с Ceramic, NFT-проектами для контроля доступа.Образовалась из сообществ Keep и NuCypher (в прошлом поддерживались a16z, Polychain). Threshold управляется DAO; после слияния нового венчурного финансирования не было (гранты от Ethereum Community Fund и т. д.). Партнерства: работает с Curve, Aave (интеграции tBTC).При поддержке a16z, SoftBank, Multicoin Capital (привлечено 73 млн $ в раунде серии A). Тесные связи с исследованиями Ethereum Foundation (Ранд Хинди, генеральный директор, является активным сторонником FHE в Ethereum). Сотрудничество с такими проектами, как Optalysys, для аппаратного ускорения.

Конкурентное преимущество Ika: Отличительные особенности Ika заключаются в ее производительности при масштабировании и уникальной модели безопасности. По сравнению с Lit Protocol, Ika может поддерживать гораздо больше подписантов и значительно более высокую пропускную способность, что делает ее подходящей для вариантов использования (таких как высокообъемный трейдинг или игры), с которыми сеть Lit могла бы не справиться. Ika также не полагается на доверенные среды выполнения (TEE), к которым некоторые разработчики относятся с опаской (из-за потенциальных уязвимостей в SGX); вместо этого Ika достигает доверительности исключительно с помощью криптографии и консенсуса. В противовес Threshold Network, Ika предлагает более универсальную платформу. Threshold в значительной степени ориентирована на мосты Bitcoin ↔ Ethereum (tBTC) и несколько криптографических сервисов, таких как прокси-перешифрование, в то время как Ika — это гибкий слой интероперабельности, который может работать с любой сетью и активом «из коробки». Кроме того, модель Ika с участием пользователя в процессе означает, что она не требует избыточного обеспечения или страхования депозитов (tBTC v2 использует надежную, но сложную экономическую модель для обеспечения депозитов BTC, тогда как в Ika пользователь изначально не теряет контроль). По сравнению с Zama, Ika решает другую задачу: Zama нацелена на конфиденциальность, а Ika — на интероперабельность. Однако вполне вероятно, что в будущем они смогут дополнять друг друга (например, используя FHE для активов, хранящихся в Ika). На данный момент преимущество Ika в том, что она начнет функционировать раньше в нише с немедленным спросом (мосты и сети MPC необходимы уже сегодня, в то время как FHE все еще созревает).

Одним из потенциальных вызовов для Ika является просвещение рынка и доверие. Она представляет новый способ кроссчейн-взаимодействия (dWallets вместо традиционных мостов типа lock-and-mint). Ей нужно будет продемонстрировать свою безопасность на практике со временем, чтобы завоевать такой же уровень доверия, какой постепенно заслужила Threshold Network (Threshold пришлось доказывать надежность tBTC после того, как ранняя версия была приостановлена из-за рисков). Если технология Ika будет работать так, как заявлено, она фактически опередит конкурентов, решив трилемму децентрализации, безопасности и скорости в пространстве MPC. Сильная поддержка со стороны Sui и обширные аудиты / статьи добавляют проекту авторитетности.

В заключение, Ika выделяется среди сетей MPC своей амбициозной масштабируемостью и ориентированной на пользователя моделью безопасности. Инвесторы рассматривают ее как ставку на будущее кроссчейн-координации — будущего, где пользователи могут беспрепятственно перемещать ценности и логику между множеством блокчейнов, не теряя контроля над своими ключами. Если Ika получит широкое признание, она может стать такой же неотъемлемой частью инфраструктуры Web3, как протоколы кроссчейн-сообщений или основные блокчейны Layer-1. Предстоящий год (2025) станет критическим, поскольку мейннет Ika и первые варианты использования будут запущены в эксплуатацию, доказывая, может ли эта передовая криптография выполнить свои обещания в реальных рыночных условиях. Первые признаки — сильные технические основы, активная подготовка интеграций и существенная поддержка инвесторов — позволяют предположить, что у Ika есть реальный шанс переопределить кроссчейн-взаимодействие с помощью MPC.

Источники: Основная информация была собрана из официальной документации и whitepaper Ika, объявлений Sui Foundation, пресс-релизов и новостей о финансировании, а также технических документов и анализов конкурентов для контекста (отчет Messari о Lit Protocol, документация Threshold Network и описания FHE от Zama). Вся информация актуальна по состоянию на 2025 год.

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

· 44 мин чтения
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, а также отраслевые статьи, освещающие варианты использования конфиденциальных блокчейн-технологий. Эти и другие источники цитировались на протяжении всего текста для предоставления дополнительной информации и подтверждения описанных архитектур и приложений.