毎日、人々は最大4億200万テラバイトの機密データを生成している。個人が自分のデータを広く共有することにますます消極的になるにつれ、こうしたデータのプライベートな計算の必要性は日々高まっている。これらのソリューションは、世界のクラウド・コンピューティング市場の約30%を占めるAmazon Web Services(AWS)のインフラに大きく依存しています。
しかし、AWSには、主にその集中型アーキテクチャに起因する多くの欠点があります。AWS Nitro Enclavesを通じて強化されたセキュアなコンピューティングが導入されたとしても、開発者の採用にはまだ大きな課題があり、ブロックチェーンのセキュリティとWeb3の採用にはさらに深い障壁があります。
本稿では、AWSの現状を解剖し、AWSの欠点に対処するだけでなく、他の既存のTEEの制限も克服する分散型TEEクラウドソリューションを紹介します。しかし、その前に、AWSとそのNitro Enclaves製品がどのようにして多くの知名度と市場シェアを獲得したのか、そして、これらの進歩の背後にどのような問題が残っているのかを探る必要があります。
AWS Nitro with TEE
AWSは圧倒的に人気のあるクラウド・コンピューティング・プラットフォームで、豊富なツールセットを提供しています。要するに、AWSは本質的に、コンピュート、ストレージ、データベース・サービスなど、開発者のあらゆるコンピューティング・ニーズに応えるクラウド・インフラなのだ。周知の通り、AWSはクラウド・インフラストラクチャ市場の約30%のシェアを占めている。ソフトウェアエンジニアや開発者の48%近くが何らかの形でAWSを使用しており、高い需要があります。
大規模な金融機関、政府機関、機密性の高いデータを扱う新興企業などの需要や顧客基盤の拡大に伴い、AWSのセキュリティや、これらの事業体がこのデータを安全に保管し、機密計算に使用する能力について疑問が投げかけられている。と疑問視されている。
AWSが、使用中のデータを保護するためにプラットフォームにTEEを実装し、静止中のデータと転送中のデータの暗号化を補完するというアイデアを開発したのは、このような背景があったからです。
TEEを統合するこの新しいソリューションは、AWS Nitro Enclavesと呼ばれ、ハードウェアに裏打ちされた分離された実行環境を提供します。Amazon EC2インスタンスは、インタラクティブアクセス、永続ストレージ、外部ネットワーク接続を排除したセキュアな環境を確立します。この分離により、機密性の高いワークロードを親EC2インスタンスやそのオペレータ、その他のソフトウェアから分離することで、攻撃対象領域を最小限に抑えます。

