У жовтні термін «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.

джуджуцу Кайсен

Для використання простої аналогії 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 TEE

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. Розширені TEEs

Як ми обговоримо пізніше, багато оригінальних TEE, включаючи Intel SGX, зіткнулися з вразливостями бічних каналів і проблемами розробки через структурні проблеми. Щоб вирішити ці проблеми, вендори випустили покращені версії. Зі зростанням попиту на безпечні хмарні обчислення такі платформи, як AWS/Azure/GCP, почали пропонувати власні послуги TEE. Нещодавно концепція TEE була поширена і на графічні процесори. Деякі варіанти використання Web3 зараз реалізують ці просунуті TEE, тому я коротко поясню їх.

Cloud TEEs: AWS Nitro, Azure Конфіденційне обчислення, Google Cloud Конфіденційне обчислення

З ростом попиту на послуги хмарного обчислення провайдери почали розробляти свої власні рішення TEE. Nitro від AWS - це середовище обчислення в енклавах, яке працює поряд з екземплярами 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), включаючи обмеження розміру конфіденційної зони в 256 МБ та збільшення складності розробки через створення конфіденційних зон на рівні процесу. Основна відмінність від SEV полягає в тому, що TDX частково довіряє операційній системі, зокрема, гіпервізору, управління ресурсами віртуальної машини. Крім того, існують різниці в механізмах шифрування для кожної віртуальної машини.

AMD SEV-SNP

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

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

GPU TEE: NVIDIA Конфіденційне обчислення

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

NVIDIA Confidential Computing пропонує незалежно зашифровані та керовані екземпляри GPU, забезпечуючи повну безпеку на всьому шляху від початку до кінця, коли поєднано з 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 став популярним у другій половині цього року, узгоджуючи з AI-темами, такими як конфіденційність даних та надійні агенти AI. Однак спроби інтегрувати TEE в екосистему Web3 існували задовго до цього. У цій статті ми представимо проекти в різних галузях, які застосовують TEE в екосистемі Web3, поза сектором штучного інтелекту.

2.1. Конфіденційний копроцесор

Марлін

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

1) Устриця CVM

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

джерело:https://docs.marlin.org/oyster/protocol/cvm/workflow/

Устриці мають дуже схожу структуру з Акашем. У в Остриці роль блокчейну полягає в тому, щоб перевірити, чи працює кожне обчислювальне середовище TEE належним чином, і це робиться через спостерігачів, яких називають Провайдерами. Провайдери постійно перевіряють доступність Енклавів в реальному часі та повідомляють свої висновки мережі Oyster. Вони стейкують $PONDтокени, які можуть бути відрізані, якщо вони займаються зловживаннями. Крім того, існує децентралізована мережа сутностей, які називаються 'аудиторами', для нагляду за відрізанням Постачальника. Кожну епоху аудиторам призначають свої завдання і вони надсилають запити на аудит до закритих приміщень, які вибираються випадковим чином за допомогою створеного всередині закритого приміщення насіння.

Однак Oyster реалізував контракт під назвою NitroProverщо перевіряє результати віддаленої атестації на ланцюжку, дозволяючи користувачам перевірити цілісність придбаного TEE на ланцюжку.

Екземпляри, розгорнуті користувачем, можна отримати як через розумні контракти, так і через API Web2. Результати обчислення можуть бути інтегровані в контракти, представляючи їх у вигляді оракулів. Як показано у панелі управління, ця можливість підходить не тільки для розумних контрактів, але й для децентралізації послуг Web2.

Подібно до Akash, Oyster піддається можливій захопленню екземплярів з боку зловмисників, якщо є вразливості в позаланцюговому ринку. У таких сценаріях, хоча дані енклейва можуть залишатися безпечними, сирий дані, збережені поза енклейвою, а також привілеї обслуговування можуть бути скомпрометовані. У разі чутливих даних, які зберігаються в ненадійній пам'яті, але не повинні бути викриті, розробники повинні шифрувати ці дані та зберігати їх окремо. Marlin в даний час надає зовнішнє сховище з постійним ключем на основі КСМ для обробки таких випадків.

2) Остер Serverless

