В октябре термин "TEE (Trusted Execution Environment)" стал часто появляться в X ленте. Это удивило меня, потому что TEE традиционно был узкой темой, в основном обсуждаемой в академических кругах системной безопасности. Как человек, проводивший исследования в лаборатории системной безопасности, я был рад увидеть это развитие. Однако меня интересовало, почему TEE внезапно привлек внимание в пространстве Web3. Я также заметил отсутствие доступного контента, объясняющего концепции TEE общественности, что мотивировало меня написать эту статью.

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

В заключение, в этой статье будут рассмотрены следующие темы:

• Введение в концепции TEE и краткий обзор современных TEE
• Различные случаи реализации TEE в экосистеме Web3
• Ограничения TEE и личные взгляды на эти ограничения
• Будущее TEE в экосистеме Web3

1. Что такое TEE?

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

Основные концепции

Большинство серверов Web2 управляют доступом к данным через настройки авторизации. Однако, поскольку этот подход является исключительно программным, он фактически становится неэффективным, если получены привилегии более высокого уровня. Например, если злоумышленник получает привилегии уровня ядра в операционной системе сервера, они потенциально могут получить доступ ко всем данным, контролируемым разрешениями, на сервере, включая ключи шифрования. В таких экстремальных сценариях практически нет способа предотвратить кражу данных только через программные методы. TEE, или Доверенная Среда Выполнения, пытается фундаментально решить эту проблему через аппаратную безопасность. TEE часто называют "конфиденциальным вычислением", но это более широкая концепция, которая включает в себя механизмы вычислений, обеспечивающие конфиденциальность пользовательских данных, такие как ZK, MPC и FHE.

источник: Jujutsu Kaisen

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

Создание закрытого помещения и обработка данных внутри него требует определенных наборов инструкций, аналогичных опкодам. Эти инструкции используют ключи шифрования, хранящиеся в защищенных областях аппаратуры, для выполнения вычислений над данными внутри закрытого помещения. Поскольку TEE является модулем аппаратного уровня безопасности, его реализация различается в зависимости от производителя процессора. Например, Intel поддерживает SGX, AMD поддерживает SEV, а ARM поддерживает TrustZone. С более широкой точки зрения, эти реализации общаются концепцией «защиты памяти с помощью аппаратного шифрования».

1.1. Как TEE защищает данные

Давайте сначала рассмотрим, как работают наиболее распространенные TEE — Intel SGX, AMD SEV и ARM TrustZone, а затем познакомимся с более новыми реализациями TEE.

1.1.1. Тройники OG

Intel SGX

SGX создает и получает доступ к окружениям на уровне процесса. На следующем изображении показано четкое представление того, как работает программа с поддержкой SGX.

исходный текст: https://sgx101.gitbook.io/sgx101/sgx-bootstrap/enclave/interaction-between-pse-and-application-enclaves

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

источник: https://www.intel.com/content/www/us/en/developer/articles/training/intel-software-guard-extensions-tutorial-part-7-refining-the-enclave.html

Если пользователям необходимо напрямую взаимодействовать с данными в пределах анклава — например, предоставлять ввод или получать вывод — они могут взаимодействовать через безопасные каналы, установленные с использованием протоколов, таких как SSL.

AMD SEV

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

SEV генерирует ключи шифрования через процессор безопасности, который физически отделен от ЦП во время создания ВМ. Затем эти ключи используются для шифрования памяти ВМ. Ниже приведена схема, иллюстрирующая разницу между SGX и SEV.

исходный текст: 10.1109/SRDS.2018.00042

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

ARM TrustZone

В отличие от Intel и AMD, которые в основном производят ЦП для настольных компьютеров и серверов, ARM проектирует чипсеты для легких систем, таких как мобильные и встроенные устройства. В результате их реализация Secure Enclave немного отличается от SGX или SEV, используемых в архитектурах более высокого уровня.

TrustZone делит систему на безопасный мир и обычный мир на аппаратном уровне. Разработчики, использующие TrustZone, должны реализовывать функции критической безопасности в безопасном мире, в то время как общие функции выполняются в обычном мире. Переходы между этими двумя мирами происходят через специальные системные вызовы, известные как Secure Monitor Calls, аналогичные SGX.

Основное различие заключается в том, что отдельный блок TrustZone распространяется не только на ЦП или память; он охватывает всю систему, включая системную шину, периферийные устройства и контроллеры прерываний. Apple также использует технологию TEE, называемую Secure Enclave, в своих продуктах, которая очень похожа на TrustZone на высоком уровне.

1.1.2. Расширенные TEE

Как мы обсудим позже, многие оригинальные TEE, включая Intel SGX, столкнулись с уязвимостями каналов боковой информации и трудностями разработки из-за структурных проблем. Для решения этих проблем поставщики выпустили улучшенные версии. С увеличением спроса на безопасное облачное вычисление платформы, такие как AWS/Azure/GCP, начали предлагать собственные службы TEE. Недавно концепция TEE была расширена и на графические процессоры. Некоторые примеры использования Web3 теперь реализуют эти передовые TEE, так что я вкратце объясню их.

Облачные TEE: AWS Nitro, Azure Confidential Computing, Google Cloud Confidential Computing

В связи с растущим спросом на услуги облачных вычислений провайдеры начали разрабатывать собственные решения TEE. AWS Nitro – это анклавная вычислительная среда, которая работает вместе с инстансами EC2. Он обеспечивает физическое разделение вычислительной среды за счет использования специального чипа безопасности Nitro для аттестации и управления ключами. Гипервизор Nitro защищает области памяти анклава с помощью функций, предоставляемых чипом, эффективно защищая от атак как со стороны пользователей, так и со стороны поставщиков облачных услуг.

