AWSはWeb3には適していない：分散化TEEクラウドは10倍の効率を向上させることができる

毎日、人々は最大4.02億TBのセンシティブなデータを生成しています。個人がデータを広く共有することにますます消極的になる中、これらのデータに対するプライベート計算の需要は日々高まっています。これらのソリューションは主にアマゾン ウェブ サービス（AWS）のインフラに依存しており、これは世界のクラウドコンピューティング市場の約30％を占めています。

しかし、AWSにはいくつかの欠点があり、主にその集中型アーキテクチャに起因しています。AWS Nitro Enclavesによって強化された安全な計算が導入されたとしても、開発者の採用に関しては依然として重大な課題に直面しており、ブロックチェーンの安全性やWeb3アプリケーションに対して深刻な障害を引き起こしています。

この記事では、AWSの現状を分析し、AWSの欠点を解決し、既存の他のTEEの限界を克服する分散型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は完全にAWSのEC2サービス内で作成および管理されており、高度に集中化されたフレームワークに属しています。作成から終了まで、Enclave管理のすべての側面はAWSのインフラストラクチャによって制御されており、AWSが集中型クラウドプロバイダーであるという性質を考慮すると、これは本質的に集中化されています。

要するに、AWS Nitro Enclavesはハードウェアベースの信頼できる実行環境を通じて強力な隔離を提供し、敏感なワークロードを保護します。しかし、その集中型アーキテクチャは特定の制限とトレードオフをもたらします。

AWS の集中化以外の制限

すべてのコンポーネントとデータが単一システムの集中化の欠点に依存するだけでなく、AWS Nitro Enclavesはさらに多くの課題と新しいセキュリティ上の考慮事項をもたらしました。AWSは、TEEペイロードを実行するために複数のNitroカード（カスタムハードウェア）をCPUに接続しており、これにより二重のセキュリティリスクが生じます：基盤となるCPUとNitroカードの両方に脆弱性が存在する可能性があります。

Nitro Enclaveesの重大な問題は、確立されたメモリ暗号化メカニズムがないことです。 メモリ暗号化がCPUに直接統合されるソリューションとは異なり、Nitroカードの外部特性により、メモリ内データのエンドツーエンドの暗号化を確保することは困難です。 この構成では、暗号化は CPU と外部デバイス間の相互作用に依存するため、メモリ アクセス中に機密情報が改ざんされる可能性があります。

それに加えて、開発者はDockerを使用してEnclaveソフトウェアを含むAmazonマシンイメージ（AMI）を作成および構成する必要がありますが、これはコンテナ化に不慣れな人にとっては難しい場合があります。彼らはまた、AWS CLIとNitro Enclaves CLIを使用してインスタンスを起動し、Enclaveを管理し、Nitro Enclaves APIをナビゲートし、AWSキー管理サービスと統合する必要があり、これには時折暗号証明プロセスの理解が必要です。

TEEがNitroカードに依存しているため、コードの完全性の測定がCPU自体ではなくNitroカードから来るため、検証不可能な証明が生じます。

AWSは、開発者や管理者にアイデンティティとアクセス管理ポリシーを設定することを信頼していますが、これにより機密データへのアクセスが可能になることがあります。彼らの高度なアクセス権は、データを閲覧または改ざんする可能性があるため、内部脅威のリスクを生じさせます。

AWS Nitro のトラスト仮説レビュー

しかし、最も重要な制限は、AWSが分散型アプリケーションとエコシステムに最適化されておらず、Web3ユースケースやガバナンスシステムに対するネイティブサポートが不足していることです。

例えば、AWS Nitro Enclavesは持続的なストレージを欠いています。このような隔離は安全性に寄与しますが、ベクトルデータベースにユーザーデータを保存する必要があるAIエージェントのようなユースケースを制限します。

鍵管理は「ゼロトラスト」シナリオにも適合していません。AWSキー管理サービス（KMS）は利用可能ですが、これはWeb2向けに設計されており、管理者がプライベートキーにアクセスできることを許可しています。これは、Web3がキーを完全にコードによって制御され、誰にも（管理者を含む）公開されない必要があるという要求と矛盾します。

Nitro Enclavesは、クラウドに対する開発者の不信感を解決しますが、Web3では、ユーザー、開発者、ベンダー間のトラストレスなソリューションが必要です。 安全なコードのアップグレードはサポートされておらず、スマートコントラクトのガバナンスと同様に分散型の所有権が必要であり、開発者はゼロから構築する必要があり、これには数か月かかる可能性があり、適切に実装されていない場合、コードは脆弱になる可能性があります。