Поки Oyster CVM працює як ринок P2P TEE, Oyster Serverless нагадує AWS Lambda (або Function-as-a-Service) з TEE. Використовуючи Oyster Serverless, користувачі можуть виконувати функції без оренди екземплярів та сплати за вимогою.

Процес виконання Oyster Serverless буде таким:

1. Користувачі створюють запити до контракту Релею
2. Сервер шлюзу поза ланцюгово спостерігає за запитами користувачів через подію
3. шлюзовий сервер передає запит користувача протоколу шлюзу
4. Протокол шлюзу створює та призначає завдання протоколу безсерверної обробки, на основі запиту користувача
5. Сервери виконавця слухають завдання, призначені для протоколу безсерверних, виконують завдання та надсилають відповідь
6. Відповідь — результат запиту користувача — передається користувачеві послідовно

З Oyster Serverless користувачі можуть відправляти запити web2 API або виклики розумних контрактів через розумний контракт, при цьому забезпечується цілісність виконання через TEE. Користувачі також можуть підписатися на Serverless для періодичного виконання, що було б особливо корисно для оракул-витягів.

Phala Network

Phala, яка раніше обговорювалася в нашій статті про штучний інтелект та криптовалюту, значно змінила свою увагу на AI-супроцесори.

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

джерело: https://docs.phala.network/tech-specs/blockchain

Phala розширила свої можливості, підтримуючи SDK для конфіденційних ВМ в середовищах Intel TDX. Недавно, спільно з Flashbot, вони запустили Dstack. Цей продукт має API віддаленої атестації для перевірки робочого стану кількох образів Docker-контейнера, розгорнутих в конфіденційних ВМ. Віддалена атестація через Dstack забезпечує прозорість за допомогою окремого Дослідник.

Ще одним важливим досягненням є їх продукт конфіденційного ШІ, запроваджений у відповідь на останній приріст проектів з ШІ. Phala Network зараз підтримує відносно нову конфіденційну обчислювальну технологію Nvidia, спрямовану на покращення послуг з ШІ за допомогою ZK/FHE. Ця технологія раніше зіткнулася з труднощами через високі накладні витрати, що обмежували її практичність.

джерело: https://docs.phala.network/overview/phala-network/confidential-ai-inference

Зображення ілюструє структуру конфіденційної системи логічного висновку штучного інтелекту Phala Network. Ця система використовує довірені середовища виконання (TEE) на рівні віртуальної машини, такі як Intel TDX і AMD SEV, для розгортання моделей штучного інтелекту. Він проводить висновки штучного інтелекту за допомогою конфіденційних обчислень Nvidia та безпечно передає результати назад до анклаву центрального процесора. Цей метод може спричинити значні накладні витрати порівняно зі звичайними моделями, оскільки він передбачає два раунди обчислень анклаву. Тим не менш, очікується, що він забезпечить значне підвищення продуктивності порівняно з існуючими методами логічного висновку штучного інтелекту на основі TEE, які повністю покладаються на продуктивність процесора. Відповідно до папірпублікується Phala Network, накладні витрати ЛЛМ на основі Llama3 були виміряні на рівні 6-8%.

Інші

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

2.2. Безпечні розумні контракти

Оазис (Попередньо Роуз)

Oasis, раніше відомий як Rose, є блокчейном 1-го рівня, призначеним для захисту приватності користувачів під час транзакцій, запускаючи свій клієнт виконання в межах SGX-сховища. Незважаючи на те, що це відносно зрілий ланцюг, Oasis інноваційно реалізував підтримку багато-VM у своєму рівні виконання.

Шар виконання, який називається Paratime, включає три компоненти: Cipher, конфіденційна ВМ на основі WASM; Sapphire, конфіденційна ВМ на основі EVM; та Emerald, стандартна ВМ, сумісна з EVM. Oasis фундаментально захищає смарт-контракти та їх обчислювальні процеси від произвольних змін вузлами, забезпечуючи, що клієнт виконання працює в межах захищеної області TEE. Ця структура показана на супровідній схемі.

джерело: https://docs.oasis.io/general/oasis-network/