Azure поддерживает различные спецификации TEE, включая Intel SGX, AMD SEV-SNP и собственную изоляцию на основе виртуализации. Эта гибкость выбора аппаратной среды предоставляет пользователям больше возможностей, но может увеличить поверхность атаки, когда пользователь использует несколько TEE.

Google Cloud предоставляет услуги конфиденциального вычисления, использующие доверенные исполнительные среды (TEE) и сосредотачивающиеся на нагрузках искусственного интеллекта и машинного обучения. В отличие от AWS Nitro, Google Cloud, как и Azure, предлагает изоляцию на основе виртуализации с использованием существующей инфраструктуры TEE. Основные отличия включают поддержку ускорителей CPU, таких как Intel AMX, для обработки интенсивных задач искусственного интеллекта и машинного обучения, а также конфиденциальное вычисление на основе GPU через NVIDIA, о чем будет рассказано позже.

ARM CCA

ARM CCA, выпущенный в конце 2021 года, предназначен для облачных сред, в отличие от TrustZone, который был разработан для одиночных встроенных или мобильных сред. TrustZone статически управляет предварительно определенными защищенными областями памяти, тогда как CCA облегчает динамическое создание Realms (защищенные ограждения). Это позволяет создавать несколько изолированных сред в рамках одной физической установки.

CCA можно сравнить с ARM-версией Intel SGX, хотя есть значительные отличия. В то время как SGX имеет ограничения на память, CCA предоставляет гибкое распределение памяти. Кроме того, CCA использует фундаментально другой подход к безопасности, шифруя всю физическую память, а не только области защищенного завещания, как это делает SGX.

Intel TDX

Intel представила TDX, технологию, которая шифрует память на уровне виртуальной машины, аналогично SEV от AMD. Этот релиз учитывает отзывы о ограничениях SGX(v1), включая ограничение размера enclave до 256 МБ и увеличенную сложность разработки из-за создания enclave на уровне процесса. Основное различие от SEV заключается в том, что TDX частично доверяет операционной системе, а именно гипервизору, управлению ресурсами виртуальной машины. Кроме того, существуют различия в механизмах шифрования для каждой виртуальной машины.

AMD SEV-SNP

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

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

GPU TEE: NVIDIA Конфиденциальные вычисления

Разработка TEE традиционно была сосредоточена на ЦПУ из-за зависимости от производителей аппаратного обеспечения. Однако необходимость обработки сложных вычислений, таких как безопасное обучение и защита данных обучения ИИ, подчеркнула необходимость GPU TEE. В ответ NVIDIA представила функции конфиденциальных вычислений на графическом процессоре H100 в 2023 году.

NVIDIA Confidential Computing предлагает независимо зашифрованные и управляемые экземпляры графических процессоров, обеспечивая сквозную безопасность в сочетании с CPU TEE. В настоящее время это достигается за счет интеграции с AMD SEV-SNP или Intel TDX для создания конвейеров конфиденциальных вычислений.

1.2. Как мы можем доверять TEE?

При изучении проектов Web3 вы часто можете встретить утверждения о сообщественном управлении через загрузку кода на GitHub. Но как можно проверить, что программа, развернутая на сервере, действительно соответствует коду GitHub?

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

Тот же принцип применим к программам в пределах анклавов TEE. Чтобы пользователи полностью доверяли программам, развернутым на сервере, им необходимо проверить (засвидетельствовать), что код и данные в пределах анклава остаются неизменными. В случае SGX он связывается с IAS (Intel Attestation Service), используя ключ, сохраненный в специальном анклаве. IAS проверяет целостность анклава и его внутренние данные, затем возвращает результаты пользователям. В общем, TEE требует связи с аттестационными серверами, предоставленными поставщиком оборудования, чтобы обеспечить целостность анклава.

2. TEE на Web3

Почему TEE на Web3?

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

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

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

2.1. Конфиденциальный копроцессор

Марлин

Marlin - это протокол проверяемых вычислений, разработанный для создания безопасной вычислительной среды с использованием TEE или ZK технологии. Одна из их основных целей - разработка децентрализованной веб-платформы. Marlin управляет двумя подсетями: Oyster и Kalypso, причем Oyster функционирует как протокол совместной обработки на основе TEE.

1) Oyster CVM

Oyster CVM (Oyster for convenience) действует как маркетплейс P2P TEE. Пользователи покупают вычислительные среды AWS Nitro Enclave через внебиржевой маркетплейс Oyster и развертывают свои образы программ там. Ниже приведена абстрактная структура Oyster:

источник: https://docs.marlin.org/oyster/protocol/cvm/workflow/

Oyster имеет очень похожую структуру на Akash. В Oyster роль блокчейна заключается в проверке правильности работы каждой вычислительной среды TEE, и это осуществляется через наблюдателей, называемых провайдерами. Провайдеры непрерывно проверяют доступность Энклав в реальном времени и сообщают свои результаты сети Oyster. Они ставят на конец.$PONDтокены, которые подвержены риску сокращения, если они занимаются злонамеренной деятельностью. Кроме того, существует децентрализованная сеть сущностей, называемых 'аудиторами', которые контролируют сокращение Провайдеров. Каждую эпоху аудиторы получают свои задания и отправляют запросы на аудит в запечатанные помещения, которые выбираются случайным образом с помощью сгенерированного внутри помещения семени.

