Публичные блокчейны предоставляют каждому участнику синхронизированный, проверяемый реестр, но по умолчанию они также раскрывают каждую часть данных. Seal, запущенный в основной сети Sui (Sui Mainnet) 3 сентября 2025 года, решает эту проблему, объединяя логику политики в блокчейне с децентрализованным управлением ключами, чтобы разработчики Web3 могли точно определять, кто получает доступ к расшифровке каких полезных данных.

Краткое содержание​

• Что это: Seal — это сеть управления секретами, которая позволяет смарт-контрактам Sui принудительно применять политики дешифрования в блокчейне, в то время как клиенты шифруют данные с помощью шифрования на основе идентификаторов (IBE) и полагаются на пороговые ключевые серверы для вывода ключей.
• Почему это важно: Вместо пользовательских бэкендов или непрозрачных внесетевых скриптов, конфиденциальность и контроль доступа становятся первоклассными примитивами Move. Разработчики могут хранить зашифрованные тексты где угодно — Walrus является естественным дополнением — но при этом ограничивать, кто может их читать.
• Кто выигрывает: Команды, выпускающие медиаконтент с токен-доступом, раскрытие информации по истечении времени, приватные сообщения или ИИ-агентов, осведомленных о политиках, могут подключиться к SDK Seal и сосредоточиться на продуктовой логике, а не на специализированной криптографической инфраструктуре.

Логика политики находится в Move​

Пакеты Seal поставляются с функциями Move seal_approve*, которые определяют, кто может запрашивать ключи для данной строки идентификатора и при каких условиях. Политики могут сочетать владение NFT, белые списки, временные блокировки или пользовательские системы ролей. Когда пользователь или агент запрашивает дешифрование, ключевые серверы оценивают эти политики через состояние полного узла Sui и одобряют запрос только в том случае, если блокчейн согласен.

Поскольку правила доступа являются частью вашего пакета в блокчейне, они прозрачны, проверяемы и версионируемы наряду с остальным кодом вашего смарт-контракта. Обновления управления могут быть развернуты, как любое другое обновление Move, с проверкой сообщества и историей в блокчейне.

Пороговая криптография управляет ключами​

Seal шифрует данные для идентификаторов, определенных приложением. Комитет независимых ключевых серверов, выбранных разработчиком, разделяет главный секрет IBE. Когда проверка политики пройдена, каждый сервер выводит долю ключа для запрошенного идентификатора. Как только кворум из t серверов отвечает, клиент объединяет доли в пригодный для использования ключ дешифрования.

Вы можете установить компромисс между живучестью и конфиденциальностью, выбирая членов комитета (Ruby Nodes, NodeInfra, Overclock, Studio Mirai, H2O Nodes, Triton One или сервис Enoki от Mysten) и выбирая порог. Нужна более высокая доступность? Выберите более крупный комитет с более низким порогом. Хотите более высокие гарантии конфиденциальности? Ужесточите кворум и полагайтесь на авторизованных провайдеров.

Опыт разработчика: SDK и сеансовые ключи​

Seal поставляется с TypeScript SDK (npm i @mysten/seal), который обрабатывает потоки шифрования/дешифрования, форматирование идентификаторов и пакетную обработку. Он также выдает сеансовые ключи, чтобы кошельки не засыпались постоянными запросами, когда приложению требуется повторный доступ. Для расширенных рабочих процессов контракты Move могут запрашивать дешифрование в блокчейне через специализированные режимы, позволяя логике, такой как раскрытие эскроу или аукционы, устойчивые к MEV, выполняться непосредственно в коде смарт-контракта.

Поскольку Seal независим от хранилища, команды могут использовать его в паре с Walrus для проверяемого хранилища больших двоичных объектов, с IPFS или даже с централизованными хранилищами, когда это соответствует операционным реалиям. Граница шифрования — и применение ее политики — перемещается вместе с данными независимо от того, где находится зашифрованный текст.

Проектирование с Seal: Лучшие практики​

• Моделируйте риск доступности: Пороги, такие как 2 из 3 или 3 из 5, напрямую соответствуют гарантиям бесперебойной работы. Промышленные развертывания должны использовать комбинацию провайдеров, отслеживать телеметрию и согласовывать SLA, прежде чем доверять критически важные рабочие процессы.
• Учитывайте изменчивость состояния: Оценка политики зависит от выполнения полными узлами вызовов dry_run. Избегайте правил, которые зависят от быстро меняющихся счетчиков или порядка внутри контрольных точек, чтобы предотвратить непоследовательные одобрения на разных серверах.
• Планируйте гигиену ключей: Производные ключи хранятся на клиенте. Настройте логирование, ротируйте сеансовые ключи и рассмотрите конвертное шифрование — используйте Seal для защиты симметричного ключа, который шифрует более крупную полезную нагрузку — чтобы ограничить радиус поражения в случае компрометации устройства.
• Архитектура для ротации: Комитет зашифрованного текста фиксируется во время шифрования. Создавайте пути обновления, которые повторно шифруют данные через новые комитеты, когда вам нужно сменить провайдеров или скорректировать предположения о доверии.

Что дальше​

Дорожная карта Seal указывает на управляемые валидаторами MPC-серверы, клиентские инструменты в стиле DRM и постквантовые опции KEM. Для разработчиков, исследующих ИИ-агентов, премиум-контент или регулируемые потоки данных, сегодняшний релиз уже предоставляет четкий план: кодируйте свою политику в Move, создайте разнообразный ключевой комитет и предоставляйте зашифрованные возможности, которые уважают конфиденциальность пользователей, не выходя за пределы границы доверия Sui.

Если вы рассматриваете Seal для вашего следующего запуска, начните с прототипирования простой политики с NFT-доступом с открытым комитетом 2 из 3, затем итерируйте к комбинации провайдеров и операционных контролей, которые соответствуют профилю риска вашего приложения.

title: "Доверенные среды исполнения (TEE) в экосистеме Web3: Глубокое погружение" description: "Глубокое погружение в технологию доверенных сред исполнения (TEE), их роль в Web3 и ключевые аппаратные реализации, такие как Intel SGX, ARM TrustZone и AMD SEV." keywords:

• TEE
• Web3
• безопасность блокчейна
• Intel SGX
• ARM TrustZone
• AMD SEV
• конфиденциальные вычисления
• инфраструктура блокчейна image: "https://opengraph-image.blockeden.xyz/api/og-blockeden-xyz?title=%D0%94%D0%BE%D0%B2%D0%B5%D1%80%D0%B5%D0%BD%D0%BD%D1%8B%D0%B5%20%D1%81%D1%80%D0%B5%D0%B4%D1%8B%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F%20(TEE)%20в%20экосистеме%20Web3%3A%20Глубокое%20погружение"

---

Доверенные среды исполнения (TEE) в экосистеме Web3: Глубокое погружение

1. Обзор технологии TEE​

Определение и архитектура: Доверенная среда исполнения (TEE) — это защищенная область процессора, которая обеспечивает конфиденциальность и целостность загруженного в нее кода и данных. С практической точки зрения, TEE действует как изолированный «анклав» внутри центрального процессора (ЦП) — своего рода «черный ящик», в котором могут выполняться конфиденциальные вычисления, защищенные от остальной части системы. Код, работающий внутри анклава TEE, защищен таким образом, что даже скомпрометированная операционная система или гипервизор не могут прочитать или изменить данные или код анклава. Ключевые свойства безопасности, обеспечиваемые TEE, включают:

• Изоляция (Isolation): Память анклава изолирована от других процессов и даже ядра ОС. Даже если злоумышленник получит полные права администратора на машине, он не сможет напрямую просмотреть или изменить память анклава.
• Целостность (Integrity): Аппаратное обеспечение гарантирует, что код, выполняющийся в TEE, не может быть изменен внешними атаками. Любое вмешательство в код анклава или состояние среды выполнения будет обнаружено, что предотвратит получение скомпрометированных результатов.
• Конфиденциальность (Confidentiality): Данные внутри анклава остаются зашифрованными в памяти и расшифровываются только для использования внутри ЦП, поэтому секретные данные не раскрываются в открытом виде внешнему миру.
• Удаленная аттестация (Remote Attestation): TEE может создавать криптографические доказательства (аттестации), чтобы убедить удаленную сторону в своей подлинности и в том, что внутри него работает конкретный доверенный код. Это означает, что пользователи могут проверить, находится ли анклав в доверенном состоянии (например, выполняет ли ожидаемый код на подлинном оборудовании), прежде чем передавать ему секретные данные.

Концептуальная диаграмма доверенной среды исполнения как защищенного анклава — «черного ящика» для исполнения смарт-контрактов. Зашифрованные входные данные (данные и код контракта) расшифровываются и обрабатываются внутри защищенного анклава, и только зашифрованные результаты покидают анклав. Это гарантирует, что конфиденциальные данные контракта остаются закрытыми для всех за пределами TEE.

На техническом уровне работа TEE обеспечивается аппаратным шифрованием памяти и контролем доступа в ЦП. Например, когда создается анклав TEE, ЦП выделяет для него защищенную область памяти и использует выделенные ключи (вшитые в оборудование или управляемые защищенным сопроцессором) для шифрования / дешифрования данных на лету. Любая попытка внешнего программного обеспечения прочитать память анклава приводит к получению только зашифрованных байтов. Эта уникальная защита на уровне ЦП позволяет даже коду на уровне пользователя определять области частной памяти (анклавы), которые вредоносное ПО с привилегиями или даже злонамеренный системный администратор не могут отследить или изменить. По сути, TEE обеспечивает более высокий уровень безопасности приложений, чем обычная операционная среда, при этом оставаясь более гибким решением, чем специализированные защищенные элементы (Secure Elements) или аппаратные модули безопасности (HSM).

Ключевые аппаратные реализации: Существует несколько аппаратных технологий TEE, каждая из которых имеет разную архитектуру, но преследует схожую цель — создание защищенного анклава внутри системы:

• Intel SGX (Software Guard Extensions): Intel SGX — одна из наиболее широко используемых реализаций TEE. Она позволяет приложениям создавать анклавы на уровне процессов, при этом шифрование памяти и контроль доступа обеспечиваются ЦП. Разработчики должны разделять свой код на «доверенный» (внутри анклава) и «недоверенный» (обычный мир), используя специальные инструкции (ECALL / OCALL) для передачи данных в анклав и из него. SGX обеспечивает сильную изоляцию анклавов и поддерживает удаленную аттестацию через службу аттестации Intel (IAS). Многие блокчейн-проекты, в частности Secret Network и Oasis Network, построили функционал смарт-контрактов с сохранением конфиденциальности на базе анклавов SGX. Однако архитектура SGX на сложных системах x86 привела к возникновению некоторых уязвимостей (см. § 4), а аттестация Intel вводит зависимость от централизованного доверия.

• ARM TrustZone: TrustZone использует другой подход, разделяя всю среду выполнения процессора на два мира: Безопасный мир (Secure World) и Нормальный мир (Normal World). Конфиденциальный код работает в Безопасном мире, который имеет доступ к определенной защищенной памяти и периферийным устройствам, в то время как Нормальный мир запускает обычную ОС и приложения. Переключения между мирами контролируются ЦП. TrustZone обычно используется в мобильных устройствах и устройствах IoT для таких задач, как защищенный пользовательский интерфейс, обработка платежей или управление цифровыми правами (DRM). В контексте блокчейна TrustZone может позволить создавать мобильные Web3-приложения, позволяя закрытым ключам или конфиденциальной логике работать в защищенном анклаве телефона. Однако анклавы TrustZone обычно более крупнозернистые (на уровне ОС или виртуальной машины) и не так часто используются в текущих Web3-проектах, как SGX.

• AMD SEV (Secure Encrypted Virtualization): Технология SEV от AMD ориентирована на виртуализированные среды. Вместо создания анклавов на уровне приложений, SEV может шифровать память целых виртуальных машин. Она использует встроенный процессор безопасности для управления криптографическими ключами и выполнения шифрования памяти, так что память ВМ остается конфиденциальной даже для хост-гипервизора. Это делает SEV подходящим для облачных или серверных сценариев: например, блокчейн-узел или оффчейн-воркер может работать внутри полностью зашифрованной ВМ, защищая свои данные от злонамеренного облачного провайдера. Дизайн SEV требует от разработчика меньше усилий по разделению кода (вы можете запустить существующее приложение или даже целую ОС в защищенной ВМ). Новые итерации, такие как SEV-SNP, добавляют такие функции, как обнаружение вмешательства, и позволяют владельцам ВМ проводить аттестацию своих машин, не полагаясь на централизованную службу. SEV крайне актуальна для использования TEE в облачной блокчейн-инфраструктуре.

Другие развивающиеся или нишевые реализации TEE включают Intel TDX (Trust Domain Extensions для защиты виртуальных машин на уровне анклавов в новых чипах Intel), TEE с открытым исходным кодом, такие как Keystone (RISC-V), и чипы защищенных анклавов в мобильных устройствах (например, Secure Enclave от Apple, хотя обычно он закрыт для произвольного кода). Каждая TEE имеет свою собственную модель разработки и предположения о доверии, но все они разделяют основную идею аппаратно изолированного безопасного исполнения.

2. Применение TEE в Web3​