Коли користувачі відправляють транзакції, вони шифрують дані транзакції за допомогою тимчасового ключа, що генерується менеджером ключів вузла Oasis всередині засобу захисту і передають його модулю обчислень. Модуль обчислень отримує приватний ключ для тимчасового ключа від менеджера ключів, використовує його для розшифрування даних всередині засобу захисту, виконує розумний контракт і змінює значення стану вузла. Оскільки результати виконання транзакцій також надходять до користувачів у зашифрованій формі, ані сервер, що керує клієнтом вузла Oasis, ані зовнішні сутності не можуть спостерігати зміст транзакцій.

Oasis підкреслює свою силу в тому, що допомагає створювати DApps, які обробляють чутливу особисту інформацію на публічних блокчейнах, використовуючи свій Confidential Paratime. Ця функція дозволяє розробляти сервіси, які потребують перевірки ідентифікації, такі як SocialFi, кредитне позичання, CEX інтеграційні послуги та сервіси на основі репутації. Ці додатки можуть безпечно отримувати та перевіряти біометричну або KYC інформацію користувача в захищеному оточенні.

Секретна мережа

Secret Network є ланцюгом першого рівня в екосистемі Cosmos і є одним з найдавніших блокчейнів, які базуються на TEE. Він використовує енклави Intel SGX для шифрування значень стану ланцюга, підтримуючи приватні транзакції для своїх користувачів.

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

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

Оскільки всі значення стану смарт-контрактів зашифровані, їх перегляд потребує дешифрування. Мережа Secret вирішує це, вводячи ключі перегляду. Ці ключі зв'язують конкретні паролі користувачів з контрактами, дозволяючи лише авторизованим користувачам спостерігати за значеннями стану контрактів.

Клік, Протокол Quex

У відміну від раніше представлених L1, що базуються на TEE, протоколи Clique та Quex надають інфраструктуру, яка дозволяє загальним DApps делегувати приватні обчислення в позачергове середовище TEE. Ці результати можуть бути використані на рівні розумного контракту. Вони особливо використовуються для механізмів розподілу перевірних стимулів, позачергових книг замовлень, оракулів та захисту даних KYC.

2.3. Система доказу правомірності

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

Taiko

Taiko в даний час є найвідомішою (планованою) мережею ролапів на основі Base. Ланцюжок згортання делегує секвенування ініціаторам блоків Ethereum без підтримки окремого централізованого секвенсера. Згідно з діаграмою Based Rollup від Taiko, пошукачі L2 складають пакети транзакцій і доставляють їх до L1 пакетами. Потім ініціатори блоків L1 реконструюють їх разом із транзакціями L1, щоб генерувати блоки L1 та захоплювати MEV.

джерело: https://docs.taiko.xyz/core-concepts/multi-proofs/

У Taiko TEE використовується не на етапі складання блоку, а на етапі генерації доказу, про що ми пояснимо. Taiko, завдяки своїй децентралізованій структурі, не потребує перевірки несправностей послідовника. Проте, якщо є помилки в кодовій базі клієнта L2-вузла, повністю децентралізоване налаштування не може швидко їх вирішити. Це потребує високорівневих доказів правильності для забезпечення безпеки, що веде до більш складного проектування в порівнянні з іншими rollups.

Блоки Taiko проходять три етапи підтвердження: запропоновані, доведені та перевірені. Блок вважається запропонованим, коли його валідність перевіряється L1-контрактом Тайко (rollup contract). Він досягає доведеного стану, коли його перевіряють паралельними доказами, і перевіреного стану, коли доведено його батьківський блок. Для перевірки блоків 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 перевіряє обчислювальну цілісність за набагато меншою ціною за аналогічних умов безпеки. Перевірка цих доведень включає прості перевірки, наприклад, переконання у тому, що ЕЦП-підпис, який використовується у доведенні, відповідає підпису доведувача.

Загалом, докази про валідність на основі TEE можуть бути розглянуті як метод перевірки цілісності ланцюжка шляхом генерації доказів з трохи меншим рівнем безпеки, але за значно меншою вартістю порівняно з ZK доказами.

Прокручувати

Scroll - відомий ролап, який використовує багатопрофільну систему. Він співпрацює з Automata, шаром атестації, який буде представлений пізніше, для генерації як ZK-доказів, так і TEE-доказів для всіх блоків. Ця співпраця активує систему суперечок для вирішення конфліктів між цими двома доказами.

джерело: https://scroll.io/blog/scaling-security

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

Ternoa