Тем не менее, Oyster выполнила контракт под названием NitroProverкоторый проверяет результаты удаленной аттестации на цепочке, позволяя пользователям проверить целостность своей приобретенной TEE на цепочке.

Экземпляры, развернутые пользователем, могут быть доступны как через смарт-контракты, так и через Web2 API. Результаты вычислений могут быть интегрированы в контракты, представляя их в виде оракулов. Как показано в панели управления, эта возможность подходит не только для смарт-контрактов, но и для децентрализации веб-сервисов Web2.

Подобно Akash, Oyster уязвим для возможных захватов экземпляров злоумышленниками, если внецепных рынках существуют уязвимости. В таких сценариях, хотя данные в enclave могут оставаться безопасными, сырые данные, хранящиеся за пределами enclave, и привилегии работы службы могут быть скомпрометированы. В случае чувствительных данных, которые хранятся в недоверенной памяти, но не должны быть выставлены, разработчики должны зашифровать эти данные и хранить их отдельно. Marlin в настоящее время предоставляет внешнее хранилище с постоянным ключом на основе MPC для решения этих случаев.

2) Oyster Безсерверный

Пока Oyster CVM работает как рынок P2P TEE, Oyster Serverless напоминает AWS Lambda (или функцию как сервис) с TEE. Используя Oyster Serverless, пользователи могут выполнять функции без аренды экземпляров, оплачивая их по требованию.

Порядок выполнения Oyster Serverless будет следующим:

1. Пользователи создают запросы к контракту Relay
2. Сервер шлюза вне цепочки наблюдает за запросами пользователей через события
3. сервер шлюза передает запрос пользователя протоколу шлюза
4. Протокол Gateway создает и назначает задание протоколу Serverless на основе запроса пользователя
5. Серверы исполнителей слушают задания, назначенные протоколу Serverless, выполняют задание и отправляют ответ
6. Ответ — результат запроса пользователя — последовательно передается пользователю

С помощью Oyster Serverless пользователи могут отправлять запросы web2 API или вызывать смарт-контракты через смарт-контракт, при этом обеспечивается целостность выполнения через TEE. Пользователи также могут подписаться на Serverless для периодического выполнения, что особенно полезно для получателей оракулов.

Phala Network

Phala, ранее обсуждавшаяся в нашей статье AI X Crypto, значительно сместила свое внимание на AI-сопроцессоры.

Основной дизайн сети Phala включает в себя Рабочих и gatekeepers. Рабочие функционируют как обычные узлы, выполняющие вычисления для клиентов. gatekeepers, с другой стороны, управляют ключами, позволяющими Рабочим расшифровывать и вычислять зашифрованные состояния. Рабочие обрабатывают зашифрованные значения состояния контракта через Intel SGX, что требует ключей от gatekeepers для чтения или записи этих значений.

исходный: https://docs.phala.network/tech-specs/blockchain

Phala расширила свои возможности, поддерживая SDK для конфиденциальных виртуальных машин в средах Intel TDX. Недавно, в сотрудничестве с Flashbot, они запустили Dstack. Этот продукт включает API удаленной аттестации для проверки операционного статуса нескольких образов Docker-контейнеров, развернутых в конфиденциальных виртуальных машинах. Удаленная аттестация через Dstack обеспечивает прозрачность через специализированный Explorer.

Еще одним значительным развитием является их продукт Confidential AI Inference, представленный в ответ на последний всплеск проектов искусственного интеллекта. Phala Network теперь поддерживает относительно новую конфиденциальную вычислительную технологию Nvidia, с целью усовершенствования услуг по выводу искусственного интеллекта с использованием ZK/FHE. Ранее эта технология сталкивалась с проблемами из-за высоких накладных расходов, что ограничивало ее практичность.

источник: https://docs.phala.network/overview/phala-network/confidential-ai-inference

Изображение иллюстрирует структуру конфиденциальной системы вывода Phala Network AI. Для развертывания моделей искусственного интеллекта в этой системе используются доверенные выполнение среды (TEE) на уровне виртуальной машины, такие как Intel TDX и AMD SEV. Выполнение искусственного интеллекта осуществляется через конфиденциальные вычисления Nvidia, а результаты безопасно передаются обратно в область CPU. В отличие от обычных моделей, этот метод может повлечь значительные накладные расходы, так как он включает два раунда вычислений в области. Тем не менее, ожидается, что он приведет к существенному улучшению производительности по сравнению с существующими методами вывода искусственного интеллекта, основанными на TEE, которые полностью полагаются на производительность CPU. Согласно бумагаОпубликованные сетью Phala результаты показали, что накладные расходы на вывод LLM на основе Llama3 составляют около 6–8%.

Другие

В области AI X Crypto другие примеры использования TEE в качестве копроцессоров включают iExec RLC, PIN AI и Super Protocol. iExec RLC и PIN AI фокусируются на защите моделей и данных обучения AI с помощью TEE, соответственно. Super Protocol готовится к запуску рынка для торговли вычислительными средами TEE, аналогичными Marlin. Однако подробная техническая информация об этих проектах пока не доступна публично. Мы предоставим обновления после запуска их продукта.

2.2. Безопасные смарт-контракты

Oasis (Prev. Rose)

Oasis, ранее известный как Rose, является блокчейном Layer 1, разработанным для защиты конфиденциальности пользователей во время транзакций путем запуска своего клиента исполнения внутри SGX-резервуара. Несмотря на то, что это относительно зрелая цепочка, Oasis инновационно реализовал поддержку многовиртуальных машин в своем слое исполнения.