ネットワークアクセスが不足しているため、Webサービスの設定は時間と労力がかかり、開発者はアプリケーションに適応し、暗号セキュリティを確保するために大量のコードを書くことを余儀なくされますが、これはしばしば完璧ではありません。

なぜWeb3にはTEEが必要なのか？

TEE を使用するのは、開発者や管理者を完全に信頼できないからです。 Web3の参加者は異なる哲学を持ち、トラストレスなシステムを追求しています:何かを信頼しなければならない場合、それはあまり信頼できるようには見えません。 そのため、ユーザーはハードウェア オペレーターにアプリケーションの検査と管理を任せています。 暗号化はCPUと外部デバイス間のスムーズな連携に依存しているため、メモリアクセス中に機密データに干渉したり、スクレイピングしたり、変更したりするのを防ぐために、アプリケーションを切り離すことができます。 ユーザーとデータプロバイダーは、データに対して実行されたアクションについて明確な保証と検証を行う必要があります。

Phala Networkの開発において、私たちの出発点はAWSの利点とTEEの安全性を組み合わせることでした。分散化により複雑性を排除し、同時に安全性を強化することを目指しています。このアプローチはWeb3のユースケースのニーズを満たすことを目的としています。その結果、分散化されたTEEクラウドの概念を提案し、分散型アプリケーションに安全性と統合性を提供することができました。

分散型TEEクラウドを作成

去中心化TEEクラウドの概念を理解するためには、まず去中心化クラウドとは何かを定義する必要があります。それでは、これは何でしょうか？

分散型クラウドは、データの保存、処理、管理が単一の中央サーバーやデータセンターに集中せず、複数のノードのネットワークに分散される計算インフラストラクチャです。AWSなどの従来の集中型クラウドシステムとは異なり、分散型クラウドは単一の管理エンティティを必要とせず、ブロックチェーンに依存して機能します。

分散型TEEクラウド

分散型TEEクラウドは、TEEと分散型ノードのネットワークを組み合わせて、安全でプライベートで検証可能なコンピューティングを提供するコンピューティングインフラストラクチャです。 各ノードにはTEEが装備されており、機密性の高いコードやデータをノードオペレーターによるアクセスや改ざんから保護します。

Phala Networkは、ワーカーノードの分散型ネットワークで構成されており、それぞれにTEEが装備されています。 これらのノードは、スマートコントラクトの実行や機密データの処理など、顧客のニーズに基づいてユーザーのために計算タスクを実行します。

このプロセスは、ユーザーがアプリケーションやタスクをネットワークにデプロイすることから始まります。計算タスクはこれらのノードのTEE内で実行され、コードとデータの機密性が保たれ、ノードのオペレーターでさえそれらを確認したり改ざんしたりすることはできません。

!

Phalaは、TEE内での計算が正しく実行されているかを検証するために暗号学的証明を使用します。ノードオペレーターは、誠実で安全なサービスを提供することに対して報酬を得ており、経済的インセンティブを通じてネットワークの完全性を維持しています。これは一見簡単に思えますが、このソリューションを実装することは見た目よりもはるかに複雑です。

なぜ分散型TEEクラウドを作ることがこんなにも難しいのですか？

TEE自体は中央集権的または分散化されておらず、中央集権化の程度は、システム内でどのように実装および展開されるかによって異なります。 TEE は、プロセッサ内の安全で分離された領域であり、機密性の高いコードとデータをオペレーティング システムまたは同じデバイス上の他のプロセスによる不正アクセスから保護するように設計されています。 TEE が中央集権型モードで動作するか分散型モードで動作するかは、TEE が配置されている広範なシステムのアーキテクチャによって異なります。

歴史的に、中央集権的なシステムを作成することは、実装とノード通信の面で課題に直面してきた分散型システムを作成するよりも簡単でした。 Phala Cloudに先立ち、私たちは完全分散型のPhala Network 1.0(SGX)を成功裏に作成していました。 Phala Cloudは現在、同じ哲学で開発されていますが、時間がかかります。 Phalaは現在、中央集権的なプロバイダーや部分的に分散化されたプロトコルとは異なり、TEEと完全な分散化を組み合わせた唯一のプラットフォームです。