Ternoa надає пріоритет виявленню зловмисних дій централізованими сутностями L2 над виправленням помилок в самому виконанні. На відміну від Taiko або Scroll, які використовують TEE Provers для доповнення існуючих ZK Proofs, Ternoa використовує Спостерігачів у середовищах на основі TEE. Ці Спостерігачі виявляють зловмисні дії L2 послідовників та перевіряльників, фокусуючись на областях, які не можуть бути оцінені лише на підставі даних про транзакції. Приклади включають цензуру транзакцій RPC-вузлами на основі IP-адрес, зміну алгоритмів послідовності послідовниками або навмисне не надсилання пакетних даних.

Ternoa працює на окремій мережі L2, яка називається Ланцюгом Перевірки Цілісності (IVC) для завдань перевірки, пов'язаних з сутностями Rollup. Постачальник фреймворку Rollup надсилає останнє зображення секвенсора до IVC. Коли новий Rollup запитує про розгортання, IVC повертає службові зображення, збережені в TEE. Після розгортання Спостерігачі регулярно перевіряють, чи використовує розгорнутий Rollup зображення секвенсора, як було заплановано. Потім вони надсилають докази цілісності, включаючи результати перевірки та звіти про атестацію з їхнього середовища TEE, для підтвердження цілісності ланцюга.

2.3. Ethereum безпека

2.3.1. Децентралізація Блокувальника

Flashbots BuilderNet

Флешботи, широко визнані як постачальник рішень MEV, послідовно досліджували застосування надійних середовищ виконання (TEE) в технології блокчейну. Варто відзначити наукові зусилля, включаючи:

• Розслідування страти ґетів в анклаві SGX та її обмежень
• Впровадження блоку, заснованого на SGX
• Створення ланцюга TEE-сопроцесорів на основі виконання REVM у межах SGX Enclave, доповнений верифікаційним рівнем Automata

У цій статті ми коротко опишемо поточну роль Flashbots і обговоримо BuilderNet, нещодавню ініціативу, спрямовану на децентралізацію побудови блоків. Flashbots оголосили про повні плани міграції свого існуючого рішення через BuilderNet.

Ethereum використовує модель поділу Proposer-Builder. Ця система розділяє створення блоків на дві ролі — 1) Будівельники: відповідальні за створення блоків і вилучення MEV 2) Пропонанти: підписуйте та розповсюджуйте блоки, створені будівельниками, щоб децентралізувати прибуток MEV. Ця структура призвела до того, що деякі децентралізовані програми вступили в змову з Builders off-chain, щоб отримати значний прибуток MEV. В результаті кілька будівельників, таких як Beaverbuild і Titan Builder, монополістично створюють понад 90% блоків Ethereum. У серйозних випадках ці Будівельники можуть цензурувати довільні транзакції. Наприклад, регульовані транзакції, такі як транзакції з Tornado Cash, активно цензуруються великими будівельниками.

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

джерело: https://buildernet.org/docs/architecture

Нодами-будівельниками, що приймають транзакції користувачів (Orderflow), керують різні оператори Node. Кожен з них працює з екземплярами Builder з відкритим вихідним кодом у середовищах Intel TDX. Користувачі можуть вільно перевіряти середовище TEE кожного оператора та надсилати зашифровані транзакції. Потім оператори діляться отриманим потоком замовлень, надсилають блоки в ретранслятор 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-based signer для підвищеної безпеки.

джерело: https://docs.puffer.fi/technology/secure-signer/

Безпечний підписник працює за допомогою генерації та зберігання ключів BLS валідатора в енклаві SGX, доступ до них здійснюється лише в разі необхідності. Його логіка проста: поряд із безпекою, забезпеченою надійним середовищем виконання (TEE), він може виявляти помилки валідатора або злочинні дії. Це досягається шляхом забезпечення того, що слоти суворо збільшилися перед підписанням блоків або доказів. Puffer Finance підкреслює, що ця настройка дозволяє валідаторам отримати рівні безпеки, порівнянні з апаратними гаманцями, перевершуючи типові захисти, що пропонуються програмними рішеннями.

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

Unichain

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