Уровень выполнения, называемый Paratime, включает в себя три компонента: Cipher, конфиденциальную виртуальную машину на основе WASM; Sapphire — конфиденциальная виртуальная машина на базе EVM; и Emerald, стандартная виртуальная машина, совместимая с EVM. Oasis фундаментально защищает смарт-контракты и их вычислительные процессы от произвольных модификаций узлами, гарантируя, что клиент исполнения работает в анклаве TEE. Эта структура проиллюстрирована на прилагаемой схеме.

источник: https://docs.oasis.io/general/oasis-network/

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

Oasis подчеркивает свою силу в облегчении создания DApps, которые обрабатывают чувствительную личную информацию на публичных блокчейнах с использованием своего Конфиденциального Паратайма. Эта функция позволяет разрабатывать сервисы, требующие проверки личности, такие как SocialFi, кредитование, интеграция CEX и сервисы на основе репутации. Эти приложения могут безопасно получать и проверять биометрическую или KYC-информацию пользователей в защищенном хранилище.

Сеть Secret

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

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

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

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

Clique, протокол Quex

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

2.3. Система доказательства действительности

Некоторые цепи ZK L2 используют многоподтверждающие системы, чтобы решить внутреннюю нестабильность доказательств нулевого знания, часто включая доказательства TEE. Современные механизмы доказательств нулевого знания еще не достаточно зрелы для полной доверенности их безопасности, а ошибки, связанные с звучностью в ZK-схемах, требуют значительных усилий для устранения при возникновении инцидентов. В качестве предосторожности цепи, использующие доказательства ZK или ZK-EVM, принимают доказательства TEE для обнаружения потенциальных ошибок путем повторного выполнения блоков через локальные ВМ в пределах ограждений. В настоящее время L2, использующие многоподтверждающие системы, включая TEE, - это Taiko, Scroll и Ternoa. Давайте кратко рассмотрим их мотивации для использования многоподтверждающих систем и их структуры.

Taiko

Taiko в настоящее время является самой заметной (планируемой) цепочкой rollup на основе. Цепочка rollup делегирует упорядочивание предложений блоков Ethereum без поддержки отдельного централизованного упорядочивателя. Согласно диаграмме Based Rollup Taiko, поисковые системы L2 составляют пакеты транзакций и доставляют их на L1 в виде пакетов. Затем предложители блоков L1 восстанавливают их, вместе с транзакциями L1, чтобы сгенерировать блоки L1 и захватить MEV.

Источник: https://docs.taiko.xyz/core-concepts/multi-proofs/

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

Блоки Taiko проходят три стадии подтверждения: предложенный, проверенный и подтвержденный. Блок считается предложенным, когда его допустимость проверяется контрактом L1 Taiko (контракт rollup). Он достигает состояния проверенного, когда проверяется параллельными доказателями, и состояния подтвержденного, когда его родительский блок был проверен. Для проверки блоков Taiko использует три типа доказательств: доказательство TEE на основе SGX V2, доказательство ZK на основе Succinct/RiscZero и доказательство Guardian, которое зависит от централизованной мультисиги.

Taiko использует модель конкуренции для проверки блоков, устанавливая иерархию уровней безопасности среди доказывающих: TEE, ZK, ZK + TEE и Guardian. Такая настройка позволяет вызывающим лицам получать большую награду, когда они выявляют неверные доказательства, сгенерированные моделями более высокого уровня. Для каждого блока требуются случайно назначенные доказательства с следующими весовыми коэффициентами: 5% для SGX + ZKP, 20% для ZKP и остаток с использованием SGX. Это гарантирует, что ZK-доказывающие всегда могут получать более высокую награду при успешных вызовах.

Читатели могут задаться вопросом, как генерируют и проверяют доказательства провайдеры SGX. Основная роль провайдеров SGX - продемонстрировать, что блоки Taiko были сгенерированы стандартным вычислением. Эти провайдеры генерируют доказательства изменений состояния значения и проверяют окружение, используя результаты повторного выполнения блоков через локальную виртуальную машину в рамках среды TEE, наряду с результатами аттестации ограждения.

В отличие от генерации доказательства ZK, которая требует значительных вычислительных затрат, генерация доказательства на основе TEE проверяет вычислительную целостность по гораздо более низкой стоимости при схожих предположениях о безопасности. Проверка этих доказательств включает простые проверки, такие как убедиться, что ECDSA-подпись, используемая в доказательстве, соответствует подписи предъявителя.

В заключение, доказательства корректности на основе TEE могут рассматриваться как метод проверки целостности цепочки путем генерации доказательств с немного более низким уровнем безопасности, но с существенно более низкой стоимостью по сравнению с ZK-доказательствами.

Прокрутить

Scroll - это заметный роллап, который принимает систему Multi-proof. Он сотрудничает с Automata, слоем аттестации, который будет представлен позже, чтобы генерировать как ZK-доказательства, так и TEE-доказательства для всех блоков. Это сотрудничество активирует систему разрешения споров для разрешения конфликтов между двумя доказательствами.

источник: https://scroll.io/blog/scaling-security

Scroll планирует поддерживать различные аппаратные среды (в настоящее время только SGX), включая Intel SGX, AMD SEV и AWS Nitro, чтобы минимизировать зависимость от аппаратных средств. Они решают потенциальные проблемы безопасности в TEE, собирая доказательства из разнообразных сред с помощью пороговых подписей.