分散化とTEEの利点は明らかですが、製品開発にはまだ十分ではありません。 アリババが巨大な市場シェアを持つ世界最大の電子商取引プラットフォームであると想像してみてください。 もし新製品が2倍のパワーと低価格で発売されたら、それは市場全体を席巻するのでしょうか? 残念ながら、人々は既存の製品に慣れており、新製品が優れていても偏見があるためです。

これは私たちが直面した課題の1つでしたが、2倍の改善を目指すのではなく、競合他社の10倍優れたPhalaをユーザーフレンドリーにしました。 また、前述の通り、AWSはWeb3環境には適していないため、Web3アプリケーションや開発者にとってこのギャップを埋めることを目指しています。 分散化の明らかな利点に加えて、Phala と AWS の他の違いも強調したいと思います。

Phala Cloud と AWS の比較

まず第一に、Nitro EnclavesのAWSセットアッププロセスは複雑です。 これには、Nitro CLIのインストール、Dockerイメージのエンクレーブファイルへの変換、ファイル転送の処理など、複数の手順が含まれますが、これらはすべて時間がかかります。

対照的に、Phala を使用すると、開発者は「オンザフライ」でデプロイでき、既存の Docker コンテナを安全な TEE に簡単に移行できます。 Dstack SDK を使用すると、開発者は最小限の変更で Docker コンテナを Confidential VMs に変換し、ユーザーフレンドリーな Cloud UI を使用してデプロイしながら、テンプレートとカスタム Docker Compose ファイルを引き続きサポートできます。

セキュリティに関しては、AWSは開発者と管理者を信頼して、アクセス制御を適切に設定し、リソースを管理することに依存しています。 AWSは分離されたコンピューティングにTEEを使用していますが、その一元化されたインフラストラクチャには、AWSを信頼してシステムを管理する人が必要であり、機密データへのアクセスにつながる可能性があります。 Phala はゼロトラストモデルを使用しており、デフォルトではどのパーティも信頼しません。 機密データはTEE内で安全に保たれ、ノードオペレーターでさえもアクセスできないため、トラストレスな操作を必要とするWeb3アプリケーションに適しています。

製品の観点から見ると、AWSは主に企業顧客にサービスを提供しています。これは、従来のIT分野の企業が非常に多いためです。そのため、製品および技術の面ではWeb3スタートアップの価値提案に完全には適合していません。それに対して、Phalaは分散型アプリケーションのために構築されています。これにより、ブロックチェーンのスマートコントラクトと相互作用するAIエージェントおよびプライバシー保護のDAppをネイティブにサポートしています。

さらに、Phalaはさまざまなプロトコルのパートナーシップや、TEEのセキュリティを活用したいDAppの統合を通じて、ブロックチェーンエコシステムに深く統合されています。

PhalaはWeb3 AIの実行レイヤーとして位置付けられており、開発者はブロックチェーンのスマートコントラクトを安全かつプライベートに理解し、対話できるAIエージェントを構築、起動、収益化することができます。 NVIDIA は、NVIDIA GPU TEE を活用して、安全で検証可能なプライバシー重視の環境で大規模言語モデル (LLM) を実行することで、NEAR AI や Sentient などの分散型 AI プラットフォームをサポートしています。 たとえば、NOTAI とのパートナーシップでは、AI エージェントのゼロトラスト エンフォースメントが強調されており、TEE と RA Explorer を通じてトラストレスでプライバシー保護を提供しています。

また、ネイティブHTTPリクエストをサポートする低コスト、低遅延のスマートコントラクトであるPhat Contractsを通じて、AI関連以外のアプリケーションとの統合もサポートしています。

しかし、多くの暗号ネイティブチームがTEEやその他の安全な計算方法を構築していることを考慮すると、Phalaはこれらのソリューションとどのように差別化されるのでしょうか？

Phala Cloud with TEE ソリューション

Phala Networkは、DAppsに安全でプライベートで検証可能な計算を提供する唯一の完全分散型TEEクラウドとして際立っています。 Oasis ProtocolやSecret Networkは、それぞれのブロックチェーンでTEEを使用したプライバシー対応のスマートコントラクトに焦点を当てていますが、Phalaはネットワーク全体のオフラインコンピューティングのための分散型クラウドコンピューティングプラットフォームを提供しています。

Phalaは柔軟でカスタマイズ可能で、Intel SGX、Intel TDX、AMD SEV、NVIDIA GPU TEEなどの幅広いTEEハードウェアを利用しています。Marlin ProtocolはWeb3のネットワーク性能を向上させますが、計算またはプライバシー機能は提供していません。一方、OasisとSecretは特定のブロックチェーンエコシステム内で動作します。Phalaは、広範なハードウェアサポートとDstackなどの開発者向けツールを持つ唯一の分散型TEEクラウドとして、独自の利点を持っています。