• Розділення Sequencer-Builder: Щоб покращити існуючі структури зведення, де секвенування та генерація блоків L2 обробляються централізованими секвенсорами, Unichain співпрацює з Flashbots. Це партнерство спрямоване на те, щоб відокремити секвенсери L2 від блокових конструкторів. Конструктори блоків Unichain працюватимуть з відкритим вихідним кодом у Intel TDX, забезпечуючи прозорість шляхом публічного оприлюднення результатів атестації для виконання.
• Flashblock: Unichain виявляє обмеження в масштабованості з поточним процесом передпідтвердження, який надають послідовники rollup, такими як серіалізація та генерація кореневих станів. Для вирішення цих питань вони планують ввести «Flashblocks», що дозволить користувачам отримувати очікувані блоки безпосередньо після впорядкування транзакцій за допомогою TEE-будівників. Вони наголошують на тому, що впорядкування всередині TEE забезпечить впорядкування транзакцій виключно на основі пріоритетних комісій та часу подання без втручання послідовників, що дозволить швидше передпідтвердження.

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

2.5. Приватний НВК

Автомати

Хоча блокчейн досяг значного децентралізації в архітектурних аспектах, багато елементів все ще не мають достатньої стійкості до цензури через залежність від операторів серверів. Automata має на меті надати рішення, які мінімізують залежність від операторів серверів та розголошення даних в архітектурі блокчейн на основі TEE. Відомі реалізації Automata включають відкритий вихідний код SGX Proverі Верифікатор, TEE Compileяка перевіряє відповідність між виконуваними файлами, розгорнутими в TEE, та вихідним кодом, і TEE Builderяке додає конфіденційність до механізмів побудови блоків через TEE-базовий мемпул та будівельник блоків. Крім того, Automata дозволяє результати віддаленої атестації TEE бути опублікованими на ланцюжку, що дозволяє їх публічно перевіряти та інтегрувати в смарт-контракти.

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

2.6. Агенти штучного інтелекту

джерело:https://x.com/tee_hee_he

Те, що нарешті привело мету TEE до визнання у веб3, - це Twitter AI-агент на основі TEE. Багато людей, ймовірно, вперше зіткнулися з TEE, коли AI-агент назвався @tee_hee_heз'явився на X наприкінці жовтня і запустив свою мем-монету на Ethereum.@tee_hee_he — це агент штучного інтелекту, розроблений спільно Nous Research та проєктом Teleport від Flashbots. Це з'явилося у відповідь на занепокоєння, що популярні облікові записи агентів ШІ на той час не могли довести, що вони насправді передають результати, згенеровані моделями штучного інтелекту. Розробники розробили модель, яка мінімізувала втручання централізованих організацій у такі процеси, як налаштування облікового запису Twitter, створення криптогаманця та передача результатів моделі штучного інтелекту.

джерело: @tee_hee_he/setting-your-pet-rock-free-3e7895201f46"">https://medium.com/@tee_hee_he/setting-your-pet-rock-free-3e7895201f46

Вони розгорнули AI агента в середовищі Intel TDX, генеруючи електронну пошту, паролі облікового запису X та маркери OAuth для доступу до Twitter через імітацію браузера, а потім видалили всі опції відновлення.

Останнім часом TEE використовувався в аналогічному контексті для AI-Pool, де@123skelyуспішно провів збір коштів. На даний момент, після розгортання контрактів та публікації адрес meme-монет зі штучним інтелектом, технічно вдосконалені снайперські боти зазвичай забезпечують більшість ліквідності та маніпулюють цінами. AI-Pool намагається вирішити цю проблему шляхом проведення попередньої розпродажу з використанням штучного інтелекту.

джерело: https://x.com/0xCygaar/status/1871421277832954055

Ще один цікавий кейс — DeepWorm, агент штучного інтелекту з біонейронною мережею, яка імітує мозок хробака. Подібно до інших агентів штучного інтелекту, DeepWorm завантажує анклавне зображення свого мозку хробака в Marlin Network, щоб захистити свою модель і забезпечити перевірюваність її роботи.

джерело: https://x.com/deepwormxyz/status/1867190794354078135

З @tee_hee_heзавдяки відкритим кодам, необхідним для розгортання, розгортання надійних, невідступних AI-агентів на основі TEE стало досить простим. Недавно Phala Network розгорнула Eliza в TEE a16z. Як відзначено в звіті a16z про перспективи криптовалютного ринку до 2025 року, TEE-оснований ринок AI-агентів очікується стати важливою інфраструктурою на ринку мем-криптовалюти AI-агентів у майбутньому.

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 було створено контракт для управління сертифікатами користувачів, запобігання подвійним витратам і впровадження виходів подій при завантаженні твітів користувачів.