Среды доверенного исполнения (Trusted Execution Environments, TEE) стали мощным инструментом для решения некоторых наиболее сложных задач Web3. Обеспечивая безопасный и приватный уровень вычислений, TEE открывают новые возможности для блокчейн-приложений в области конфиденциальности, масштабируемости, безопасности оракулов и целостности данных. Ниже мы рассмотрим основные области применения:

Смарт-контракты с сохранением конфиденциальности​

Одним из наиболее значимых способов использования TEE в Web3 является создание конфиденциальных смарт-контрактов — программ, которые работают в блокчейне, но могут безопасно обрабатывать частные данные. Блокчейны, такие как Ethereum, по умолчанию прозрачны: все данные транзакций и состояния контрактов являются публичными. Эта прозрачность проблематична для сценариев использования, требующих конфиденциальности (например, частные финансовые сделки, тайное голосование, обработка персональных данных). TEE предлагают решение, выступая в качестве анклава для вычислений с сохранением конфиденциальности, подключенного к блокчейну.

В системе смарт-контрактов на базе TEE входные данные транзакции могут быть отправлены в безопасный анклав на узле валидатора или воркера, обработаны внутри анклава, где они остаются зашифрованными для внешнего мира, а затем анклав может вывести зашифрованный или хешированный результат обратно в сеть. Только авторизованные стороны с ключом расшифровки (или сама логика контракта) могут получить доступ к результату в открытом виде. Например, Secret Network использует Intel SGX в своих узлах консенсуса для выполнения смарт-контрактов CosmWasm на зашифрованных входных данных, поэтому такие вещи, как балансы счетов, суммы транзакций или состояние контракта, могут быть скрыты от общественности, оставаясь при этом доступными для вычислений. Это позволило создать приложения secret DeFi — например, частные обмены токенов, где суммы конфиденциальны, или секретные аукционы, где ставки шифруются и раскрываются только после закрытия аукциона. Другим примером является Parcel от Oasis Network и конфиденциальный ParaTime, которые позволяют токенизировать данные и использовать их в смарт-контрактах с соблюдением конфиденциальности, обеспечивая такие сценарии использования, как кредитный скоринг или медицинские данные в блокчейне с соблюдением стандартов приватности.

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

Помимо конфиденциальности, TEE также помогают обеспечивать справедливость в смарт-контрактах. Например, децентрализованная биржа могла бы запускать свой механизм сопоставления ордеров внутри TEE, чтобы предотвратить возможность майнеров или валидаторов видеть ожидающие ордера и недобросовестно совершать опережающие сделки (front-running). Таким образом, TEE приносят в Web3 столь необходимый уровень конфиденциальности, открывая такие приложения, как конфиденциальный DeFi, частное голосование / управление и корпоративные контракты, которые ранее были невозможны в публичных реестрах.

Масштабируемость и оффчейн-вычисления​

Еще одна важная роль TEE заключается в улучшении блокчейн- масштабируемости путем выноса тяжелых вычислений за пределы сети (off-chain) в безопасную среду. Блокчейны испытывают трудности со сложными или ресурсоемкими задачами из-за ограничений производительности и стоимости выполнения операций внутри сети. Оффчейн-вычисления с поддержкой TEE позволяют выполнять эти задачи вне основной сети (таким образом, не потребляя газ и не замедляя пропускную способность сети), сохраняя при этом гарантии доверия к правильности результатов. По сути, TEE может служить верифицируемым акселератором оффчейн-вычислений для Web3.

Например, платформа iExec использует TEE для создания децентрализованного рынка облачных вычислений, где разработчики могут запускать вычисления вне сети и получать результаты, которым доверяет блокчейн. dApp может запросить выполнение вычислений (например, вывод сложной модели ИИ или анализ больших данных) узлами-воркерами iExec. Эти рабочие узлы выполняют задачу внутри анклава SGX, выдавая результат вместе с аттестацией того, что правильный код был запущен в подлинном анклаве. Затем результат возвращается в сеть, и смарт-контракт может проверить аттестацию анклава перед принятием вывода. Эта архитектура позволяет обрабатывать тяжелые рабочие нагрузки вне сети без ущерба для доверия, фактически повышая пропускную способность. Интеграция iExec Orchestrator с Chainlink демонстрирует это: оракул Chainlink извлекает внешние данные, затем передает сложные вычисления воркерам TEE iExec (например, агрегирование или скоринг данных), и, наконец, безопасный результат доставляется в сеть. Примеры использования включают такие вещи, как децентрализованные страховые расчеты (как продемонстрировал iExec), где большие объемы данных могут обрабатываться вне сети и дешево, а в блокчейн попадает только конечный результат.

Оффчейн-вычисления на базе TEE также лежат в основе некоторых Layer-2 решений для масштабирования. Ранний прототип Oasis Labs Ekiden (предшественник Oasis Network) использовал анклавы SGX для параллельного выполнения транзакций вне сети, фиксируя в основной сети только корни состояний, что фактически аналогично идеям роллапов, но с использованием аппаратного доверия. Выполняя контракты в TEE, они достигли высокой пропускной способности, полагаясь на анклавы для обеспечения безопасности. Другим примером является готовящийся к выпуску L2 Op-Succinct от Sanders Network, который сочетает в себе TEE и zkSNARK: TEE выполняют транзакции приватно и быстро, а затем генерируются zk-доказательства для подтверждения правильности этих выполнений в Ethereum. Этот гибридный подход использует скорость TEE и проверяемость ZK для создания масштабируемого и приватного L2-решения.

В целом, TEE могут выполнять вычисления с производительностью, близкой к нативной (поскольку они используют реальные инструкции процессора, просто с изоляцией), поэтому они на порядки быстрее, чем чисто криптографические альтернативы, такие как гомоморфное шифрование или доказательства с нулевым разглашением для сложной логики. Перенося работу в анклавы, блокчейны могут поддерживать более сложные приложения (такие как машинное обучение, обработка изображений / аудио, масштабная аналитика), которые были бы практически невыполнимы в сети. Результаты возвращаются с аттестацией, которую контракт в сети или пользователи могут проверить как исходящую из доверенного анклава, сохраняя таким образом целостность данных и правильность. Эту модель часто называют «верифицируемыми оффчейн-вычислениями», и TEE являются краеугольным камнем для многих таких разработок (например, Hyperledger Avalon Trusted Compute Framework, разработанный Intel, iExec и другими, использует TEE для оффчейн-выполнения байт-кода EVM с публикацией доказательства корректности в сети).

Безопасные оракулы и целостность данных​

Оракулы связывают блокчейны с данными реального мира, но они вносят проблемы с доверием: как смарт-контракт может быть уверен, что оффчейн-канал данных верен и не был подделан? TEE предоставляют решение, выступая в качестве безопасной «песочницы» для узлов оракулов. Узел оракула на базе TEE может извлекать данные из внешних источников (API, веб-сервисы) и обрабатывать их внутри анклава, который гарантирует, что данные не были изменены оператором узла или вредоносным ПО на узле. Затем анклав может подписать или подтвердить истинность предоставляемых им данных. Это значительно повышает целостность и надежность данных оракула. Даже если оператор оракула злонамерен, он не может изменить данные, не нарушив аттестацию анклава (что будет обнаружено блокчейном).

Ярким примером является Town Crier, система оракулов, разработанная в Корнельском университете, которая была одной из первых, использовавших анклавы Intel SGX для предоставления аутентифицированных данных контрактам Ethereum. Town Crier извлекал данные (например, с HTTPS-сайтов) внутри анклава SGX и передавал их контракту вместе с доказательством (подписью анклава) того, что данные поступили непосредственно из источника и не были подделаны. Chainlink оценила это и приобрела Town Crier в 2018 году, чтобы интегрировать оракулы на базе TEE в свою децентрализованную сеть. Сегодня у Chainlink и других провайдеров оракулов есть инициативы в области TEE: например, DECO и Fair Sequencing Services от Chainlink включают TEE для обеспечения конфиденциальности данных и справедливой очередности. Как отмечается в одном анализе, «TEE произвели революцию в безопасности оракулов, обеспечив защищенную от несанкционированного доступа среду для обработки данных... даже сами операторы узлов не могут манипулировать данными во время их обработки». Это особенно важно для высокоценных потоков финансовых данных (таких как ценовые оракулы для DeFi): TEE может предотвратить даже незначительные манипуляции, которые могут привести к крупным эксплойтам.

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

Что касается кроссчейн-мостов, TEE аналогичным образом повышают их целостность. Мосты часто полагаются на набор валидаторов или мультиподпись для хранения активов и проверки переводов между сетями, что делает их основной мишенью для атак. Запуская логику валидатора моста внутри TEE, можно защитить закрытые ключи моста и процессы верификации от несанкционированного доступа. Даже если ОС валидатора скомпрометирована, злоумышленник не сможет извлечь закрытые ключи или фальсифицировать сообщения изнутри анклава. TEE могут гарантировать, что транзакции моста обрабатываются точно в соответствии с правилами протокола, снижая риск того, что операторы-люди или вредоносное ПО внедрят мошеннические переводы. Кроме того, TEE позволяют обрабатывать атомарные свопы и кроссчейн-транзакции в безопасном анклаве, который либо завершает обе стороны сделки, либо корректно прерывает её, предотвращая сценарии застревания средств из-за вмешательства. Несколько проектов мостов и консорциумов изучают безопасность на базе TEE, чтобы смягчить проблему взломов мостов, участившихся в последние годы.

Целостность и верифицируемость данных вне сети​

Во всех вышеперечисленных сценариях повторяющейся темой является то, что TEE помогают поддерживать целостность данных даже за пределами блокчейна. Поскольку TEE может доказать, какой код он запускает (посредством аттестации), и может гарантировать, что код выполняется без вмешательства, он обеспечивает форму верифицируемых вычислений. Пользователи и смарт-контракты могут доверять результатам, поступающим из TEE, как если бы они были вычислены в сети, при условии, что проверка аттестации пройдена. Эта гарантия целостности — причина, по которой TEE иногда называют « якорем доверия» (trust anchor) для оффчейн-данных и вычислений.

Однако стоит отметить, что эта модель доверия переносит некоторые допущения на оборудование (см. §4). Целостность данных сильна лишь настолько, насколько сильна безопасность самого TEE. Если анклав скомпрометирован или аттестация подделана, целостность может быть нарушена. Тем не менее, на практике TEE (при своевременном обновлении) значительно усложняют проведение определенных атак. Например, кредитная DeFi-платформа может использовать TEE для расчета кредитного рейтинга на основе частных данных пользователя вне сети, и смарт-контракт примет этот рейтинг только в том случае, если он сопровождается действующей аттестацией анклава. Таким образом, контракт «знает», что рейтинг был рассчитан по утвержденному алгоритму на реальных данных, а не слепо доверяет пользователю или оракулу.

TEE также играют роль в развивающихся системах децентрализованной идентификации (DID) и аутентификации. Они могут безопасно управлять закрытыми ключами, персональными данными и процессами аутентификации таким образом, чтобы конфиденциальная информация пользователя никогда не раскрывалась блокчейну или провайдерам dApp. Например, TEE на мобильном устройстве может обрабатывать биометрическую аутентификацию и подписывать блокчейн-транзакцию в случае успешной проверки биометрии, и все это без раскрытия биометрических данных пользователя. Это обеспечивает как безопасность, так и конфиденциальность при управлении идентификационными данными — важный компонент для того, чтобы Web3 мог работать с такими вещами, как паспорта, сертификаты или данные KYC, обеспечивая суверенитет пользователя.

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

3. Заметные Web3-проекты, использующие TEE​

Ряд ведущих блокчейн-проектов построили свои основные предложения на базе доверенных сред исполнения (Trusted Execution Environments). Ниже мы подробно рассмотрим несколько наиболее примечательных из них, изучая, как каждый из них использует технологию TEE и какую уникальную ценность она добавляет:

Secret Network​

Secret Network — это блокчейн первого уровня (построенный на Cosmos SDK), который стал пионером в создании смарт-контрактов с сохранением конфиденциальности с использованием TEE. Все узлы-валидаторы в Secret Network запускают анклавы Intel SGX, которые выполняют код смарт-контракта таким образом, что состояние контракта, а также входные и выходные данные остаются зашифрованными даже для операторов узлов. Это делает Secret одной из первых платформ смарт-контрактов, ориентированных на конфиденциальность — конфиденциальность здесь не является необязательным дополнением, а является функцией сети по умолчанию на уровне протокола.

В модели Secret Network пользователи отправляют зашифрованные транзакции, которые валидаторы загружают в свой анклав SGX для выполнения. Анклав расшифровывает входные данные, запускает контракт (написанный в модифицированной среде выполнения CosmWasm) и создает зашифрованные выходные данные, которые записываются в блокчейн. Только пользователи с правильным ключом просмотра (или сам контракт со своим внутренним ключом) могут расшифровать и просмотреть фактические данные. Это позволяет приложениям использовать частные данные в сети (on-chain), не раскрывая их публично.

Сеть продемонстрировала несколько новых вариантов использования:

• Secret DeFi: например, SecretSwap (AMM), где балансы счетов пользователей и суммы транзакций являются конфиденциальными, что смягчает проблему опережения (front-running) и защищает торговые стратегии. Поставщики ликвидности и трейдеры могут работать, не транслируя каждый свой шаг конкурентам.
• Secret Auctions (Секретные аукционы): Аукционные контракты, в которых ставки держатся в секрете до окончания аукциона, что предотвращает стратегическое поведение на основе ставок других участников.
• Приватное голосование и управление: Владельцы токенов могут голосовать по предложениям, не раскрывая свой выбор, в то время как подсчет голосов все равно может быть проверен — это обеспечивает честное управление без запугивания.
• Рынки данных: Конфиденциальные наборы данных могут передаваться и использоваться в вычислениях без раскрытия необработанных данных покупателям или узлам.

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