!

Phalaは、特定のユースケースに焦点を当てたOasis Protocol、Marlin、Secret Networkとは異なり、汎用の分散型TEEクラウドを提供するという点で異なります。 Phalaを使用すると、開発者はAIモデル、Webサーバー、データベースなどの任意のアプリケーションを安全な環境にデプロイできます。 これは、Phat Contractsと、Docker化されたデプロイメントをサポートし、CPUとGPU TEEへのワンクリックアクセスを提供するPhala Cloudによって可能になります。

さらに、TEEとマルチパーティ計算（MPC）のどちらが特定のユースケースにより適しているかについての比較は多くあります。我々の見解では、TEEとMPCは競合相手ではなく、補完的なパートナーです。

Phala は TEE と MPC を統合して、TEE ベースのアプリケーションを保護するための高度なアプローチである分散型 Root of Trust (DeRoT) モデルを作成します。 MPCはTEE内で動作してノードの共謀のリスクを軽減しますが、TEEブロック証明はゼロ知識証明(ZKP)実装のエラーを軽減するためにMPC証明とともに提出されます。 このマルチ認証システムは、MPC ノードが TEE 内で動作するという要件によってさらに強化されます。 DeRoTモデルは、TEE、MPC、およびZKPを使用して、ネットワーク内の信頼性を分散します。 このアプローチは、潜在的なハードウェアまたはノードレベルの脅威に対処することにより、TEEを使用するDAppsのセキュリティを向上させます。

分散型TEEクラウドの可能性

Phalaではすでに多くのアプリケーションが実行されているため、このトピックに記事を捧げます。 その結果、このセクションは記事全体と同じくらい長くなる可能性があります。 しかし、分散型TEEクラウドの可能なユースケースを概説したいと思います。

まず、PhalaはTEE内でのAIモデルの展開をサポートし、ブロックチェーンネットワークとのインタラクションの安全で自律的な運用を確保します。 これには、スマートコントラクトの強化とエージェント間の相互作用のためのAIプロキシが含まれます。 開発者は、AI コンピューティングに GPU TEE を活用して、真の検閲耐性とプライバシー保護を実現できます。

開発者は、レガシーアプリケーションを安全でトラストレスな環境に移行して、セキュリティを向上させることもできます。 このプラットフォームは、Web3と、個々のユーザー情報を公開せずにデータを分析できる従来の分析ツールを通じて、プライバシーを保護したデータ分析を可能にします。 さらに、機密取引ポジションやダークプール取引などのプライバシー機能により、DeFiの安全な計算を強化することができます。 最後に、分散型TEEクラウドは、ブロックビルドをTEEに移動して公正な順序付けと実行を行うことで、MEV保護を実装できます。

多くの製品がPhalaをそのインフラストラクチャの一部として使用しています。これらの製品がどのようにPhalaを利用し、その統合から何を得ているのかについては、別の記事で詳しく探ります。

まとめ

Web3とWeb2の信頼モデルには根本的な違いがあり、AWSのようなプラットフォームには制限があります。 Web3では、データ(本質的にデータであるトークンを含む)は真にユーザーが所有しており、アプリ開発者はデフォルトでは信頼されていません。 この不信感は、開発者が許可なくユーザーデータにアクセス、変更、または盗もうとする可能性に起因しています。

このパラダイムは、Web3におけるいくつかの重要な実践を説明しています：

1. スマートコントラクトのコードは、バックドアや脆弱性を排除するために厳格な審査を受けなければなりません。

スマートコントラクトの所有権(または管理上の制御)は重要な問題であり、ユーザーは開発者が自由に制御できるようにすることよりも透明性を重視しています。

2.Web3環境において理想的には、開発者はスマートコントラクトコードを作成してデプロイし、その後すべての管理権を放棄し、アプリケーションに対して一切の特権を保持しないべきです。

スマートコントラクトとは異なり、TEEはより広範なプログラムの範囲内で類似の所有権と制御原則を実行できます。しかし、AWS Nitro EnclavesはWeb2フレームワーク内で動作し、開発者はデータとアプリケーションへのログイン、アクセス、変更の能力を保持します。PhalaのTEEはWeb3原則に基づいて設計されており、TEEベースのアプリケーションを管理するためのスマートコントラクトをネイティブにサポートし、分散型信頼モデルと一貫性を保っています。