Ternoa

Ternoa приоритизирует обнаружение вредоносных действий централизованными L2-сущностями перед устранением ошибок в самом Execution. В отличие от Taiko или Scroll, которые используют TEE Provers для дополнения существующих ZK Proofs, Ternoa использует Observers в средах, основанных на TEE. Эти Observers обнаруживают вредоносные действия L2-секвенсоров и валидаторов, фокусируясь на областях, которые нельзя оценить только на основе данных транзакций. Примеры включают цензурирование транзакций RPC-узлами на основе IP-адреса, изменение алгоритмов последовательности секвенсорами или намеренное несоответствие пакетных данных.

Ternoa работает на отдельной сети L2, называемой Integrity Verification Chain (IVC), для задач верификации, связанных с rollup-сущностями. Поставщик фреймворка rollup отправляет последнее изображение последовательности на IVC. При запросе развертывания нового rollup IVC возвращает хранящиеся в TEE образы службы. После развертывания наблюдатели регулярно проверяют, использует ли развернутый rollup изображение последовательности, как предполагалось. Затем они представляют доказательства целостности, объединяя свои результаты верификации и отчеты об аттестации из среды TEE, чтобы подтвердить целостность цепи.

2.3. Безопасность Ethereum

2.3.1. Децентрализация строителя блоков

Flashbots BuilderNet

Flashbots, широко признанный в качестве поставщика решений MEV, последовательно исследовал применение доверенных исполнительных сред (TEE) в технологии блокчейн. Заметные исследовательские усилия включают в себя:

• Исследование выполнения Geth внутри SGX Enclave и его ограничения
• Реализация блока, основанная на SGX
• Строительство цепочки сопроцессоров TEE на основе выполнения REVM внутри SGX Enclave, дополненное слоем верификации Automata

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

Ethereum использует модель разделения построителя и предлагателя. Эта система разделяет создание блоков на две роли — 1) Построители: отвечают за создание блоков и извлечение MEV 2) Предлагатели: подписывают и распространяют блоки, созданные построителями, для децентрализации прибыли от MEV. Эта структура привела к тому, что некоторые децентрализованные приложения сговариваются с построителями вне цепи, чтобы захватить значительную прибыль от MEV. В результате несколько построителей, таких как Beaverbuild и Titan Builder, монополистически создают более 90% блоков Ethereum. В экстремальных случаях эти построители могут цензурировать произвольные транзакции. Например, регулируемые транзакции, такие как те, которые поступают от Tornado Cash, активно подвергаются цензуре крупными постройщиками.

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

source: https://buildernet.org/docs/architecture

Узлы-строители, получающие пользовательские транзакции (Orderflow), управляются различными операторами узлов. Каждый из них управляет открытыми экземплярами Builder в средах Intel TDX. Пользователи могут свободно проверить среду TEE каждого оператора и отправлять зашифрованные транзакции. Затем операторы делятся полученным Orderflow, отправляют блоки на реле MEV-boost и распределяют блоковые награды скаутам и другим участникам создания блоков при успешной отправке.

Эта структура обеспечивает несколько преимуществ децентрализации:

• Проверяемость: каждый экземпляр Builder работает в рамках TEE, что позволяет пользователям проверять, не цензурировали ли Builders транзакции или произвольно изменяли клиентов. Политика распределения вознаграждения для участников создания блоков также является прозрачной в рамках TEE.
• Устойчивость к цензуре: в BuilderNet узлы строителей запускаются несколькими операторами, каждый с разными регуляторными политиками. Это разнообразие означает, что они выбирают разные транзакции для исключения. Даже если некоторые операторы цензурируют транзакции, другие все еще могут выбирать их. Теоретически, если есть хотя бы один строитель, который не цензурирует, транзакции пользователей могут быть включены в блоки. BuilderNet также предлагает решение проблем цензуры L2, показывая, что L2 могут достичь более высокой устойчивости к цензуре, чем одиночные последователи, передавая создание блоков в BuilderNet. (В этом случае уровень устойчивости к цензуре может быть повлиян дополнительными компонентами, которые фильтруют транзакции до последователя, например, брандмауэр).
• Децентрализация: Текущим строителям блоков предоставляется вызов в связи с надежностью централизованной инфраструктуры. BuilderNet стремится решить эту проблему, интегрируя различных строителей, начиная с Beaverbuild. По мере присоединения к BuilderNet все большего числа строителей блоков, структура PBS Ethereum увидит увеличение децентрализации. В настоящее время в BuilderNet входят только Beaverbuild, Flashbots и Nethermind. Другим строителям требуется разрешение на присоединение, но существуют планы сделать операторское развертывание безразрешительным и полностью устранить централизованную инфраструктуру в будущем.

2.3.2. Защита валидатора

Puffer Finance

Puffer Finance представила инструмент Secure Signer, разработанный для снижения риска сокращения Ethereum валидаторов из-за ошибок клиента или ошибок. Данный инструмент использует подписчик на основе SGX Enclave для повышенной безопасности.

исходный текст: https://docs.puffer.fi/technology/secure-signer/

Secure Signer работает путем генерации и хранения ключей BLS-валидатора внутри SGX-оболочки, обращаясь к ним только при необходимости. Его логика проста: вместе с безопасностью, обеспечиваемой доверенной средой выполнения (TEE), он может обнаруживать ошибки валидатора или злонамеренные действия. Это достигается путем обеспечения строго возрастающих слотов перед подписью блоков или доказательств. Puffer Finance подчеркивает, что такая настройка позволяет валидаторам достичь уровней безопасности, сравнимых с аппаратными кошельками, превосходящими типичные защиты, предлагаемые программными решениями.