Oasis Network​

Oasis Network — это еще один блокчейн первого уровня, нацеленный на масштабируемость и конфиденциальность, который широко использует TEE (Intel SGX) в своей архитектуре. Oasis представила инновационный дизайн, который разделяет консенсус и вычисления на разные уровни, называемые Consensus Layer (уровень консенсуса) и ParaTime Layer (уровень ParaTime). Уровень консенсуса отвечает за упорядочивание и финализацию в блокчейне, в то время как каждый ParaTime может быть средой выполнения для смарт-контрактов. Примечательно, что ParaTime Emerald в Oasis — это EVM-совместимая среда, а Sapphire — это конфиденциальная EVM, использующая TEE для сохранения приватности состояния смарт-контрактов.

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

Технически Oasis добавила дополнительные уровни безопасности помимо стандартного SGX. Они реализовали «многослойный корень доверия» (layered root of trust): использование Intel SGX Quoting Enclave и настраиваемого облегченного ядра для проверки надежности оборудования и изоляции (песочницы) системных вызовов анклава. Это уменьшает поверхность атаки (путем фильтрации вызовов ОС, которые могут делать анклавы) и защищает от определенных известных атак на SGX. Oasis также представила такие функции, как устойчивые анклавы (durable enclaves, чтобы анклавы могли сохранять состояние после перезагрузки) и защищенное ведение журналов для смягчения атак отката (rollback attacks, когда узел может попытаться воспроизвести старое состояние анклава). Эти инновации были описаны в их технических документах и являются частью причины, по которой Oasis считается проектом, основанным на исследованиях в области блокчейн-вычислений на базе TEE.

С точки зрения экосистемы Oasis позиционирует себя для таких вещей, как приватный DeFi (позволяющий банкам участвовать, не допуская утечки данных клиентов) и токенизация данных (где частные лица или компании могут конфиденциально передавать данные моделям ИИ и получать вознаграждение, и все это через блокчейн). Они также сотрудничали с предприятиями в пилотных проектах (например, работа с BMW по конфиденциальности данных и с другими компаниями по обмену данными медицинских исследований). В целом, Oasis Network демонстрирует, как сочетание TEE с масштабируемой архитектурой может решить проблемы как конфиденциальности, так и производительности, что делает ее значимым игроком в решениях Web3 на базе TEE.

Sanders Network​

Sanders Network — это децентрализованная сеть облачных вычислений в экосистеме Polkadot, использующая TEE для предоставления конфиденциальных и высокопроизводительных вычислительных услуг. Это парачейн на Polkadot, что означает, что он извлекает выгоду из безопасности и совместимости Polkadot, но вводит собственную новую среду выполнения для внесетевых (off-chain) вычислений в защищенных анклавах.

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

Можно представить Sanders как аналог Amazon EC2 или AWS Lambda, но децентрализованный: разработчики могут развертывать код в сети Sanders и запускать его на многих машинах с поддержкой SGX по всему миру, оплачивая услугу токенами Sanders. Некоторые выделенные варианты использования:

• Web3-аналитика и ИИ: Проект может анализировать данные пользователей или запускать алгоритмы ИИ в анклавах Sanders, чтобы необработанные пользовательские данные оставались зашифрованными (защищая конфиденциальность), в то время как из анклава выходят только агрегированные аналитические данные.
• Бэкенды для игр и Метавселенная: Sanders может обрабатывать интенсивную игровую логику или симуляции виртуальных миров вне сети, отправляя в блокчейн только обязательства или хеши, что позволяет сделать игровой процесс более насыщенным без доверия к какому-либо одному серверу.
• Он-чейн сервисы: Sanders построила платформу внесетевых вычислений под названием Sanders Cloud. Например, она может служить бэкендом для ботов, децентрализованных веб-сервисов или даже внесетевой книги ордеров, которая публикует сделки в смарт-контракт DEX с аттестацией TEE.

Sanders подчеркивает, что может горизонтально масштабировать конфиденциальные вычисления: нужно больше мощностей? Добавьте больше рабочих узлов TEE. Это не похоже на одиночный блокчейн, где вычислительная мощность ограничена консенсусом. Таким образом, Sanders открывает возможности для вычислительно интенсивных dApps, которым по-прежнему нужна безопасность без доверия. Важно отметить, что Sanders не полагается исключительно на аппаратное доверие; она интегрируется с консенсусом Polkadot (например, стейкинг и слэшинг за плохие результаты) и даже изучает сочетание TEE с доказательствами с нулевым разглашением (как уже упоминалось, их предстоящий L2 использует TEE для ускорения выполнения и ZKP для его краткой проверки на Ethereum). Этот гибридный подход помогает смягчить риск взлома любого отдельного TEE, добавляя криптографическую проверку сверху.

Таким образом, Sanders Network использует TEE для предоставления децентрализованного конфиденциального облака для Web3, обеспечивая внесетевые вычисления с гарантиями безопасности. Это открывает путь для класса блокчейн-приложений, которым требуются как тяжелые вычисления, так и конфиденциальность данных, устраняя разрыв между он-чейн и офф-чейн мирами.

iExec​

iExec — это децентрализованная торговая площадка для облачных вычислительных ресурсов, построенная на Ethereum. В отличие от трех предыдущих проектов (которые являются собственными сетями или парачейнами), iExec работает как сеть второго уровня или внесетевая сеть, которая координирует свои действия со смарт-контрактами Ethereum. TEE (в частности, Intel SGX) являются краеугольным камнем подхода iExec к установлению доверия во внесетевых вычислениях.

Сеть iExec состоит из рабочих узлов (worker nodes), предоставляемых различными провайдерами. Эти рабочие узлы могут выполнять задачи, запрашиваемые пользователями (разработчиками dApp, поставщиками данных и т. д.). Чтобы гарантировать надежность этих внесетевых вычислений, iExec представила структуру «доверенных внесетевых вычислений» (Trusted off-chain Computing): задачи могут выполняться внутри анклавов SGX, а результаты сопровождаются подписью анклава, которая доказывает, что задача была выполнена правильно на защищенном узле. iExec в партнерстве с Intel запустила эту функцию доверенных вычислений и даже присоединилась к Confidential Computing Consortium для продвижения стандартов. Их протокол консенсуса, называемый Proof-of-Contribution (PoCo), агрегирует голоса/аттестации от нескольких рабочих узлов, когда это необходимо для достижения консенсуса по правильному результату. Во многих случаях аттестации одного анклава может быть достаточно, если код детерминирован и доверие к SGX велико; для более высокой уверенности iExec может дублировать задачи на нескольких TEE и использовать консенсус или голосование большинством.

Платформа iExec позволяет реализовать несколько интересных вариантов использования:

• Децентрализованные вычисления оракулов: Как упоминалось ранее, iExec может работать с Chainlink. Узел Chainlink может получать необработанные данные, а затем передавать их рабочему узлу iExec SGX для выполнения вычислений (например, проприетарного алгоритма или вывода ИИ) на этих данных и, наконец, возвращать результат в блокчейн. Это расширяет возможности оракулов за пределы простой ретрансляции данных — теперь они могут предоставлять вычислительные услуги (например, вызывать модель ИИ или агрегировать множество источников) с помощью TEE, гарантирующего честность.
• ИИ и DePIN (Децентрализованная сеть физической инфраструктуры): iExec позиционируется как уровень доверия для децентрализованных приложений ИИ. Например, dApp, использующее модель машинного обучения, может запускать модель в анклаве для защиты как самой модели (если она является частной), так и подаваемых пользовательских данных. В контексте DePIN (например, распределенных сетей Интернета вещей), TEE могут использоваться на периферийных устройствах для доверия показаниям датчиков и вычислениям на основе этих показаний.
• Безопасная монетизация данных: Поставщики данных могут сделать свои наборы данных доступными на торговой площадке iExec в зашифрованном виде. Покупатели могут отправлять свои алгоритмы для запуска на этих данных внутри TEE (таким образом, необработанные данные поставщика никогда не раскрываются, что защищает его интеллектуальную собственность, а детали алгоритма также могут быть скрыты). Результат вычислений возвращается покупателю, а соответствующая оплата поставщику данных осуществляется через смарт-контракты. Эта схема, часто называемая безопасным обменом данными, облегчается конфиденциальностью TEE.

В целом, iExec обеспечивает связующее звено между смарт-контрактами Ethereum и безопасным внесетевым выполнением. Она демонстрирует, как «рабочие» TEE могут быть объединены в сеть для формирования децентрализованного облака, дополненного торговой площадкой (с использованием токена RLC для оплаты) и механизмами консенсуса. Возглавляя рабочую группу Enterprise Ethereum Alliance по доверенным вычислениям и участвуя в разработке стандартов (таких как Hyperledger Avalon), iExec также способствует более широкому внедрению TEE в корпоративных блокчейн-сценариях.

Другие проекты и экосистемы​

Помимо четырех вышеупомянутых, стоит отметить еще несколько проектов:

• Integritee — еще один парачейн Polkadot, похожий на Sanders (фактически, он выделился из работы Energy Web Foundation по TEE). Integritee использует TEE для создания «парачейна как услуги» (parachain-as-a-service) для предприятий, сочетая он-чейн и офф-чейн обработку в анклавах.
• Automata Network — протокол промежуточного программного обеспечения (middleware) для конфиденциальности Web3, который использует TEE для частных транзакций, анонимного голосования и обработки транзакций, устойчивых к MEV. Automata работает как внесетевая сеть, предоставляя такие услуги, как частный RPC-ретранслятор, и упоминалась как использующая TEE для таких вещей, как защищенная идентификация и безгазовые частные транзакции.
• Hyperledger Sawtooth (PoET) — в корпоративной сфере Sawtooth представила алгоритм консенсуса под названием Proof of Elapsed Time (доказательство прошедшего времени), который опирался на SGX. Каждый валидатор запускает анклав, который ждет случайное время и выдает доказательство; тот, у кого время ожидания самое короткое, «выигрывает» блок — честная лотерея, обеспечиваемая SGX. Хотя Sawtooth не является проектом Web3 как таковым (скорее корпоративным блокчейном), это творческое использование TEE для консенсуса.
• Корпоративные/консорциумные сети — многие корпоративные блокчейн-решения (например, ConsenSys Quorum, IBM Blockchain) включают TEE для обеспечения конфиденциальных транзакций в консорциумах, где только авторизованные узлы видят определенные данные. Например, план архитектуры Trusted Compute Framework (TCF) от Enterprise Ethereum Alliance использует TEE для выполнения частных контрактов вне сети и доставки доказательств Меркла в сеть.

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

4. Преимущества и проблемы TEE в децентрализованных средах​

Внедрение доверенных сред выполнения (Trusted Execution Environments, TEE) в блокчейн-системы приносит как значительные технические преимущества, так и заметные проблемы и компромиссы. Мы рассмотрим обе стороны: что TEE предлагают децентрализованным приложениям и какие проблемы или риски возникают при их использовании.

Преимущества и технические сильные стороны​

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

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

• Улучшенная масштабируемость (за счет выноса вычислений): Позволяя безопасно выполнять тяжелые вычисления вне сети, TEE помогают снизить нагрузку и затраты на газ в основных сетях. Они позволяют создавать решения Layer-2 и побочные протоколы, где блокчейн используется только для проверки или окончательного расчета, в то время как основная часть вычислений происходит в параллельных анклавах. Такая модуляция (логика с интенсивными вычислениями в TEE, консенсус в сети) может значительно повысить пропускную способность и масштабируемость децентрализованных приложений. Например, DEX может выполнять сопоставление ордеров в TEE оффчейн и публиковать только исполненные сделки ончейн, увеличивая пропускную способность и снижая затраты на газ в сети.

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

• Совместимость с другими технологиями: Интересно, что TEE могут дополнять другие технологии (что не является преимуществом только TEE, но проявляется в их комбинации). Они могут служить связующим звеном для гибридных решений: например, запуск программы в анклаве с одновременной генерацией ZK-доказательства её выполнения, где анклав помогает ускорить процесс доказательства. Или использование TEE в сетях MPC для выполнения определенных задач с меньшим количеством раундов связи. Мы обсудим сравнения в разделе §5, но многие проекты подчеркивают, что TEE не должны заменять криптографию — они могут работать вместе для усиления безопасности (мантра Сандерса: «Сила TEE заключается в поддержке других, а не в их замене»).

Допущения доверия и уязвимости безопасности​

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