Azuki забезпечив надійність процесу події, опублікувавши 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 ніколи не повинен викривати дані, збережені в енклейвах. Однак, оскільки TEE може шифрувати дані лише в енклейвах, вразливості можуть виникнути через атаки з використанням додаткової інформації, а не оригінальних даних. З моменту публічного випуску Intel SGX у 2015 році на кращих конференціях з системної безпеки було відзначено безліч критичних атак з використанням бокових каналів. Нижче наведені потенційні сценарії атак у випадках використання TEE, розподілені за їх впливом:

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

Хоча TEE не є системою, яка нейтралізує всі вектори атак і може спричинити витік інформації різних рівнів через свої фундаментальні характеристики, ці атаки вимагають серйозних передумов, таких як код зловмисника та жертви, що працює на одному ядрі процесора. Це призвело до того, що дехто описав її як модель безпеки «Людина з Glock».

джерело: https://x.com/hdevalence/status/1613247598139428864

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

3) Реальні / останні витоки на TEE

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

• Secret Network: Як одна з небагатьох жертв справжніх вразливостей TEE, цей проект на основі SGX піддався атакі з витоком ÆPIC, виявленій в 2022 році. Атака спрямовувалася на набір інструкцій AVX (Advanced Vector Extensions) в останніх процесорах Intel. Вона використовувала спекулятивні виконавчі шаблони під час операцій AVX для відновлення ключів шифрування, збережених у регіонах особливої безпеки. Secret Network використовував початковий ключ згоди для розшифрування приватних транзакцій валідаторів. Атакувач успішно витягнув цей ключ, що дозволило розшифрувати всі історичні приватні транзакції в мережі. Докладніші відомості про вразливість описано в sgx.fail.
• Розкриття кореневого ключа SGX: У серпні дослідник безпеки Марк Єрмолов оголосив про успішне розшифрування кореневого ключа та кореневого ключа герметизації SGX, важливих компонентів криптографічної моделі довіри 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 намалював контур frameworkдля конфіденційної еволюції апаратного забезпечення, класифікування безпечного апаратного забезпечення на п'ять різних рівнів:

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

Наразі проекти, такі як Phala Network’s Confidential AI Inference, працюють на рівні 3, тоді як більшість сервісів залишаються на рівні 2, використовуючи cloud TEE або Intel TDX. Хоча проекти на основі Web3 TEE врешті-решт повинні прогресувати до обладнання рівня 4, поточні обмеження продуктивності роблять це непрактичним. Однак, з великими венчурними фондами, такими як Paradigm, і дослідницькими командами, такими як Flashbots і Nethermind, які працюють над демократизацією TEE, і враховуючи відповідність TEE з принципами Web3, ймовірно, воно стане необхідною інфраструктурою для проектів Web3.

Про ChainLight

Ecosystem Explorer - це звіт ChainLight, в якому введено внутрішній аналіз тенденційних проектів екосистеми веб3 з точки зору безпеки, написаний нашими дослідниками. З місією допомагати дослідникам з питань безпеки та розробникам колективно навчатися, рости та вносити свій внесок у зроблення веб3 безпечнішим місцем, ми періодично випускаємо наш звіт безкоштовно.

Щоб отримати найновіші дослідження та звіти, проведені відзначеними нагородами експертами:

👉 Follow @ChainLight_io @c4lvin

Заснована в 2016 році, нагороджені експерти ChainLight надають індивідуальні рішення з безпеки, щоб зміцнити ваш розумний контракт та допомогти вам процвітати на блокчейні.

Відмова від відповідальності:

1. Цю статтю розміщено з [ Gate]. Усі авторські права належать оригінальному авторові [c4lvin*]. Якщо є зауваження до цього повторного надруку, будь ласка, зв'яжіться з Gate Learnкоманда, і вони вчасно цим займуться.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є інвестиційною порадою.
3. Команда Gate Learn переклала статтю на інші мови. Копіювання, поширення або плагіат перекладених статей заборонено, якщо це не зазначено.