ただし、Nitro Enclavesは、高度に集中化されたフレームワークであるAWSのEC2サービス内で完全に作成・管理されます。エンクレーブの作成から終了まで、エンクレーブ管理のすべての側面はAWSのインフラストラクチャによって制御され、集中型クラウドプロバイダーとしてのAWSの性質上、本質的に集中化されています。
一言で言えば、AWS Nitro Enclavesは、機密性の高いワークロードを保護するために、ハードウェアベースの信頼された実行環境を通じて堅牢な分離を提供します。しかし、その集中型アーキテクチャは特定の制限とトレードオフをもたらします。
AWSの集中化を超える制限
Nitroエンクレーブの大きな問題の1つは、健全なメモリ暗号化メカニズムがないことです。メモリ暗号化がCPUに直接統合されているソリューションとは異なり、Nitroカードは外付けのため、メモリ内のデータのエンドツーエンドの暗号化を保証することが困難です。この構成では、暗号化がCPUと外部デバイス間の相互作用に依存するため、メモリアクセス中に機密情報が改ざんされる可能性があります。
その上、開発者は依然としてDockerを使用して、Enclaveソフトウェアを含むAmazon Machine Image(AMI)を作成および構成する必要があります。また、AWS CLIとNitro Enclaves CLIを使用してインスタンスを起動し、Enclaveを管理し、Nitro Enclaves APIを操作し、AWSキー管理サービスと統合する必要があります。
TEEがNitroカードに依存すると、コードの整合性測定がCPU自体ではなくNitroカードから得られるため、検証不可能な証明になります。
AWSは、IDおよびアクセス管理ポリシーを設定する開発者と管理者を信頼しており、機密データへのアクセスを許可する可能性があります。彼らの高度なアクセスは、データを閲覧したり改ざんしたりする可能性があるため、内部脅威のリスクを生み出します。span leaf="">しかし、最も重要な制限は、AWSが分散型アプリケーションやエコシステム向けに最適化されておらず、Web3のユースケースやガバナンスシステムをネイティブにサポートしていないことです。
たとえば、AWS Nitro Enclaves には永続的なストレージがありません。この分離はセキュリティには有益ですが、ベクターデータベースにユーザーデータを保存する必要があるAIエージェントなどのユースケースが制限されます。
鍵管理も「ゼロ信頼」シナリオには適合しません。AWSの鍵管理サービス(KMS)は利用可能ですが、Web2用に設計されており、管理者が秘密鍵にアクセスできるようになっています。これは、鍵はコードによって完全に管理されなければならず、管理者を含む誰にも公開されないというWeb3の要件と矛盾します。
NitroのEnclavesは、クラウドに対する開発者の不信の問題を解決しますが、Web3では、ユーザー、開発者、ベンダーの間の信頼を必要としないソリューションが必要です。セキュアなコードのアップグレードはサポートされておらず、スマート・コントラクトのガバナンスに似た分散型の所有権が必要で、開発者はゼロから構築しなければならず、それには数カ月かかり、コードは適切に実装されていないと脆弱になる可能性がある。
ウェブサービスのセットアップは、ウェブアクセスがないため時間と労力がかかり、開発者はアプリケーションに適応するために大量のコードを書き、完璧ではないことが多い暗号セキュリティを確保することを余儀なくされる。
なぜWeb3にTEEが必要なのか
ファラネットワークを開発する際、私たちの当初の意図は、AWSの利点とTEEのセキュリティを組み合わせ、セキュリティを強化しながら、分散化によって複雑さを取り除くことでした。このアプローチは、Web3のユースケースのニーズを満たすために設計されました。その結果、分散型アプリケーションのセキュリティと統合を提供する分散型TEEクラウドというコンセプトが生まれました。
分散型TEEクラウドの作成
分散型TEEクラウドのコンセプトを理解するには、まず分散型クラウドとは何かを定義する必要があります。では、それは何なのでしょうか?
分散型クラウドとは、データの保存、処理、管理が単一の中央サーバーやデータセンターに集中するのではなく、複数のノードのネットワークに分散されるタイプのコンピューティング・インフラストラクチャです。AWSのような従来の集中型クラウドシステムとは異なり、分散型クラウドは単一の制御エンティティを必要とせず、ブロックチェーンに依存して機能する。
分散型TEEクラウド
分散型TEEクラウドは、TEEと分散型ノードのネットワークを組み合わせたコンピューティングインフラであり、セキュアでプライベートな検証可能コンピューティングを提供します。各ノードにはTEEが搭載されており、ノードオペレータによるアクセスや改ざんから機密コードやデータを保護します。
Phalaネットワークは、各ノードがTEEを装備した作業ノードの分散型ネットワークで構成されています。これらのノードは、スマートコントラクトの実行や機密データの処理など、顧客の要求に基づいてユーザーのために計算タスクを実行します。
ユーザーがアプリケーションやタスクをネットワークにデプロイするところからプロセスは始まります。コンピュート・タスクはこれらのノードの TEE 内で実行され、コードとデータの機密性が保たれ、ノードのオペレーターでさえ、それらを閲覧したり、改ざんしたりできないようにします。