• Доверие к оборудованию и централизация: Используя TEE, пользователь по умолчанию доверяет производителю чипов, безопасности их аппаратного дизайна и цепочке поставок. Например, использование Intel SGX означает веру в то, что у Intel нет бэкдоров, что их производство безопасно и что микрокод процессора правильно реализует изоляцию анклава. Это более централизованная модель доверия по сравнению с чистой криптографией (которая опирается на математические допущения, распределенные между всеми пользователями). Более того, аттестация для SGX исторически опирается на обращение к сервису аттестации Intel (Intel Attestation Service), что означает, что если Intel уйдет в офлайн или решит отозвать ключи, это может затронуть анклавы по всему миру. Такая зависимость от инфраструктуры одной компании вызывает опасения: она может стать единой точкой отказа или даже целью государственного регулирования (например, экспортный контроль США теоретически может ограничить использование сильных TEE). AMD SEV смягчает это, позволяя проводить более децентрализованную аттестацию (владельцы виртуальных машин могут аттестовать свои ВМ), но все равно требует доверия к чипу и прошивке AMD. Риск централизации часто называют фактором, в некоторой степени противоречащим децентрализации блокчейна. Проекты вроде Keystone (TEE с открытым исходным кодом) и другие исследуют способы снижения зависимости от проприетарных «черных ящиков», но они пока не стали мейнстримом.

• Атаки по сторонним каналам и другие уязвимости: TEE не являются панацеей; их можно атаковать косвенными методами. Атаки по сторонним каналам используют тот факт, что даже если прямой доступ к памяти заблокирован, работа анклава может незаметно влиять на систему (через время выполнения, использование кэша, энергопотребление, электромагнитное излучение и т. д.). За последние несколько лет было продемонстрировано множество академических атак на Intel SGX: от Foreshadow (извлечение секретов анклава через утечки времени кэша L1) до Plundervolt (внедрение ошибок через изменение напряжения с помощью привилегированных инструкций) и SGAxe (извлечение ключей аттестации) и других. Эти изощренные атаки показывают, что TEE могут быть скомпрометированы без взлома криптографической защиты — вместо этого используются микроархитектурные особенности или недостатки реализации. В результате признается, что «исследователи выявили различные потенциальные векторы атак, которые могут использовать уязвимости оборудования или различия во времени операций TEE». Хотя эти атаки нетривиальны и часто требуют либо локального доступа, либо вредоносного оборудования, они представляют собой реальную угрозу. TEE также обычно не защищают от физических атак, если у злоумышленника есть чип на руках (например, декапсуляция чипа, зондирование шин и т. д. могут победить большинство коммерческих TEE).

  Ответы производителей на обнаружение сторонних каналов заключались в выпуске патчей микрокода и обновлении SDK анклавов для устранения известных утечек (иногда ценой производительности). Но это остается игрой в кошки-мышки. Для Web3 это означает, что если кто-то найдет новый сторонний канал в SGX, «безопасный» DeFi-контракт, работающий в SGX, потенциально может быть взломан (например, для утечки секретных данных или манипулирования выполнением). Таким образом, опора на TEE означает принятие потенциальной поверхности уязвимости на уровне оборудования, которая находится за пределами типичной модели угроз блокчейна. Это активная область исследований по укреплению TEE против подобных атак (например, путем проектирования кода анклава с операциями постоянного времени, избегания шаблонов доступа к памяти, зависящих от секретов, и использования таких методов, как ORAM — Oblivious RAM). Некоторые проекты также дополняют TEE вторичными проверками — например, комбинируя их с ZK-доказательствами или запуская несколько анклавов на оборудовании разных производителей, чтобы снизить риск зависимости от одного чипа.

• Ограничения производительности и ресурсов: Хотя TEE работают почти с нативной скоростью для задач, ограниченных процессором, они все же имеют определенные накладные расходы и лимиты. Вход в анклав (ECALL) и выход из него (OCALL) имеют свою стоимость, так же как и шифрование/дешифрование страниц памяти. Это может повлиять на производительность при очень частых пересечениях границ анклава. Анклавы также часто имеют ограничения по объему памяти. Например, ранние версии SGX имели ограниченный кэш страниц анклава (EPC), и когда анклавы использовали больше памяти, страницы приходилось подкачивать (с шифрованием), что катастрофически замедляло работу. Даже новые TEE часто не позволяют легко использовать всю системную оперативную память — существует защищенная область памяти, которая может быть ограничена. Это означает, что обработка очень масштабных вычислений или наборов данных может быть затруднена целиком внутри TEE. В контексте Web3 это может ограничивать сложность смарт-контрактов или моделей машинного обучения, которые могут работать в анклаве. Разработчикам приходится оптимизировать использование памяти и, возможно, разделять рабочие нагрузки.

• Сложность аттестации и управления ключами: Использование TEE в децентрализованной среде требует надежных рабочих процессов аттестации: каждый узел должен доказать другим, что он запускает подлинный анклав с ожидаемым кодом. Настройка такой проверки аттестации ончейн может быть сложной. Обычно это включает в себя жесткое кодирование публичного ключа аттестации или сертификата производителя в протоколе и написание логики проверки в смарт-контрактах или оффчейн-клиентах. Это вносит дополнительные расходы в проектирование протокола, а любые изменения (например, смена формата подписи аттестации Intel с EPID на DCAP) могут создать нагрузку на обслуживание. Кроме того, управление ключами внутри TEE (для дешифрования данных или подписи результатов) добавляет еще один уровень сложности. Ошибки в управлении ключами анклава могут подорвать безопасность (например, если анклав непреднамеренно раскроет ключ дешифрования из-за ошибки, все его обещания конфиденциальности рухнут). Лучшие практики включают использование API запечатывания (sealing) TEE для безопасного хранения ключей и их ротацию при необходимости, но это опять же требует тщательного проектирования со стороны разработчиков.

• Отказ в обслуживании и доступность: Возможно, менее обсуждаемая проблема: TEE не помогают с доступностью и даже могут создавать новые пути для DoS-атак. Например, злоумышленник может наводнить сервис на базе TEE входными данными, обработка которых обходится дорого, зная, что оператор не может легко проверить или прервать работу анклава (так как он изолирован). Кроме того, если будет обнаружена уязвимость и для исправления потребуется обновление прошивки, в течение этого цикла многим сервисам анклавов, возможно, придется приостановить работу (в целях безопасности) до тех пор, пока узлы не будут пропатчены, что приведет к простою. В консенсусе блокчейна представьте, если бы была найдена критическая ошибка в SGX — такие сети, как Secret, могли бы остановиться до исправления, так как доверие к анклавам было бы подорвано. Координация таких мер в децентрализованной сети является сложной задачей.

Компонуемость и ограничения экосистемы​

• Ограниченная компонуемость с другими контрактами: В публичных платформах смарт-контрактов, таких как Ethereum, контракты могут легко вызывать другие контракты, и все состояние открыто, что позволяет создавать «финансовое лего» (money legos) и богатые комбинации. В модели контрактов на базе TEE частное состояние не может быть свободно передано или скомпоновано без нарушения конфиденциальности. Например, если контракту А в анклаве нужно взаимодействовать с контрактом Б, и оба хранят секретные данные, как им сотрудничать? Либо они должны использовать сложный протокол безопасных многосторонних вычислений (что нивелирует простоту TEE), либо объединяться в один анклав (что снижает модульность). Это проблема, с которой сталкиваются Secret Network и другие: межконтрактные вызовы с сохранением конфиденциальности нетривиальны. Некоторые решения предполагают использование одного анклава для выполнения нескольких контрактов, чтобы он мог внутренне управлять общими секретами, но это может сделать систему более монолитной. Таким образом, компонуемость приватных контрактов более ограничена, чем публичных, или требует новых паттернов проектирования. Аналогично, интеграция модулей на базе TEE в существующие dApps блокчейна требует тщательного проектирования интерфейса — часто в блокчейне публикуется только результат работы анклава, который может быть доказательством (SNARK) или хешем, и другие контракты могут использовать только эту ограниченную информацию. Это определенно компромисс; такие проекты, как Secret, предоставляют ключи просмотра (viewing keys), позволяя делиться секретами по мере необходимости, но это не так бесшовно, как обычная ончейн-компонуемость.

• Стандартизация и интероперабельность: В экосистеме TEE в настоящее время отсутствуют единые стандарты между производителями. Intel SGX, AMD SEV, ARM TrustZone — все имеют разные модели программирования и методы аттестации. Эта фрагментация означает, что dApp, написанное для анклавов SGX, нельзя тривиально перенести на TrustZone и т. д. В блокчейне это может привязать проект к конкретному оборудованию (например, Secret и Oasis сейчас привязаны к серверам x86 с SGX). Если в дальнейшем они захотят поддерживать узлы ARM (скажем, валидаторы на мобильных устройствах), это потребует дополнительной разработки и, возможно, другой логики проверки аттестации. Существуют инициативы (такие как CCC — Confidential Computing Consortium) по стандартизации API аттестации и анклавов, но мы еще не достигли этой цели. Отсутствие стандартов также влияет на инструменты разработчика — можно обнаружить, что SGX SDK зрелый, но затем столкнуться с необходимостью адаптации к другому TEE с другим SDK. Эта проблема интероперабельности может замедлить внедрение и увеличить расходы.

• Кривая обучения для разработчиков: Создание приложений, работающих внутри TEE, требует специальных знаний, которыми могут не обладать многие разработчики блокчейнов. Часто требуется низкоуровневое программирование на C/C++ (для SGX/TrustZone) или понимание безопасности памяти и кодирования, устойчивого к атакам по сторонним каналам. Отладка кода анклава печально известна своей сложностью (вы не можете легко заглянуть внутрь анклава во время его работы из соображений безопасности!). Хотя существуют фреймворки и языки более высокого уровня (например, использование Rust в Oasis для их конфиденциальной среды исполнения или инструменты для запуска WebAssembly в анклавах), опыт разработчика все еще сложнее, чем при типичной разработке смарт-контрактов или оффчейн-разработке Web2. Эта крутая кривая обучения и незрелость инструментов могут отпугивать разработчиков или приводить к ошибкам при небрежном подходе. Также существует аспект необходимости оборудования для тестирования — для запуска кода SGX требуется процессор с поддержкой SGX или эмулятор (который работает медленнее), поэтому порог входа выше. В результате сегодня сравнительно немногие разработчики глубоко знакомы с разработкой анклавов, что делает аудит и поддержку сообщества более дефицитными, чем, скажем, в хорошо изученном сообществе Solidity.

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

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

5. TEE против других технологий сохранения конфиденциальности (ZKP, FHE, MPC)​

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

Краткое определение альтернатив:

• ZKP: Криптографические доказательства (такие как zk-SNARKs, zk-STARKs), которые позволяют одной стороне доказать другим, что утверждение верно (например, «я знаю секрет, который удовлетворяет этому вычислению»), не раскрывая, почему оно верно (скрывая секретные входные данные). В блокчейне ZKP используются для частных транзакций (например, Zcash, Aztec) и для масштабируемости (роллапы, которые публикуют доказательства правильного выполнения). Они обеспечивают высокую конфиденциальность (секретные данные не утекают, только доказательства) и целостность, гарантированную математикой, но генерация таких доказательств может быть вычислительно тяжелой, а схемы должны быть тщательно спроектированы.
• FHE: Схема шифрования, которая позволяет выполнять произвольные вычисления над зашифрованными данными таким образом, что результат после расшифровки совпадает с результатом вычислений над открытым текстом. Теоретически FHE обеспечивает абсолютную конфиденциальность — данные всегда остаются зашифрованными — и вам не нужно доверять кому-либо необработанные данные. Но FHE работает чрезвычайно медленно для общих вычислений (хотя ситуация улучшается благодаря исследованиям); из-за производительности оно до сих пор находится в основном в стадии экспериментального или специализированного использования.
• MPC: Протоколы, в которых несколько сторон совместно вычисляют функцию от своих частных входных данных, не раскрывая эти данные друг другу. Это часто включает разделение секретов между сторонами и выполнение криптографических операций таким образом, чтобы результат был верным, но индивидуальные входные данные оставались скрытыми. MPC позволяет распределить доверие (ни одна сторона не видит все данные) и может быть эффективным для определенных операций, но обычно влечет за собой затраты на связь и координацию и может быть сложным в реализации для крупных сетей.

Ниже приведена сравнительная таблица, обобщающая ключевые различия:

