Щодня люди генерують до 402 мільйонів терабайт конфіденційних даних. У міру того, як люди все більш неохоче діляться даними в широкому сенсі, зростає потреба в приватних обчисленнях цих даних. Ці рішення значною мірою покладаються на інфраструктуру Amazon Web Services (AWS), на частку якої припадає близько 30% світового ринку хмарних обчислень.
Однак у AWS є кілька недоліків, які в основному пов'язані з його централізованою архітектурою. Навіть із впровадженням покращених захищених обчислень через AWS Nitro Enclaves, все ще існують серйозні виклики для розробників, які створюють глибокі перешкоди для безпеки блокчейну та додатків Web3.
У цій статті ми розберемо поточний стан AWS та представимо децентралізоване хмарне рішення TEE, яке не тільки вирішує недоліки AWS, але й долає обмеження інших існуючих TEE. Але перш ніж ми зможемо це зробити, нам потрібно дослідити, чому AWS та її продукти Nitro Enclaves досягли такої високої видимості та частки ринку, і що стоїть за цими досягненнями.
AWS Nitro проти TEE
Наразі AWS є найпопулярнішою платформою хмарних обчислень, яка пропонує багатий набір інструментів. У двох словах, AWS — це, по суті, хмарна інфраструктура для всіх обчислювальних потреб розробника, включаючи обчислення, зберігання та служби баз даних. Як ми всі знаємо, на AWS припадає близько 30% частки ринку хмарної інфраструктури, що є досить значним відсотком. Майже 48% інженерів-програмістів або розробників так чи інакше використовують AWS, тому він користується великим попитом.
З розширенням попиту та клієнтської бази, включаючи великі фінансові установи, урядові органи та стартапи, які мають високочутливі дані, виникають питання щодо безпеки AWS та того, чи можуть ці установи безпечно зберігати та використовувати ці дані для конфіденційних обчислень.
Саме в цьому контексті AWS виступила з ідеєю впровадження TEE на своїй платформі для захисту даних у використанні, доповнюючи шифрування даних у стані спокою та передачі.
Це нове рішення для інтеграції TEE називається AWS Nitro Enclaves, і воно забезпечує апаратно підтримуване, ізольоване середовище виконання. TEE створюють безпечне середовище в екземплярах Amazon EC2, усуваючи інтерактивний доступ, постійне зберігання та підключення до зовнішньої мережі. Ця ізоляція мінімізує поверхню атаки, відокремлюючи конфіденційні робочі навантаження від батьківського екземпляра EC2, його операторів та іншого програмного забезпечення.
!
Однак Nitro Enclaves повністю створюються та керуються в рамках служби EC2 від AWS, що належить до високост centrівних структур. Від створення до припинення всі аспекти управління Enclave контролюються інфраструктурою AWS, враховуючи природу AWS як централізованого постачальника хмарних послуг, це по суті є централізованим.
Коротше кажучи, AWS Nitro Enclaves забезпечує надійну ізоляцію за допомогою апаратного Trusted Execution Environment для захисту чутливих робочих навантажень. Однак його централізована архітектура вносить певні обмеження та компроміси.
Обмеження поза централізованим AWS
Окрім всіх недоліків централізованої системи, де всі компоненти та дані залежать від єдиного центру, AWS Nitro Enclaves також приносить більше викликів та нових аспектів безпеки. AWS з'єднує кілька карт Nitro (індивідуальне апаратне забезпечення) з процесором для виконання навантаження TEE, що створює подвійний ризик безпеки: основний процесор та картки Nitro можуть містити вразливості.
Суттєвою проблемою Nitro Enclaves є відсутність налагодженого механізму шифрування пам'яті. На відміну від рішень, де шифрування пам'яті інтегровано безпосередньо в центральний процесор, зовнішня природа карти Nitro ускладнює забезпечення наскрізного шифрування даних у пам'яті. Ця конфігурація може розкрити конфіденційну інформацію для несанкціонованого доступу до пам'яті, оскільки шифрування залежить від взаємодії між центральним процесором і зовнішніми пристроями.
На додаток до цього, розробникам все ще потрібно використовувати Docker для створення та налаштування образів Amazon Machine Images (AMI), які включають програмне забезпечення Enclave, що може бути складним для людей, які не знайомі з контейнеризацією. Їм також потрібно використовувати AWS CLI та Nitro Enclaves CLI для запуску інстансів та керування анклавами, навігації по API Nitro Enclaves та інтеграції зі службами керування ключами AWS, що іноді вимагає розуміння процесу криптографічної атестації.
Залежність TEE від картки Nitro призвела до нездатності перевірки доказів, оскільки вимірювання цілісності коду походить від картки Nitro, а не від самого процесора.
AWS довіряє розробникам та адміністраторам встановлювати політики керування ідентифікацією та доступом, що може надати їм доступ до конфіденційних даних. Їхній розширений доступ створює ризик внутрішньої загрози, оскільки вони можуть переглядати або фальсифікувати дані.
Огляд довіри AWS Nitro
Однак найзначнішим обмеженням є те, що AWS не оптимізований для децентралізованих додатків та екосистем, йому бракує рідної підтримки для випадків використання Web3 або систем управління.
Наприклад, AWS Nitro Enclaves не вистачає постійного сховища. Хоча ця ізоляція корисна для безпеки, вона обмежує випадки використання, такі як агенти штучного інтелекту, яким потрібно зберігати дані користувачів у векторній базі даних.
Управління ключами також не вписується в сценарій «нульової довіри». Хоча служба керування ключами AWS (KMS) доступна, вона розроблена для Web2 і дозволяє адміністраторам отримувати доступ до приватних ключів. Це суперечить вимозі Web3 про те, що ключі мають повністю контролюватися кодом і не бути доступними нікому, включаючи адміністраторів.
Nitro Enclaves вирішує проблему недовіри розробників до хмари, але Web3 вимагає реалізації безпечних рішень без довіри між користувачами, розробниками та постачальниками. Не підтримується безпечне оновлення коду, потрібна децентралізована власність, подібна до управління смарт-контрактами, а розробники повинні будувати все з нуля, що може зайняти кілька місяців, і якщо реалізація буде невдалою, у коді можуть бути вразливості.
Через відсутність доступу до мережі налаштування веб-сервісів є трудомістким і витратним, змушуючи розробників писати велику кількість коду для адаптації додатків і забезпечення криптографічної безпеки, що часто не є досконалим.
Чому Web3 потребує TEE?
Ми використовуємо TEE, тому що не можемо повністю довіряти розробникам або адміністраторам. Учасники Web3 мають іншу філософію та дотримуються систем без довіри: якщо щось потрібно довіряти, це виглядає не дуже надійно. Ось чому користувачі покладаються на операторів апаратного забезпечення для перевірки програм і керування ними. Програми можна від'єднати, щоб запобігти їхньому втручанню, вилученню чи зміні конфіденційних даних під час доступу до пам'яті, оскільки шифрування ґрунтується на безперебійній співпраці між центральним процесором і зовнішніми пристроями. Користувачі та постачальники даних повинні мати чіткі гарантії та перевірку дій, що виконуються з їхніми даними.
Розробляючи Phala Network, ми були розроблені, щоб поєднати переваги AWS із безпекою TEE, щоб усунути складність за допомогою децентралізації та підвищити безпеку. Цей підхід розроблений для задоволення потреб сценаріїв використання Web3. В результаті ми придумали концепцію децентралізованої хмари TEE, яка забезпечує безпеку та інтеграцію для децентралізованих додатків.
створити децентралізоване TEE хмара
Щоб зрозуміти концепцію децентралізованого TEE-хмари, спочатку потрібно визначити, що таке децентралізоване хмара. Отже, що це таке?
Децентралізована хмара — це тип обчислювальної інфраструктури, в якій зберігання, обробка та керування даними розподілені по мережі з кількох вузлів, а не централізовані на одному центральному сервері чи центрі обробки даних. На відміну від традиційних централізованих хмарних систем, таких як AWS, децентралізовані хмари не вимагають єдиної контролюючої організації, а натомість покладаються на блокчейн для функціонування.
Децентралізоване TEE-хмара
Децентралізована хмара TEE – це обчислювальна інфраструктура, яка поєднує TEE з мережею децентралізованих вузлів для забезпечення безпечних, приватних і перевірених обчислень. Кожен вузол оснащений TEE для захисту конфіденційного коду та даних від доступу або втручання з боку операторів вузла.
Phala Network складається з децентралізованої мережі робочих вузлів, кожен з яких обладнаний TEE. Ці вузли виконують обчислювальні завдання для користувачів відповідно до вимог клієнтів, такі як виконання смарт-контрактів або обробка чутливих даних.
Цей процес починається з того, що користувач розгортає свої додатки або завдання в мережі. Обчислювальні завдання виконуються в TEE цих вузлів, що забезпечує конфіденційність коду та даних, навіть оператори вузлів не можуть їх переглядати або змінювати.
!
Phala використовує криптографічні докази для перевірки правильності виконання обчислень у TEE. Оператори вузлів отримують винагороду за надання чесних та безпечних послуг, підтримуючи цілісність мережі через економічні стимули. Хоча це звучить досить просто, реалізація цього рішення набагато складніша, ніж здається.
Чому створити децентралізовану TEE хмару так важко?
Сам по собі TEE не є централізованим або децентралізованим, і ступінь централізації залежить від того, як він впроваджений і розгорнутий в системі. TEE — це безпечна, ізольована область у процесорі, призначена для захисту конфіденційного коду та даних від несанкціонованого доступу операційної системи або інших процесів на тому самому пристрої. Чи працює TEE в централізованому або децентралізованому режимі, залежить від архітектури більш широкої системи, в якій він розташований.
Історично склалося так, що створення централізованої системи було простіше, ніж створення децентралізованої системи, яка зіткнулася з проблемами з точки зору впровадження та зв'язку вузлів. До Phala Cloud ми успішно створили повністю децентралізовану мережу Phala Network 1.0 (SGX). Зараз Phala Cloud розробляється з тією ж філософією, хоча це займе час. На даний момент Phala є єдиною платформою, яка поєднує TEE з повною децентралізацією, на відміну від централізованих провайдерів або частково децентралізованих протоколів.
Переваги децентралізації та TEE очевидні, але їх все одно недостатньо при розробці продукту. Imagine Alibaba — найбільша у світі платформа електронної комерції з величезною часткою ринку. Якщо новий продукт буде запущений з удвічі більшою потужністю та нижчою ціною, чи захопить він весь ринок? На жаль, ні, тому що люди звикли до існуючих продуктів і існує упереджене ставлення до нових продуктів, навіть якщо вони кращі.
Це була одна з проблем, з якою ми зіткнулися, але замість того, щоб вдосконалюватися вдвічі, ми подбали про те, щоб Phala, яка була в десять разів кращою за конкурентів, була зручною для користувача. Крім того, як згадувалося раніше, AWS не підходить для середовища Web3, і ми прагнемо заповнити цю прогалину для Web3-додатків і розробників. Окрім очевидної переваги децентралізації, хочемо також виділити й інші відмінності між Phala та AWS.
Phala Cloud проти AWS
По-перше, налаштування Nitro Enclaves в AWS є складним процесом. Це включає в себе кілька етапів, зокрема встановлення Nitro CLI, перетворення Docker-образів у файли Enclave та обробку передачі файлів, що займає багато часу.
У порівнянні, Phala дозволяє розробникам "мігрувати та змінювати" розгортання і легко переносити існуючі контейнери Docker у безпечне TEE. Використовуючи Dstack SDK, розробники можуть внести лише мінімальні зміни, щоб перетворити контейнери Docker на конфіденційні віртуальні машини (Confidential VM) і розгортати їх через зручний для користувача Cloud UI, при цьому все ще підтримуючи шаблони та власні файли Docker Compose.
Коли справа доходить до безпеки, AWS покладається на довіру розробників та адміністраторів для правильного налаштування контролю доступу та управління ресурсами. Хоча AWS використовує TEE для ізольованих обчислень, для його централізованої інфраструктури потрібні люди, які довіряють AWS і керують системою, що може призвести до доступу до конфіденційних даних. Phala використовує модель нульової довіри і за замовчуванням не довіряє жодній стороні. Конфіденційні дані залишаються в безпеці в TEE і недоступні навіть для операторів вузлів, що робить їх придатними для додатків Web3, які вимагають безнадійних операцій.
З точки зору продукту, AWS в першу чергу обслуговує корпоративних клієнтів через велику кількість підприємств у традиційному ІТ-просторі. Як наслідок, це не повністю узгоджується з ціннісною пропозицією Web3-стартапів з точки зору продуктів і технологій. На противагу цьому, Phala спеціально створена для децентралізованих додатків. Він підтримує проксі зі штучним інтелектом, які взаємодіють зі смарт-контрактами на блокчейні, а також DApps, що зберігають конфіденційність.
Крім того, Phala глибоко інтегрована в екосистему блокчейну через партнерства з різними протоколами та інтеграцію DApp, які прагнуть скористатися безпекою TEE.
Phala позиціонується як рівень виконання Web3 AI, що дозволяє розробникам створювати, запускати та монетизувати агентів штучного інтелекту, які можуть розуміти та безпечно та конфіденційно взаємодіяти зі смарт-контрактами на блокчейні. Ми підтримуємо децентралізовані платформи штучного інтелекту, такі як NEAR AI та Sentient, використовуючи NVIDIA GPU TEE для запуску великих мовних моделей (LLM) у безпечному, перевіреному та орієнтованому на конфіденційність середовищі. Наприклад, наше партнерство з NOTAI підкреслює застосування нульової довіри до агентів штучного інтелекту, де ми забезпечуємо довірчий захист і захист конфіденційності за допомогою TEE та RA Explorer.
Ми також підтримуємо інтеграцію не пов'язаних з AI додатків через Phat Contracts, які є низькозатратними, з низькою затримкою смарт-контрактами з підтримкою нативних HTTP-запитів.
Однак, враховуючи, що багато крипто-орієнтованих команд також працюють над TEE та іншими методами безпечних обчислень, як Phala може відрізнити себе від цих рішень?
Phala Cloud з рішеннями TEE
Phala Network виділяється як єдина повністю децентралізована хмара TEE, яка забезпечує безпечні, приватні та перевірені обчислення для DApps. На відміну від Oasis Protocol і Secret Network, які зосереджені на смарт-контрактах з підтримкою конфіденційності з використанням TEE у відповідних блокчейнах, Phala надає децентралізовану платформу хмарних обчислень для офлайн-обчислень у мережі.
Phala гнучка та налаштовується, використовуючи широкий спектр апаратного забезпечення TEE, включаючи Intel SGX, Intel TDX, AMD SEV і NVIDIA GPU TEE. Marlin Protocol підвищує продуктивність мережі Web3, але не надає функцій обчислень або конфіденційності, тоді як Oasis і Secret працюють у певній екосистемі блокчейну. Phala унікально позиціонується як єдина децентралізована хмара TEE з широкою підтримкою апаратного забезпечення та інструментами, орієнтованими на розробників, такими як Dstack.
!
Phala відрізняється тим, що пропонує децентралізовану хмару TEE загального призначення, на відміну від Oasis Protocol, Marlin і Secret Network, які зосереджені на конкретних випадках використання. Phala дозволяє розробникам розгортати будь-яку програму, таку як модель штучного інтелекту, веб-сервер або база даних, у безпечному середовищі. Це стало можливим завдяки Phat Contracts і Phala Cloud, які підтримують розгортання Dockerized і забезпечують доступ в один клік до TEE CPU і GPU.
Крім того, існує багато порівнянь між TEE та багатосторонніми обчисленнями (MPC), щоб визначити, який з них більше підходить для конкретного випадку використання. На нашу думку, TEE та MPC не є конкурентами, а є взаємодоповнюючими партнерами.
Phala інтегрує TEE з MPC для створення децентралізованої моделі Root of Trust (DeRoT), передового підходу для захисту додатків на основі EE. MPC працює в межах TEE, щоб зменшити ризик змови вузлів, тоді як докази блоків TEE подаються з доказами MPC для пом'якшення помилок у реалізаціях доказів із нульовим розголошенням (ZKP). Ця система мультиатестації ще більше удосконалюється вимогою до вузлів MPC працювати в межах TEE. Модель DeRoT використовує TEE, MPC і ZKP для розподілу довіри в мережі. Цей підхід підвищує безпеку DApps за допомогою TEE шляхом усунення потенційних загроз на рівні апаратного забезпечення або вузлів.
можливості децентралізованого TEE хмари
Ми спеціально напишемо статтю, щоб обговорити цю тему, оскільки вже багато застосувань працює на Phala. Тому ця частина може бути такою ж довгою, як і вся стаття. Але ми хочемо окреслити можливі варіанти використання децентралізованого TEE хмари.
По-перше, Phala підтримує розгортання AI-моделей у TEE, забезпечуючи безпеку та автономну операцію під час взаємодії з блокчейн-мережею. Це включає AI-агенти для підвищення смарт-контрактів та міжагентної взаємодії. Розробники можуть використовувати GPU TEE для AI-обчислень, що забезпечує справжню антикорупцію та захист конфіденційності.
Розробники також можуть переносити традиційні додатки в безпечне та бездоверене середовище, щоб підвищити безпеку. Ця платформа реалізує захищений аналіз даних з використанням Web3 та традиційних аналітичних інструментів, які можуть аналізувати дані без розкриття інформації про окремих користувачів. Крім того, вона може зміцнити безпечні обчислення DeFi за допомогою функцій конфіденційності, таких як конфіденційні торгові позиції або темні пулові угоди. Нарешті, децентралізоване хмарне середовище TEE може забезпечити захист MEV, перемістивши побудову блоків у TEE для забезпечення справедливого сортування та виконання.
Є багато продуктів, які використовують Phala як частину своєї інфраструктури. Ми детально розглянемо в іншій статті, як ці продукти використовують Phala і яку вигоду вони отримують від цієї інтеграції.
Висновок
Моделі довіри Web3 і Web2 мають фундаментальні відмінності, що призводить до обмежень таких платформ, як AWS. У Web3 дані (включаючи токени, які по суті є даними) насправді належать користувачам, тоді як розробники програм за замовчуванням вважаються ненадійними. Ця недовіра виникає через потенціал розробників намагатися несанкціоновано отримати доступ, змінити або вкрасти дані користувачів.
Ця парадигма пояснює кілька ключових практик у Web3:
Код смарт-контракту повинен пройти сувору перевірку, щоб усунути будь-які бекдори або вразливості.
Володіння (або управлінський контроль) смарт-контрактами є ключовим питанням, користувачі більше цінують прозорість, а не дозволяють розробникам мати необмежений контроль.
В ідеальних умовах у середовищі Web3 розробники повинні писати та розгортати код смарт-контрактів, а потім відмовлятися від усіх прав контролю, більше не залишаючи за собою жодних привілеїв у застосунку.
На відміну від смарт-контрактів, TEE можуть застосовувати схожі принципи власності та контролю в рамках ширшого спектру процедур. Однак AWS Nitro Enclaves працює в рамках Web2, де розробники зберігають можливість входити в систему, отримувати доступ і змінювати дані та програми. TEE від Phala розроблено на основі принципів Web3 і за замовчуванням підтримує смарт-контракти для керування програмами на основі TEE, що відповідає моделі децентралізованої довіри.
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
AWS не підходить для Web3: Децентралізація TEE хмари може підвищити ефективність в 10 разів
Щодня люди генерують до 402 мільйонів терабайт конфіденційних даних. У міру того, як люди все більш неохоче діляться даними в широкому сенсі, зростає потреба в приватних обчисленнях цих даних. Ці рішення значною мірою покладаються на інфраструктуру Amazon Web Services (AWS), на частку якої припадає близько 30% світового ринку хмарних обчислень.
Однак у AWS є кілька недоліків, які в основному пов'язані з його централізованою архітектурою. Навіть із впровадженням покращених захищених обчислень через AWS Nitro Enclaves, все ще існують серйозні виклики для розробників, які створюють глибокі перешкоди для безпеки блокчейну та додатків Web3.
У цій статті ми розберемо поточний стан AWS та представимо децентралізоване хмарне рішення TEE, яке не тільки вирішує недоліки AWS, але й долає обмеження інших існуючих TEE. Але перш ніж ми зможемо це зробити, нам потрібно дослідити, чому AWS та її продукти Nitro Enclaves досягли такої високої видимості та частки ринку, і що стоїть за цими досягненнями.
AWS Nitro проти TEE
Наразі AWS є найпопулярнішою платформою хмарних обчислень, яка пропонує багатий набір інструментів. У двох словах, AWS — це, по суті, хмарна інфраструктура для всіх обчислювальних потреб розробника, включаючи обчислення, зберігання та служби баз даних. Як ми всі знаємо, на AWS припадає близько 30% частки ринку хмарної інфраструктури, що є досить значним відсотком. Майже 48% інженерів-програмістів або розробників так чи інакше використовують AWS, тому він користується великим попитом.
З розширенням попиту та клієнтської бази, включаючи великі фінансові установи, урядові органи та стартапи, які мають високочутливі дані, виникають питання щодо безпеки AWS та того, чи можуть ці установи безпечно зберігати та використовувати ці дані для конфіденційних обчислень.
Саме в цьому контексті AWS виступила з ідеєю впровадження TEE на своїй платформі для захисту даних у використанні, доповнюючи шифрування даних у стані спокою та передачі.
Це нове рішення для інтеграції TEE називається AWS Nitro Enclaves, і воно забезпечує апаратно підтримуване, ізольоване середовище виконання. TEE створюють безпечне середовище в екземплярах Amazon EC2, усуваючи інтерактивний доступ, постійне зберігання та підключення до зовнішньої мережі. Ця ізоляція мінімізує поверхню атаки, відокремлюючи конфіденційні робочі навантаження від батьківського екземпляра EC2, його операторів та іншого програмного забезпечення.
!
Однак Nitro Enclaves повністю створюються та керуються в рамках служби EC2 від AWS, що належить до високост centrівних структур. Від створення до припинення всі аспекти управління Enclave контролюються інфраструктурою AWS, враховуючи природу AWS як централізованого постачальника хмарних послуг, це по суті є централізованим.
Коротше кажучи, AWS Nitro Enclaves забезпечує надійну ізоляцію за допомогою апаратного Trusted Execution Environment для захисту чутливих робочих навантажень. Однак його централізована архітектура вносить певні обмеження та компроміси.
Обмеження поза централізованим AWS
Окрім всіх недоліків централізованої системи, де всі компоненти та дані залежать від єдиного центру, AWS Nitro Enclaves також приносить більше викликів та нових аспектів безпеки. AWS з'єднує кілька карт Nitro (індивідуальне апаратне забезпечення) з процесором для виконання навантаження TEE, що створює подвійний ризик безпеки: основний процесор та картки Nitro можуть містити вразливості.
Суттєвою проблемою Nitro Enclaves є відсутність налагодженого механізму шифрування пам'яті. На відміну від рішень, де шифрування пам'яті інтегровано безпосередньо в центральний процесор, зовнішня природа карти Nitro ускладнює забезпечення наскрізного шифрування даних у пам'яті. Ця конфігурація може розкрити конфіденційну інформацію для несанкціонованого доступу до пам'яті, оскільки шифрування залежить від взаємодії між центральним процесором і зовнішніми пристроями.
На додаток до цього, розробникам все ще потрібно використовувати Docker для створення та налаштування образів Amazon Machine Images (AMI), які включають програмне забезпечення Enclave, що може бути складним для людей, які не знайомі з контейнеризацією. Їм також потрібно використовувати AWS CLI та Nitro Enclaves CLI для запуску інстансів та керування анклавами, навігації по API Nitro Enclaves та інтеграції зі службами керування ключами AWS, що іноді вимагає розуміння процесу криптографічної атестації.
Залежність TEE від картки Nitro призвела до нездатності перевірки доказів, оскільки вимірювання цілісності коду походить від картки Nitro, а не від самого процесора.
AWS довіряє розробникам та адміністраторам встановлювати політики керування ідентифікацією та доступом, що може надати їм доступ до конфіденційних даних. Їхній розширений доступ створює ризик внутрішньої загрози, оскільки вони можуть переглядати або фальсифікувати дані.
Огляд довіри AWS Nitro
Однак найзначнішим обмеженням є те, що AWS не оптимізований для децентралізованих додатків та екосистем, йому бракує рідної підтримки для випадків використання Web3 або систем управління.
Наприклад, AWS Nitro Enclaves не вистачає постійного сховища. Хоча ця ізоляція корисна для безпеки, вона обмежує випадки використання, такі як агенти штучного інтелекту, яким потрібно зберігати дані користувачів у векторній базі даних.
Управління ключами також не вписується в сценарій «нульової довіри». Хоча служба керування ключами AWS (KMS) доступна, вона розроблена для Web2 і дозволяє адміністраторам отримувати доступ до приватних ключів. Це суперечить вимозі Web3 про те, що ключі мають повністю контролюватися кодом і не бути доступними нікому, включаючи адміністраторів.
Nitro Enclaves вирішує проблему недовіри розробників до хмари, але Web3 вимагає реалізації безпечних рішень без довіри між користувачами, розробниками та постачальниками. Не підтримується безпечне оновлення коду, потрібна децентралізована власність, подібна до управління смарт-контрактами, а розробники повинні будувати все з нуля, що може зайняти кілька місяців, і якщо реалізація буде невдалою, у коді можуть бути вразливості.
Через відсутність доступу до мережі налаштування веб-сервісів є трудомістким і витратним, змушуючи розробників писати велику кількість коду для адаптації додатків і забезпечення криптографічної безпеки, що часто не є досконалим.
Чому Web3 потребує TEE?
Ми використовуємо TEE, тому що не можемо повністю довіряти розробникам або адміністраторам. Учасники Web3 мають іншу філософію та дотримуються систем без довіри: якщо щось потрібно довіряти, це виглядає не дуже надійно. Ось чому користувачі покладаються на операторів апаратного забезпечення для перевірки програм і керування ними. Програми можна від'єднати, щоб запобігти їхньому втручанню, вилученню чи зміні конфіденційних даних під час доступу до пам'яті, оскільки шифрування ґрунтується на безперебійній співпраці між центральним процесором і зовнішніми пристроями. Користувачі та постачальники даних повинні мати чіткі гарантії та перевірку дій, що виконуються з їхніми даними.
Розробляючи Phala Network, ми були розроблені, щоб поєднати переваги AWS із безпекою TEE, щоб усунути складність за допомогою децентралізації та підвищити безпеку. Цей підхід розроблений для задоволення потреб сценаріїв використання Web3. В результаті ми придумали концепцію децентралізованої хмари TEE, яка забезпечує безпеку та інтеграцію для децентралізованих додатків.
створити децентралізоване TEE хмара
Щоб зрозуміти концепцію децентралізованого TEE-хмари, спочатку потрібно визначити, що таке децентралізоване хмара. Отже, що це таке?
Децентралізована хмара — це тип обчислювальної інфраструктури, в якій зберігання, обробка та керування даними розподілені по мережі з кількох вузлів, а не централізовані на одному центральному сервері чи центрі обробки даних. На відміну від традиційних централізованих хмарних систем, таких як AWS, децентралізовані хмари не вимагають єдиної контролюючої організації, а натомість покладаються на блокчейн для функціонування.
Децентралізоване TEE-хмара
Децентралізована хмара TEE – це обчислювальна інфраструктура, яка поєднує TEE з мережею децентралізованих вузлів для забезпечення безпечних, приватних і перевірених обчислень. Кожен вузол оснащений TEE для захисту конфіденційного коду та даних від доступу або втручання з боку операторів вузла.
Phala Network складається з децентралізованої мережі робочих вузлів, кожен з яких обладнаний TEE. Ці вузли виконують обчислювальні завдання для користувачів відповідно до вимог клієнтів, такі як виконання смарт-контрактів або обробка чутливих даних.
Цей процес починається з того, що користувач розгортає свої додатки або завдання в мережі. Обчислювальні завдання виконуються в TEE цих вузлів, що забезпечує конфіденційність коду та даних, навіть оператори вузлів не можуть їх переглядати або змінювати.
!
Phala використовує криптографічні докази для перевірки правильності виконання обчислень у TEE. Оператори вузлів отримують винагороду за надання чесних та безпечних послуг, підтримуючи цілісність мережі через економічні стимули. Хоча це звучить досить просто, реалізація цього рішення набагато складніша, ніж здається.
Чому створити децентралізовану TEE хмару так важко?
Сам по собі TEE не є централізованим або децентралізованим, і ступінь централізації залежить від того, як він впроваджений і розгорнутий в системі. TEE — це безпечна, ізольована область у процесорі, призначена для захисту конфіденційного коду та даних від несанкціонованого доступу операційної системи або інших процесів на тому самому пристрої. Чи працює TEE в централізованому або децентралізованому режимі, залежить від архітектури більш широкої системи, в якій він розташований.
Історично склалося так, що створення централізованої системи було простіше, ніж створення децентралізованої системи, яка зіткнулася з проблемами з точки зору впровадження та зв'язку вузлів. До Phala Cloud ми успішно створили повністю децентралізовану мережу Phala Network 1.0 (SGX). Зараз Phala Cloud розробляється з тією ж філософією, хоча це займе час. На даний момент Phala є єдиною платформою, яка поєднує TEE з повною децентралізацією, на відміну від централізованих провайдерів або частково децентралізованих протоколів.
Переваги децентралізації та TEE очевидні, але їх все одно недостатньо при розробці продукту. Imagine Alibaba — найбільша у світі платформа електронної комерції з величезною часткою ринку. Якщо новий продукт буде запущений з удвічі більшою потужністю та нижчою ціною, чи захопить він весь ринок? На жаль, ні, тому що люди звикли до існуючих продуктів і існує упереджене ставлення до нових продуктів, навіть якщо вони кращі.
Це була одна з проблем, з якою ми зіткнулися, але замість того, щоб вдосконалюватися вдвічі, ми подбали про те, щоб Phala, яка була в десять разів кращою за конкурентів, була зручною для користувача. Крім того, як згадувалося раніше, AWS не підходить для середовища Web3, і ми прагнемо заповнити цю прогалину для Web3-додатків і розробників. Окрім очевидної переваги децентралізації, хочемо також виділити й інші відмінності між Phala та AWS.
Phala Cloud проти AWS
По-перше, налаштування Nitro Enclaves в AWS є складним процесом. Це включає в себе кілька етапів, зокрема встановлення Nitro CLI, перетворення Docker-образів у файли Enclave та обробку передачі файлів, що займає багато часу.
У порівнянні, Phala дозволяє розробникам "мігрувати та змінювати" розгортання і легко переносити існуючі контейнери Docker у безпечне TEE. Використовуючи Dstack SDK, розробники можуть внести лише мінімальні зміни, щоб перетворити контейнери Docker на конфіденційні віртуальні машини (Confidential VM) і розгортати їх через зручний для користувача Cloud UI, при цьому все ще підтримуючи шаблони та власні файли Docker Compose.
Коли справа доходить до безпеки, AWS покладається на довіру розробників та адміністраторів для правильного налаштування контролю доступу та управління ресурсами. Хоча AWS використовує TEE для ізольованих обчислень, для його централізованої інфраструктури потрібні люди, які довіряють AWS і керують системою, що може призвести до доступу до конфіденційних даних. Phala використовує модель нульової довіри і за замовчуванням не довіряє жодній стороні. Конфіденційні дані залишаються в безпеці в TEE і недоступні навіть для операторів вузлів, що робить їх придатними для додатків Web3, які вимагають безнадійних операцій.
З точки зору продукту, AWS в першу чергу обслуговує корпоративних клієнтів через велику кількість підприємств у традиційному ІТ-просторі. Як наслідок, це не повністю узгоджується з ціннісною пропозицією Web3-стартапів з точки зору продуктів і технологій. На противагу цьому, Phala спеціально створена для децентралізованих додатків. Він підтримує проксі зі штучним інтелектом, які взаємодіють зі смарт-контрактами на блокчейні, а також DApps, що зберігають конфіденційність.
Крім того, Phala глибоко інтегрована в екосистему блокчейну через партнерства з різними протоколами та інтеграцію DApp, які прагнуть скористатися безпекою TEE.
Phala позиціонується як рівень виконання Web3 AI, що дозволяє розробникам створювати, запускати та монетизувати агентів штучного інтелекту, які можуть розуміти та безпечно та конфіденційно взаємодіяти зі смарт-контрактами на блокчейні. Ми підтримуємо децентралізовані платформи штучного інтелекту, такі як NEAR AI та Sentient, використовуючи NVIDIA GPU TEE для запуску великих мовних моделей (LLM) у безпечному, перевіреному та орієнтованому на конфіденційність середовищі. Наприклад, наше партнерство з NOTAI підкреслює застосування нульової довіри до агентів штучного інтелекту, де ми забезпечуємо довірчий захист і захист конфіденційності за допомогою TEE та RA Explorer.
Ми також підтримуємо інтеграцію не пов'язаних з AI додатків через Phat Contracts, які є низькозатратними, з низькою затримкою смарт-контрактами з підтримкою нативних HTTP-запитів.
Однак, враховуючи, що багато крипто-орієнтованих команд також працюють над TEE та іншими методами безпечних обчислень, як Phala може відрізнити себе від цих рішень?
Phala Cloud з рішеннями TEE
Phala Network виділяється як єдина повністю децентралізована хмара TEE, яка забезпечує безпечні, приватні та перевірені обчислення для DApps. На відміну від Oasis Protocol і Secret Network, які зосереджені на смарт-контрактах з підтримкою конфіденційності з використанням TEE у відповідних блокчейнах, Phala надає децентралізовану платформу хмарних обчислень для офлайн-обчислень у мережі.
Phala гнучка та налаштовується, використовуючи широкий спектр апаратного забезпечення TEE, включаючи Intel SGX, Intel TDX, AMD SEV і NVIDIA GPU TEE. Marlin Protocol підвищує продуктивність мережі Web3, але не надає функцій обчислень або конфіденційності, тоді як Oasis і Secret працюють у певній екосистемі блокчейну. Phala унікально позиціонується як єдина децентралізована хмара TEE з широкою підтримкою апаратного забезпечення та інструментами, орієнтованими на розробників, такими як Dstack.
!
Phala відрізняється тим, що пропонує децентралізовану хмару TEE загального призначення, на відміну від Oasis Protocol, Marlin і Secret Network, які зосереджені на конкретних випадках використання. Phala дозволяє розробникам розгортати будь-яку програму, таку як модель штучного інтелекту, веб-сервер або база даних, у безпечному середовищі. Це стало можливим завдяки Phat Contracts і Phala Cloud, які підтримують розгортання Dockerized і забезпечують доступ в один клік до TEE CPU і GPU.
Крім того, існує багато порівнянь між TEE та багатосторонніми обчисленнями (MPC), щоб визначити, який з них більше підходить для конкретного випадку використання. На нашу думку, TEE та MPC не є конкурентами, а є взаємодоповнюючими партнерами.
Phala інтегрує TEE з MPC для створення децентралізованої моделі Root of Trust (DeRoT), передового підходу для захисту додатків на основі EE. MPC працює в межах TEE, щоб зменшити ризик змови вузлів, тоді як докази блоків TEE подаються з доказами MPC для пом'якшення помилок у реалізаціях доказів із нульовим розголошенням (ZKP). Ця система мультиатестації ще більше удосконалюється вимогою до вузлів MPC працювати в межах TEE. Модель DeRoT використовує TEE, MPC і ZKP для розподілу довіри в мережі. Цей підхід підвищує безпеку DApps за допомогою TEE шляхом усунення потенційних загроз на рівні апаратного забезпечення або вузлів.
можливості децентралізованого TEE хмари
Ми спеціально напишемо статтю, щоб обговорити цю тему, оскільки вже багато застосувань працює на Phala. Тому ця частина може бути такою ж довгою, як і вся стаття. Але ми хочемо окреслити можливі варіанти використання децентралізованого TEE хмари.
По-перше, Phala підтримує розгортання AI-моделей у TEE, забезпечуючи безпеку та автономну операцію під час взаємодії з блокчейн-мережею. Це включає AI-агенти для підвищення смарт-контрактів та міжагентної взаємодії. Розробники можуть використовувати GPU TEE для AI-обчислень, що забезпечує справжню антикорупцію та захист конфіденційності.
Розробники також можуть переносити традиційні додатки в безпечне та бездоверене середовище, щоб підвищити безпеку. Ця платформа реалізує захищений аналіз даних з використанням Web3 та традиційних аналітичних інструментів, які можуть аналізувати дані без розкриття інформації про окремих користувачів. Крім того, вона може зміцнити безпечні обчислення DeFi за допомогою функцій конфіденційності, таких як конфіденційні торгові позиції або темні пулові угоди. Нарешті, децентралізоване хмарне середовище TEE може забезпечити захист MEV, перемістивши побудову блоків у TEE для забезпечення справедливого сортування та виконання.
Є багато продуктів, які використовують Phala як частину своєї інфраструктури. Ми детально розглянемо в іншій статті, як ці продукти використовують Phala і яку вигоду вони отримують від цієї інтеграції.
Висновок
Моделі довіри Web3 і Web2 мають фундаментальні відмінності, що призводить до обмежень таких платформ, як AWS. У Web3 дані (включаючи токени, які по суті є даними) насправді належать користувачам, тоді як розробники програм за замовчуванням вважаються ненадійними. Ця недовіра виникає через потенціал розробників намагатися несанкціоновано отримати доступ, змінити або вкрасти дані користувачів.
Ця парадигма пояснює кілька ключових практик у Web3:
Володіння (або управлінський контроль) смарт-контрактами є ключовим питанням, користувачі більше цінують прозорість, а не дозволяють розробникам мати необмежений контроль.
На відміну від смарт-контрактів, TEE можуть застосовувати схожі принципи власності та контролю в рамках ширшого спектру процедур. Однак AWS Nitro Enclaves працює в рамках Web2, де розробники зберігають можливість входити в систему, отримувати доступ і змінювати дані та програми. TEE від Phala розроблено на основі принципів Web3 і за замовчуванням підтримує смарт-контракти для керування програмами на основі TEE, що відповідає моделі децентралізованої довіри.