2.4. Децентрализация L2-секвенсора

Unichain

Unichain, Ethereum Layer 2 (L2) цепочка Uniswap, запланированная к запуску в первом квартале следующего года, в своем белой бумаге поделилась планами по децентрализации механизмов построения блоков L2 с использованием доверенных исполнительных сред (TEE). Хотя подробные технические спецификации пока не опубликованы, вот краткое изложение их ключевых предложений:

• Разделение построителя последовательности: Чтобы улучшить существующие структуры роллапа, где последовательность и генерация блоков L2 осуществляются централизованными последователями, Unichain сотрудничает с Flashbots. Это партнерство направлено на разделение последователей L2 от строителей блоков. Строители блоков Unichain будут работать с использованием открытого программного кода в рамках Intel TDX, обеспечивая прозрачность путем публичного раскрытия результатов аттестации для выполнения.
• Flashblock: Unichain выявляет ограничения масштабируемости с текущим процессом предварительного подтверждения, предоставляемым последовательностями rollup, такими как сериализация и генерация корневого состояния. Чтобы решить эту проблему, они планируют внедрить «Flashblocks», позволяющие пользователям получать ожидающие блоки немедленно после упорядочивания транзакций через TEE-строителей. Они подчеркивают, что упорядочивание внутри TEE обеспечит, что упорядочивание транзакций будет основано исключительно на приоритетных комиссиях и времени подачи без вмешательства последователей, что позволит ускорить предварительное подтверждение.

Кроме того, Unichain намеревается разработать различные функции на основе TEE, включая зашифрованный пул памяти, запланированные транзакции и защищенные TEE смарт-контракты.

2.5. Частный RPC

Автоматы

Пока блокчейн достиг значительной децентрализации в архитектурных аспектах, многие элементы все еще не обладают достаточной устойчивостью к цензуре из-за зависимости от операторов серверов. Automata стремится предоставить решения, которые минимизируют зависимость от операторов серверов и раскрытие данных в архитектуре блокчейна на основе TEE. Заметные реализации Automata включают открытый исходный код.SGX Proverи Verifier, TEE Компиляциякоторый проверяет соответствие между исполняемыми файлами, развернутыми в TEE, и исходным кодом, иTEE Builderкоторый добавляет конфиденциальность к механизмам построения блоков через TEE-основанный mempool и block builder. Кроме того, Automata позволяет результат удаленной аттестации TEE быть размещенным на цепочке, что позволяет его общедоступно проверять и интегрировать в смарт-контракты.

В настоящее время Automata управляет 1RPC, службой RPC на основе TEE, предназначенной для защиты идентифицирующей информации отправителей транзакций, такой как IP-адрес и сведения об устройстве, с помощью безопасных анклавов. Automata подчеркивает риск того, что с коммерциализацией UserOp из-за разработки абстракции учетной записи RPC-сервисы могут выводить шаблоны UserOp для конкретных пользователей через интеграцию с ИИ, потенциально ставя под угрозу конфиденциальность. Структура 1RPC проста. Он устанавливает безопасные соединения с пользователями, получает транзакции (UserOp) в TEE и обрабатывает их с помощью кода, развернутого в анклаве. Однако 1RPC защищает только метаданные UserOp. Фактические вовлеченные стороны и содержимое транзакции остаются открытыми во время взаимодействия с ончейн-точкой входа. Более фундаментальный подход к обеспечению конфиденциальности транзакций предполагает защиту уровней мемпула и построителя блоков с помощью TEE. Этого можно достичь путем интеграции с TEE Builder от Automata.

2.6. AI Agents

исходный: https://x.com/tee_hee_he

То, что в конечном итоге привело TEE мета в центр внимания в web3, был TEE-основанный Twitter AI агент. Многие, вероятно, впервые столкнулись с TEE, когда AI агент по имени @tee_hee_heпоявился на X в конце октября и запустил свою мем-монету на Ethereum.@tee_hee_heЭто агент искусственного интеллекта, совместно разработанный Nous Research и проектом Teleport Flashbots. Он появился в ответ на опасения, что на тот момент тенденции учетных записей агентов искусственного интеллекта не могли доказать, что они действительно передают результаты, сгенерированные моделями искусственного интеллекта. Разработчики разработали модель, которая минимизировала вмешательство централизованных сущностей в процессы, такие как настройка учетной записи Twitter, создание криптовалютного кошелька и передача результатов модели искусственного интеллекта.

источник: @tee_hee_he/освобождение-вашей-домашней-скалы-3e7895201f46"">https://medium.com/@tee_hee_he/освобождение-вашей-домашней-скалы-3e7895201f46

Они развернули AI-агента в среде Intel TDX, генерируя электронную почту, пароли для аккаунтов X и токены OAuth для доступа в Twitter через симуляцию браузера, а затем удалили все варианты восстановления.

Недавно TEE была использована в похожем контексте для AI-Pool, где @123skely успешно проведен фандрайзинг. В настоящее время после того, как мем-монеты с искусственным интеллектом развертывают свои контракты, а адреса становятся общедоступными, технически совершенные боты-снайперы, как правило, обеспечивают большую часть ликвидности и манипулируют ценами. AI-Pool пытается решить эту проблему, заставляя ИИ проводить своего рода предпродажу.