Технология	Модель доверия	Производительность	Конфиденциальность данных	Удобство для разработчиков
TEE (Intel SGX и др.)	Доверие производителю оборудования (в некоторых случаях — централизованному серверу аттестации). Предполагается, что чип безопасен; если оборудование скомпрометировано, безопасность нарушается.	Скорость выполнения, близкая к нативной; минимальные накладные расходы. Хорошо подходит для вычислений в реальном времени и больших нагрузок. Масштабируемость ограничена наличием узлов с поддержкой TEE.	Данные находятся в открытом виде внутри анклава, но зашифрованы для внешнего мира. Высокая конфиденциальность, если оборудование надежно, но при взломе анклава секреты раскрываются (нет дополнительной математической защиты).	Средняя сложность. Часто можно повторно использовать существующий код/языки (C, Rust) и запускать его в анклаве с минимальными изменениями. Самый низкий порог входа среди перечисленных — не нужно изучать продвинутую криптографию — но требуются знания системного программирования и SDK для конкретных TEE.
ZKP (zk-SNARK/STARK)	Доверие математическим предположениям (например, сложности криптографических задач) и иногда доверенной установке (для SNARK). Отсутствие зависимости от какой-либо одной стороны во время выполнения.	Генерация доказательств вычислительно тяжела (особенно для сложных программ), часто на порядки медленнее нативного выполнения. Проверка в блокчейне выполняется быстро (несколько мс). Не идеально для вычислений с большими данными из-за времени доказательства. Масштабируемость: хорошо для лаконичной проверки (роллапы), но доказывающее устройство (prover) является узким местом.	Очень высокая конфиденциальность — можно доказать правильность, не раскрывая никаких частных входных данных. Утекает только минимальная информация (например, размер доказательства). Идеально для финансовой конфиденциальности и т. д.	Высокая сложность. Требует изучения специализированных языков (схем, zkDSL, таких как Circom или Noir) и мышления в терминах арифметических схем. Отладка затруднена. Доступно меньше специалистов.
FHE	Доверие математике (задачи на решетках). Нет доверенной стороны; безопасность сохраняется до тех пор, пока шифрование не взломано.	Очень медленно для общего использования. Операции над зашифрованными данными на несколько порядков медленнее, чем над открытым текстом. Некоторое масштабирование происходит за счет улучшения оборудования и алгоритмов, но в настоящее время непрактично для использования в реальном времени в контексте блокчейна.	Абсолютная конфиденциальность — данные остаются зашифрованными все время, даже во время вычислений. Это идеально подходит для конфиденциальных данных (например, медицинских, межинституциональной аналитики), если позволяет производительность.	Очень специализированно. Разработчикам требуется опыт в криптографии. Существуют некоторые библиотеки (например, Microsoft SEAL, TFHE), но написание произвольных программ на FHE сложно и запутанно. Пока не является повседневной целью разработки для dApps.
MPC	Доверие распределено между несколькими сторонами. Предполагается, что пороговое число сторон честно (отсутствие сговора сверх определенного количества). Доверие к оборудованию не требуется. Сбой доверия, если слишком много сторон вступят в сговор.	Обычно медленнее нативного выполнения из-за раундов связи, но часто быстрее FHE. Производительность варьируется: простые операции (сложение, умножение) могут быть эффективными; сложная логика может привести к резкому росту затрат на связь. Задержка чувствительна к скорости сети. Масштабируемость можно улучшить с помощью шардинга или частичных предположений о доверии.	Сильная конфиденциальность при соблюдении предположений — ни один узел не видит входные данные целиком. Но некоторая информация может утечь через результат или если стороны выпадут (плюс не хватает лаконичности ZK — вы получаете результат, но нет легко передаваемого доказательства без повторного запуска протокола).	Высокая сложность. Требует разработки индивидуального протокола для каждого случая использования или использования фреймворков (например, SPDZ или предложения Partisia). Разработчики должны разбираться в криптографических протоколах и часто координировать развертывание нескольких узлов. Интеграция в блокчейн-приложения может быть сложной (требуются внечейновые раунды).

Ссылки: Приведенное выше сравнение основано на таких источниках, как анализ Sanders Network и других, в которых подчеркивается, что TEE превосходят другие технологии в скорости и простоте использования, в то время как ZK и FHE сосредоточены на максимальной бездоверительности за счет тяжелых вычислений, а MPC распределяет доверие, но создает сетевые накладные расходы.

Из таблицы становятся очевидными несколько ключевых компромиссов:

• Производительность: TEE обладают огромным преимуществом в чистой скорости и низкой задержке. MPC часто может справляться с умеренной сложностью с некоторым замедлением, ZK медленно генерируется, но быстро проверяется (асинхронное использование), а FHE на данный момент является самым медленным для произвольных задач (хотя подходит для ограниченных операций, таких как простые сложения/умножения). Если вашему приложению требуются сложные вычисления в реальном времени (например, интерактивные приложения, принятие решений с высокой частотой), TEE или, возможно, MPC (с небольшим количеством сторон на хороших соединениях) являются единственными жизнеспособными вариантами на сегодняшний день. ZK и FHE были бы слишком медленными в таких сценариях.

• Модель доверия: ZKP и FHE полностью не требуют доверия (доверие только математике). MPC переносит доверие на предположения о честности участников (которые можно усилить за счет большого количества сторон или экономических стимулов). TEE возлагает доверие на оборудование и производителя. Это фундаментальное различие: TEE вводят доверенную третью сторону (чип) в обычно бездоверительный мир блокчейна. Напротив, ZK и FHE часто хвалят за лучшее соответствие духу децентрализации — нет никаких специальных структур, которым нужно доверять, только вычислительная сложность. MPC находится посередине: доверие децентрализовано, но не устранено (если N из M узлов вступят в сговор, конфиденциальность нарушится). Таким образом, для максимальной бездоверительности (например, для по-настоящему устойчивой к цензуре децентрализованной системы) можно склониться к криптографическим решениям. С другой стороны, многие практические системы вполне допускают предположение о честности Intel или о том, что набор крупных валидаторов не вступит в сговор, обменивая небольшую долю доверия на огромный выигрыш в эффективности.

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

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

• Композируемость и интеграция: TEE довольно легко интегрируются в существующие системы — вы можете взять существующую программу, поместить ее в анклав и получить некоторые преимущества безопасности без особого изменения модели программирования. ZK и FHE часто требуют переписывания программы в виде схемы или ограничительной формы, что может потребовать огромных усилий. Например, написание простой верификации модели ИИ в ZK включает ее преобразование в серию арифметических операций и ограничений, что далеко не так просто, как обычный запуск TensorFlow в TEE и аттестация результата. MPC аналогичным образом может потребовать создания индивидуального протокола для каждого случая использования. Поэтому с точки зрения производительности и стоимости разработки TEE привлекательны. Мы видим более быстрое внедрение TEE в некоторых областях именно потому, что можно использовать существующие экосистемы программного обеспечения (многие библиотеки работают в анклавах с минимальными изменениями). ZK/MPC требуют специальных инженерных талантов, которые в дефиците. Однако обратной стороной является то, что TEE создают решение, которое часто является более изолированным (вы должны доверять этому анклаву или этому набору узлов), тогда как ZK дает вам доказательство, которое любой может проверить в блокчейне, что делает его высококомпозируемым (любой контракт может проверить zk-доказательство). Таким образом, результаты ZK являются переносимыми — они создают небольшое доказательство, которое любое количество других контрактов или пользователей могут использовать для получения доверия. Результаты TEE обычно представляются в виде аттестации, привязанной к конкретному оборудованию, и, возможно, не являются лаконичными; ими может быть не так легко поделиться, и они могут зависеть от конкретной сети (хотя вы можете опубликовать подпись результата и настроить контракты на ее прием, если им известен открытый ключ анклава).

На практике мы видим гибридные подходы: например, Sanders Network утверждает, что TEE, MPC и ZK проявляют себя наилучшим образом в разных областях и могут дополнять друг друга. Конкретный пример — децентрализованная идентификация: можно использовать доказательства ZK для подтверждения учетных данных личности, не раскрывая их, но сами эти учетные данные могли быть проверены и выданы процессом на базе TEE, который конфиденциально проверил ваши документы. Или рассмотрим масштабирование: ZK-роллапы предоставляют лаконичные доказательства для множества транзакций, но генерацию этих доказательств можно было бы ускорить, используя TEE для более быстрого выполнения некоторых вычислений (и затем доказывая только меньшее утверждение). Сочетание иногда может снизить требования к доверию к TEE (например, использовать TEE для производительности, но при этом проверять итоговую правильность с помощью ZK-доказательства или через игру с ончейн-вызовами, чтобы скомпрометированный TEE не мог обмануть, не будучи пойманным). Между тем, MPC можно комбинировать с TEE, сделав вычислительный узел каждой стороны анклавом TEE, добавляя дополнительный уровень защиты, чтобы даже если некоторые стороны вступят в сговор, они все равно не могли видеть данные друг друга, если только не взломают аппаратную безопасность.

Вкратце, TEE предлагают очень практичный и быстрый путь к безопасным вычислениям с умеренными предположениями (доверие оборудованию), в то время как ZK и FHE предлагают более теоретический и бездоверительный путь, но с высокими вычислительными затратами, а MPC предлагает путь распределенного доверия с сетевыми затратами. Правильный выбор в Web3 зависит от требований приложения:

• Если вам нужны быстрые и сложные вычисления на конфиденциальных данных (например, ИИ, большие наборы данных), TEE (или MPC с небольшим количеством сторон) в настоящее время являются единственным осуществимым способом.
• Если вам нужна максимальная децентрализация и проверяемость, лучше всего подходят доказательства ZK (например, для частных криптовалютных транзакций предпочтительнее ZKP, как в Zcash, потому что пользователи не хотят доверять ничему, кроме математики).
• Если вам нужны совместные вычисления между несколькими заинтересованными сторонами, естественно подходит MPC (например, управление ключами с участием нескольких сторон или аукционы).
• Если у вас есть крайне чувствительные данные и долгосрочная конфиденциальность является обязательной, FHE может быть привлекательным вариантом при улучшении производительности, так как даже если кто-то получит ваши зашифрованные тексты годы спустя, без ключа он ничего не узнает, в то время как компрометация анклава может привести к ретроспективной утечке секретов, если велись логи.

Стоит отметить, что блокчейн-пространство активно исследует все эти технологии параллельно. Мы, вероятно, увидим комбинации: например, решения Layer 2, интегрирующие TEE для упорядочивания транзакций и последующего использования ZKP для доказательства того, что TEE следовал правилам (концепция, изучаемая в некоторых исследованиях Ethereum), или сети MPC, использующие TEE в каждом узле для снижения сложности протоколов MPC (поскольку каждый узел внутренне безопасен и может симулировать несколько сторон).

В конечном счете, выбор между TEE, ZK, MPC и FHE не является игрой с нулевой суммой — каждый из них нацелен на разные точки в треугольнике безопасности, производительности и бездоверительности. Как сказано в одной статье, все четыре технологии сталкиваются с «невозможным треугольником» производительности, стоимости и безопасности — ни одно решение не является превосходящим во всех аспектах. Оптимальный дизайн часто предполагает использование правильного инструмента для соответствующей части задачи.

6. Внедрение в основные блокчейн-экосистемы​

Доверенные среды исполнения (Trusted Execution Environments, TEE) находят разный уровень признания в различных блокчейн-экосистемах, что часто зависит от приоритетов сообществ и простоты интеграции. Здесь мы оценим, как TEE используются (или исследуются) в некоторых крупнейших экосистемах: Ethereum, Cosmos и Polkadot, а также коснемся других.

Ethereum (и основные Layer-1 сети)​

В самой основной сети Ethereum TEE не являются частью базового протокола, но они используются в приложениях и Layer-2 решениях. Философия Ethereum опирается на криптографическую безопасность (например, развивающиеся ZK-роллапы), однако TEE нашли применение в оракулах и внесетевом (off-chain) исполнении для Ethereum:

• Сервисы оракулов: Как уже обсуждалось, Chainlink внедрила решения на базе TEE, такие как Town Crier. Хотя не все узлы Chainlink используют TEE по умолчанию, технология доступна для потоков данных, требующих повышенного доверия. Кроме того, API3 (еще один проект оракулов) упоминал использование Intel SGX для работы API и подписания данных для обеспечения их подлинности. Эти сервисы поставляют данные в контракты Ethereum с более строгими гарантиями.

• Layer-2 и роллапы: В сообществе Ethereum ведутся исследования и дискуссии об использовании TEE в секвенсорах роллапов или валидаторах. Например, концепция «ZK-Portal» от ConsenSys и другие проекты предлагали использовать TEE для обеспечения правильного порядка транзакций в оптимистичных роллапах или для защиты секвенсора от цензуры. Статья на Medium даже предполагает, что к 2025 году TEE может стать стандартной функцией в некоторых L2 для таких задач, как защита от высокочастотной торговли (HFT). Проекты вроде Catalyst (DEX для высокочастотной торговли) и Flashbots (для MEV-реле) рассматривали TEE для обеспечения честного упорядочивания транзакций до того, как они попадут в блокчейн.

• Enterprise Ethereum (корпоративный Ethereum): В консорциумных или частных сетях Ethereum на базе разрешений TEE внедряются шире. Trusted Compute Framework (TCF) от Enterprise Ethereum Alliance фактически стал планом интеграции TEE в клиенты Ethereum. Hyperledger Avalon (ранее EEA TCF) позволяет выполнять части смарт-контрактов Ethereum вне сети в TEE, а затем верифицировать их в основной сети. В этот проект внесли вклад такие компании, как IBM, Microsoft и iExec. Хотя в публичном Ethereum это не стало повсеместным, в приватных развертываниях (например, группа банков, использующая Quorum или Besu) TEE могут применяться для того, чтобы даже участники консорциума не видели данные друг друга, а получали только авторизованные результаты. Это позволяет удовлетворить требования к конфиденциальности в корпоративной среде.

• Заметные проекты: Помимо iExec, работающего на Ethereum, существовали такие проекты, как Enigma (который начинался как проект MPC в MIT, затем перешел на использование SGX; позже он стал Secret Network в Cosmos). Другим примером был Decentralized Cloud Services (DCS) в ранних дискуссиях об Ethereum. Совсем недавно OAuth (Oasis Ethereum ParaTime) позволил контрактам Solidity работать конфиденциально, используя бэкенд TEE от Oasis с расчетами в сети Ethereum. Также некоторые DApps на базе Ethereum, связанные с обменом медицинскими данными или играми, экспериментировали с TEE, используя внесетевой компонент анклава для взаимодействия со своими контрактами.

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

Экосистема Cosmos​

