Web3 エコシステムにおける高信頼実行環境 (TEE) の徹底解説
1. TEE 技術の概要
定義とアーキテクチャ: 高信頼実行環境 (Trusted Execution Environment, TEE) とは、プロセッサ内の安全な領域であり、内部にロードされたコードとデータを機密性と完全性の観点から保護します。実用的な観点から言えば、TEE は CPU 内の隔離された「エンクレーブ」として機能し、一種のブラックボックスとして、システムの他の部分から遮蔽された状態で機密性の高い計算を実行できます。TEE エンクレーブ内で実行されるコードは保護されており、たとえ侵害されたオペレーティングシステムやハイパーバイザーであっても、エンクレーブのデータやコードを読み取ったり改ざんしたりすることはできません。TEE が提供する主要なセキュリティ特性は以下の通りです:
- 分離 (Isolation): エンクレーブのメモリは、他のプロセスや OS カーネルからも分離されています。攻撃者がマシン上で完全な管理者権限を取得したとしても、エンクレーブのメモリを直接検査したり変更したりすることはできません。
- 完全性 (Integrity): ハードウェアは、TEE 内で実行されるコードが外部からの攻撃によって変更されないことを保証します。エンクレーブのコードやランタイム状態に対するいかなる改ざんも検出され、侵害された結果が生成される のを防ぎます。
- 機密性 (Confidentiality): エンクレーブ内のデータはメモリ内で暗号化されたままであり、CPU 内での使用時にのみ復号されるため、秘密データが平文で外部に公開されることはありません。
- リモートアテステーション (Remote Attestation): TEE は、自身が本物であり、特定の信頼されたコードが内部で実行されていることをリモートの相手に証明するための暗号学的証明 (アテステーション) を生成できます。これにより、ユーザーはエンクレーブに秘密データを供給する前に、そのエンクレーブが信頼できる状態にあること (例: 本物のハードウェア上で期待されるコードが実行されていること) を検証できます。
スマートコントラクト実行のための安全なエンクレーブ「ブラックボックス」としての高信頼実行環境の概念図。暗号化された入力 (データとコントラクトコード) は、安全なエンクレーブ内で復号されて処理され、暗号化された結果のみがエンクレーブから出力されます。これにより、機密性の高いコントラクトデータが TEE の外部の誰からも機密に保たれます。
内部的には、TEE は CPU のハードウェアベースのメモリ暗号化とアクセス制御によって実現されています。例えば、TEE エンクレーブが作成されると、CPU はそのために保護されたメモリ領域を割り当て、専用のキー (ハードウェアに焼き込まれているか、セキュアコプロセッサによって管理される) を使用してデータを動的に暗号化/復号します。外部のソフトウェアがエンクレーブのメモリを読み取ろうとしても、暗号化されたバイトしか得られません。このユニークな CPU レベ ルの保護により、ユーザーレベルのコードでさえ、特権を持つマルウェアや悪意のあるシステム管理者でさえも覗き見したり変更したりできないプライベートなメモリ領域 (エンクレーブ) を定義できます。本質的に、TEE は通常の動作環境よりも高いレベルのセキュリティをアプリケーションに提供しつつ、専用のセキュアエレメントやハードウェアセキュリティモジュールよりも柔軟性があります。
主要なハードウェア実装: いくつかのハードウェア TEE 技術が存在し、それぞれ異なるアーキテクチャを持っていますが、システム内に安全なエンクレーブを作成するという同様の目標を共有しています:
-
Intel SGX (Software Guard Extensions): Intel SGX は、最も広く使用されている TEE 実装の一つです。アプリケーションがプロセスレベルでエンクレーブを作成することを可能にし、メモリの暗号化とアクセス制御は CPU によって強制されます。開発者は、コードを「信頼された」コード (エンクレーブ内) と「信頼されていない」コード (通常の世界) に分割し、特別な命令 (ECALL/OCALL) を使用してエンクレーブとの間でデータをやり取りする必要があります。SGX はエンクレーブに強力な分離を提供し、Intel のアテステーションサービス (IAS) を介したリモートアテステーションをサポートしています。Secret Network や Oasis Network をはじめとする多くのブロックチェーンプロジェクトが、SGX エンクレーブ上でプライバシー保護スマートコントラクト機能を構築しました。しかし、複雑な x86 アーキテクチャ上の SGX の設計は、いくつかの脆弱性 (§4 参照) を引き起こしており、Intel のアテステーションは中央集権的な信頼依存性を導入しています。
-
ARM TrustZone: TrustZone は異なるアプローチを取り、プロセッサの実行環境全体をセキュアワールドとノーマルワールドの 2 つの世界に分割します。機密コードはセキュアワールドで実行され、特定の保護されたメモリや周辺機器にアクセスできます。一方、ノーマルワールドでは通常の OS とアプリケーションが実行されます。ワールド間の切り替えは CPU によって制御されます。TrustZone は、セキュア UI、支払い処理、デジタル著作権管理などのために、モバイルや IoT デバイスで一般的に使用されています。ブロックチェーンの文脈では、TrustZone は秘密鍵や機密ロジックを携帯電話のセキュアエンクレーブで実行できるようにすることで、モバイルファーストの Web3 アプリケーションを可能にする可能性があります。しかし、TrustZone のエンクレーブは通常、より大きな粒度 (OS または VM レベル) であり、現在の Web3 プロジェクトでは SGX ほど一般的に採用されていません。
-
AMD SEV (Secure Encrypted Virtualization): AMD の SEV 技術は、仮想化環境を対象としています。アプリケーションレベルのエンクレーブを要求する代わりに、SEV は仮想マシン全体のメモリを暗号化できます。組み込みのセキュリティプロセッサを使用して暗号鍵を管理し、メモリ暗号化を実行するため、VM のメモリはホスティングハイパーバイザーに対しても機密に保たれます。これにより、SEV はクラウドやサーバーのユースケースに適しています。例えば、ブロックチェーンノードやオフチェーンワーカーを完全に暗号化された VM 内で実行し、悪意のあるクラウドプロバイダーからデータを保護することができます。SEV の設計は、コードを分割する開発者の労力が少ないことを意味します (既存のアプリケーションや OS 全体を保護された VM で実行できます)。SEV-SNP のような新しいイテレーションでは、改ざん検出などの機能が追加され、VM の所有者が中央集権的なサービスに依存することなく VM を証明できるようになります。SEV は、クラウドベースのブロックチェーンインフラにおける TEE の使用に非常に関連性が高いです。
その他の新興またはニッチな TEE 実装には、Intel TDX (Trust Domain Extensions、新しい Intel チップ上の VM でエンクレーブのような保護を提供)、Keystone (RISC-V) のようなオープンソース TEE、およびモバイルのセキュアエンクレーブチップ (Apple の Secure Enclave など、ただし通常は任意のコード実行には開放されていない) があります。各 TEE には独自の開発モデルと信頼の前提がありますが、すべてハードウェアで分離された安全な実行という中心的な考えを共有しています。
2. Web3 における TEE の応用
高信頼実行環境は、Web3 の最も困難な課題のいくつかに取り組むための強力なツールとなっています。安全でプライベートな計算レイヤーを提供することで、TEE はプライバシー、スケーラビリティ、オラクルのセキュリティ、完全性の分野で ブロックチェーンアプリケーションの新たな可能性を切り開きます。以下では、主要な応用分野を探ります:
プライバシー保護スマートコントラクト
Web3 における TEE の最も顕著な用途の一つは、機密スマートコントラクト、つまりブロックチェーン上で実行されるがプライベートなデータを安全に処理できるプログラムを可能にすることです。Ethereum のようなブロックチェーンはデフォルトで透明であり、すべてのトランザクションデータとコントラクトの状態は公開されています。この透明性は、機密性を必要とするユースケース (例: プライベートな金融取引、秘密投票、個人データ処理) にとって問題となります。TEE は、ブロックチェーンに接続されたプライバシー保護計算エンクレーブとして機能することで、解決策を提供します。
TEE を活用したスマートコントラクトシステムでは、トランザクションの入力はバリデーターやワーカーノード上のセキュアエンクレーブに送信され、エンクレーブ内で処理されます。そこではデータは外部の世界に対して暗号化されたままであり、その後エンクレーブは暗号化またはハッシュ化された結果をチェーンに返すことができます。復号鍵を持つ承認された当事者 (またはコントラクトロジック自体) のみが平文の結果にアクセスできます。例えば、Secret Network は、コンセンサスノードで Intel SGX を使用して、暗号化された入力に対して CosmWasm スマートコントラクトを実行します。これにより、アカウントの残高、トランザクションの金額、コントラクトの状態などを公開せずに計算で使用できます。これにより、シークレット DeFi アプリケーションが可能になりました。例えば、金額が機密に保たれるプライベートなトークンスワップや、入札が暗号化されオークション終了後にのみ公開されるシークレットオークションなどです。別の例として、Oasis Network の Parcel と機密 ParaTime があり、データをトークン化し、機密性制約の下でスマートコントラクトで使用できるようにすることで、信用スコアリングや医療データなどのユースケースをプライバシーコンプライアンスを遵守しながらブロックチェーン上で実現します。
TEE によるプライバシー保護スマートコントラクトは、企業や機関によるブロックチェーンの採用にとって魅力的です。組織は、機密性の高いビジネスロジックやデータを機密に保ちながら、スマートコントラクトを活用できます。例えば、銀行は TEE 対応のコントラクトを使用して、顧客データをオンチェーンで公開することなくローン申請や取引決済を処理し、それでもブロックチェーン検証の透明性と完全性の恩恵を受けることができます。この機能は、GDPR や HIPAA などの規制上のプライバシー要件に直接対応し、医療、金融、その他の機密性の高い業界でブロックチェーンのコンプライアンスに準拠した使用を可能にします。実際、TEE はデータ保護法への準拠を促進します。個人データをエンクレーブ 内で処理し、暗号化された出力のみが外部に出るようにすることで、データが保護されていることを規制当局に納得させることができます。
機密性だけでなく、TEE はスマートコントラクトの_公平性_を強制するのにも役立ちます。例えば、分散型取引所は、マイナーやバリデーターが保留中の注文を見て不当にフロントランニングするのを防ぐために、マッチングエンジンを TEE 内で実行することができます。要約すると、TEE は Web3 に待望のプライバシーレイヤーをもたらし、機密 DeFi、プライベートな投票/ガバナンス、および以前は公開台帳では実現不可能だったエンタープライズコントラクトのようなアプリケーションを解き放ちます。
スケーラビリティとオフチェーン計算
TEE のもう一つの重要な役割は、重い計算をオフチェーンの安全な環境にオフロードすることで、ブロックチェーンのスケーラビリティを向上させることです。ブロックチェーンは、パフォーマンスの限界とオンチェーン実行のコストのために、複雑または計算集約的なタスクに苦労しています。TEE 対応のオフチェーン計算により、これらのタスクをメインチェーンの外で行うことができ (したがって、ブロックガスを消費したり、オンチェーンのスループットを低下させたりしない)、結果の正しさに関する信頼保証を維持できます。事実上、TEE は Web3 のための_検証可能なオフチェーン計算アクセラレータ_として機能します。
例えば、iExec プラットフォームは TEE を使用して、開発者がオフチェーンで計算を実行し、ブロックチェーンによって信頼される結果を得ることができる分散型クラウドコンピューティングマーケットプレイスを作成します。dApp は、iExec ワーカーノードによって実行される計算 (例えば、複雑な AI モデルの推論やビッグデータ分析) を要求できます。これらのワーカーノードは、タスクを SGX エンクレーブ内で実行し、正しいコードが本物のエンクレーブで実行されたことを証明するアテステーションと共に結果を生成します。結果はオンチェーンで返され、スマートコントラクトは出力を受け入れる前にエンクレーブのアテステーションを検証できます。このアーキテクチャにより、信頼を犠牲にすることなく重いワークロードをオフチェーンで処理でき、効果的にスループットを向上させます。iExec Orchestrator と Chainlink の統合はこれを示しています: Chainlink オラクルが外部データを取得し、複雑な計算を iExec の TEE ワーカーに渡し (例: データの集計やスコアリング)、最後に安全な結果がオンチェーンで配信されます。ユースケースには、iExec が実証したような分散型保険計算などがあり、大量のデータ処理をオフチェーンで安価に行い、最終的な結果のみをブロックチェーンに記録します。
TEE ベースのオフチェーン計算は、一部のレイヤー 2 スケーリングソリューションの基盤ともなっています。Oasis Labs の初期プロトタイプ Ekiden (Oasis Network の前身) は、SGX エンクレーブを使用してトランザクション実行をオフチェーンで並行して行い、状態のルートのみをメインチェーンにコミットしました。これは、ロールアップのアイデアに似ていますが、ハードウェアの信頼を使用しています。コントラクト実行を TEE で行うことにより、エンクレーブにセキュリティを依存させながら高いスループットを達成しました。別の例は、Sanders Network の今後の Op-Succinct L2 で、TEE と zkSNARK を組み合わせています: TEE はトランザクションをプライベートかつ迅速に実行し、その後、それらの実行の正しさを Ethereum に証明するために zk-proof が生成されます。このハイブリッドアプローチは、スケーラブルでプライベートな L2 ソリューションのために、TEE の速度と ZK の検証可能性を活用しています。
一般的に、TEE はほぼネイティブなパフォーマンスで計算を実行できるため (実際の CPU 命令を使用し、分離されているだけ)、準同型暗号やゼロ知識証明のような純粋な暗号学的代替手段よりも、複雑なロジックに対して桁違いに高速です。作業をエンクレーブにオフロードすることで、ブロックチェーンは、オンチェーンでは非現実的なより複雑なアプリケーション (機械学習、画像/音声処理、大規模な分析など) を処理できます。結果はアテステーションと共に返され、オンチェーンのコントラクトやユーザーは、それが信頼されたエンクレーブから発信されたものであることを検証でき、データの完全性と正しさを維持します。このモデルはしばしば**「検証可能なオフチェーン計算」**と呼ばれ、TEE は多くのそのような設計 (例: Intel、iExec などによ って開発された Hyperledger Avalon の Trusted Compute Framework は、TEE を使用して EVM バイトコードをオフチェーンで実行し、正しさの証明をオンチェーンに投稿する) の礎となっています。
セキュアオラクルとデータ完全性
オラクルはブロックチェーンと実世界のデータを橋渡ししますが、信頼性の課題をもたらします: スマートコントラクトは、オフチェーンのデータフィードが正しく、改ざんされていないことをどのように信頼できるでしょうか? TEE は、オラクルノードのための安全なサンドボックスとして機能することで解決策を提供します。TEE ベースのオラクルノードは、外部ソース (API、Web サービス) からデータを取得し、ノードオペレーターやノード上のマルウェアによってデータが操作されていないことを保証するエンクレーブ内で処理できます。その後、エンクレーブは提供するデータの真実性を署名または証明できます。これにより、オラクルのデータの完全性と信頼性が大幅に向上します。オラクルオペレーターが悪意を持っていたとしても、エンクレーブのアテステーションを破ることなくデータを変更することはできません (ブロックチェーンはそれを検出します)。
注目すべき例は、Cornell で開発されたオラクルシステムである Town Crier です。これは、Intel SGX エンクレーブを使用して Ethereum コントラクトに認証済みデータを提供した最初のシステムの一つです。Town Crier は、SGX エンクレーブ内でデータ (例: HTTPS Web サイトから) を取得し、データがソースから直接来て偽造されていないという証拠 (エンクレーブ署名) と共にコントラクトに配信しました。Chainlink はこの価値を認識し、2018 年に Town Crier を買収して、TEE ベースのオラクルを分散型ネットワークに統合しました。今日、Chainlink や他のオラクルプロバイダーは TEE イニシアチブを持っています: 例えば、Chainlink の DECO や Fair Sequencing Services は、データの機密性と公正な順序付けを保証するために TEE を含んでいます。ある分析で述べられているように、「TEE はデータ処理のための改ざん防止環境を提供することでオラクルのセキュリティに革命をもたらしました... ノードオペレーター自身でさえ、処理中のデータを操作することはできません」。これは、高価値の金融データフィード (DeFi の価格オラクルなど) にとって特に重要です: TEE は、大きなエクスプロイトにつながる可能性のある微妙な改ざんさえも防ぐことができます。
TEE はまた、オラクルがブロックチェーン上で平文で公開できなかった機密データや専有データを扱うことを可能にします。例えば、オラクルネットワークはエンクレーブを使用して_プライベート_なデータ (機密の株式注文板や個人の健康データなど) を集計し、生の機密入力を公開することなく、派生した結果や検証済みの証明のみをブロックチェーンにフィードすることができます。このようにして、TEE はスマートコントラクトに安全に統合できるデータの範囲を広げます。これは、_実世界資産 (RWA) のトークン化、信用スコアリング、保険、その他のデータ集約的なオンチェーンサービス_にとって不可欠です。
クロスチェーンブリッジに関しても、TEE は同様に完全性を向上させます。ブリッジはしばしば、資産を保管し、チェーン間の転送を検証するために、一連のバリデーターやマルチシグに依存しており、これが攻撃の主要な標的となっています。ブリッジのバリデーターロジックを TEE 内で実行することにより、ブリッジの秘密鍵と検証プロセスを改ざんから保護することができます。バリデーターの OS が侵害されたとしても、攻撃者はエンクレーブ内から秘密鍵を抽出したり、メッセージを偽造したりすることはできないはずです。TEE は、ブリッジのトランザクションがプロトコルのルールに厳密に従って処理されることを強制し、人間のオペレーターやマルウェアが不正な転送を注入するリスクを低減します。さらに、TEE はアトミックスワップやクロスチェーントランザクションを安全なエンクレーブで処理できるようにし、両側を完了させるか、クリーンに中止するかのいずれかを行い、干渉によって資金が動かなくなるシナリオを防ぎます。いくつかのブリッジプロジェクトやコンソーシアムは、近年発生したブリッジハッキングの惨劇を軽減するために、TEE ベースのセキュリティを検討しています。
オフチェーンでのデータ完全性と検証可能性
上記のすべてのシナリオで繰り返されるテーマは、TEE がブロックチェーンの外部であっても_データの完全性_を維持するのに役立つということです。TEE は実行しているコードを (アテステーションを介して) 証明でき、コードが干渉なしに実行されることを保証できるため、検証可能なコンピューティングの一形態を提供します。ユーザーとスマートコントラクトは、アテステーションがチェックされれば、TEE からの結果をオンチェーンで計算されたかのように信頼できます。この完全性の保証が、TEE がオフチェーンのデータと計算に**「信頼の基点 (トラストアンカー)」**をもたらすと言われる理由です。
ただし、この信頼モデルはいくつかの前提をハードウェアに移すことに注意する価値があります (§4 参照)。データの完全性は、TEE のセキュリティと同じくらい強力です。エンクレーブが侵害されたり、アテステーションが偽造されたりすると、完全性は失われる可能性があります。それにもかかわらず、実際には TEE (最新の状態に保たれている場合) は、特定の攻撃を大幅に困難にします。例えば、DeFi レンディングプラットフォームは、TEE を使用してユーザーのプライベートデータからオフチェーンで信用スコアを計算し、スマートコントラクトは有効なエンクレーブのアテステーションが添付されている場合にのみスコアを受け入れます。このようにして、コントラクトは、ユーザーやオラクルを盲目的に信頼するのではなく、承認されたアルゴリズムによって実際のデー タでスコアが計算されたことを知ることができます。
TEE はまた、新興の分散型アイデンティティ (DID) および認証システムにおいても役割を果たします。ユーザーの機密情報がブロックチェーンや dApp プロバイダーに公開されることなく、秘密鍵、個人データ、認証プロセスを安全に管理できます。例えば、モバイルデバイス上の TEE は、生体認証を処理し、生体認証チェックが通過した場合にブロックチェーンのトランザクションに署名することができます。これらすべては、ユーザーの生体情報を明らかにすることなく行われます。これにより、アイデンティティ管理におけるセキュリティとプライバシーの両方が提供されます。これは、Web3 がパスポート、証明書、KYC データなどをユーザー主権の方法で扱う場合に不可欠な要素です。
要約すると、TEE は Web3 における多目的なツールとして機能します: オンチェーンロジックの機密性を可能にし、オフチェーンのセキュアな計算によるスケーリングを可能にし、オラクルやブリッジの完全性を保護し、新しい用途 (プライベートアイデンティティからコンプライアンスに準拠したデータ共有まで) を切り開きます。次に、これらの機能を活用している特定のプロジェクトを見ていきます。
3. TEE を活用する注目の Web3 プロジェクト
いくつかの主要なブロックチェーンプロジェクトは、高信頼実行環境を中心にコアサービスを構築しています。以下では、いくつかの注目すべきプロジェクトを掘り下げ、それぞれが TEE 技術をどのように使用し、どのような独自の価値を付加しているかを検証します:
Secret Network
Secret Network は、TEE を使用してプライバシー保護スマートコントラクトを開拓したレイヤー 1 ブロックチェーン (Cosmos SDK 上に構築) です。Secret Network のすべてのバリデーターノードは Intel SGX エンクレーブを実行し、スマートコントラクトコードを実行することで、コントラクトの状態と入出力がノードオペレーターにさえも暗号化されたままになるようにします。これにより、Secret は最初のプライバシーファーストのスマートコントラクトプラットフォームの一つとなりました。プライバシーはオプションの追加機能ではなく、プロトコルレベルでのネットワークのデフォルト機能です。
Secret Network のモデルでは、ユーザーは暗号化されたトランザクションを送信し、バリデーターはそれを実行のために SGX エンクレーブにロードします。エンクレーブは入力を復号し、(変更された CosmWasm ランタイムで書かれた) コントラクトを実行し、ブロックチェーンに書き込まれる暗号化された出力を生成します。正しいビューイングキーを持つユーザー (または内部キーを持つコントラクト自体) のみが、実際のデータを復号して表示で きます。これにより、アプリケーションはプライベートなデータを公開することなくオンチェーンで使用できます。
このネットワークは、いくつかの新しいユースケースを実証しています:
- シークレット DeFi: 例えば、SecretSwap (AMM) では、ユーザーのアカウント残高とトランザクション金額がプライベートであり、フロントランニングを軽減し、取引戦略を保護します。流動性プロバイダーとトレーダーは、自分たちのすべての動きを競合他社に放送することなく操作できます。
- シークレットオークション: 入札がオークション終了まで秘密に保たれるオークションコントラクトで、他者の入札に基づく戦略的な行動を防ぎます。
- プライベートな投票とガバナンス: トークン保有者は、投票の選択肢を明らかにすることなく提案に投票でき、集計は依然として検証可能です。これにより、公正で脅迫のないガバナンスが保証されます。
- データマーケットプレイス: 機密性の高いデータセットを、生のデータを購入者やノードに公開することなく、取引し、計算で使用できます。
Secret Network は基本的に、プロトコルレベルで TEE を組み込むことで、独自の価値提案を生み出しています: それは_プログラム可能なプライバシー_を提供します。彼らが取り組む課題には、分散型バリデーターセット全体でのエンクレーブアテステーションの調整や、コントラクトがバリデーターから秘密を保ちながら入力を復号できるようにするための鍵配布の管理が含まれます。あらゆる点で、Secret は公開ブロックチェーン上での TEE による機密性の実現可能性を証明し、この分野のリーダーとしての地位を確立しました。
Oasis Network
Oasis Network は、スケーラビリティとプライバシーを目指すもう一つのレイヤー 1 であり、そのアーキテクチャで TEE (Intel SGX) を広範囲に活用しています。Oasis は、コンセンサスと計算を分離し、コンセンサスレイヤーとParaTime レイヤーと呼ばれる異なるレイヤーに分ける革新的な設計を導入しました。コンセンサスレイヤーはブロックチェーンの順序付けとファイナリティを処理し、各 ParaTime はスマートコントラクトのランタイム環境となり得ます。特に、Oasis の Emerald ParaTime は EVM 互換環境であり、Sapphire は TEE を使用してスマートコントラクトの状態をプライベートに保つ機密 EVM です。
Oasis の TEE の使用は、大規模な機密計算に焦点を当てています。重い計算を並列化可能な ParaTime (多くのノードで実行可能) に分離することで高いスループットを達成し、それらの ParaTime ノード内で TEE を使用することで、計算に機密データを含めてもそれを公開しないことを保証します。例えば、機関はプライベートなデータを機密 ParaTime に供給することで、Oasis 上で信用スコアリングアルゴリズムを実行できます。データはノードに対して暗号化されたまま (エンクレーブ内で処理されるため) であり、スコアのみが出力されます。一方、Oasis のコンセンサスは、計算が正しく行わ れたことの証明を記録するだけです。
技術的には、Oasis は標準の SGX を超える追加のセキュリティレイヤーを実装しました。彼らは_「階層化された信頼の基点」_を実装しました: Intel の SGX Quoting Enclave とカスタムの軽量カーネルを使用して、ハードウェアの信頼性を検証し、エンクレーブのシステムコールをサンドボックス化します。これにより、攻撃対象領域を縮小し (エンクレーブが実行できる OS コールをフィルタリングすることで)、特定の既知の SGX 攻撃から保護します。Oasis はまた、永続エンクレーブ (エンクレーブが再起動後も状態を維持できるようにする) やセキュアロギングなどの機能を導入し、ロールバック攻撃 (ノードが古いエンクレーブ状態を再生しようとする) を軽減しました。これらの革新は彼らの技術論文で説明されており、Oasis が TEE ベースのブロックチェーンコンピューティングにおける_研究主導_のプロジェクトと見なされる理由の一部です。
エコシステムの観点から、Oasis はプライベート DeFi (銀行が顧客データを漏洩することなく参加できるようにする) やデータトークン化 (個人や企業が機密性を保ちながら AI モデルにデータを共有し、報酬を得ることをすべてブロックチェーンを介して行う) などの分野で自らを位置づけています。彼らはまた、企業とのパイロットプロジェクトで協力しています (例えば、BMW とのデータプライバシーに関する協力や、その他との医療研究データ共有など)。全体として、Oasis Network は、TEE とスケーラブルなアーキテクチャを組み合わせることで、プライバシー_と_パフォーマンスの両方に対応できることを示しており、TEE ベースの Web3 ソリューションにおける重要なプレイヤーとなっています。
Sanders Network
Sanders Network は、Polkadot エコシステム内の分散型クラウドコンピューティングネットワークであり、TEE を使用して機密性の高い高性能な計算サービスを提供します。これは Polkadot のパラチェーンであり、Polkadot のセキュリティと相互運用性の恩恵を受けますが、セキュアエンクレーブでのオフチェーン計算のための独自の新しいランタイムを導入しています。
Sanders の中心的なアイデアは、(Sanders マイナーと呼ばれる) ワーカーノードの大規模なネットワークを維持し、それらが TEE (具体的にはこれまでのところ Intel SGX) 内でタスクを実行し、検証可能な結果を生成することです。これらのタスクは、スマートコントラクトの一部を実行することから、ユーザーが要求する汎用計算まで多岐にわたります。ワーカーは SGX で実行されるため、Sanders は計算が機密性 (入力データはワーカーオペレーターから隠される) と完全性 (結果にはアテステーションが付属する) を持って行われることを保証します。これにより、ユーザーがホストが覗き見したり改ざんしたりできないことを知ってワークロードを展開できる_トラストレスなクラウド_が効果的に作成されます。
Sanders は、Amazon EC2 や AWS Lambda に似ていますが、分散型であると考えることができます: 開 発者は Sanders のネットワークにコードを展開し、世界中の多くの SGX 対応マシンで実行させ、サービスに対して Sanders のトークンで支払うことができます。いくつかの注目されるユースケース:
- Web3 アナリティクスと AI: プロジェクトは、Sanders エンクレーブでユーザーデータを分析したり AI アルゴリズムを実行したりできます。これにより、生のユーザーデータは暗号化されたまま (プライバシーを保護) で、集計されたインサイトのみがエンクレーブから出力されます。
- ゲームのバックエンドとメタバース: Sanders は、集中的なゲームロジックや仮想世界のシミュレーションをオフチェーンで処理し、コミットメントやハッシュのみをブロックチェーンに送信することで、単一のサーバーを信頼することなく、より豊かなゲームプレイを可能にします。
- オンチェーンサービス: Sanders は Sanders Cloud と呼ばれるオフチェーン計算プラットフォームを構築しました。例えば、ボット、分散型 Web サービス、さらには TEE アテステーション付きで DEX スマートコントラクトに取引を公開するオフチェーンのオーダーブックのバックエンドとして機能することができます。
Sanders は、機密コンピューティングを水平方向にスケールできることを強調しています: より多くの容量が必要ですか? TEE ワーカーノードを追加するだけです。これは、計算能力がコンセンサスによって制限される単一のブロックチェーンとは異なります。したがって、Sanders は、トラストレスなセキュリティを依然として望む計算集約的な dApp の可能性を開きます。重要なことに、Sanders はハードウェアの信頼だけに依存しているわけではありません。Polkadot のコンセンサス (例: 不正な結果に対するステーキングとスラッシング) と統合しており、さらには TEE とゼロ知識証明の組み合わせも探求しています (前述の通り、彼らの今後の L2 は TEE を使用して実行を高速化し、ZKP を使用して Ethereum 上で簡潔に検証します)。このハイブリッドアプローチは、暗号学的検証を重ねることで、単一の TEE の侵害リスクを軽減するのに役立ちます。
要約すると、Sanders Network は TEE を活用して、Web3 向けの分散型で機密性の高いクラウドを提供し、セキュリティ保証付きのオフチェーン計算を可能にします。これにより、重い計算とデータプライバシーの両方を必要とするブロックチェーンアプリケーションのクラスが解き放たれ、オンチェーンとオフチェーンの世界の間のギャップを埋めます。
iExec
iExec は、Ethereum 上に構築されたクラウドコンピューティングリソースの分散型マーケットプレイスです。前の 3 つ (独自のチェーンまたはパラチェーン) とは異なり、iExec は Ethereum スマートコントラクトと連携するレイヤー 2 またはオフチェーンネットワークとして動作します。TEE (具体的には Intel SGX) は、オフチェーン計算における信頼を確立するための iExec のアプローチの礎です。
iExec ネットワークは、さまざまなプロバイダーから提供されるワーカーノードで構成されています。これらのワーカーは、ユーザー (dApp 開発者、データプロバイダーなど) から要求されたタスクを実行できます。これらのオフチェーン計算が信頼できることを保証するために、iExec は**「Trusted off-chain Computing (信頼されたオフチェーンコンピューティング)」フレームワークを導入しました: タスクは SGX エンクレーブ内で実行でき、結果にはタスクがセキュアノードで正しく実行されたことを証明するエンクレーブ署名が付属します。iExec は Intel と提携してこの信頼されたコンピューティング機能を立ち上げ、さらには Confidential Computing Consortium に参加して標準を推進しました。彼らのコンセンサスプロトコルであるProof-of-Contribution (PoCo)** は、必要に応じて複数のワーカーからの投票/アテステーションを集約して、正しい結果に関するコンセンサスに達します。多くの場合、コードが決定論的で SGX への信頼が高い場合は、単一のエンクレーブのアテステーションで十分かもしれません。より高い保証のためには、iExec は複数の TEE でタスクを複製し、コンセンサスまたは多数決を使用できます。
iExec のプラットフォームは、いくつかの興味深いユースケースを可能にします:
- 分散型オラクルコンピューティング: 前述の通り、iExec は Chainlink と連携できます。Chainlink ノードは生のデータを取得し、それを iExec の SGX ワーカーに渡して計算 (例: 独自のアルゴリズムや AI 推論) を実行させ、最終的に結果をオンチェーンで返します。これにより、オラクルは単にデータを中継するだけでなく、TEE が誠実さを保証する_計算サービス_ (AI モデルの呼び出しや多くのソースの集計など) を提供できるように なります。
- AI と DePIN (分散型物理インフラネットワーク): iExec は、分散型 AI アプリの信頼レイヤーとして位置づけられています。例えば、機械学習モデルを使用する dApp は、モデル (専有の場合) と入力されるユーザーデータの両方を保護するために、エンクレーブ内でモデルを実行できます。DePIN (分散型 IoT ネットワークなど) の文脈では、TEE はエッジデバイスで使用して、センサーの読み取り値とそれらの読み取り値に対する計算を信頼することができます。
- セキュアなデータ収益化: データプロバイダーは、iExec のマーケットプレイスでデータセットを暗号化された形式で利用可能にできます。購入者は、アルゴリズムを TEE 内でデータ上で実行するように送信できます (これにより、データプロバイダーの生のデータは決して公開されず、IP が保護され、アルゴリズムの詳細も隠すことができます)。計算の結果は購入者に返され、データプロバイダーへの適切な支払いはスマートコントラクトを介して処理されます。このスキームは、しばしば_セキュアなデータ交換_と呼ばれ、TEE の機密性によって促進されます。
全体として、iExec は Ethereum スマートコントラクトとセキュアなオフチェーン実行の間の接着剤を提供します。それは、TEE「ワーカー」がネットワーク化されて分散型クラウドを形成し、マーケットプレイス (支払いに iExec の RLC トークンを使用) とコンセンサスメカニズムを備えていることを示しています。Enterprise Ethereum Alliance の Trusted Compute ワーキンググループを主導し、標準 (Hyperledger Avalon など) に貢献することで、iExec はエンタ ープライズブロックチェーンシナリオにおける TEE のより広範な採用も推進しています。
その他のプロジェクトとエコシステム
上記の 4 つ以外にも、注目すべきプロジェクトがいくつかあります:
- Integritee – Sanders に似たもう一つの Polkadot パラチェーン (実際には、Energy Web Foundation の TEE 研究からスピンアウトしました)。Integritee は TEE を使用して、オンチェーンとオフチェーンのエンクレーブ処理を組み合わせた、企業向けの「サービスとしてのパラチェーン」を作成します。
- Automata Network – プライベートトランザクション、匿名投票、MEV 耐性のあるトランザクション処理のために TEE を活用する Web3 プライバシーのための中間層プロトコル。Automata は、プライベート RPC リレーのようなサービスを提供するオフチェーンネットワークとして実行され、シールドされたアイデンティティやガスレスのプライベートトランザクションなどに TEE を使用していると述べられています。
- Hyperledger Sawtooth (PoET) – エンタープライズ分野では、Sawtooth は Proof of Elapsed Time と呼ばれるコンセンサスアルゴリズムを導入しました。これは SGX に依存していました。各バリデーターは、ランダムな時間待機して証明を生成するエンクレーブを実行します。最も短い待機時間を持つものがブロックを「 勝ち取る」という、SGX によって強制される公正な抽選です。Sawtooth は Web3 プロジェクトではありませんが (エンタープライズブロックチェーン寄り)、コンセンサスにおける TEE の創造的な使用例です。
- エンタープライズ/コンソーシアムチェーン – 多くのエンタープライズブロックチェーンソリューション (例: ConsenSys Quorum, IBM Blockchain) は、承認されたノードのみが特定のデータを閲覧できる機密コンソーシアムトランザクションを可能にするために TEE を組み込んでいます。例えば、Enterprise Ethereum Alliance の Trusted Compute Framework (TCF) の青写真は、TEE を使用してプライベートコントラクトをオフチェーンで実行し、マークルプルーフをオンチェーンで配信します。
これらのプロジェクトは、TEE の多用途性を集合的に示しています: プライバシーに焦点を当てた L1 全体を動かし、オフチェーンネットワークとして機能し、オラクルやブリッジのようなインフラの一部を保護し、さらにはコンセンサスアルゴリズムの基盤ともなっています。次に、分散環境で TEE を使用することの広範な利点と課題を考察します。
4. 分散環境における TEE の利点と課題
ブロックチェーンシステムに高信頼実行環境を採用することには、大きな技術的利点と、注目すべき課題およびトレードオフが伴います。ここ では、TEE が分散アプリケーションに何を提供し、その使用からどのような問題やリスクが生じるか、両側面を検証します。
利点と技術的強み
-
強力なセキュリティとプライバシー: 最大の利点は、機密性と完全性の保証です。TEE は、機密コードが外部のマルウェアによって覗き見されたり改ざんされたりしないという保証のもとで実行されることを可能にします。これにより、以前は利用できなかったオフチェーン計算における信頼レベルが提供されます。ブロックチェーンにとって、これはプライベートデータが (dApp の機能を強化しながら) セキュリティを犠牲にすることなく利用できることを意味します。信頼できない環境 (クラウドサーバー、第三者が運営するバリデーターノード) でさえ、TEE は秘密を安全に保ちます。これは、暗号システム内での秘密鍵、ユーザーデータ、専有アルゴリズムの管理に特に有益です。例えば、ハードウェアウォレットやクラウド署名サービスは、TEE を使用して内部でブロックチェーントランザクションに署名することで、秘密鍵が平文で公開されることがなく、利便性とセキュリティを両立させることができます。
-
ほぼネイティブなパフォーマンス: ZK プルーフや準同型暗号のような純粋に暗号学的なセキュアコンピューティングアプローチとは異なり、TEE のオーバーヘッドは比較的小さいです。コードは CPU 上で直接実行されるため、エンクレーブ内の計算は外部での実行とほぼ同じ速さです (エンクレーブへの移行やメモリ暗号化には多少のオーバーヘッドがあり、SGX では通常 1 桁パーセントの速度低下)。これは、TEE が計算集約的なタスクを効率的に処理できることを意味し、暗号プロトコルで行うと桁違いに遅くなるユースケース (リアルタイムのデータフィード、複雑なスマートコントラクト、機械学習など) を可能にします。エンクレーブの低遅延は、高速な応答が必要な場合に適しています (例: TEE で保護された高頻度取引ボットや、遅延が大きいとユーザーエクスペリエンスが損なわれるインタラクティブなアプリケーションやゲーム)。
-
スケーラビリティの向上 (オフロードによる): 重い計算をオフチェーンで安全に行うことを可能にすることで、TEE はメインチェーンの混雑とガス代を緩和するのに役立ちます。これにより、ブロックチェーンが検証や最終的な決済にのみ使用され、計算の大部分が並列エンクレーブで行われるレイヤー 2 設計やサイドプロトコルが可能になります。このモジュール化 (計算集約的なロジックは TEE で、コンセンサスはオンチェーンで) は、分散アプリのスループットとスケーラビリティを劇的に向上させることができます。例えば、DEX はマッチメイキングを TEE でオフチェーンで行い、マッチした取引のみをオンチェーンに投稿することで、スループットを向上させ、オンチェーンのガスを削減できます。
-
より良いユーザーエクスペリエンスと機能性: TEE を使用すると、dApp は機密性や複雑な分析などの機能を 提供でき、より多くのユーザー (機関投資家を含む) を引き付けることができます。Automata が TEE を使用してプライベートトランザクションのガスを削減したと指摘されているように、TEE はオフチェーンで安全に実行し、結果を送信することでガスレスまたはメタトランザクションも可能にします。さらに、機密状態をオフチェーンのエンクレーブに保存することで、オンチェーンで公開されるデータを削減でき、これはユーザーのプライバシーとネットワークの効率 (保存/検証するオンチェーンデータが少ない) にとって良いことです。
-
他の技術との構成可能性: 興味深いことに、TEE は他の技術を補完することができます (TEE 単独の利点ではなく、組み合わせによるもの)。ハイブリッドソリューションをつなぎ合わせる接着剤として機能することができます: 例えば、エンクレーブでプログラムを実行し、同時にその実行の ZK プルーフを生成する、ここでエンクレーブは証明プロセスの一部を支援して高速化します。あるいは、MPC ネットワークで TEE を使用して、通信ラウンドを減らして特定のタスクを処理します。§5 で比較を議論しますが、多くのプロジェクトは TEE が暗号技術を_置き換える_必要はなく、セキュリティを強化するために並行して機能することができると強調しています (Sanders のマントラ: 「TEE の強みは他者を置き換えることではなく、サポートすることにある」)。
信頼の前提とセキュリティ脆弱性
その強みにもかかわらず、TEE は特定の信頼の前提を導入し、無敵ではありません。これらの課題を理解することが重要です:
-
ハードウェアへの信頼と中央集権化: TEE を使用することで、本質的にシリコンベンダーとそのハードウェア設計およびサプライチェーンのセキュリティに信頼を置くことになります。例えば、Intel SGX を使用することは、Intel にバックドアがなく、製造が安全であり、CPU のマイクロコードがエンクレーブの分離を正しく実装していることを信頼することを意味します。これは、純粋な暗号技術 (すべてのユーザーに分散された数学的な仮定に依存する) と比較して、より中央集権的な信頼モデルです。さらに、SGX のアテステーションは歴史的に Intel のアテステーションサービスに連絡することに依存しており、もし Intel がオフラインになったり、キーを取り消したりすると、世界中のエンクレーブが影響を受ける可能性があります。この単一企業のインフラへの依存は懸念を引き起こします: それは単一障害点になる可能性があり、あるいは政府規制の対象になる可能性さえあります (例: 米国の輸出規制は、理論的には誰が強力な TEE を使用できるかを制限する可能性があります)。AMD SEV は、より分散化されたアテステーションを可能にすることでこれを緩和しますが (VM の所有者は自分の VM を証明できる)、それでも AMD のチップとファームウェアを信頼する必要があります。中央集権化のリスクは、しばしばブロックチェー ンの分散化とは相容れないものとして挙げられます。Keystone (オープンソース TEE) などのプロジェクトは、独自のブラックボックスへの依存を減らす方法を研究していますが、これらはまだ主流ではありません。
-
サイドチャネル攻撃およびその他の脆弱性: TEE は魔法の弾丸ではありません。間接的な手段によって攻撃される可能性があります。サイドチャネル攻撃は、直接的なメモリアクセスがブロックされていても、エンクレーブの操作がシステムに微妙な影響を与える可能性があるという事実を利用します (タイミング、キャッシュ使用量、消費電力、電磁放射などを通じて)。過去数年間で、Intel SGX に対する数多くの学術的な攻撃が実証されてきました: Foreshadow (L1 キャッシュのタイミングリークを介してエンクレーブの秘密を抽出) から Plundervolt (特権命令を介した電圧フォールトインジェクション)、SGAxe (アテステーションキーの抽出) などがあります。これらの高度な攻撃は、TEE が暗号保護を破ることなく、マイクロアーキテクチャの挙動や実装の欠陥を悪用することで侵害される可能性があることを示しています。その結果、_「研究者たちは、ハードウェアの脆弱性や TEE 操作のタイミングの違いを悪用する可能性のあるさまざまな攻撃ベクトルを特定している」_と認識されています。これらの攻撃は些細なものではなく、多くの場合、ローカルアクセスまたは悪意のあるハードウェアが必要ですが、それらは現実の脅威です。また、TEE は一般的に、敵がチップを手にしている場合の物理的攻撃から保護 しません (例: チップのデキャップ、バスのプロービングなどは、ほとんどの商用 TEE を打ち負かすことができます)。
サイドチャネルの発見に対するベンダーの対応は、既知のリークを軽減するためのマイクロコードパッチとエンクレーブ SDK の更新でした (時にはパフォーマンスを犠牲にして)。しかし、それはいたちごっこのままです。Web3 にとって、これは誰かが SGX の新しいサイドチャネルを見つけた場合、SGX で実行されている_「安全な」_DeFi コントラクトが潜在的に悪用される可能性があることを意味します (例: 秘密データを漏洩させたり、実行を操作したりする)。したがって、TEE に依存するということは、典型的なブロックチェーンの脅威モデルの外にあるハードウェアレベルでの潜在的な脆弱性表面を受け入れることを意味します。これらに対して TEE を強化することは活発な研究分野です (例えば、コンスタントタイム操作でエンクレーブコードを設計する、秘密に依存するメモリアクセスパターンを避ける、オブリビアス RAM のような技術を使用するなど)。一部のプロジェクトは、二次的なチェックで TEE を補強しています。例えば、ZK プルーフと組み合わせる、または単一チップのリスクを減らすために異なるハードウェアベンダーで複数のエンクレーブを実行するなどです。
-
パフォーマンスとリソースの制約: TEE は CPU バウンドなタスクに対してほぼネイティブな速度で実行されますが、いくつかのオーバーヘッドと制限が伴います。エンクレーブへの切り替え (ECALL) とエンクレーブからの切り替え (OCALL) にはコストがかかり、メモリページの暗号化/復号にもコストがかかります。これは、非常に頻繁なエンクレーブ境界の横断に対してパフォーマンスに影響を与える可能性があります。エンクレーブにはメモリサイズの制限があることも多いです。例えば、初期の SGX は Enclave Page Cache が限られており、エンクレーブがより多くのメモリを使用すると、ページをスワップする必要があり (暗号化を伴う)、パフォーマンスが大幅に低下しました。新しい TEE でさえ、システム RAM の_すべて_を簡単に使用できるわけではありません。上限がある可能性のあるセキュアなメモリ領域があります。これは、非常に大規模な計算やデータセットを TEE 内で完全に処理することが困難になる可能性があることを意味します。Web3 の文脈では、これはエンクレーブで実行できるスマートコントラクトや ML モデルの複雑さを制限する可能性があります。開発者はメモリを最適化し、場合によってはワークロードを分割する必要があります。
-
アテステーションと鍵管理の複雑さ: 分散環境で TEE を使用するには、堅牢なアテステーションワークフローが必要です: 各ノードは、期待されるコードを持つ本物のエンクレーブを実行していることを他のノードに証明する必要があります。このアテステーション検証をオンチェーンで設定することは複雑になる可能性があります。通常、ベンダーの公開アテステーションキーや証明書をプロトコルにハードコーディングし、検証ロジックをスマートコントラクトやオフチェーンクライアントに記述する必要があります。これはプロトコル設計にオーバーヘッドをもたらし、変更 (Intel がアテステーション署名キー形式を EPID から DCAP に変更するなど) はメンテナンスの負担を引き起こす可能性があります。さらに、TEE 内での鍵管理 (データの復号や結果の署名のため) は、別の複雑さの層を追加します。エンクレーブの鍵管理の誤りは、セキュリティを損なう可能性があります (例: エンクレーブがバグによって誤って復号キーを公開した場合、そのすべての機密性の約束は崩壊します)。ベストプラクティスには、TEE のシーリング API を使用してキーを安全に保存し、必要に応じてキーをローテーションすることが含まれますが、これも開発者による慎重な設計が必要です。
-
サービス拒否と可用性: あまり議論されていない問題かもしれませんが、TEE は可用性の向上には役立たず、新しい DoS の経路を導入することさえあります。例えば、攻撃者は、エンクレーブがオペレーターによって簡単に検査されたり中断されたりできないこと (分離されているため) を知って、処理にコストがかかる入力で TEE ベースのサービスを溢れさせる可能性があります。また、脆弱性が発見され、パッチにファームウェアの更新が必要な場合、そのサイクル中に多くのエンクレーブサービスは (セキュリティのために) ノードがパッチされるまで一時停止しなければならず、ダウンタイムを引き起こす可能性があります。ブロックチェーンのコンセンサスで、もし重大な SGX のバグが発見された場合を想像してみてください。Secret のようなネットワークは、エンクレーブへの信頼が壊れるため、修正されるまで停止しなければならないかもしれません。このような対応を分散ネットワークで調整 することは困難です。
構成可能性とエコシステムの制限
-
他のコントラクトとの限定的な構成可能性: Ethereum のような公開スマートコントラクトプラットフォームでは、コントラクトは他のコントラクトを簡単に呼び出すことができ、すべての状態は公開されているため、DeFi のマネーレゴと豊かな構成が可能になります。TEE ベースのコントラクトモデルでは、プライベートな状態は機密性を損なうことなく自由に共有または構成することはできません。例えば、エンクレーブ内のコントラクト A がコントラクト B と対話する必要があり、両方が何らかの秘密データを保持している場合、どのように協力するのでしょうか? 複雑なセキュアマルチパーティプロトコルを実行する必要があるか (これは TEE の単純さの一部を否定します)、または一つのエンクレーブに結合する必要があります (モジュール性を低下させます)。これは Secret Network などが直面している課題です: プライバシーを伴うクロス・コントラクト・コールは些細なことではありません。いくつかの解決策には、単一のエンクレーブが複数のコントラクトの実行を処理し、内部で共有された秘密を管理できるようにすることが含まれますが、それはシステムをよりモノリシックにする可能性があります。したがって、プライベートコントラク トの構成可能性は公開コントラクトよりも限定的であるか、新しい設計パターンが必要です。同様に、TEE ベースのモジュールを既存のブロックチェーン dApp に統合するには、慎重なインターフェース設計が必要です。多くの場合、エンクレーブの結果のみがオンチェーンに投稿され、それはスナークやハッシュである可能性があり、他のコントラクトはその限られた情報しか使用できません。これは確かにトレードオフです。Secret のようなプロジェクトは、ビューイングキーを提供し、必要に応じて秘密の共有を許可しますが、通常のオンチェーンの構成可能性ほどシームレスではありません。
-
標準化と相互運用性: TEE エコシステムは現在、ベンダー間で統一された標準を欠いています。Intel SGX、AMD SEV、ARM TrustZone はすべて、異なるプログラミングモデルとアテステーション方法を持っています。この断片化は、SGX エンクレーブ用に書かれた dApp が TrustZone に簡単に移植できないことなどを意味します。ブロックチェーンでは、これによりプロジェクトが特定のハードウェアに縛られる可能性があります (例: Secret と Oasis は現在、SGX を搭載した x86 サーバーに縛られています)。将来的にそれらが ARM ノード (例えば、モバイル上のバリデーター) をサポートしたい場合、追加の開発とおそらく異なるアテステーション検証ロジックが必要になります。アテステーションとエンクレーブ API を標準化するための取り組み (CCC – Confidential Computing Consortium など) がありますが、まだ完全ではありません。標準の欠如は開発者ツールにも影響します。SGX SDK は成熟しているかもしれませんが、その後、別の SDK を持つ別の TEE に適応する必要があります。この相互運用性の課題は、採用を遅らせ、コストを増加させる可能性があります。
-
開発者の学習曲線: TEE 内で実行されるアプリケーションを構築するには、多くのブロックチェーン開発者が持っていない可能性のある専門知識が必要です。低レベルの C/C++ プログラミング (SGX/TrustZone 用) や、メモリ安全性とサイドチャネル耐性のあるコーディングの理解がしばしば必要です。エンクレーブコードのデバッグは非常にトリッキーであることで有名です (セキュリティ上の理由から、実行中のエンクレーブの内部を簡単に見ることはできません!)。フレームワークや高レベル言語 (Oasis が機密ランタイムに Rust を使用していることや、エンクレーブで WebAssembly を実行するためのツールなど) は存在しますが、開発者エクスペリエンスは、典型的なスマートコントラクト開発やオフチェーンの Web2 開発よりもまだ粗削りです。この急な学習曲線と未熟なツールは、開発者を思いとどまらせたり、注意深く扱わないと間違いにつながる可能性があります。また、テスト用のハードウェアが必要であるという側面もあります。SGX コードを実行するには、SGX 対応の CPU またはエミュレーター (より遅い) が必要であり、参入障壁は高くなります。その結果、今日、エンクレーブ開発に深く精通している開発者は比較的少なく、監査やコミュニティのサポートは、例えば、よく知られた Solidity コミュニティよりも希少です。
-
運用コスト: TEE ベースのインフラを運用することは、よりコストがかかる可能性があります。ハードウェア自体が高価であったり、希少であったりする可能性があります (例: 特定のクラウドプロバイダーは SGX 対応の VM にプレミアム料金を請求します)。運用にもオーバーヘッドがあります: ファームウェアを最新の状態に保つ (セキュリティパッチのため)、アテステーションネットワーキングを管理するなど、小規模なプロジェクトにとっては負担になる可能性があります。すべてのノードが特定の CPU を持つ必要がある場合、それは潜在的なバリデータープールを減らす可能性があります (誰もが必要なハードウェアを持っているわけではありません)。これにより、分散化に影響を与え、おそらくクラウドホスティングの使用率が高くなる可能性があります。
要約すると、TEE は強力な機能を解き放ちますが、信頼のトレードオフ (ハードウェアへの信頼 vs 数学への信頼)、潜在的なセキュリティの弱点 (特にサイドチャネル)、および分散コンテキストでの統合のハードルももたらします。TEE を使用するプロジェクトは、これらの問題に慎重に対処する必要があります。多層防御を採用し (TEE が破られないと仮定しない)、信頼されたコンピューティングベースを最小限に保ち、ユーザーに対して信頼の前提を透明にすること (例えば、ブロックチェーンのコンセンサスに加えて Intel のハードウェアを信頼していることが明確になるように) が必要です。
5. TEE vs 他のプライバシー保護技術 (ZKP, FHE, MPC)
高信頼実行環境は、Web3 でプライバシーとセキュリティを達成するための一つのアプローチですが、ゼロ知識証明 (ZKP)、完全準同型暗号 (FHE)、セキュアマルチパーティ計算 (MPC) を含む他の主要な技術があります。これらの技術はそれぞれ異なる信頼モデルとパフォーマンスプロファイルを持っています。多くの場合、これらは相互に排他的ではなく、互いに補完し合うことができますが、パフォーマンス、信頼、開発者の使いやすさにおけるトレードオフを比較することは有用です:
代替案を簡単に定義すると:
- ZKP: ある当事者が他の当事者に対して、あるステートメントが真であること (例: 「私はこの計算を満たす秘密を知っている」) を、その理由を明らかにすることなく (秘密の入力を隠して) 証明できる暗号学的証明 (zk-SNARKs, zk-STARKs など)。ブロックチェーンでは、ZKP はプライベートなトランザクション (例: Zcash, Aztec) やスケーラビリティ (正しい実行の証明を投稿するロールアップ) に使用されます。強力なプライバシー (秘密データは漏洩せず、証明のみ) と数学によって保証された完全性を確保しますが、これらの証明の生成は計算的に重く、回路を慎重に設計する必要があります。
- FHE: 暗号化されたデータに対して任意の計算を可能にする暗号化スキームで、その結果を復号すると、平文で計算した結果と一致します。理論上、FHE は 究極のプライバシーを提供します (データは常に暗号化されたまま)。そして、生のデータを誰かに信頼する必要はありません。しかし、FHE は一般的な計算には非常に遅く (研究によって改善されていますが)、パフォーマンスのためにまだほとんどが実験的または専門的な使用にとどまっています。
- MPC: 複数の当事者が、お互いに自分のプライベートな入力を明かすことなく、それらの入力に対する関数を共同で計算するプロトコル。多くの場合、当事者間でデータを秘密分散し、暗号操作を実行することで、出力は正しいが個々の入力は隠されたままになります。MPC は信頼を分散させることができ (単一の点がすべてのデータを見ることはない)、特定の操作には効率的ですが、通常は通信と調整のオーバーヘッドが発生し、大規模なネットワークでは実装が複雑になる可能性があります。
以下は、主要な違いをまとめた比較表です:
技術 | 信頼モデル | パフォーマンス | データプライバシー | 開発者の使いやすさ |
---|---|---|---|---|
TEE (Intel SGX など) | ハードウェア製造元への信頼 (場合によっては中央集権的なアテステーションサーバー)。チップが安全であると仮定。ハードウェアが侵害されるとセキュリティは破られる。 | ほぼネイティブな実行速度。最小限のオーバーヘッド。リアルタイム計算や大規模なワークロードに適している。スケーラビリティは TEE 対応ノードの可用性に制限される。 | データはエンクレーブ_内_では平文だが、外部に対しては暗号化される。ハードウェアが保持されれば強力な機密性。しかし、エンクレーブが侵害されると秘密が暴露される (追加の数学的保護はない)。 | 中程度の複雑さ。既存のコード/言語 (C, Rust) を再利用し、わずかな変更でエンクレーブで実行できることが多い。これらの技術の中で最も参入障壁が低い。高度な暗号学を学ぶ必要はないが、システムプログラミングと TEE 固有の SDK の知識が必要。 |
ZKP (zk-SNARK/STARK) | 数学的な仮定 (例: 暗号問題の困難性) への信頼、場合によっては信頼されたセットアップ (SNARKs の場合)。実行時に単一の当事者に依存しない。 | 証明の生成は計算的に重い (特に複雑なプログラムの場合)、ネイティブより数桁遅いことが多い。オンチェーンでの検証は速い (数ミリ秒)。証明時間のため、大規模なデータ計算には理想的ではない。スケーラビリティ: 簡潔な検証 (ロールアップ) には良いが、証明者がボトルネック。 | 非常に強力なプライバシー。プライベートな入力を一切明かすことなく正しさを証明できる。最小限の情報 (証明サイズなど) のみが漏洩する。金融プライバシーなどに理想的。 | 高い複雑さ。専門的な言語 (回路、Circom や Noir のような zkDSL) を学び、算術回路の観点で考える必要がある。デバッグは難しい。利用可能な専門家が少ない。 |
FHE | 数学 (格子問題) への信頼。信頼された当事者はいない。暗号化が破られない限りセキュリティは保持される。 | 一般的な使用には非常に遅い。暗号化されたデータに対する操作は、平文 よりも数桁遅い。ハードウェアの改善やより良いアルゴリズムで多少スケーリングしているが、現在ブロックチェーンの文脈でのリアルタイム使用には非現実的。 | 究極のプライバシー。データは計算中も含め、常に暗号化されたままである。パフォーマンスが許せば、機密データ (例: 医療、機関間の分析) に理想的。 | 非常に専門的。開発者は暗号学のバックグラウンドが必要。いくつかのライブラリ (Microsoft SEAL, TFHE など) は存在するが、FHE で任意のプログラムを書くことは困難で回りくどい。まだ dApp の日常的な開発対象ではない。 |
MPC | 複数の当事者間で信頼が分散される。ある閾値の当事者が正直であると仮定 (特定の数を超えた共謀はない)。ハードウェアへの信頼は不要。あまりにも多くが共謀すると信頼は失われる。 | 通信ラウンドのためネイティブより遅いことが多いが、FHE よりは速いことが多い。パフォーマンスは変動する: 単純な操作 (加算、乗算) は効率的だが、複雑なロジックは通信コストが爆発する可能性がある。遅延はネットワーク速度に敏感。シャーディングや部分的な信頼の仮定でスケーラビリティを向上させることができる。 | 仮定が保持されれば強力なプライバシー。単一のノードが入力全体を見ることはない。しかし、出力が公開されたり、当事者が脱落したりすると情報が漏洩する可能性がある (さらに、ZK のような簡潔さはない。プロトコルを再度実行しないと、結果は得られるが簡単に共有できる証明は得られない)。 | 高い複雑さ。各ユースケースにカスタムプロトコルを設計するか、フレームワーク (SPDZ や Partisia の提 供物など) を使用する必要がある。開発者は暗号プロトコルについて考え、しばしば複数のノードの展開を調整する必要がある。ブロックチェーンアプリへの統合は複雑になる可能性がある (オフチェーンのラウンドが必要)。 |
引用: 上記の比較は、Sanders Network の分析などの情報源に基づいています。これらは、TEE が速度と使いやすさで優れているのに対し、ZK と FHE は重い計算を犠牲にして最大限のトラストレス性に焦点を当て、MPC は信頼を分散させるがネットワークのオーバーヘッドを導入することを強調しています。
この表から、いくつかの主要なトレードオフが明らかになります:
-
パフォーマンス: TEE は生の速度と低遅延で大きな利点があります。MPC はしばしば中程度の複雑さをある程度の速度低下で処理でき、ZK は生成は遅いが検証は速く (非同期使用)、FHE は現在、任意のタスクに対してはるかに最も遅いです (ただし、単純な加算/乗算のような限定的な操作には問題ありません)。アプリケーションがリアルタイムの複雑な処理 (インタラクティブなアプリケーション、高頻度の意思決定など) を必要とする場合、TEE またはおそらく MPC (良好な接続を持つ少数の当事者) が今日唯一の実行可能な選択肢です。そのようなシナリオでは、ZK と FHE は遅すぎます。
-
信頼モデル: ZKP と FHE は純粋にトラストレスです (数学のみを信頼)。MPC は信頼を参加者の正直さに関する仮定に移します (これは多くの当事者や経済的インセンティブによって強化できます)。TEE はハードウェアとベンダーに信頼を置きます。これは根本的な違いです: TEE は通常トラストレスなブロックチェーンの世界に_信頼された第三者_ (チップ) を導入します。対照的に、ZK と FHE は分散化の精神によりよく合致しているとしばしば称賛されます。信頼する特別なエンティティはなく、計算の困難性だけです。MPC はその中間に位置します: 信頼は分散化されていますが、排除されてはいません (M ノードのうち N ノードが共謀するとプライバシーは破られます)。したがって、最大限のトラストレス性 (例えば、真に検閲耐性のある分散型システム) のためには、暗号学的ソリューションに傾くかもしれません。一方、多くの実用的なシステムは、Intel が正直であることや、主要なバリデーターのセットが共謀しないことを前提とすることに満足しており、効率の大幅な向上のために少しの信頼をトレードしています。
-
セキュリティ/脆弱性: TEE は、議論したように、ハードウェアのバグやサイドチャネルによって損なわれる可能性があります。ZK と FHE のセキュリティは、基礎となる数学 (例えば、楕円曲線や格子問題) が破られると損なわれる可能性がありますが、それらはよく研究された問題であり、攻撃はおそらく気づかれるでしょう (また、パラメータの選択は既知のリスクを軽減できます)。MPC のセキュリティは、プロトコルがそのように設計されていない場合、アクティブな敵によって破られる可能性があります (一部の MPC プロトコルは「正直だが好奇心旺盛な」参加者を想定しており、誰かが完全に不正行為をすると失敗する可能性があります)。ブロックチェーンの文脈では、TEE の侵害はより壊滅的である可能性があ ります (パッチが適用されるまで、すべてのエンクレーブベースのコントラクトが危険にさらされる可能性があります)。一方、ZK の暗号学的破壊 (ZK ロールアップで使用されるハッシュ関数の欠陥を発見するなど) も壊滅的である可能性がありますが、より単純な仮定を考えると、一般的には可能性が低いと考えられています。攻撃の表面は非常に異なります: TEE は電力分析のようなことを心配しなければならないのに対し、ZK は数学的なブレークスルーを心配しなければなりません。
-
データプライバシー: FHE と ZK は最も強力なプライバシー保証を提供します。データは暗号学的に保護されたままです。MPC はデータが秘密分散されることを保証するため、単一の当事者はそれを見ることができません (ただし、出力が公開されたり、プロトコルが慎重に設計されていない場合、情報が漏洩する可能性があります)。TEE はデータを外部からプライベートに保ちますが、エンクレーブの_内部_ではデータは復号されます。誰かが何らかの方法でエンクレーブの制御を得ると、データの機密性は失われます。また、TEE は通常、コードがデータに対して何でもできることを許可します (コードが悪意のある場合、サイドチャネルやネットワークを介して誤って漏洩させることを含む)。したがって、TEE はハードウェアだけでなく、エンクレーブの_コード_も信頼する必要があります。対照的に、ZKP は秘密を一切明かすことなくコードのプロパティを証明するため、コードを信頼する必要さえありません (証明されたプロパティを実際に持っていることを超えて)。エンクレーブアプリケーションにログファイルにデータを漏洩させるバグがあった場合、TEE ハードウェアはそれを防ぎませんが、ZK プルーフシステムは意図された証明以外は何も明らかにしません。これはニュアンスです: TEE は外部の敵から保護しますが、エンクレーブプログラム自体のロジックバグからは必ずしも保護しません。一方、ZK の設計はより宣言的なアプローチを強制します (意図されたことだけを正確に証明し、それ以上は何も証明しません)。
-
構成可能性と統合: TEE は既存のシステムにかなり簡単に統合できます。既存のプログラムをエンクレーブに入れ、プログラミングモデルをあまり変更することなくセキュリティ上の利点を得ることができます。ZK と FHE はしばしば、プログラムを回路や制限された形式に書き直す必要があり、これは大変な労力になる可能性があります。例えば、ZK で単純な AI モデルの検証を書くには、それを一連の算術演算と制約に変換する必要があり、これは TEE で TensorFlow を実行して結果を証明するだけとは大きく異なります。MPC も同様に、ユースケースごとにカスタムプロトコルが必要になる場合があります。したがって、開発者の生産性とコストの観点から、TEE は魅力的です。既存のソフトウェアエコシステムを活用できるため (多くのライブラリはわずかな調整でエンクレーブで実行できます)、一部の分野で TEE の採用がより迅速に進んでいるのを見てきました。ZK/MPC は希少な専門的なエンジニアリングの才能を必要とします。しかし、その裏返しとして、TEE はしばしばよりサイロ化されたソリューションを生み出します (そのエンクレーブまたはそのノードのセッ トを信頼する必要があります)。一方、ZK は誰でもオンチェーンでチェックできる証明を提供し、非常に構成可能性が高くなります (どのコントラクトも zk プルーフを検証できます)。したがって、ZK の結果は_ポータブル_です。他の多くのコントラクトやユーザーが信頼を得るために使用できる小さな証明を生成します。TEE の結果は通常、特定のハードウェアに関連付けられたアテステーションの形式で提供され、必ずしも簡潔ではないかもしれません。それらは簡単に共有可能であったり、チェーンに依存しないものではないかもしれません (ただし、結果の署名を投稿し、エンクレーブの公開鍵を知っていればそれを受け入れるようにプログラムされたコントラクトを持つことはできます)。
実際には、ハイブリッドアプローチが見られます: 例えば、Sanders Network は、TEE、MPC、ZK がそれぞれ異なる分野で輝き、互いに補完し合うことができると主張しています。具体的なケースは分散型アイデンティティです: ZK プルーフを使用して、それを明かすことなくアイデンティティ資格情報を証明するかもしれませんが、その資格情報は、あなたの文書をプライベートにチェックした TEE ベースのプロセスによって検証され、発行された可能性があります。あるいはスケーリングを考えてみましょう: ZK ロールアップは多くのトランザクションに対して簡潔な証明を提供しますが、それらの証明の生成は、TEE を使用して一部の計算をより速く行うことで高速化できる可能性があります (そして、より小さなステートメントのみを証明する)。この組み合わせは、TEE に対する信頼要件を減らすことができる場合があります (例: パフォーマンスのために TEE を使用するが、最終的な正しさは ZK プルーフまたはオンチェーンのチャレンジゲームを介して検証し、侵害された TEE が捕まることなく不正行為をできないようにする)。一方、MPC は、各当事者の計算ノードを TEE にすることで TEE と組み合わせることができ、追加のレイヤーを追加することで、一部の当事者が共謀しても、ハードウェアのセキュリティも破らない限り、お互いのデータを見ることができないようにします。
要約すると、TEE はささやかな仮定 (ハードウェアへの信頼) でセキュアな計算への非常に_実用的かつ即時の道_を提供し、一方 ZK と FHE は高い計算コストでより_理論的かつトラストレスな道_を提供し、MPC はネットワークコストを伴う_分散された信頼の道_を提供します。Web3 での正しい選択は、アプリケーションの要件に依存します:
- プライベートデータに対する高速で複雑な計算 (AI、大規模データセットなど) が必要な場合、TEE (または少数の当事者による MPC) が現在唯一の実行可能な方法です。
- _最大限の分散化と検証可能性_が必要な場合、ZK プルーフが輝きます (例えば、プライベートな暗号通貨トランザクションは、ユーザーが数学以外何も信頼したくないため、Zcash のように ZKP を好みます)。
- _複数の利害関係者間の協調計算_が必要な場合、MPC が自然に適しています (マルチパーティの鍵管理やオークションなど)。
- _非常に機密性の高いデータがあり、長期的なプライバシーが必須_である場合、パフォーマンスが向上すれば FHE が魅力的にな る可能性があります。なぜなら、数年後に誰かがあなたの暗号文を入手しても、鍵がなければ何も学べないからです。一方、エンクレーブの侵害は、ログが保持されていれば遡って秘密を漏洩させる可能性があります。
ブロックチェーン空間は、これらすべての技術を並行して積極的に探求していることに注意する価値があります。組み合わせが見られる可能性が高いです: 例えば、TEE を統合したレイヤー 2 ソリューションがトランザクションのシーケンシングを行い、その後 ZKP を使用して TEE がルールに従ったことを証明する (一部の Ethereum 研究で探求されている概念)、または各ノードで TEE を使用する MPC ネットワークが MPC プロトコルの複雑さを軽減する (各ノードが内部的に安全であり、複数の当事者をシミュレートできるため)。
最終的に、TEE vs ZK vs MPC vs FHE はゼロサムの選択ではありません。それぞれがセキュリティ、パフォーマンス、トラストレス性の三角形の異なる点をターゲットにしています。ある記事が述べたように、4 つすべてがパフォーマンス、コスト、セキュリティの「不可能な三角形」に直面しており、すべての側面で優れた単一のソリューションはありません。最適な設計は、問題の正しい部分に正しいツールを使用することが多いです。