source: https://x.com/0xCygaar/status/1871421277832954055

Еще один интересный кейс — DeepWorm, ИИ-агент с бионейронной сетью, которая имитирует мозг червя. Подобно другим агентам искусственного интеллекта, DeepWorm загружает анклавное изображение своего червячного мозга в Marlin Network, чтобы защитить свою модель и обеспечить проверяемость своей работы.

источник:https://x.com/deepwormxyz/status/1867190794354078135

Поскольку @tee_hee_he Благодаря открытому исходному коду всего кода, необходимого для развертывания, развертывание надежных, ненадежных агентов ИИ на основе TEE стало довольно простым. Недавно Phala Network развернула Eliza от a16z в TEE. Как подчеркнула a16z в своем отчете о перспективах рынка криптовалют на 2025 год, ожидается, что рынок ИИ-агентов на основе TEE будет служить важной инфраструктурой на будущем рынке мемкоинов ИИ-агентов.

2.7. Социальная игра

Азуки Бобу

Azuki, известный проект Ethereum NFT, сотрудничал с Flashbots в октябре прошлого года, чтобы провести уникальное социальное мероприятие.

исходный:https://x.com/Azuki/status/1841906534151864557

Это включало в себя делегирование разрешений на загрузку аккаунтов в Twitter Flashbots и Bobu, которые затем публиковали твиты одновременно, как во флешмобе. Мероприятие прошло успешно, как показано на изображении ниже.

источник: https://collective.flashbots.net/t/tee-enabled-social-games-an-experiment-with-bobu-s-magic-show/3963

Разработанный Flashbots и Azuki, структура мероприятия была следующей:

1. Генерация закрытых ключей и сертификатов TLS, а также закрытых ключей Ethereum в рамках Gramin-SGX.
2. Пользователи создали OAuth-токены с ограниченными правами для публикации одного твита и отправили их в TEE Flashbots через TLS.
3. Контракт был создан на Arbitrum для управления пользовательскими сертификатами, предотвращения двойных расходов и реализации событийных выводов при загрузке пользовательских твитов.

Адзуки обеспечил надежность процесса обработки событий, опубликовав образ Docker Enclave в Docker Hub. Они также загрузили сценарии проверки прозрачности журналов сертификатов и результаты удаленной аттестации для среды TEE на GitHub. Хотя Flashbots определили зависимости от RPC и узлов блокчейна как оставшиеся риски, их можно смягчить с помощью TEE RPC или роллапов на основе TEE, таких как Unichain.

Хотя проект не достиг технического прорыва, стоит отметить, что он провел надежное социальное мероприятие, используя только стек TEE.

3. Безопасность TEE

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

1) Централизованный механизм аттестации

Как уже упоминалось ранее, пользователи могут использовать механизмы удаленной проверки подлинности, чтобы проверить целостность защищенных сред выполнения TEE и то, что данные внутри защищенных сред не были подвергнуты вмешательству. Однако этот процесс верификации неизбежно зависит от серверов производителя микросхем. Степень доверия немного различается в зависимости от поставщика - SGX/TDX полностью зависит от аттестационного сервера Intel, в то время как SEV позволяет владельцам виртуальных машин выполнять аттестацию напрямую. Это внутренняя проблема в структуре TEE, и исследователи TEE работают над ее решением через разработку открытых исходных кодов TEE, о чем мы упомянем позже.

2) Атаки через боковые каналы

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

• Утечка потока управления: вредоносные операционные системы или программы могут восстанавливать данные, используя доступную информацию. Например, они могут воспользоваться тем фактом, что доступ к данным кэша процессора намного быстрее, чем доступ к данным DRAM. Это позволяет им выявлять шаблоны выполнения кода операции и выводить информацию о программном ключе, например ключи RSA. Кроме того, атака может произойти, когда вредоносная ОС ограничивает доступ к страницам памяти, вызывая ошибки страниц в коде анклава для раскрытия шаблонов доступа к памяти. Манипулирование целевым буфером ветвей для прогнозирования ветвей кода и управления ими также может выявить поток выполнения кода. Кроме того, злоумышленники могут многократно выполнять код анклава в атаках микроскопа для получения информации.
• Утечка данных: Уязвимости, которые утекают изолированные данные, могут привести к критическим атакам, потенциально подрывая удаленную аттестацию. Особенно заметно, что секретные ключи внутри изолированной области были утечки путем создания приложений-теней, эмулирующих код и данные изолированной области, выполняя на них атаки ROP (Dark-ROP). Дополнительные уязвимости возникают из-за спекулятивного выполнения программ на процессорах Intel для оптимизации производительности (Foreshadow). Хотя память изолированной области защищена шифрованием, данные, получаемые спекулятивно выполняемыми инструкциями, могут находиться в кэше на короткое время. Это может быть использовано для чтения данных изолированной области через атаки с использованием канала бокового кэша.
• DoS-атаки: Для SGX, когда проверка целостности памяти обнаруживает вмешательство, система останавливается. Эта уязвимость использовалась для DoS-атак, намеренно вызывая сбои проверки целостности. Злоумышленники могут вызвать остановку системы, многократно обращаясь к определенным строкам DRAM, чтобы вызвать переключение битов в соседних строках, потенциально повреждая память анклава.

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

source: https://x.com/hdevalence/status/1613247598139428864

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

3) Реальные / последние эксплуатации TEE

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