Phalaは、TEE内の計算が正しく実行されていることを検証するために暗号化証明を使用します。ノードオペレータは、誠実で安全なサービスを提供することで報酬を受け、金銭的なインセンティブを通じてネットワークの整合性を維持します。これは単純に聞こえるが、このソリューションの実装は見た目よりもはるかに複雑である。
なぜ分散型TEEクラウドの作成は難しいのでしょうか?
TEEは本質的に集中型でも分散型でもなく、集中性の度合いは、TEEがどのように実装され、システムに展開されるかに依存します。TEEが集中モードで動作するか分散モードで動作するかは、TEEが存在する広域システムのアーキテクチャに依存します。
歴史的に、実装とノード通信の課題に直面する分散型システムよりも、中央集権型システムの方がシンプルです。ファラクラウドに先立ち、私たちは完全分散型のファラネットワーク1.0(SGX)の構築に成功しました。ファラクラウドは現在、時間はかかりますが、同じ哲学で開発されています。Phalaは現在、中央集権的なプロバイダーや部分的に分散化されたプロトコルとは異なり、TEEと完全な分散化を組み合わせた唯一のプラットフォームです。
分散化とTEEの利点は明らかですが、製品開発においてはまだ十分ではありません。アリババが巨大な市場シェアを持つ世界最大の電子商取引プラットフォームであると想像してみてください。2倍の機能と低価格を備えた新製品が発売されたとして、それが市場全体を支配するでしょうか?残念ながら、そうはならない。なぜなら、人々は既存の製品に慣れ親しんでいるので、たとえ新製品が優れていたとしても、それに対して偏見を抱いてしまうからだ。
これは私たちが直面している課題の1つですが、2倍の改善を追い求めるのではなく、Phalaが競合他社よりも10倍優れていて、ユーザーフレンドリーであることを確認しています。加えて、前述したように、AWSはWeb3環境には適しておらず、我々はWeb3アプリケーションと開発者のためにそのギャップを埋めることを目指しています。分散化という明らかな利点とは別に、PhalaとAWSには強調したい違いがあります。
Phala Cloud vs AWS
AWSには、Nitro Enclavesのための複雑なセットアップ プロセスがあります。Nitro CLIのインストール、DockerイメージのEnclaveファイルへの変換、ファイル転送の処理など、複数のステップが必要で、どれも時間がかかる。
これに対してPhalaでは、開発者はオンザフライでデプロイでき、既存のDockerコンテナをセキュアなTEEに簡単に移行できます。Dstack SDKを使用することで、開発者は最小限の変更でDockerコンテナをConfidential VMに変換し、ユーザーフレンドリーなクラウドUIを通じてデプロイすることができます。
セキュリティに関して言えば、AWSは開発者と管理者がアクセス制御を適切に構成し、リソースを管理することを信頼しています。AWSは分離されたコンピューティングのためにTEEを使用していますが、その集中型インフラストラクチャは、AWSと管理システムを信頼する人々を必要とし、機密データへのアクセスにつながる可能性があります。Phalaはゼロトラストモデルを使用しており、デフォルトではどちらの当事者も信頼していません。Phalaはゼロトラストモデルを採用し、デフォルトでどちらの当事者も信頼しません。機密データはTEE内で安全に保たれ、ノードのオペレータでさえアクセスできないため、信頼なしで動作する必要があるWeb3アプリケーションに適しています。
製品の観点から見ると、AWSは主にエンタープライズ顧客にサービスを提供している。その結果、製品と技術の面でWeb3スタートアップの価値提案に完全にはマッチしない。対照的に、Phalaは分散型アプリケーションに特化して構築されている。
さらに、Phalaは、幅広いプロトコルとのパートナーシップを通じて、分散型アプリケーション向けに設計されています。のセキュリティとブロックチェーンエコシステムに深く統合されたDAppsの統合を利用したいDAppsのために設計されています。
PhalaはWeb3 AIの実行レイヤーとして位置付けられており、開発者がブロックチェーンのスマートコントラクトを安全かつ非公開に理解し、対話できるAIエージェントを構築、起動、収益化できるようにしています。私たちは、NVIDIA GPU TEEを活用して、安全で検証可能なプライバシー重視の環境で大規模言語モデル(LLM)を実行することで、NEAR AIやSentientなどの分散型AIプラットフォームをサポートしています。例えば、NOTAIとのパートナーシップは、AIエージェントのゼロトラスト実行を強調しており、TEEとRA Explorerを通じて、トラストレスでプライバシーを保護することができます。
また、ネイティブのHTTPリクエストをサポートする低コスト、低レイテンシーのスマートコントラクトであるPhat Contractsを通じて、AI関連以外のアプリケーションとの統合もサポートしています。
しかし、多くの暗号ネイティブチームがTEEやその他のセキュアコンピューティングアプローチも構築していることを考えると、Phalaはこれらのソリューションとどのように差別化しているのでしょうか?span leaf="">Phalaネットワークは、唯一の完全分散型TEEクラウドとして際立っており、DAppsのための安全でプライベートかつ検証可能なコンピューティングを提供します。オアシスプロトコルやシークレットネットワークが、それぞれのブロックチェーンでTEEを使用してプライバシーを有効にするスマートコントラクトを実装することに重点を置いているのとは異なり、Phalaはネットワーク全体でオフラインコンピューティングを行うための分散型クラウドコンピューティングプラットフォームを提供します。
Phalaは柔軟でカスタマイズ可能で、Intel SGX、Intel TDX、AMD SEV、NVIDIA GPU TEEなど、幅広いTEEハードウェアを活用できます。一方、OasisとSecretは特定のブロックチェーンエコシステムで動作します。Phalaは、幅広いハードウェアサポートとDstackのような開発者中心のツールを備えた唯一の分散型TEEクラウドとして、独自の地位を確立しています。