Экосистема Cosmos открыта для экспериментов благодаря модульному SDK и суверенным чейнам, и Secret Network (описанная выше) является ярким примером внедрения TEE в Cosmos. Secret Network фактически представляет собой блокчейн на базе Cosmos SDK с консенсусом Tendermint, модифицированным для обязательного использования SGX в валидаторах. Это одна из самых заметных зон Cosmos после основного Cosmos Hub, что указывает на значительное признание технологии TEE в этом сообществе. Успех Secret в обеспечении межсетевой конфиденциальности (благодаря соединениям IBC Secret может служить хабом конфиденциальности для других чейнов Cosmos) является примечательным примером интеграции TEE на уровне L1.

Еще один проект, связанный с Cosmos — Oasis Network (хотя он построен не на Cosmos SDK, он был разработан некоторыми из тех же людей, которые участвовали в создании Tendermint, и разделяет схожую философию модульной архитектуры). Oasis автономен, но может подключаться к Cosmos через мосты и другие механизмы. И Secret, и Oasis показывают, что в мире Cosmos идея «конфиденциальности как функции» через TEE набрала достаточно оборотов, чтобы оправдать создание выделенных сетей.

В Cosmos даже существует концепция «провайдеров конфиденциальности» для межсетевых приложений — например, приложение в одной сети может вызвать контракт в Secret Network через IBC для выполнения конфиденциального вычисления, а затем получить результат обратно. Эта компонуемость (composability) зарождается прямо сейчас.

Кроме того, проект Anoma (не относящийся строго к Cosmos, но связанный в плане взаимодействия сетей) обсуждал использование TEE для архитектур, ориентированных на намерения (intent-centric), хотя это пока носит более теоретический характер.

Вкратце, в Cosmos есть как минимум одна крупная сеть, полностью принявшая TEE (Secret), и другие, взаимодействующие с ней, что иллюстрирует здоровое внедрение в этой сфере. Модульность Cosmos может позволить появиться большему числу таких сетей (например, можно представить зону Cosmos, специализирующуюся на оракулах или идентификации на базе TEE).

Polkadot и Substrate​

Дизайн Polkadot позволяет парачейнам специализироваться, и действительно, Polkadot хостит несколько парачейнов, использующих TEE:

• Sanders Network: Как уже было сказано, это парачейн, предлагающий облачные вычисления на базе TEE. Sanders работает как парачейн, предоставляя услуги другим сетям через XCMP (кросс-чейн передача сообщений). Например, другой проект Polkadot может передать конфиденциальную задачу воркерам Sanders и получить обратно доказательство или результат. Токеномика Sanders стимулирует запуск узлов TEE, и проект имеет значительное сообщество, что сигнализирует о сильном внедрении.
• Integritee: Еще один парачейн, ориентированный на корпоративные решения и конфиденциальность данных с использованием TEE. Integritee позволяет командам развертывать собственные приватные сайдчейны (называемые Teewasms), где исполнение происходит в анклавах. Он нацелен на такие варианты использования, как конфиденциальная обработка данных для корпораций, которые при этом хотят опираться на безопасность Polkadot.
• /Root или Crust?: В некоторых проектах, связанных с Polkadot, возникали идеи использования TEE для децентрализованного хранения или случайных маяков (random beacons). Например, Crust Network (децентрализованное хранение) изначально планировала доказательство хранения на базе TEE (хотя позже перешла на другой дизайн). А парачейн случайных чисел Polkadot (Entropy) рассматривал выбор между TEE и VRF.

Опора Polkadot на ончейн-управление и обновления означает, что парачейны могут быстро внедрять новые технологии. И Sanders, и Integritee прошли через обновления для улучшения интеграции TEE (например, поддержку новых функций SGX или совершенствование методов аттестации). Web3 Foundation также финансировал ранние разработки TEE-проектов на базе Substrate, таких как SubstraTEE (ранний прототип, демонстрировавший внесетевое исполнение контрактов в TEE с ончейн-верификацией).

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

Другие экосистемы и общее внедрение​

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

• Layer-1 сети за пределами Ethereum: Некоторые новые L1 экспериментировали с TEE. У NEAR Protocol была ранняя концепция шарда на базе TEE для приватных контрактов (пока не реализована). Celo рассматривал TEE для доказательств легких клиентов (их доказательства Plumo теперь полагаются на SNARK, но в какой-то момент они изучали SGX для сжатия данных чейна для мобильных устройств). Concordium, регулируемая L1 с упором на конфиденциальность, использует ZK для анонимности, но также исследует TEE для верификации личности. Dfinity / Internet Computer использует защищенные анклавы в своих узловых машинах, но для обеспечения доверия при начальной загрузке (а не для исполнения контрактов, так как их криптография «Chain Key» справляется с этим).

• Bitcoin: Хотя сам Bitcoin не использует TEE, существуют побочные проекты. Например, кастодиальные решения на базе TEE (системы Vault) для ключей Bitcoin или определенные предложения в DLC (Discrete Log Contracts) по использованию оракулов, которые могут быть защищены с помощью TEE. В целом сообщество Bitcoin более консервативно и вряд ли доверит Intel участие в консенсусе, но как вспомогательная технология (аппаратные кошельки с защищенными элементами) она уже принята.

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

• Метрики внедрения: Сложно количественно оценить внедрение, но можно взглянуть на такие индикаторы, как количество проектов, объем инвестиций и доступность инфраструктуры. На этом фронте сегодня (2025 год) мы имеем: как минимум 3–4 публичные сети (Secret, Oasis, Sanders, Integritee, Automata как внесетевая), явно использующие TEE; включение технологии в крупнейшие сети оракулов; поддержку конфиденциальных вычислений крупными техгигантами (Microsoft Azure, Google Cloud предлагают виртуальные машины с поддержкой TEE — и эти услуги используются узлами блокчейна как опция). Консорциум конфиденциальных вычислений (Confidential Computing Consortium) теперь включает участников, ориентированных на блокчейн (Ethereum Foundation, Chainlink, Fortanix и др.), что свидетельствует о межотраслевом сотрудничестве. Все это указывает на растущее, но нишевое внедрение — TEE пока не вездесущи в Web3, но они заняли важные ниши там, где требуются конфиденциальность и безопасные внесетевые вычисления.

title: 7. Бизнес- и регуляторные аспекты description: Анализ влияния доверенных сред исполнения (TEE) на блокчейн-инфраструктуру, комплаенс и институциональное внедрение. keywords:

• TEE
• конфиденциальные вычисления
• блокчейн-инфраструктура
• комплаенс
• Web3 разработка
• регуляции
• Intel SGX
• конфиденциальность данных tags: [blockchain, web3] image: "https://opengraph-image.blockeden.xyz/api/og-blockeden-xyz?title=7.%20%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%20%D0%B8%20%D1%80%D0%B5%D0%B3%D1%83%D0%BB%D1%8F%D1%82%D0%BE%D1%80%D0%BD%D1%8B%D0%B5%20%D0%B0%D1%81%D0%BF%D0%B5%D0%BA%D1%82%D1%8B%22%0A%0A%23%23%207.%20%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%20%D0%B8%20%D1%80%D0%B5%D0%B3%D1%83%D0%BB%D1%8F%D1%82%D0%BE%D1%80%D0%BD%D1%8B%D0%B5%20%D0%B0%D1%81%D0%BF%D0%B5%D0%BA%D1%82%D1%8B%0A%0A%D0%98%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%20%D0%B4%D0%BE%D0%B2%D0%B5%D1%80%D0%B5%D0%BD%D0%BD%D1%8B%D1%85%20%D1%81%D1%80%D0%B5%D0%B4%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F%20(TEE) в блокчейн-приложениях поднимает ряд деловых и нормативных вопросов, которые должны учитывать заинтересованные стороны:

Соблюдение конфиденциальности и институциональное внедрение​

Одним из бизнес-драйверов внедрения TEE является необходимость соблюдения правил конфиденциальности данных (таких как GDPR в Европе или HIPAA в США для медицинских данных) при использовании технологии блокчейн. Публичные блокчейны по умолчанию транслируют данные на весь мир, что противоречит правилам, требующим защиты конфиденциальных личных данных. TEE предлагают способ сохранить конфиденциальность данных ончейн и делиться ими только контролируемым образом, обеспечивая тем самым соблюдение нормативных требований. Как уже отмечалось, «TEE способствуют соблюдению правил конфиденциальности данных, изолируя конфиденциальные данные пользователей и обеспечивая их безопасную обработку». Эта возможность имеет решающее значение для привлечения предприятий и институтов в Web3, поскольку они не могут рисковать нарушением закона. Например, медицинское dApp, обрабатывающее информацию о пациентах, может использовать TEE для гарантии того, что никакие необработанные данные пациентов не попадут в блокчейн, что соответствует требованиям HIPAA к шифрованию и контролю доступа. Аналогичным образом, европейский банк может использовать сеть на базе TEE для токенизации и торговли активами без раскрытия личных данных клиентов, что соответствует GDPR.

Это имеет положительный регуляторный аспект: некоторые регуляторы указывают, что такие решения, как TEE (и связанные с ними концепции конфиденциальных вычислений), являются предпочтительными, поскольку они обеспечивают техническое обеспечение конфиденциальности. Мы видели, как Всемирный экономический форум и другие организации выделяли TEE как средство внедрения принципа «конфиденциальность по проектированию» (privacy by design) в блокчейн-системы (по сути, встраивая комплаенс на уровне протокола). Таким образом, с точки зрения бизнеса TEE могут ускорить институциональное внедрение, устранив один из ключевых блокирующих факторов — конфиденциальность данных. Компании охотнее используют блокчейн или строят на его основе решения, если знают, что существует аппаратная защита их данных.

Еще одним аспектом комплаенса является аудируемость и надзор. Предприятиям часто требуются журналы аудита и возможность доказать аудиторам, что они контролируют данные. TEE могут помочь в этом, создавая отчеты об аттестации и защищенные журналы доступа. Например, «устойчивое логирование» Oasis в анклаве обеспечивает защищенный от несанкционированного доступа журнал конфиденциальных операций. Предприятие может показать этот журнал регуляторам, чтобы доказать, что, скажем, запускался только авторизованный код и к данным клиентов выполнялись только определенные запросы. Такой вид аттестованного аудита может удовлетворить регуляторов больше, чем традиционная система, где приходится доверять журналам системного администратора.

Доверие и ответственность​

С другой стороны, внедрение TEE меняет структуру доверия и, следовательно, модель ответственности в блокчейн-решениях. Если DeFi-платформа использует TEE и что-то идет не так из-за аппаратного сбоя, кто несет ответственность? Например, рассмотрим сценарий, в котором ошибка в Intel SGX приводит к утечке деталей секретных транзакций обмена, из-за чего пользователи теряют деньги (в результате фронтраннинга и т. д.). Пользователи доверяли заявлениям платформы о безопасности. Виновата ли платформа или Intel? Юридически пользователи могут предъявить претензии платформе (которой, в свою очередь, возможно, придется предъявить претензии Intel). Это усложняет ситуацию, поскольку в модель безопасности глубоко встроен сторонний поставщик технологий (производитель процессоров). Компании, использующие TEE, должны учитывать это в контрактах и оценках рисков. Некоторые могут запрашивать гарантии или поддержку у производителей оборудования при использовании их TEE в критически важной инфраструктуре.

Существует также опасение по поводу централизации: если безопасность блокчейна зависит от оборудования одной компании (Intel или AMD), регуляторы могут отнестись к этому со скептицизмом. Например, может ли правительство вызвать в суд или принудить эту компанию скомпрометировать определенные анклавы? Это не чисто теоретическая проблема — вспомните законы об экспортном контроле: высококачественное оборудование для шифрования может подлежать регулированию. Если значительная часть криптоинфраструктуры будет полагаться на TEE, вполне вероятно, что правительства могут попытаться внедрить бэкдоры (хотя доказательств этому нет, важно само восприятие). Некоторые защитники конфиденциальности указывают регуляторам на это: TEE концентрируют доверие, и регуляторы должны тщательно их проверять. Напротив, регуляторы, стремящиеся к большему контролю, могут предпочесть TEE математической конфиденциальности, такой как ZK, потому что с TEE существует по крайней мере представление о том, что правоохранительные органы могут обратиться к производителю оборудования с судебным ордером в случае крайней необходимости (например, для получения мастер-ключа аттестации — что не так просто и маловероятно, но это путь, которого не существует в случае с ZK). Таким образом, регуляторное восприятие может разделиться: регуляторы конфиденциальности (агентства по защите данных) выступают за TEE ради комплаенса, в то время как правоохранительные органы могут быть осторожно оптимистичны, поскольку TEE не делают данные полностью «невидимыми» так, как это делает сильное шифрование — существует теоретический рычаг (оборудование), за который они могли бы попытаться потянуть.

Бизнесу необходимо ориентироваться в этом, возможно, участвуя в сертификации. Существуют сертификаты безопасности, такие как FIPS 140 или Common Criteria для аппаратных модулей. В настоящее время SGX и другие имеют некоторые сертификаты (например, у SGX были уровни EAL Common Criteria для определенных целей). Если блокчейн-платформа может указать на то, что технология анклавов сертифицирована по высокому стандарту, регуляторам и партнерам может быть спокойнее. Например, проект CBDC (цифровой валюты центрального банка) может потребовать, чтобы любая используемая TEE была сертифицирована по стандарту FIPS для подтверждения надежности генерации случайных чисел и т. д. Это вводит дополнительные процессы и, возможно, ограничивает выбор определенными версиями оборудования.

Экосистема и стоимостные факторы​