• Secret Network: Будучи одной из немногих жертв подлинных эксплойтов TEE, этот проект на основе SGX стал жертвой атаки ÆPIC Leakage, обнаруженной в 2022 году. Атака была нацелена на набор инструкций AVX (Advanced Vector Extensions) в последних процессорах Intel. Он использовал спекулятивные шаблоны выполнения во время операций AVX для восстановления ключей шифрования, хранящихся в регионах анклава. Secret Network использовала начальное значение консенсуса для валидаторов для расшифровки частных транзакций. Злоумышленник успешно извлек это начальное число, что позволило расшифровать все исторические частные транзакции в сети. Подробнее об уязвимости можно прочитать на странице sgx.fail.
• Раскрытие корневого ключа SGX: В августе исследователь безопасности Марк Ермолов объявил об успешной расшифровке ключа SGX Root Provisioning Key и Root Sealing Key, важных компонентов криптографической модели доверия SGX. Эти ключи обычно защищены сложной логикой в физическом устройстве контроллера предохранителей. Однако была обнаружена критическая уязвимость, из-за которой копии этих ключей оставались во внутренних буферах во время операций. Несмотря на то, что обладание этими двумя ключами само по себе не ставит под угрозу SGX, получение глобального ключа-оболочки потенциально может подвергнуть всю систему SGX уязвимостям. Несмотря на то, что SGX устарел в коммерческих процессорах Intel, выпущенных после 2021 года, он остается жизнеспособным вектором атаки, поскольку несколько проектов все еще используют его.
• Уязвимость AMD SEV-SNP: AMD SEV, относительно новая реализация TEE с широким охватом защиты на уровне виртуальных машин, исторически показала меньше уязвимостей по сравнению с SGX. Тем не менее, принятие доклада на IEEE S&P 2025, в котором обсуждается уязвимость BadRAM, нацеленная на AMD SEV-SNP, подчеркивает, что даже современные реализации TEE не застрахованы от недостатков безопасности. BadRAM использует модули памяти DDR4 и DDR5 для создания псевдонимов адресного пространства в физической памяти. Используя Raspberry Pi Pico, который стоит около 10 долларов, злоумышленники могут модифицировать чипы памяти, чтобы обмануть процессор относительно физического размера памяти. Это позволяет эффективно обходить механизм защиты AMD SEV-SNP RMP (Reverse Map Table). Подробнее об уязвимости можно прочитать на странице badram.eu.

Эти случаи показывают, что «полностью безопасная TEE» недостижима, и пользователи должны знать о потенциальных уязвимостях новых аппаратных релизов.

4. Заключение: Открытый исходный код - это будущее

В ноябре Георгиос Константопулос из Paradigm объяснил, что фреймворкдля конфиденциальной аппаратной эволюции, классификация безопасного оборудования на пять различных уровней:

• Уровень 1: обеспечивает достаточную конфиденциальность для приложений оракулов и мостов, безопасность которых зависит от цепочки поставок. Примеры включают SGX.
• Уровень 2: Сохраняет уровень безопасности 1, улучшая при этом работу разработчиков и поддерживая расширенные приложения, такие как делегирование учетных записей OAuth, как в случае с Teleport. Gramine SGX является примером этого уровня.
• Уровень 3: Расширяет безопасность 1-го уровня с поддержкой GPU, позволяя создавать сложные приложения, такие как частные и проверяемые модели машинного обучения. Intel TDX + Nvidia Confidential Computing представляет этот уровень.
• Уровень 4: Использует открытые наборы инструкций с публично подтверждаемыми процессами производства, устраняя зависимость от производителей оборудования, как продемонстрировано OpenTEE.
• Уровень 5: Достигает идеального состояния, когда несколько OpenTEEs работают вместе через FHE/MPC, поддерживая целостность даже в случае компрометации отдельных аппаратных блоков.

В настоящее время проекты, такие как конфиденциальные AI-вычисления от Phala Network, работают на уровне 3, тогда как большинство сервисов остаются на уровне 2 с использованием облачных TEE или Intel TDX. Хотя проектам на основе TEE Web3 должно в конечном итоге удалось достичь аппаратного уровня 4, текущие ограничения производительности делают это практически невозможным. Однако, с участием основных венчурных капиталовых фондов, таких как Paradigm, и исследовательских команд, таких как Flashbots и Nethermind, работающих над демократизацией TEE, и учитывая соответствие TEE принципам Web3, он, вероятно, станет неотъемлемой инфраструктурой для проектов Web3.

О ChainLight

Ecosystem Explorer - отчет ChainLight, представляющий внутренний анализ актуальных проектов экосистемы Web3 с точки зрения безопасности, написанный нашими исследовательскими аналитиками. С миссией помочь исследователям безопасности и разработчикам совместно учиться, расти и вносить свой вклад в создание безопасного места для Web3, мы регулярно выпускаем наш отчет бесплатно.

Чтобы получать последние исследования и отчеты, проводимые награжденными экспертами:

👉 Подписывайтесь на @ChainLight_io @c4lvin

Учрежденная в 2016 году компания ChainLight предоставляет индивидуальные решения в области безопасности для укрепления ваших смарт-контрактов и помощи в развитии на блокчейне.

Отказ от ответственности:

1. Эта статья взята из [ gate.Chainlight]. Все авторские права принадлежат оригинальному автору [c4lvin*]. Если есть возражения против этой перепечатки, пожалуйста, свяжитесь с Gate Learnкоманда и они обработают это незамедлительно.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
3. Команда Gate Learn перевела статью на другие языки. Копирование, распространение или плагиат переведенных статей запрещено, если не указано иное.