Phalaは、特定のユースケースに特化したOasis Protocol、Marlin、Secret Networkとは異なり、一般的な分散型TEEクラウドを提供している点が異なります。Phalaは、AIモデル、ウェブサーバー、データベースなど、あらゆるアプリケーションを安全な環境にデプロイすることを可能にします。これは、Docker化されたデプロイメントとCPUおよびGPU TEEへのワンクリック・アクセスをサポートするPhat ContractsとPhala Cloudによって実現されます。
さらに、TEEとマルチパーティー・コンピューティング(MPC)のどちらが特定のユースケースに適しているかについては、多くの議論があります。MPC)のどちらがより特定のユースケースに適しているかという議論が盛んに行われている。私たちの見解では、TEEとMPCは競合ではなく、補完的なパートナーです。
PhalaはTEEとMPCを統合し、TEEベースのアプリを保護するための最先端のアプローチであるDecentralised Root of Trust(DeRoT)モデルを構築しています。 MPCはTEE内で動作し、ノードの共謀リスクを低減します。また、ゼロ知識証明(ZKP)の実装におけるエラーを軽減するために、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を使用し、この統合から何を得ているかについては、別の投稿で掘り下げていきます。
結論
Web3Web3とWeb2の信頼モデルには根本的な違いがあり、AWSのようなプラットフォームでの制限につながります。Web3では、データ(本質的にデータであるパスを含む)はユーザーによって所有され、アプリケーション開発者はデフォルトでは信頼されない。この不信感は、開発者が権限なしにユーザーデータにアクセス、変更、または盗用を試みる可能性に起因しています。
このパラダイムは、Web3におけるいくつかの重要なプラクティスを説明します:
1.スマートコントラクトのコード
1.スマートコントラクトのコードは、バックドアや脆弱性を排除するために精査されなければなりません。
スマートコントラクトの所有権(または管理コントロール)は重要な問題であり、ユーザーは開発者が自由にコントロールできることよりも透明性を重視します。
2.理想的には、Web3環境では、開発者はスマートコントラクトのコードを書いてデプロイした後、すべての制御を放棄し、アプリに対する特権を保持しないようにします。
スマートコントラクトとは異なり、TEEは、より広範なプロセスにわたって、同様の所有権と制御の原則を強制することができます。しかし、AWS Nitro Enclavesは、開発者がデータやアプリケーションにログインし、アクセスし、変更する能力を保持するWeb2フレームワーク内で動作します。PhalaのTEEはWeb3の原則に従って設計されており、TEEベースのアプリケーションを管理するためのスマートコントラクトをネイティブにサポートしています。