С точки зрения бизнеса, использование TEE может повлиять на структуру затрат блокчейн-операций. Узлы (ноды) должны иметь специфические процессоры (которые могут быть дороже или менее энергоэффективны). Это может означать более высокие счета за облачный хостинг или капитальные затраты. Например, если проект требует наличия Intel Xeon с SGX для всех валидаторов, это становится ограничением — валидатором не может стать любой человек с Raspberry Pi или старым ноутбуком; им нужно соответствующее оборудование. Это может централизовать круг участников (возможно, в пользу тех, кто может позволить себе высокопроизводительные серверы или использует облачных провайдеров, предлагающих виртуальные машины с SGX). В крайних случаях это может подтолкнуть сеть к большей закрытости (permissioned) или зависимости от облачных провайдеров, что является компромиссом в плане децентрализации и бизнес-компромиссом (сети, возможно, придется субсидировать операторов узлов).

С другой стороны, некоторые компании могут счесть это приемлемым, поскольку они хотят работать с известными валидаторами или имеют список разрешенных участников (особенно в корпоративных консорциумах). Но в публичных криптосетях это вызывало дебаты — например, когда требовался SGX, люди спрашивали: «Означает ли это, что только крупные центры обработки данных будут запускать узлы?». Это влияет на настроения сообщества и, следовательно, на рыночное признание. Например, некоторые крипто-пуристы могут избегать сетей, требующих TEE, называя их «менее бездоверительными» (less trustless) или слишком централизованными. Поэтому проектам приходится заниматься PR и просвещением сообщества, разъясняя допущения о доверии и причины, по которым это все еще безопасно. Мы видели, как Secret Network боролась с FUD (страхом и неуверенностью), объясняя строгий мониторинг обновлений Intel и то, что валидаторы подвергаются слэшингу, если не обновляют анклавы, создавая по сути социальный уровень доверия поверх аппаратного.

Еще одним фактором являются партнерства и поддержка. Бизнес-экосистема вокруг TEE включает в себя технологических гигантов (Intel, AMD, ARM, Microsoft, Google и др.). Блокчейн-проекты, использующие TEE, часто сотрудничают с ними (например, iExec сотрудничает с Intel, Secret Network работает с Intel над улучшением аттестации, Oasis — с Microsoft над конфиденциальным ИИ и т. д.). Эти партнерства могут обеспечить финансирование, техническую помощь и доверие. Это стратегический момент: сближение с индустрией конфиденциальных вычислений может открыть двери (для финансирования или корпоративных пилотных проектов), но также означает, что криптопроект может объединиться с крупными корпорациями, что имеет идеологические последствия в сообществе.

Регуляторная неопределенность​

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

• Юрисдикция данных: Если данные обрабатываются внутри TEE в определенной стране, считается ли, что они «обрабатываются в этой стране» или нигде (поскольку они зашифрованы)? Некоторые законы о конфиденциальности требуют, чтобы данные граждан не покидали определенных регионов. TEE могут размыть эти границы — у вас может быть анклав в облачном регионе, но на вход и выход поступают только зашифрованные данные. Регуляторам может потребоваться прояснить, как они рассматривают такую обработку.
• Экспортный контроль: Продвинутые технологии шифрования могут подлежать ограничениям на экспорт. TEE включают шифрование памяти — исторически это не было проблемой (так как процессоры с этими функциями продаются по всему миру), но если это когда-либо изменится, это может повлиять на поставки. Также некоторые страны могут запретить или ограничить использование иностранных TEE из соображений национальной безопасности (например, у Китая есть собственный эквивалент SGX, так как они не доверяют Intel, и они могут не разрешить использование SGX для конфиденциальных целей).
• Юридическое принуждение: Сценарий: может ли правительство вызвать в суд оператора узла, чтобы извлечь данные из анклава? Обычно они не могут этого сделать, так как даже оператор не видит содержимое. Но что, если они вызовут в суд Intel для получения конкретного ключа аттестации? Архитектура Intel такова, что даже они не могут расшифровать память анклава (они выдают ключи процессору, который выполняет работу). Но если бы существовал бэкдор или специальная прошивка, которую Intel могла бы подписать для дампа памяти, это была бы гипотетическая проблема, которая беспокоит людей. Юридически такая компания, как Intel, может отказаться, если ее попросят подорвать безопасность (скорее всего, так и будет, чтобы не разрушить доверие к продукту). Но сама возможность может всплывать в регуляторных дискуссиях о законном доступе. Компании, использующие TEE, должны следить за подобными событиями, хотя в настоящее время не существует публичного механизма для извлечения данных анклава компаниями Intel или AMD — в этом и заключается смысл TEE.

Рыночная дифференциация и новые услуги​

С положительной стороны для бизнеса, TEE позволяют создавать новые продукты и услуги, которые можно монетизировать. Например:

• Маркетплейсы конфиденциальных данных: Как отмечали iExec, Ocean Protocol и другие, компании владеют ценными данными, которые они могли бы монетизировать, если бы имели гарантии их неразглашения. TEE позволяют реализовать «аренду данных», когда сами данные никогда не покидают анклав, а передаются только результаты анализа. Это может открыть новые источники дохода и бизнес-модели. Мы видим, как стартапы в Web3 предлагают предприятиям услуги конфиденциальных вычислений, по сути продавая идею «получения аналитики из блокчейна или кросс-корпоративных данных без раскрытия чего-либо».
• Корпоративный DeFi: Финансовые институты часто называют отсутствие конфиденциальности причиной своего отказа от работы с DeFi или публичными блокчейнами. Если TEE смогут гарантировать конфиденциальность их позиций или сделок, они могут принять участие, привнеся в экосистему больше ликвидности и бизнеса. Проекты, ориентированные на это (например, секретные займы Secret или частный AMM Oasis с функциями комплаенса), стремятся привлечь институциональных пользователей. В случае успеха это может стать значительным рынком (представьте институциональные AMM-пулы, где идентификационные данные и суммы защищены, но анклав обеспечивает внутреннюю проверку на соответствие требованиям, таким как AML — это продукт, который может привлечь большие деньги в DeFi при соблюдении регуляторного комфорта).
• Страхование и управление рисками: Поскольку TEE снижают определенные риски (например, манипулирование оракулами), мы можем увидеть снижение страховых премий или появление новых страховых продуктов для смарт-контрактных платформ. И наоборот, TEE вносят новые риски (например, технический сбой анклавов), которые сами по себе могут быть страховыми случаями. Сфера криптострахования только зарождается; то, как она будет относиться к системам, основанным на TEE, будет интересным. Платформа может позиционировать использование TEE как способ снижения риска утечки данных, что облегчает и удешевляет страхование, давая ей конкурентное преимущество.

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

Заключение​

Доверенные среды исполнения (Trusted Execution Environments, TEE) стали мощным компонентом в инструментарии Web3, открыв путь для нового класса децентрализованных приложений, требующих конфиденциальности и безопасных внечейн-вычислений. Мы увидели, что TEE, такие как Intel SGX, ARM TrustZone и AMD SEV, предоставляют аппаратно изолированный «сейф» для вычислений, и это свойство было использовано для создания смарт-контрактов с сохранением конфиденциальности, верифицируемых оракулов, масштабируемой внечейн-обработки и многого другого. Проекты в различных экосистемах — от приватных контрактов Secret Network на Cosmos до конфиденциальных ParaTimes в Oasis, облака Sanders на базе TEE в Polkadot и маркетплейса iExec для внечейн-вычислений на Ethereum — демонстрируют разнообразные способы интеграции TEE в блокчейн-платформы.

С технической точки зрения TEE предлагают впечатляющие преимущества в скорости и строгую конфиденциальность данных, но они сопряжены со своими трудностями: необходимостью доверять производителям оборудования, потенциальными уязвимостями по сторонним каналам, а также сложностями в интеграции и компонуемости. Мы сравнили TEE с криптографическими альтернативами (ZKP, FHE, MPC) и обнаружили, что у каждой технологии есть своя ниша: TEE превосходят в производительности и простоте использования, в то время как ZKP и FHE обеспечивают максимальную децентрализацию без необходимости в доверии (trustlessness) при высокой вычислительной стоимости, а MPC распределяет доверие между участниками. На самом деле многие передовые решения являются гибридными, используя TEE наряду с криптографическими методами, чтобы получить лучшее из обоих миров.

Внедрение решений на базе TEE неуклонно растет. dApps на Ethereum используют TEE для безопасности оракулов и приватных вычислений, Cosmos и Polkadot имеют нативную поддержку через специализированные чейны, а корпоративные блокчейн-инициативы внедряют TEE для обеспечения соответствия нормативным требованиям. С точки зрения бизнеса TEE могут стать мостом между децентрализованными технологиями и регулированием, позволяя обрабатывать конфиденциальные данные в блокчейне под защитой аппаратной безопасности, что открывает двери для институционального использования и новых услуг. В то же время использование TEE означает принятие новых парадигм доверия и необходимость следить за тем, чтобы этос децентрализации блокчейна не был подорван непрозрачностью «кремния».

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

Источники: Информация в данном отчете была собрана из различных актуальных источников, включая официальную документацию и блоги проектов, отраслевой анализ и академические исследования, на которые даны ссылки по всему тексту. Среди заметных упоминаний — руководство Metaschool 2025 по TEE в Web3, сравнения от Sanders Network, технические обзоры FHE/TEE/ZKP/MPC от ChainCatcher и других, а также заявления о соответствии нормативным требованиям от Binance Research и многие другие. Эти источники содержат более подробную информацию и рекомендуются читателям, желающим изучить конкретные аспекты более глубоко.

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

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

title: Заключение: Эра программируемой конфиденциальности description: Узнайте о будущем блокчейн-технологий и программируемой конфиденциальности через призму FHE-VM и ZK-копроцессоров. keywords:

• блокчейн
• программируемая конфиденциальность
• FHE-VM
• ZK-копроцессоры
• Web3
• криптография
• смарт-контракты tags: [blockchain, web3, privacy, cryptography] image: "https://opengraph-image.blockeden.xyz/api/og-blockeden-xyz?title=%D0%97%D0%B0%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%B8%D0%B5%3A%20%D0%AD%D1%80%D0%B0%20%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D1%83%D0%B5%D0%BC%D0%BE%D0%B9%20%D0%BA%D0%BE%D0%BD%D1%84%D0%B8%D0%B4%D0%B5%D0%BD%D1%86%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B8%22%0A%0A%23%23%20%D0%97%D0%B0%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%B8%D0%B5%0A%0A%D0%A2%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F%20%D0%B1%D0%BB%D0%BE%D0%BA%D1%87%D0%B5%D0%B9%D0%BD%20%D0%B2%D1%81%D1%82%D1%83%D0%BF%D0%B0%D0%B5%D1%82%20%D0%B2%20%D0%BD%D0%BE%D0%B2%D1%83%D1%8E%20%D1%8D%D1%80%D1%83%20**%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D1%83%D0%B5%D0%BC%D0%BE%D0%B9%20%D0%BA%D0%BE%D0%BD%D1%84%D0%B8%D0%B4%D0%B5%D0%BD%D1%86%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B8**%2C%20%D0%B3%D0%B4%D0%B5%20%D0%BA%D0%BE%D0%BD%D1%84%D0%B8%D0%B4%D0%B5%D0%BD%D1%86%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C%20%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85%20%D0%B8%20%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C%20%D1%81%D0%BC%D0%B0%D1%80%D1%82-%D0%BA%D0%BE%D0%BD%D1%82%D1%80%D0%B0%D0%BA%D1%82%D0%BE%D0%B2%20%D0%B8%D0%B4%D1%83%D1%82%20%D1%80%D1%83%D0%BA%D0%B0%20%D0%BE%D0%B1%20%D1%80%D1%83%D0%BA%D1%83.%20%D0%9F%D0%B0%D1%80%D0%B0%D0%B4%D0%B8%D0%B3%D0%BC%D1%8B%20FHE-VM%20%D0%B8%20ZK-%D0%BA%D0%BE%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D0%BE%D1%80%D0%BE%D0%B2%2C%20%D1%85%D0%BE%D1%82%D1%8F%20%D0%B8%20%D1%80%D0%B0%D0%B7%D0%BB%D0%B8%D1%87%D0%B0%D1%8E%D1%82%D1%81%D1%8F%20%D1%82%D0%B5%D1%85%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%2C%20%D1%81%D1%82%D1%80%D0%B5%D0%BC%D1%8F%D1%82%D1%81%D1%8F%20%D1%80%D0%B0%D1%81%D1%88%D0%B8%D1%80%D0%B8%D1%82%D1%8C%20%D1%81%D1%84%D0%B5%D1%80%D1%83%20%D0%BF%D1%80%D0%B8%D0%BC%D0%B5%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%B1%D0%BB%D0%BE%D0%BA%D1%87%D0%B5%D0%B9%D0%BD-%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B9%2C%20%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB%D1%8F%D1%8F%20%D1%82%D0%BE%2C%20*%D1%87%D1%82%D0%BE*%20%D0%BC%D1%8B%20%D0%BC%D0%BE%D0%B6%D0%B5%D0%BC%20%D0%B2%D1%8B%D1%87%D0%B8%D1%81%D0%BB%D0%B8%D1%82%D1%8C%2C%20%D0%B8%20%D1%82%D0%BE%2C%20*%D1%87%D1%82%D0%BE*%20%D0%BC%D1%8B%20%D0%B4%D0%BE%D0%BB%D0%B6%D0%BD%D1%8B%20%D1%80%D0%B0%D1%81%D0%BA%D1%80%D1%8B%D1%82%D1%8C.%0A%0A%D0%92%D0%B8%D1%80%D1%82%D1%83%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B5%20%D0%BC%D0%B0%D1%88%D0%B8%D0%BD%D1%8B%20%D1%81%20%D0%BF%D0%BE%D0%BB%D0%BD%D0%BE%D1%81%D1%82%D1%8C%D1%8E%20%D0%B3%D0%BE%D0%BC%D0%BE%D0%BC%D0%BE%D1%80%D1%84%D0%BD%D1%8B%D0%BC%20%D1%88%D0%B8%D1%84%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%D0%BC%20(FHE-VM) сохраняют вычисления ончейн и в зашифрованном виде, поддерживая децентрализацию и компонуемость, но требуя достижений в области эффективности. ZK-копроцессоры переносят тяжелые вычисления в оффчейн, обеспечивая практически неограниченные вычисления под криптографическими гарантиями, и уже доказывают свою ценность в масштабировании и улучшении Ethereum. Выбор между ними (и их гибридами) будет зависеть от конкретного сценария использования: если требуется взаимодействие с приватным состоянием в реальном времени, подход FHE может быть более подходящим; если требуются чрезвычайно сложные вычисления или интеграция с существующим кодом, ZK-копроцессор может стать оптимальным решением. Во многих случаях они дополняют друг друга — действительно, мы видим, как ZK-доказательства укрепляют целостность FHE, а FHE потенциально помогает ZK, обрабатывая частные данные для пруверов (provers).

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

Одно из ключевых обещаний технологии блокчейн, такой как Ethereum, — это определенная степень анонимности. Участники, известные как валидаторы, должны работать под покровом криптографических псевдонимов, защищая свою реальную личность и, как следствие, свою безопасность.

Однако недавняя исследовательская работа под названием "Деанонимизация валидаторов Ethereum: P2P-сеть имеет проблему конфиденциальности" от исследователей из ETH Zurich и других учреждений выявила критический недостаток в этом предположении. Они продемонстрировали простой, недорогой метод прямой привязки публичного идентификатора валидатора к IP-адресу машины, на которой он работает.

Короче говоря, валидаторы Ethereum далеко не так анонимны, как многие считают. Полученные данные были достаточно значимыми, чтобы принести исследователям вознаграждение за обнаруженную ошибку от Ethereum Foundation, что подтверждает серьезность утечки конфиденциальных данных.

Как работает уязвимость: недостаток в протоколе распространения информации​

Чтобы понять уязвимость, нам сначала нужно представить, как взаимодействуют валидаторы Ethereum. Сеть состоит из более чем миллиона валидаторов, которые постоянно «голосуют» за состояние цепочки. Эти голоса называются аттестациями, и они транслируются по одноранговой ($P2P$) сети всем другим нодам.

При таком большом количестве валидаторов, если бы каждый транслировал каждый голос всем остальным, сеть мгновенно бы перегрузилась. Чтобы решить эту проблему, разработчики Ethereum реализовали умное масштабирующее решение: сеть разделена на 64 отдельных канала связи, известных как подсети.

• По умолчанию каждая нода (компьютер, на котором запущено программное обеспечение валидатора) подписывается только на две из этих 64 подсетей. Ее основная задача — добросовестно ретранслировать все сообщения, которые она видит на этих двух каналах.
• Когда валидатору необходимо проголосовать, его аттестация случайным образом назначается одной из 64 подсетей для трансляции.

Именно здесь кроется уязвимость. Представьте ноду, чья задача — управлять трафиком для каналов 12 и 13. Весь день она добросовестно пересылает сообщения только из этих двух каналов. Но затем она внезапно отправляет вам сообщение, которое относится к каналу 45.

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

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

Метод оказался шокирующе эффективным. Используя всего четыре ноды в течение трех дней, команда успешно определила IP-адреса более 161 000 валидаторов, что составляет более 15% всей сети Ethereum.

Почему это важно: риски деанонимизации​

Раскрытие IP-адреса валидатора — это не пустяк. Это открывает двери для целенаправленных атак, которые угрожают отдельным операторам и здоровью сети Ethereum в целом.

1. Целенаправленные атаки и кража вознаграждений Ethereum заранее, за несколько минут, объявляет, какой валидатор должен предложить следующий блок. Злоумышленник, знающий IP-адрес этого валидатора, может запустить атаку типа «отказ в обслуживании» (DDoS), перегрузив его трафиком и отключив от сети. Если валидатор пропускает свое четырехсекундное окно для предложения блока, возможность переходит к следующему валидатору в очереди. Если злоумышленник является этим следующим валидатором, он может затем получить вознаграждение за блок и ценные комиссии за транзакции (MEV), которые должны были достаться жертве.

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

3. Выявление централизованной реальности Исследование также пролило свет на некоторые неудобные истины о децентрализации сети:

• Чрезвычайная концентрация: Команда обнаружила пиры, размещающие ошеломляющее количество валидаторов, включая один IP-адрес, на котором работало более 19 000 валидаторов. Сбой одной машины может оказать непропорционально большое влияние на сеть.
• Зависимость от облачных сервисов: Примерно 90% обнаруженных валидаторов работают на облачных провайдерах, таких как AWS и Hetzner, а не на компьютерах индивидуальных домашних стейкеров. Это представляет собой значительную точку централизации.
• Скрытые зависимости: Многие крупные стейкинг-пулы заявляют, что их операторы независимы. Однако исследование выявило случаи, когда валидаторы из разных, конкурирующих пулов работали на одной и той же физической машине, создавая скрытые системные риски.

Меры по смягчению: как валидаторы могут защитить себя?​

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

• Создание большего шума: Валидатор может выбрать подписку на более чем две подсети — или даже на все 64. Это значительно затрудняет наблюдателю различение между ретранслируемыми сообщениями и сообщениями, сгенерированными самим валидатором.
• Использование нескольких нод: Оператор может разделить обязанности валидатора между разными машинами с разными IP-адресами. Например, одна нода может обрабатывать аттестации, в то время как отдельная, приватная нода используется только для предложения высокоценных блоков.
• Приватный пиринг: Валидаторы могут устанавливать доверенные, приватные соединения с другими нодами для ретрансляции своих сообщений, скрывая их истинное происхождение внутри небольшой, доверенной группы.
• Протоколы анонимной трансляции: Могут быть реализованы более продвинутые решения, такие как Dandelion, который скрывает происхождение сообщения, передавая его по случайному «стеблю» перед широкой трансляцией.

Заключение​

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

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

Индустрия блокчейна сталкивается с критическим переломным моментом в 2024 году. В то время как мировой рынок блокчейн-технологий, по прогнозам, достигнет $469,49 млрд к 2030 году, конфиденциальность остается фундаментальной проблемой. Доверенные среды исполнения (TEE) стали потенциальным решением: ожидается, что рынок TEE вырастет с $1,2 млрд в 2023 году до $3,8 млрд к 2028 году. Но действительно ли этот аппаратный подход решает парадокс конфиденциальности блокчейна, или он вносит новые риски?

Аппаратная основа: понимание перспектив TEE​

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

На рынке в настоящее время доминируют три ключевые реализации:

1. Intel SGX (Software Guard Extensions)

   • Доля рынка: 45% серверных реализаций TEE
   • Производительность: до 40% накладных расходов для зашифрованных операций
   • Функции безопасности: шифрование памяти, удаленная аттестация
   • Известные пользователи: Microsoft Azure Confidential Computing, Fortanix

2. ARM TrustZone

   • Доля рынка: 80% мобильных реализаций TEE
   • Производительность: <5% накладных расходов для большинства операций
   • Функции безопасности: безопасная загрузка, биометрическая защита
   • Ключевые приложения: мобильные платежи, DRM, безопасная аутентификация

3. AMD SEV (Secure Encrypted Virtualization)

   • Доля рынка: 25% серверных реализаций TEE
   • Производительность: 2-7% накладных расходов для шифрования ВМ
   • Функции безопасности: шифрование памяти ВМ, защита вложенных таблиц страниц
   • Известные пользователи: Google Cloud Confidential Computing, AWS Nitro Enclaves

Влияние на реальный мир: данные говорят сами за себя​

Рассмотрим три ключевых приложения, где TEE уже трансформирует блокчейн:

1. Защита от MEV: пример Flashbots​

Реализация TEE от Flashbots продемонстрировала замечательные результаты:

• До TEE (2022):

  • Средняя ежедневная добыча MEV: $7,1 млн
  • Централизованные экстракторы: 85% MEV
  • Потери пользователей от сэндвич-атак: $3,2 млн ежедневно

• После TEE (2023):

  • Средняя ежедневная добыча MEV: $4,3 млн (-39%)
  • Демократизированная добыча: ни одна сущность не превышает 15% MEV
  • Потери пользователей от сэндвич-атак: $0,8 млн ежедневно (-75%)

По словам Фила Дайана, соучредителя Flashbots: "TEE фундаментально изменила ландшафт MEV. Мы наблюдаем более демократичный, эффективный рынок со значительно сниженным ущербом для пользователей."

2. Решения для масштабирования: прорыв Scroll​

Гибридный подход Scroll, сочетающий TEE с доказательствами с нулевым разглашением, достиг впечатляющих показателей:

• Пропускная способность транзакций: 3 000 TPS (по сравнению с 15 TPS у Ethereum)
• Стоимость транзакции: $0,05 (по сравнению с $2-20 в основной сети Ethereum)
• Время валидации: 15 секунд (по сравнению с минутами для чистых ZK-решений)
• Гарантия безопасности: 99,99% с двойной верификацией (TEE + ZK)

Доктор Сара Ванг, исследователь блокчейна в Калифорнийском университете в Беркли, отмечает: "Реализация Scroll показывает, как TEE может дополнять криптографические решения, а не заменять их. Прирост производительности значителен без ущерба для безопасности."

3. Приватный DeFi: новые приложения​

Несколько протоколов DeFi теперь используют TEE для приватных транзакций:

• Secret Network (использует Intel SGX):
  • Обработано более 500 000 приватных транзакций
  • $150 млн в приватных переводах токенов
  • Снижение фронт-раннинга на 95%

Техническая реальность: вызовы и решения​

Смягчение атак по побочным каналам​

Недавние исследования выявили как уязвимости, так и решения:

1. Атаки по анализу энергопотребления

   • Уязвимость: 85% успешность извлечения ключей
   • Решение: последнее обновление SGX от Intel снижает успешность до <0,1%
   • Стоимость: 2% дополнительных накладных расходов на производительность

2. Атаки по времени доступа к кэшу

   • Уязвимость: 70% успешность извлечения данных
   • Решение: технология разделения кэша от AMD
   • Влияние: уменьшает поверхность атаки на 99%

Анализ риска централизации​

Аппаратная зависимость вносит специфические риски:

• Доля рынка производителей оборудования (2023):
  • Intel: 45%
  • AMD: 25%
  • ARM: 20%
  • Другие: 10%

Для решения проблем централизации такие проекты, как Scroll, реализуют многовендорную верификацию TEE:

• Требуется согласие от 2+ TEE разных производителей
• Перекрестная валидация с решениями, не использующими TEE
• Инструменты верификации с открытым исходным кодом

Анализ рынка и будущие прогнозы​

Внедрение TEE в блокчейне демонстрирует сильный рост:

• Текущие затраты на внедрение:

  • Аппаратное обеспечение TEE серверного класса: $2 000-5 000
  • Стоимость интеграции: $50 000-100 000
  • Обслуживание: $5 000/месяц

• Прогнозируемое снижение затрат: 2024: -15% 2025: -30% 2026: -50%

Отраслевые эксперты прогнозируют три ключевых изменения к 2025 году:

1. Эволюция аппаратного обеспечения

   • Новые процессоры, специфичные для TEE
   • Снижение накладных расходов на производительность (<1%)
   • Улучшенная защита от атак по побочным каналам

2. Консолидация рынка

   • Появление стандартов
   • Кроссплатформенная совместимость
   • Упрощенные инструменты для разработчиков

3. Расширение приложений

   • Приватные платформы смарт-контрактов
   • Децентрализованные решения для идентификации
   • Кроссчейн-протоколы конфиденциальности

Дальнейший путь​

Хотя TEE предлагает убедительные решения, успех требует решения нескольких ключевых областей:

1. Разработка стандартов

   • Формирование отраслевых рабочих групп
   • Открытые протоколы для кросс-вендорной совместимости
   • Системы сертификации безопасности

2. Экосистема разработчиков

   • Новые инструменты и SDK
   • Программы обучения и сертификации
   • Эталонные реализации

3. Инновации в аппаратном обеспечении

   • Архитектуры TEE следующего поколения
   • Снижение затрат и энергопотребления
   • Улучшенные функции безопасности

Конкурентная среда​

TEE сталкивается с конкуренцией со стороны других решений для обеспечения конфиденциальности:

Решение	Производительность	Безопасность	Децентрализация	Стоимость
TEE	Высокая	Средне-высокая	Средняя	Средняя
MPC	Средняя	Высокая	Высокая	Высокая
FHE	Низкая	Высокая	Высокая	Очень высокая
ZK Proofs	Средне-высокая	Высокая	Высокая	Высокая

Итог​

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

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