「プライバシー」タグの記事が5件件あります

Sui 上の Seal: オンチェーンで制御できるプログラマブルなシークレットレイヤー

2025年9月3日 · 約6分

Software Engineer

パブリックブロックチェーンは、すべての参加者に同期された監査可能な元帳を提供しますが、同時にデータをデフォルトで公開します。2025 年 9 月 3 日に Sui Mainnet で稼働を開始した Seal は、オンチェーンのポリシーロジックと分散型キー管理を組み合わせることで、どのペイロードを誰が復号できるかを開発者が細かく制御できるようにします。

TL;DR

概要: Seal は、Sui スマートコントラクトがオンチェーンで復号ポリシーを強制し、クライアントはアイデンティティベース暗号（IBE）でデータを暗号化し、しきい値キーサーバーから鍵を取得できるようにするシークレット管理ネットワークです。
重要な理由: 独自バックエンドやブラックボックスなオフチェーンスクリプトを作るのではなく、プライバシーとアクセス制御を一級の Move プリミティブとして扱えます。暗号文はどこにでも保存でき（Walrus との組み合わせが自然）、誰が読むかを制御し続けられます。
想定ユーザー: トークンゲートされたコンテンツ、タイムロック公開、プライベートメッセージング、ポリシー対応 AI エージェントを構築するチームは、Seal の SDK を組み込むだけで暗号の下回りではなくプロダクトロジックに集中できます。

ポリシーロジックは Move に記述

Seal のパッケージには seal_approve* という Move 関数が用意されており、特定のアイデンティティ文字列に対して誰がどの条件で鍵を要求できるかを定義します。ポリシーには NFT 所有、許可リスト、タイムロック、独自のロールシステムを組み合わせられます。ユーザーやエージェントが復号を要求すると、キーサーバーは Sui フルノードの状態を参照してポリシーを評価し、チェーンが承認した場合にのみ応答します。

アクセスルールはパッケージ内のオンチェーンコードとして存在するため、透明で監査可能、かつ他のスマートコントラクトコードと同じようにバージョン管理できます。ガバナンスの更新も、コミュニティレビューとオンチェーン履歴を伴いながら、通常の Move アップグレードと同様に展開できます。

しきい値暗号が鍵管理を担う

Seal はアプリケーションが定義するアイデンティティに対してデータを暗号化します。開発者が選定した独立したキーサーバー委員会が IBE のマスターシークレットを共有します。ポリシーチェックを通過すると、各サーバーが要求されたアイデンティティの鍵シェアを導出します。t 台のサーバーから応答が集まると、クライアントはそれらを結合して復号に使える鍵を得ます。

委員会メンバー（Ruby Nodes、NodeInfra、Overclock、Studio Mirai、H2O Nodes、Triton One、Mysten の Enoki サービスなど）としきい値を選ぶことで、可用性と機密性のトレードオフを調整できます。可用性を重視するなら、大きな委員会と低いしきい値を選びましょう。プライバシー保証を高めたいなら、クォーラムを厳しく設定し、パーミッション型プロバイダーを活用してください。

開発者体験: SDK とセッションキー

Seal には暗号化・復号フロー、アイデンティティの整形、バッチ処理を支援する TypeScript SDK（npm i @mysten/seal）が用意されています。アプリが繰り返しアクセスする必要がある場合でもウォレットに承認要求を連発しないよう、セッションキーの発行もサポートしています。高度なワークフローでは、Move コントラクトが専用モードでオンチェーン復号を要求できるため、エスクロー開示や MEV 耐性オークションなどのロジックをスマートコントラクト内で直接実行できます。

Seal はストレージに依存しないため、Walrus と組み合わせて検証可能な BLOB ストレージを実現したり、IPFS や運用上必要な場合は中央集権型ストアとも併用したりできます。暗号化の境界とポリシーの適用は、暗号文がどこに存在してもデータとともに移動します。

Seal を設計に組み込むためのベストプラクティス

可用性リスクをモデリングする: 2-of-3 や 3-of-5 などのしきい値は、そのまま稼働率保証に直結します。本番導入ではプロバイダーを組み合わせ、テレメトリを監視し、重要なワークフローを任せる前に SLA を取り決めましょう。
状態のばらつきに注意: ポリシー評価はフルノードの dry_run 呼び出しに依存します。急速に変化するカウンターやチェックポイント内の順序に依存するルールは避け、サーバー間で不一致の承認が出ないようにしてください。
鍵の衛生管理を計画する: 導出された鍵はクライアント側に保存されます。ログを整備し、セッションキーをローテーションし、必要に応じてエンベロープ暗号化（Seal で大きなペイロードを暗号化する対称鍵を保護）を採用して、端末侵害時の影響範囲を限定しましょう。
ローテーションを設計する: 暗号文の委員会構成は暗号化時点で固定されます。プロバイダーを変更したり信頼モデルを調整したりする必要がある場合に備えて、データを新しい委員会で再暗号化するアップグレード経路を用意しましょう。

今後の展望

Seal のロードマップには、バリデータが運用する MPC サーバー、DRM スタイルのクライアントツール、ポスト量子 KEM などが示されています。AI エージェント、プレミアムコンテンツ、規制対象データフローを検討するビルダーにとって、今回のリリースだけでも十分な設計図が得られます。Move でポリシーを記述し、多様なキー委員会を組み合わせ、Sui の信頼境界内でユーザープライバシーを尊重する暗号化体験を提供しましょう。

次回のローンチで Seal の採用を検討しているなら、まずは 2-of-3 のオープン委員会を使ったシンプルな NFT ゲートポリシーを試作し、アプリのリスクプロファイルに合ったプロバイダー構成と運用コントロールへとブラッシュアップしていくのがおすすめです。

Web3 エコシステムにおける高信頼実行環境 (TEE) の徹底解説

2025年5月17日 · 約102分

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 つすべてがパフォーマンス、コスト、セキュリティの「不可能な三角形」に直面しており、すべての側面で優れた単一のソリューションはありません。最適な設計は、問題の正しい部分に正しいツールを使用することが多いです。

6. 主要なブロックチェーンエコシステムにおける採用

高信頼実行環境は、異なるブロックチェーンエコシステムでさまざまなレベルの採用が見られます。これは、それらのコミュニティの優先順位や統合の容易さに影響されることが多いです。ここでは、Ethereum、Cosmos、Polkadot などの主要なエコシステムで TEE がどのように使用されているか (または探求されているか) を評価し、その他にも触れます。

Ethereum (および一般的なレイヤー 1)

Ethereum メインネット自体では、TEE はコアプロトコルの一部ではありませんが、アプリケーションやレイヤー 2 で使用されてきました。Ethereum の哲学は暗号学的セキュリティ (例: 新興の ZK ロールアップ) に傾いていますが、TEE は Ethereum のオラクルやオフチェーン実行で役割を見出しています:

オラクルサービス: 議論したように、Chainlink は Town Crier のような TEE ベースのソリューションを組み込んでいます。すべての Chainlink ノードがデフォルトで TEE を使用しているわけではありませんが、追加の信頼が必要なデータフィードにはこの技術が存在します。また、API3 (別のオラクルプロジェクト) は、API を実行し、データの信頼性を保証するために Intel SGX を使用していると述べています。これらのサービスは、より強力な保証を持って Ethereum コントラクトにデータを供給します。
レイヤー 2 とロールアップ: Ethereum コミュニティでは、ロールアップのシーケンサーやバリデーターで TEE を使用することについて、進行中の研究と議論があります。例えば、_ConsenSys の「ZK-Portal」_コンセプトなどは、オプティミスティックロールアップで正しい順序付けを強制したり、シーケンサーを検閲から保護したりするために TEE を使用することを提案しています。私たちが見た Medium の記事では、2025 年までに、高頻度取引の保護などのために、一部の L2 で TEE がデフォルト機能になる可能性があるとさえ示唆しています。Catalyst (高頻度取引 DEX) や Flashbots (MEV リレー用) のようなプロジェクトは、トランザクションがブロックチェーンに到達する前に公正な順序付けを強制するために TEE を検討しています。
エンタープライズ Ethereum: コンソーシアムまたは許可制の Ethereum ネットワークでは、TEE はより広く採用されています。Enterprise Ethereum Alliance の Trusted Compute Framework (TCF) は、基本的に TEE を Ethereum クライアントに統合するための青写真でした。Hyperledger Avalon (旧 EEA TCF) は、Ethereum スマートコントラクトの一部を TEE でオフチェーン実行し、オンチェーンで検証することを可能にします。IBM、Microsoft、iExec などのいくつかの企業がこれに貢献しました。公開 Ethereum ではこれは一般的になっていませんが、プライベートな展開 (例: Quorum や Besu を使用する銀行グループ) では、コンソーシアムメンバーでさえお互いのデータを見ることができず、承認された結果のみを見ることができるように TEE を使用できます。これにより、エンタープライズ環境でのプライバシー要件を満たすことができます。
注目すべきプロジェクト: Ethereum 上で動作する iExec の他に、Enigma (元々は MIT の MPC プロジェクトとして始まり、その後 SGX を使用するように転換し、後に Cosmos 上の Secret Network になりました) のようなプロジェクトがありました。もう一つは、初期の Ethereum の議論における Decentralized Cloud Services (DCS) でした。最近では、OAuth (Oasis Ethereum ParaTime) は、Oasis の TEE バックエンドを使用し、Ethereum 上で決済することで、Solidity コントラクトを機密性を持って実行できるようにします。また、医療データ共有やゲームなどの一部の Ethereum ベースの dApp は、オフチェーンのエンクレーブコンポーネントをコントラクトと対話させることで TEE を実験しています。

したがって、Ethereum の採用はやや間接的です。プロトコルを変更して TEE を要求することはありませんでしたが、必要な人々のために TEE を活用する豊富なオプションサービスと拡張機能があります。重要なことに、Ethereum の研究者は依然として慎重です。「TEE 専用シャード」を作成したり、TEE を深く統合したりする提案は、信頼に関する懸念からコミュニティの懐疑論に直面しています。代わりに、TEE はコアコンポーネントではなく、Ethereum の_「コプロセッサ」_と見なされています。

Cosmos エコシステム

Cosmos エコシステムは、そのモジュラーな SDK と主権チェーンを通じて実験に友好的であり、Secret Network (上記でカバー) は Cosmos での TEE 採用の代表例です。Secret Network は実際には、バリデーターに SGX を義務付けるように変更された、Tendermint コンセンサスを持つ Cosmos SDK チェーンです。これは、主要な Cosmos Hub に次ぐ最も著名な Cosmos ゾーンの一つであり、そのコミュニティでの TEE 技術の重要な採用を示しています。Secret がインターチェーンプライバシー (IBC 接続を通じて、Secret は他の Cosmos チェーンのプライバシーハブとして機能できる) を提供することに成功したことは、L1 での TEE 統合の注目すべきケースです。

もう一つの Cosmos 関連プロジェクトは Oasis Network です (Cosmos SDK 上に構築されていませんが、Tendermint に貢献した同じ人々の何人かによって設計され、モジュラーアーキテクチャという同様の精神を共有しています)。Oasis はスタンドアロンですが、ブリッジなどを介して Cosmos に接続できます。Secret と Oasis の両方は、Cosmos の世界では、TEE を介した_「機能としてのプライバシー」_という考えが、専用ネットワークを保証するのに十分な牽引力を得たことを示しています。

Cosmos には、インターチェーンアプリケーションのための_「プライバシープロバイダー」_という概念さえあります。例えば、あるチェーン上のアプリは、IBC を介して Secret Network 上のコントラクトを呼び出して機密計算を実行し、結果を返すことができます。この構成可能性は現在出現しつつあります。

さらに、Anoma プロジェクト (厳密には Cosmos ではありませんが、相互運用性の意味で関連しています) は、インテント中心のアーキテクチャに TEE を使用することについて話していますが、それはより理論的です。

要するに、Cosmos には少なくとも一つの主要なチェーンが TEE を完全に採用しており (Secret)、他のチェーンがそれと対話していることから、その分野での健全な採用が示されています。Cosmos のモジュール性は、より多くのそのようなチェーンを可能にする可能性があります (例えば、TEE ベースのオラクルやアイデンティティに特化した Cosmos ゾーンを想像することができます)。

Polkadot と Substrate

Polkadot の設計はパラチェーンが専門化することを可能にし、実際に Polkadot はTEE を使用する複数のパラチェーンをホストしています:

Sanders Network: すでに説明済み。TEE ベースの計算クラウドを提供するパラチェーン。Sanders はパラチェーンとして稼働しており、XCMP (クロスチェーンメッセージパッシング) を通じて他のチェーンにサービスを提供しています。例えば、別の Polkadot プロジェクトは、機密タスクを Sanders のワーカーにオフロードし、証明や結果を返すことができます。Sanders のネイティブトークンエコノミクスは TEE ノードの実行を奨励しており、かなりのコミュニティがあり、強力な採用を示しています。
Integritee: TEE を使用してエンタープライズおよびデータプライバシーソリューションに焦点を当てたもう一つのパラチェーン。Integritee は、チームが独自のプライベートサイドチェーン (Teewasms と呼ばれる) を展開することを可能にし、そこでの実行はエンクレーブで行われます。Polkadot のセキュリティにアンカーしながら、企業の機密データ処理などのユースケースをターゲットにしています。
/Root or Crust?: 一部の Polkadot 関連プロジェクトでは、分散型ストレージやランダムビーコンに TEE を使用するというアイデアがありました。例えば、Crust Network (分散型ストレージ) は当初、TEE ベースのストレージ証明を計画していました (後に別の設計に移行しましたが)。そして、Polkadot のランダムパラチェーン (Entropy) は、TEE と VRF を比較検討しました。

Polkadot がオンチェーンガバナンスとアップグレードに依存していることは、パラチェーンが新しい技術を迅速に組み込むことができることを意味します。Sanders と Integritee の両方は、TEE 統合を改善するためのアップグレードを経てきました (新しい SGX 機能のサポートやアテステーション方法の改良など)。Web3 Foundation はまた、SubstraTEE (オンチェーン検証を伴う TEE でのオフチェーンコントラクト実行を披露した初期のプロトタイプ) のような Substrate ベースの TEE プロジェクトの初期の取り組みに資金を提供しました。

したがって、Polkadot エコシステムは、複数の独立したチームが TEE 技術に賭けていることを示しており、肯定的な採用傾向を示しています。「機密スマートコントラクトやオフチェーン計算が必要な場合は、そのためのパラチェーンがあります」というのが Polkadot のセールスポイントになりつつあります。

その他のエコシステムと一般的な採用

エンタープライズとコンソーシアム: 公開暗号通貨の外では、Hyperledger とエンタープライズチェーンは、許可制の設定で TEE を着実に採用しています。例えば、バーゼル銀行監督委員会は、TEE ベースの貿易金融ブロックチェーンをテストしました。一般的なパターンは次のとおりです: プライバシーやデータの機密性が必須であり、参加者が既知である場合 (そのため、彼らは集合的にハードウェアセキュアモジュールに投資するかもしれません)、TEE は快適な居場所を見つけます。これらは暗号ニュースの見出しにはならないかもしれませんが、サプライチェーン、銀行コンソーシアム、医療データ共有ネットワークなどのセクターでは、TEE はしばしば頼りになる選択肢です (第三者を信頼するか、重い暗号技術を使用するかの代替として)。
Ethereum 以外のレイヤー 1: いくつかの新しい L1 は TEE を試みています。NEAR Protocol は、プライベートコントラクトのための TEE ベースのシャードの初期コンセプトを持っていました (まだ実装されていません)。Celo は、ライトクライアントの証明に TEE を検討しました (彼らの Plumo プルーフは現在 snark に依存していますが、モバイル用のチェーンデータを圧縮するために SGX を検討したことがあります)。Concordium は、規制されたプライバシー L1 であり、匿名性のために ZK を使用していますが、アイデンティティ検証のために TEE も探求しています。Dfinity/Internet Computer は、ノードマシンでセキュアエンクレーブを使用していますが、信頼のブートストラップのためであり、コントラクト実行のためではありません (彼らの「Chain Key」暗号技術がそれを処理します)。
Bitcoin: Bitcoin 自体は TEE を使用していませんが、サイドプロジェクトがありました。例えば、Bitcoin キーのためのTEE ベースのカストディソリューション (Vault システムなど) や、TEE で保護されたオラクルを使用する可能性のある DLC (Discrete Log Contracts) の特定の提案などです。一般的に、Bitcoin コミュニティはより保守的であり、コンセンサスの一部として Intel を簡単に信頼することはありませんが、補助的な技術として (セキュアエレメントを備えたハードウェアウォレット) はすでに受け入れられています。
規制当局と政府: 採用の興味深い側面: 一部の CBDC (中央銀行デジタル通貨) 研究は、監査可能性を許容しながらプライバシーを強制するために TEE を検討しています。例えば、フランス銀行は、TEE を使用して、そうでなければプライベートなトランザクションに対して特定のコンプライアンスチェックを処理する実験を行いました。これは、規制当局でさえ、TEE をプライバシーと監督のバランスを取る方法と見なしていることを示しています。トランザクションが一般に公開されずに暗号化されているが、規制当局のエンクレーブが特定の条件下でそれらをレビューできる CBDC を持つことができます (これは仮説ですが、政策サークルで議論されています)。
採用指標: 採用を定量化するのは難しいですが、プロジェクト数、投資額、インフラの可用性などの指標を見ることができます。その点では、今日 (2025 年)、TEE を明示的に使用している少なくとも 3〜4 の公開チェーン (Secret, Oasis, Sanders, Integritee, オフチェーンとしての Automata) があります。主要なオラクルネットワークがそれを組み込んでいます。大手テクノロジー企業が機密コンピューティングを支援しています (Microsoft Azure, Google Cloud は TEE VM を提供しており、これらのサービスはブロックチェーンノードのオプションとして使用されています)。Confidential Computing Consortium には現在、ブロックチェーンに焦点を当てたメンバー (Ethereum Foundation, Chainlink, Fortanix など) が含まれており、業界横断的な協力が示されています。これらすべては、成長しているがニッチな採用を指しています。TEE はまだ Web3 でユビキタスではありませんが、プライバシーとセキュアなオフチェーン計算が必要な重要なニッチを切り開いています。

7. ビジネスおよび規制上の考慮事項

ブロックチェーンアプリケーションにおける TEE の使用は、利害関係者が考慮しなければならないいくつかのビジネスおよび規制上の点を提起します:

プライバシーコンプライアンスと機関投資家の採用

TEE 採用のビジネスドライバーの一つは、ブロックチェーン技術を活用しながらデータプライバシー規制 (ヨーロッパの GDPR、米国の健康データに関する HIPAA など) に準拠する必要性です。公開ブロックチェーンはデフォルトでデータをグローバルにブロードキャストするため、機密性の高い個人データを保護する必要がある規制と矛盾します。TEE は、データをオンチェーンで機密に保ち、制御された方法でのみ共有する方法を提供するため、コンプライアンスを可能にします。指摘されているように、「TEE は、機密性の高いユーザーデータを分離し、安全に処理されることを保証することで、データプライバシー規制への準拠を促進します」。この能力は、企業や機関を Web3 に引き込む上で不可欠です。なぜなら、彼らは法律違反のリスクを冒すことができないからです。例えば、患者情報を処理するヘルスケア dApp は、生の患者データがオンチェーンに漏洩しないように TEE を使用でき、HIPAA の暗号化とアクセス制御の要件を満たすことができます。同様に、ヨーロッパの銀行は、顧客の個人情報を公開することなく資産をトークン化して取引するために TEE ベースのチェーンを使用でき、GDPR に準拠できます。

これには肯定的な規制上の側面があります: 一部の規制当局は、TEE (および関連するコンフィデンシャルコンピューティングの概念) のようなソリューションが、プライバシーの技術的な強制を提供するため好ましいと示唆しています。世界経済フォーラムなどが、TEE をブロックチェーンシステムに_「プライバシー・バイ・デザイン」_を組み込む手段として強調しているのを見てきました (本質的に、プロトコルレベルでコンプライアンスを埋め込む)。したがって、ビジネスの観点から、TEE は主要なブロッカーの一つ (データの機密性) を取り除くことで、機関投資家の採用を加速させることができます。企業は、データのハードウェアによる保護があることを知っていれば、ブロックチェーンを使用したり、その上に構築したりすることに、より意欲的になります。

もう一つのコンプライアンスの側面は、監査可能性と監督です。企業はしばしば監査ログと、データを管理していることを監査人に証明する能力を必要とします。TEE は、アテステーションレポートとアクセスされた内容のセキュアなログを生成することで、実際にここで役立ちます。例えば、Oasis のエンクレーブ内の「永続ロギング」は、機密操作の改ざん耐性のあるログを提供します。企業はそのログを規制当局に見せて、例えば、承認されたコードのみが実行され、顧客データに対して特定のクエリのみが行われたことを証明できます。この種の_証明された監査_は、システム管理者のログを信頼する従来のシステムよりも規制当局を満足させる可能性があります。

信頼と責任

一方、TEE を導入することは、信頼構造を変え、したがってブロックチェーンソリューションにおける責任モデルも変えます。DeFi プラットフォームが TEE を使用し、ハードウェアの欠陥のために何か問題が発生した場合、誰が責任を負うのでしょうか？例えば、Intel SGX のバグが秘密のスワップトランザクションの詳細の漏洩につながり、ユーザーがお金を失う (フロントランなど) シナリオを考えてみましょう。ユーザーはプラットフォームのセキュリティ主張を信頼していました。プラットフォームに過失があるのか、それとも Intel の過失なのか？法的には、ユーザーはプラットフォームを訴えるかもしれません (プラットフォームは、今度は Intel を訴えなければならないかもしれません)。これは、セキュリティモデルに_第三者の技術プロバイダー_ (CPU ベンダー) が深く関わっているため、事態を複雑にします。TEE を使用する企業は、契約やリスク評価でこれを考慮する必要があります。重要なインフラで TEE を使用する場合、ハードウェアベンダーからの保証やサポートを求めるかもしれません。

また、中央集権化の懸念もあります: ブロックチェーンのセキュリティが単一企業のハードウェア (Intel または AMD) に依存している場合、規制当局はそれを懐疑的に見るかもしれません。例えば、政府はその企業に特定のエンクレーブを侵害するように召喚または強制することができるでしょうか？これは純粋に理論的な懸念ではありません。輸出管理法を考えてみてください: 高度な暗号化ハードウェアは規制の対象となる可能性があります。暗号インフラの大部分が TEE に依存している場合、政府がバックドアを挿入しようと試みることは考えられます (その証拠はありませんが、_認識_が重要です)。一部のプライバシー擁護者は、TEE が信頼を集中させ、むしろ規制当局はそれらを慎重に審査すべきだと規制当局に指摘しています。逆に、より多くの管理を望む規制当局は、ZK のような数学ベースのプライバシーよりも TEE を_好む_かもしれません。なぜなら、TEE には、法執行機関が絶対に必要であれば (例えば、マスターアテステーションキーなどを取得するために) ハードウェアベンダーに裁判所命令を持ってアプローチできるという概念が少なくともあるからです。これは簡単でも可能性が高いわけでもありませんが、ZK には存在しない道です。したがって、規制当局の受け止め方は分かれる可能性があります: プライバシー規制当局 (データ保護機関) はコンプライアンスのために TEE に賛成ですが、法執行機関は、TEE が強力な暗号化のように「闇に紛れる」わけではないため、慎重に楽観的かもしれません。彼らが引こうとするかもしれない理論的なレバー (ハードウェア) があります。

企業は、認証に参加することでこれを乗り切る必要があります。ハードウェアモジュールには、FIPS 140 や Common Criteria のようなセキュリティ認証があります。現在、SGX などにはいくつかの認証があります (例えば、SGX は特定の用途で Common Criteria EAL のものを取得していました)。ブロックチェーンプラットフォームが、エンクレーブ技術が高い基準で認証されていることを示せれば、規制当局やパートナーはより安心するかもしれません。例えば、CBDC プロジェクトは、使用される TEE が FIPS 認証されていることを要求するかもしれません。そうすれば、その乱数生成などを信頼できます。これは追加のプロセスを導入し、特定のハードウェアバージョンに制限する可能性があります。

エコシステムとコストの考慮事項

ビジネスの観点から、TEE を使用することは、ブロックチェーン運用のコスト構造に影響を与える可能性があります。ノードは特定の CPU を持っている必要があり (より高価であったり、エネルギー効率が低かったりする可能性があります)。これは、クラウドホスティングの請求額が高くなったり、設備投資が増えたりすることを意味する可能性があります。例えば、プロジェクトがすべてのバリデーターに SGX を搭載した Intel Xeon を義務付ける場合、それは制約です。バリデーターは Raspberry Pi や古いラップトップを持っているだけではだめで、そのハードウェアが必要です。これは、誰が参加できるかを中央集権化する可能性があります (おそらく、ハイエンドサーバーを購入できる人々や、SGX VM を提供するクラウドプロバイダーを使用する人々を優遇します)。極端な場合、ネットワークをより許可制にしたり、クラウドプロバイダーに依存させたりする可能性があり、これは分散化のトレードオフであり、ビジネスのトレードオフでもあります (ネットワークはノードプロバイダーに補助金を出さなければならないかもしれません)。

一方、一部の企業は、既知のバリデーターを_望んでいる_か、許可リストを持っているため (特にエンタープライズコンソーシアムで)、これを受け入れられるかもしれません。しかし、公開暗号ネットワークでは、これは議論を引き起こしました。例えば、SGX が必要とされたとき、人々は「これは大規模なデータセンターだけがノードを実行することを意味するのか？」と尋ねました。これはコミュニティの感情に影響を与え、したがって市場の採用にも影響します。例えば、一部の暗号純粋主義者は、TEE を必要とするチェーンを「信頼性が低い」または中央集権的すぎるとレッテルを貼り、避けるかもしれません。そのため、プロジェクトは PR とコミュニティ教育を処理し、信頼の前提が何であるか、そしてなぜそれがまだ安全であるかを明確にする必要があります。Secret Network が、Intel の更新の厳格な監視と、エンクレーブを更新しないバリデーターはスラッシュされることなどを説明することで FUD に対処しているのを見ました。基本的には、ハードウェアの信頼の上に社会的な信頼の層を築いています。

もう一つの考慮事項は、パートナーシップとサポートです。TEE を取り巻くビジネスエコシステムには、大手テクノロジー企業 (Intel, AMD, ARM, Microsoft, Google など) が含まれます。TEE を使用するブロックチェーンプロジェクトは、しばしばこれらと提携します (例: iExec と Intel の提携、Secret Network と Intel のアテステーション改善に関する協力、Oasis と Microsoft の機密 AI に関する協力など)。これらのパートナーシップは、資金、技術支援、信頼性を提供できます。これは戦略的な点です: 機密コンピューティング業界と連携することは、(資金調達やエンタープライズパイロットの) 扉を開くことができますが、暗号プロジェクトが大手企業と連携することを意味し、コミュニティにイデオロギー的な影響を与えます。

規制の不確実性

TEE を使用するブロックチェーンアプリケーションが成長するにつれて、新たな規制上の問題が生じる可能性があります。例えば:

データ管轄権: データが特定の国の TEE 内で処理される場合、それは「その国で処理された」と見なされるのか、それともどこでもない (暗号化されているため) と見なされるのか？一部のプライバシー法は、市民のデータが特定の地域を離れないことを要求しています。TEE は境界線を曖昧にする可能性があります。クラウドリージョンにエンクレーブがあるかもしれませんが、暗号化されたデータのみが出入りします。規制当局は、そのような処理をどのように見るかを明確にする必要があるかもしれません。
輸出規制: 高度な暗号化技術は輸出規制の対象となる可能性があります。TEE はメモリの暗号化を伴います。歴史的にこれは問題ではありませんでしたが (これらの機能を備えた CPU は世界中で販売されているため)、もしそれが変われば、供給に影響を与える可能性があります。また、一部の国は、国家安全保障上の理由から外国の TEE の使用を禁止または推奨しないかもしれません (例: 中国は Intel を信頼していないため、SGX に相当する独自のものを持ち、機密用途に SGX を許可しないかもしれません)。
法的強制: シナリオ: 政府はノードオペレーターにエンクレーブからデータを抽出するように召喚できるでしょうか？通常はできません。なぜなら、オペレーターでさえ内部を見ることができないからです。しかし、もし彼らが特定のアテステーションキーのために Intel を召喚したらどうでしょうか？ Intel の設計は、彼らでさえエンクレーブのメモリを復号できないようになっています (彼らは CPU にキーを発行し、CPU が作業を行います)。しかし、もしバックドアが存在したり、メモリをダンプするために Intel が署名できる特別なファームウェアがあったりすれば、それは人々を懸念させる仮説です。法的には、Intel のような企業は、セキュリティを損なうように求められた場合、拒否するかもしれません (製品への信頼を破壊しないために、おそらくそうするでしょう)。しかし、その可能性だけで、合法的なアクセスに関する規制上の議論に現れるかもしれません。TEE を使用する企業は、そのような動向に注意を払う必要がありますが、現在、Intel/AMD がエンクレーブデータを抽出するための公開メカニズムは存在しません。それが TEE のポイントです。

市場の差別化と新しいサービス

ビジネスにとっての肯定的な側面として、TEE は収益化できる新しい製品とサービスを可能にします。例えば:

機密データマーケットプレイス: iExec や Ocean Protocol などが指摘しているように、企業は漏洩しないという保証があれば収益化できる貴重なデータを保持しています。TEE は、データがエンクレーブから出ることなく、インサイトのみが出力される「データレンタル」を可能にします。これにより、新しい収益源とビジネスモデルが生まれる可能性があります。Web3 のスタートアップが、企業に機密計算サービスを提供しているのを見ます。本質的に、「何も公開せずにブロックチェーンや企業間のデータからインサイトを得る」というアイデアを販売しています。
エンタープライズ DeFi: 金融機関はしばしば、DeFi や公開ブロックチェーンに関与しない理由としてプライバシーの欠如を挙げます。もし TEE が彼らのポジションや取引のプライバシーを保証できるなら、彼らは参加するかもしれず、エコシステムにより多くの流動性とビジネスをもたらすでしょう。これに対応するプロジェクト (Secret のシークレットローンや、コンプライアンス管理を備えた Oasis のプライベート AMM など) は、機関投資家を引き付けるように位置づけられています。成功すれば、それは大きな市場になる可能性があります (アイデンティティと金額は保護されているが、エンクレーブが AML のようなコンプライアンスチェックを内部で行うことを保証する機関投資家向け AMM プールを想像してみてください。それは、規制当局の安心のもとで DeFi に大きなお金をもたらす可能性のある製品です)。
保険とリスク管理: TEE が特定のリスク (オラクルの操作など) を軽減することで、スマートコントラクトプラットフォームの保険料が下がったり、新しい保険商品が登場したりするかもしれません。逆に、TEE は新しいリスク (エンクレーブの技術的障害など) をもたらし、それ自体が保険対象のイベントになる可能性があります。暗号保険の分野が芽生えています。彼らが TEE 依存のシステムをどのように扱うかは興味深いでしょう。プラットフォームは、データ侵害のリスクを低減するために TEE を使用していることをマーケティングし、それによって保険をかけやすく/安くし、競争上の優位性を与えるかもしれません。

結論として、TEE 対応の Web3 のビジネスおよび規制の状況は、信頼とイノベーションのバランスを取ることです。TEE は法律を遵守し、エンタープライズのユースケースを解き放つ道を提供しますが (主流の採用にとって大きなプラス)、ハードウェアプロバイダーへの依存と、透明に管理されなければならない複雑さももたらします。利害関係者は、TEE の可能性を完全に実現するために、テクノロジー大手 (サポートのため) と規制当局 (明確さと保証のため) の両方と関わる必要があります。うまく行けば、TEE は、ブロックチェーンが機密データを扱う業界と深く統合することを可能にする礎となり、それによって Web3 の範囲を、以前はプライバシーの懸念から立ち入り禁止だった分野に拡大する可能性があります。

結論

高信頼実行環境は、Web3 のツールボックスにおける強力なコンポーネントとして登場し、機密性と安全なオフチェーン計算を必要とする新しいクラスの分散アプリケーションを可能にしました。Intel SGX、ARM TrustZone、AMD SEV のような TEE は、計算のためのハードウェアで分離された「安全な箱」を提供し、この特性はプライバシー保護スマートコントラクト、検証可能なオラクル、スケーラブルなオフチェーン処理などに活用されてきました。Cosmos 上の Secret Network のプライベートコントラクトから、Oasis の機密 ParaTime、Polkadot 上の Sanders の TEE クラウド、Ethereum 上の iExec のオフチェーンマーケットプレイスまで、エコシステム全体のプロジェクトは、TEE がブロックチェーンプラットフォームに統合される多様な方法を示しています。

技術的には、TEE は速度と強力なデータ機密性という魅力的な利点を提供しますが、独自の課題も伴います: ハードウェアベンダーを信頼する必要性、潜在的なサイドチャネルの脆弱性、統合と構成可能性におけるハードルです。私たちは TEE を暗号学的代替手段 (ZKP, FHE, MPC) と比較し、それぞれにニッチがあることを見出しました: TEE はパフォーマンスと使いやすさで輝き、一方 ZK と FHE は高いコストで最大限のトラストレス性を提供し、MPC は参加者間で信頼を分散させます。実際、多くの最先端のソリューションはハイブリッドであり、両方の世界の長所を得るために暗号学的手法と並行して TEE を使用しています。

TEE ベースのソリューションの採用は着実に増加しています。Ethereum の dApp はオラクルのセキュリティとプライベートな計算のために TEE を活用し、Cosmos と Polkadot は専門のチェーンを介してネイティブサポートを持ち、エンタープライズブロックチェーンの取り組みはコンプライアンスのために TEE を採用しています。ビジネス的には、TEE は分散型技術と規制の間の架け橋となり得ます。機密データをハードウェアセキュリティの保護下でオンチェーンで処理できるようにし、機関投資家の利用と新しいサービスの扉を開きます。同時に、TEE を使用することは、新しい信頼のパラダイムに関与し、ブロックチェーンの分散化の精神が不透明なシリコンによって損なわれないようにすることを意味します。

要約すると、高信頼実行環境は Web3 の進化において重要な役割を果たしています: プライバシーとスケーラビリティという最も差し迫った懸念のいくつかに対応し、万能薬ではなく (そして論争がないわけでもありませんが)、分散アプリケーションができることを大幅に拡大します。技術が成熟し (ハードウェアセキュリティの改善とアテステーションの標準化により)、より多くのプロジェクトがその価値を実証するにつれて、TEE は (補完的な暗号技術と共に) Web3 の可能性を安全かつ信頼できる方法で最大限に引き出すことを目指すブロックチェーンアーキテクチャの標準コンポーネントになることが期待できます。未来は、ハードウェアと暗号技術が連携して、パフォーマンスが高く、証明可能に安全なシステムを提供し、ユーザー、開発者、規制当局のニーズを満たす階層化されたソリューションを保持している可能性が高いです。

情報源: このレポートの情報は、公式プロジェクトのドキュメントやブログ、業界分析、学術研究など、本文全体で引用されているさまざまな最新の情報源から収集されました。注目すべき参考文献には、Web3 における TEE に関する Metaschool 2025 ガイド、Sanders Network による比較、FHE/TEE/ZKP/MPC に関する ChainCatcher などからの技術的洞察、Binance Research などからの規制コンプライアンスに関する声明が含まれます。これらの情報源は、さらなる詳細を提供しており、特定の側面をより深く探求したい読者にお勧めします。

ブロックチェーンにおけるプログラマブルプライバシー：オフチェーン計算とオンチェーン検証

2025年4月27日 · 約71分

Dora Noda

Software Engineer

パブリックブロックチェーンは、プライバシーを犠牲にすることで透明性と完全性を提供します。つまり、すべてのトランザクションとコントラクトの状態が全参加者に公開されます。この公開性は、MEV (マイナー抽出可能価値) 攻撃、コピートレーディング、機密性の高いビジネスロジックの漏洩といった問題を引き起こします。プログラマブルプライバシーは、データ自体を明らかにすることなくプライベートデータに対する計算を可能にすることで、これらの問題を解決することを目指しています。これを可能にしているのが、2つの新しい暗号技術パラダイム、完全準同型暗号仮想マシン (FHE-VM) と ゼロ知識 (ZK) コプロセッサです。これらのアプローチは、オフチェーンまたは暗号化された計算とオンチェーン検証を可能にし、トラストレスな正当性を維持しながら機密性を保護します。本レポートでは、FHE-VM と ZK コプロセッサのアーキテクチャを深く掘り下げ、それらのトレードオフを比較し、金融、アイデンティティ、ヘルスケア、データ市場、分散型機械学習にわたるユースケースを探ります。

完全準同型暗号仮想マシン (FHE-VM)

完全準同型暗号 (FHE) は、暗号化されたデータを一度も復号することなく、その上で任意の計算を行うことを可能にします。FHE 仮想マシンは、この機能をブロックチェーンのスマートコントラクトに統合し、暗号化されたコントラクトの状態とロジックを可能にします。FHE 対応のブロックチェーン (EVM 互換の設計ではしばしば fhEVM と呼ばれます) では、すべての入力、コントラクトのストレージ、および出力が実行中ずっと暗号化されたままです。これは、バリデーターが機密性の高い値を一切知ることなくトランザクションを処理し、状態を更新できることを意味し、データ機密性を伴うオンチェーン実行を実現します。

FHE-VM のアーキテクチャと設計

典型的な FHE-VM は、標準的なスマートコントラクトのランタイム (イーサリアム仮想マシンのような) を拡張し、暗号化データ型と操作のネイティブサポートを追加します。例えば、Zama の FHEVM は、暗号化された整数 (euint8, euint32 など)、暗号化されたブール値 (ebool)、さらには暗号化された配列を第一級の型として導入します。Solidity のようなスマートコントラクト言語は、ライブラリや新しいオペコードを介して拡張され、開発者は算術演算 (add, mul など)、論理演算、比較を暗号文上で直接実行できます。内部では、これらの操作は FHE プリミティブ (例えば TFHE ライブラリを使用) を呼び出し、暗号化されたビットを操作して暗号化された結果を生成します。

暗号化された状態ストレージがサポートされているため、コントラクト変数はブロックチェーンの状態で暗号化されたままです。実行フローは通常次のようになります：

クライアントサイドでの暗号化: ユーザーはトランザクションを送信する前に、公開 FHE 鍵を使用してローカルで入力を暗号化します。暗号化鍵は公開 (暗号化と評価用) ですが、復号鍵は秘密のままです。一部の設計では、各ユーザーが自身の鍵を管理しますが、他の設計では、単一のグローバル FHE 鍵が使用されます (後述)。
オンチェーンでの準同型計算: マイナー/バリデーターは、暗号化されたオペコードでコントラクトを実行します。彼らは暗号文に対して同じ決定論的な準同型操作を実行するため、暗号化された新しい状態についてコンセンサスに達することができます。重要なのは、バリデーターは平文データを一切見ないことです。彼らは「意味不明な」暗号文を見るだけですが、それでも一貫して処理できます。
復号 (任意): 結果を公開したりオフチェーンで使用したりする必要がある場合、秘密鍵を持つ承認された当事者が出力の暗号文を復号できます。それ以外の場合、結果は暗号化されたままであり、後続のトランザクションの入力として使用できます (永続的な暗号化状態での連続計算を可能にします)。

主要な設計上の考慮事項は鍵管理です。一つのアプローチはユーザーごとの鍵で、各ユーザーが自身の秘密鍵を保持し、自分に関連する出力のみを復号できます。これはプライバシーを最大化しますが (他の誰もあなたのデータを復号できません)、複雑なマルチキープロトコルなしでは、異なる鍵で暗号化されたデータを準同型操作で混合することはできません。Zama の FHEVM で使用されている別のアプローチは、グローバル FHE 鍵です。単一の公開鍵がすべてのコントラクトデータを暗号化し、分散されたバリデーターのセットが閾値復号鍵のシェアを保持します。公開の暗号化鍵と評価鍵はオンチェーンで公開されるため、誰でもネットワークにデータを暗号化できます。秘密鍵はバリデーター間で分割され、閾値スキームの下で必要に応じて集合的に復号できます。バリデーターの共謀によるプライバシー侵害を防ぐため、Zama は「ノイズフラッディング」を伴う閾値 FHE プロトコル (彼らの Noah’s Ark 研究に基づく) を採用し、部分的な復号を安全にしています。十分な数のバリデーターが協力した場合にのみ、例えば読み取りリクエストに応えるために平文を回復できます。しかし、通常の操作では、単一のノードが平文を見ることは決してありません。データは常にオンチェーンで暗号化されたままです。

アクセス制御も重要な要素です。FHE-VM の実装には、誰が (もしいるなら) 復号をトリガーしたり、特定の暗号化フィールドにアクセスしたりできるかを管理するためのきめ細かい制御が含まれています。例えば、Cypher の fhEVM は暗号文に対するアクセス制御リストをサポートしており、開発者はどのアドレスやコントラクトが特定のデータと対話したり、再暗号化したりできるかを指定できます。一部のフレームワークは再暗号化をサポートしています。これは、平文を公開することなく、暗号化された値をあるユーザーの鍵から別のユーザーの鍵へ転送する機能です。これはデータマーケットプレイスのようなものに便利で、データ所有者は自分の鍵でデータセットを暗号化し、購入時に購入者の鍵に再暗号化することができます。これらすべてがオンチェーンで行われ、公に復号されることはありません。

正当性とプライバシーの確保

すべてのデータが暗号化されている場合、どのようにしてコントラクトロジックの正当性を強制するのか、と疑問に思うかもしれません。チェーンが値を「見ることができない」場合、どのようにして無効な操作を防ぐのでしょうか？ FHE 自体は正当性の証明を提供しません。バリデーターは準同型ステップを実行できますが、ユーザーの暗号化された入力が有効であったか、条件分岐が取られるべきであったかなどを、復号なしでは本質的に判断できません。ゼロ知識証明 (ZKP) は、このギャップを埋めるために FHE を補完することができます。FHE-VM では、通常、ユーザーは必要に応じて特定の平文条件を証明する ZK 証明を提供する必要があります。例えば、Zama の設計では、各暗号化入力に 平文知識の ZK 証明 (ZKPoK) を添付します。これにより、ユーザーが自身の暗号文に対応する平文を知っており、それが期待される基準を満たしていることを、平文自体を明らかにすることなく証明します。このような**「認証済み暗号文」**は、悪意のあるユーザーが不正な形式の暗号化や範囲外の値を送信するのを防ぎます。同様に、決定が必要な操作 (例: 口座残高 ≥ 引き出し額を確認) の場合、ユーザーは暗号化された操作が実行される前に、この条件が平文で真であることを示す ZK 証明を提供できます。このようにして、チェーンは値を復号したり見たりすることはありませんが、暗号化されたトランザクションがルールに従っているという確信を得ることができます。

FHE ロールアップにおける別のアプローチは、ZKP を用いたオフチェーン検証です。Fhenix (FHE を使用する L2 ロールアップ) は、Threshold Service Network と呼ばれる別のネットワークコンポーネントが暗号化された結果を復号または検証できるオプティミスティックモデルを採用しており、不正な計算は不正証明によって異議を申し立てることができます。一般的に、FHE と ZK または不正証明を組み合わせることで、暗号化された実行が トラストレス であり続けることが保証されます。バリデーターは、承認された場合にのみ集合的に復号するか、各暗号化された状態遷移が平文を見る必要なく有効であったことを証明する証明を検証します。

パフォーマンスに関する考慮事項: FHE 操作は計算負荷が非常に高く、通常の算術演算よりも何桁も遅いです。例えば、イーサリアムでの単純な 64 ビット加算は約 3 ガスかかりますが、Zama の FHEVM で暗号化された 64 ビット整数 (euint64) の加算は約 188,000 ガスかかります。8 ビットの加算でさえ約 94,000 ガスかかることがあります。この莫大なオーバーヘッドは、既存のノードでの単純な実装が非現実的に遅く、高コストになることを意味します。FHE-VM プロジェクトは、最適化された暗号ライブラリ (Zama のバイナリゲートブートストラップ用の TFHE-rs ライブラリなど) やパフォーマンス向上のためのカスタム EVM 修正によってこれに取り組んでいます。例えば、Cypher の修正された Geth クライアントは、新しいオペコードを追加し、C++/アセンブリで準同型命令の実行を最適化してオーバーヘッドを最小限に抑えています。それでも、実用的なスループットを達成するには高速化が必要です。現在進行中の研究には、GPU、FPGA、さらには特殊なフォトニックチップを使用して FHE 計算を高速化することが含まれます。Zama は、2024 年以降、FHE のパフォーマンスが 100 倍向上し、GPU/FPGA の高速化により数千 TPS を目指していると報告しています。専用の FHE コプロセッササーバー (Optalysys の LightLocker Node など) は、バリデーターノードに接続して暗号化操作をハードウェアにオフロードし、ノードあたり毎秒 100 以上の暗号化 ERC-20 転送をサポートできます。ハードウェアとアルゴリズムが改善されるにつれて、FHE と平文計算の間のギャップは狭まり、プライベートコントラクトがより実用的な速度に近づくことが可能になります。

互換性: FHE-VM 設計の重要な目標は、既存の開発ワークフローとの互換性を維持することです。Cypher と Zama の fhEVM 実装では、開発者は最小限の変更で Solidity でコントラクトを書くことができます。ライブラリを使用して暗号化された型と操作を宣言するだけです。イーサリアムのツールチェーン (Remix, Hardhat など) の残りの部分は、基盤となる変更が主にクライアント/ノードレベルであるため、引き続き使用できます。これにより、参入障壁が低くなります。開発者は機密性の高いスマートコントラクトを書くために暗号技術の専門家である必要はありません。例えば、2 つの数値の単純な加算は euint32 c = a + b; と書くことができ、FHEVM が暗号化固有の詳細を裏で処理します。コントラクトは通常のコントラクトと相互運用することもできます。例えば、暗号化されたコントラクトが、必要に応じて復号された結果を標準のコントラクトに出力し、1 つのエコシステム内でプライベート部分とパブリック部分を混在させることができます。

現在の FHE-VM プロジェクト: いくつかのプロジェクトがこの分野を開拓しています。Zama (パリを拠点とする FHE スタートアップ) は、中核となる FHEVM のコンセプトとライブラリ (TFHE-rs と fhevm-solidity ライブラリ) を開発しました。彼らは独自のチェーンを立ち上げるつもりはなく、むしろ他の人にインフラを提供することを目指しています。Inco は、Zama の FHEVM を統合してモジュラーな機密チェーンを作成した L1 ブロックチェーン (Cosmos SDK と Evmos 上に構築) です。彼らのテストネット (Gentry と Paillier という名前) は、暗号化された ERC-20 転送やその他のプライベート DeFi プリミティブを実証しています。Fhenix は、プライバシーのために FHE を使用するイーサリアムのレイヤー 2 オプティミスティックロールアップです。FHE と ZK をすべてのブロックで一緒に行うコストが高いため、ZK ロールアップではなくオプティミスティック (不正証明) アプローチを決定しました。Fhenix は同じ TFHE-rs ライブラリ (いくつかの変更あり) を使用し、分散型の方法で復号を処理するための Threshold Service Network を導入しています。また、Fhenix (現在はリブランド) のような独立したチームや、MPC + FHE ハイブリッドを模索するスタートアップも存在します。さらに、Cypher (by Z1 Labs) は、AI とプライバシーに焦点を当てたレイヤー 3 ネットワークを構築しており、シークレットストアや連合学習サポートなどの機能を備えた fhEVM を使用しています。エコシステムはまだ初期段階ですが、多額の資金調達に支えられて急速に成長しています。例えば、Zama は 2025 年までに 1 億 3000 万ドル以上を調達し、「ユニコーン」企業となり、FHE 技術の進歩を推進しています。

要約すると、FHE-VM は、すべてのロジックをオンチェーンの暗号化データ上で実行することにより、プライバシーを保護するスマートコントラクトを可能にします。このパラダイムは最大限の機密性を保証し (機密性の高いものはトランザクションや状態で公開されることはありません)、既存のブロックチェーンコンセンサスを完全性のために活用します。その代償は、バリデーターの計算負荷の増加と、鍵管理および証明の統合における複雑さです。次に、計算を完全にオフチェーンにオフロードし、チェーンを検証にのみ使用する代替パラダイム、ゼロ知識コプロセッサを探ります。

ゼロ知識コプロセッサ (ZK-Coprocessors)

ZK コプロセッサは、高コストな計算をオフチェーンで実行し、その正当性の簡潔なゼロ知識証明をオンチェーンで検証する新しいブロックチェーンアーキテクチャパターンです。これにより、スマートコントラクトは、トラストレス性を犠牲にすることなく、オンチェーン実行で許容されるよりもはるかに大きな計算能力とデータを活用できます。_コプロセッサ_という用語は、CPU のために特殊なタスクを処理するハードウェアコプロセッサ (数学コプロセッサや GPU など) との類推から使用されています。ここでは、ブロックチェーンの「CPU」(EVM のようなネイティブ VM) が、特定のタスクを暗号コプロセッサとして機能するゼロ知識証明システムに委任します。ZK コプロセッサは、結果とその結果が正しく計算されたことの証明を返し、オンチェーンのコントラクトはそれを検証して使用できます。

アーキテクチャとワークフロー

典型的な設定では、dApp 開発者は、アプリケーションロジックの中でオンチェーン実行にはコストがかかりすぎる、または複雑すぎる部分 (例えば、履歴データに対する大規模な計算、重いアルゴリズム、ML モデルの推論など) を特定します。彼らはそれらの部分を、その実行のゼロ知識証明を生成できるオフチェーンプログラム (高水準言語またはサーキット DSL で) として実装します。オンチェーンコンポーネントは、証明をチェックし、結果をシステムの他の部分で利用可能にする検証者スマートコントラクトです。このフローは次のように要約できます：

リクエスト – オンチェーンコントラクトが、特定の計算をオフチェーンで行うようリクエストをトリガーします。これは、ユーザートランザクションによって開始されるか、あるコントラクトが ZK コプロセッサのインターフェースを呼び出すことによって行われます。例えば、DeFi コントラクトが “proveInterestRate(currentState)” を呼び出したり、ユーザーが “queryHistoricalData(query)” を呼び出したりします。
オフチェーン実行と証明 – オフチェーンサービス (分散型証明者ネットワークまたは信頼されたサービス、設計による) がリクエストを受け取ります。必要なデータ (オンチェーンの状態、オフチェーンの入力など) を収集し、特別な ZK 仮想マシン (ZKVM) またはサーキットで計算を実行します。実行中に、証明トレースが生成されます。最後に、サービスは 「入力 X に対して関数 F を計算すると出力 Y が得られる」 ことを証明する簡潔な証明 (例: SNARK または STARK) を生成し、任意でデータの完全性も証明します (詳細は後述)。
オンチェーン検証 – 証明と結果はブロックチェーンに返されます (多くの場合、コールバック関数を介して)。検証者コントラクトは、効率的な暗号検証 (ペアリングチェックなど) を使用して証明の有効性をチェックします。有効であれば、コントラクトは出力 Y を正しいものとして信頼できます。結果は状態に保存されたり、イベントとして発行されたり、さらなるコントラクトロジックに供給されたりします。証明が無効であるか、一定時間内に提供されない場合、リクエストは失敗したと見なされ (潜在的に何らかのフォールバックまたはタイムアウトロジックがトリガーされます)、処理されます。

図 1: ZK コプロセッサのアーキテクチャ (RISC Zero Bonsai の例)。オフチェーンでは、スマートコントラクトの呼び出しからの入力で ZKVM 上でプログラムが実行されます。実行の証明はリレーコントラクトを介してオンチェーンに返され、検証済みの結果とともにコールバックを呼び出します。

重要なのは、検証のためのオンチェーンのガス費用は、オフチェーンの計算がどれほど複雑であっても一定 (または非常にゆっくりと増加する) であることです。簡潔な証明の検証には数十万ガス (イーサリアムブロックの数分の一) かかるかもしれませんが、その証明はオフチェーンで行われた 数百万 の計算ステップを表すことができます。ある開発者が言ったように、「1 つのデジタル署名を証明したいですか？約 15 ドルです。100 万の署名を証明したいですか？それも約 15 ドルです。」。このスケーラビリティは大きな利点です。dApp は、ブロックチェーンを詰まらせることなく、複雑な機能 (ビッグデータ分析、精巧な金融モデルなど) を提供できます。

ZK コプロセッサシステムの主なコンポーネントは次のとおりです：

証明生成環境: これは、汎用の ZKVM (任意のプログラムを実行可能) または特定の計算に合わせたカスタムサーキットにすることができます。アプローチは様々です：
- 一部のプロジェクトは、サポートされている各クエリまたは関数に対して手作りのサーキットを使用します (その関数の効率を最大化します)。
- 他のプロジェクトは、開発者がオフチェーンロジックを記述するために使用するドメイン固有言語 (DSL) または埋め込み DSL を提供し、それがサーキットにコンパイルされます (使いやすさとパフォーマンスのバランスを取ります)。
- 最も柔軟なアプローチは zkVM です。これは、(多くの場合 RISC アーキテクチャに基づく) 仮想マシンで、プログラムを標準言語 (Rust, C など) で記述し、自動的に証明することができます。これはパフォーマンスを犠牲にしますが (サーキットで CPU をシミュレートするとオーバーヘッドが追加されます)、_開発者体験を最大化_します。
データアクセスと完全性: 特有の課題は、オフチェーン計算に正しいデータを供給することです。特にそのデータがブロックチェーン上 (過去のブロック、コントラクトの状態など) に存在する場合です。単純な解決策は、証明者にアーカイブノードから読み取らせてそれを信頼させることですが、これは信頼の仮定を導入します。ZK コプロセッサは代わりに、マークル証明や状態コミットメントにリンクすることで、使用されたオンチェーンデータが確かに本物であったことを証明します。例えば、クエリプログラムはブロック番号とストレージスロットまたはトランザクションのマークル証明を受け取り、サーキットはその証明を既知のブロックヘッダーハッシュに対して検証します。3 つのパターンが存在します：
1. インラインデータ: 必要なデータをオンチェーンに (検証者への入力として) 置くことで、直接チェックできるようにします。これは大規模なデータには非常にコストがかかり、全体の目的を損ないます。
2. オラクルを信頼する: オラクルサービスにデータを証明に供給させ、それを保証させます。これはよりシンプルですが、第三者への信頼を再導入します。
3. ZK を介してデータの包含を証明する: ゼロ知識サーキット自体の中に、チェーンの履歴におけるデータの包含証明を組み込みます。これは、各イーサリアムブロックヘッダーが (ステートルートを介して) 以前の全状態とトランザクション履歴にコミットしているという事実を活用します。サーキット内でデータのマークルパトリシア証明を検証することにより、出力証明はコントラクトに 「この計算はブロック N からの本物のブロックチェーンデータを使用した」 ことを、追加の信頼なしで保証します。
3 番目のアプローチが最もトラストレスであり、Axiom や Xpansion のような高度な ZK コプロセッサで使用されています (証明コストは増加しますが、セキュリティ上好ましいです)。例えば、Axiom のシステムは、イーサリアムのブロック構造、ステートトライ、トランザクショントライをサーキット内でモデル化しているため、「アカウント X はブロック N で残高 Y を持っていた」 や 「特定のプロパティを持つトランザクションがブロック N で発生した」 のようなステートメントを証明できます。これは、最近の信頼されたブロックハッシュが与えられれば、外部の当事者を信頼することなく、履歴データの包含を再帰的に証明できるという事実を活用しています。
検証者コントラクト: このオンチェーンコントラクトには、証明を受け入れるか拒否するための検証鍵とロジックが含まれています。Groth16 や PLONK のような SNARK の場合、検証者はいくつかの楕円曲線ペアリングを行うかもしれません。STARK の場合、いくつかのハッシュ計算を行うかもしれません。集約や再帰のようなパフォーマンス最適化により、オンチェーンの負荷を最小限に抑えることができます。例えば、RISC Zero の Bonsai は STARK-to-SNARK ラッパーを使用します。速度のためにオフチェーンで STARK ベースの VM を実行しますが、その後、STARK の有効性を証明する小さな SNARK 証明を生成します。これにより、証明サイズが数百キロバイトから数百バイトに縮小され、オンチェーンでの検証が実現可能かつ安価になります。Solidity の検証者は、その後 SNARK をチェックするだけです (これは定数時間の操作です)。

デプロイメントに関して、ZK コプロセッサは レイヤー 2 のような ネットワークとして、または純粋なオフチェーンサービスとして機能することができます。Axiom のように、イーサリアム向けの特化サービスとして始まったものもあります (Paradigm の支援を受けて)。開発者は Axiom の証明者ネットワークにクエリを送信し、オンチェーンで証明を取得します。Axiom のキャッチフレーズは、イーサリアムコントラクトに 「すべてのオンチェーンデータへのトラストレスなアクセスと、それに対する任意の表現力豊かな計算」 を提供することでした。これは、答えが信頼ではなく ZKP によって検証されるクエリオラクルとして効果的に機能します。RISC Zero の Bonsai のような他のものは、よりオープンなプラットフォームを提供します。どの開発者でもプログラム (RISC-V 互換の ZKVM にコンパイルされたもの) をアップロードし、リレーコントラクトを介して Bonsai の証明サービスを使用できます。図 1 に示されているリレーパターンは、リクエストとレスポンスを仲介するコントラクトを含みます。dApp コントラクトはリレーを呼び出して証明を要求し、オフチェーンサービスはこれを聞き (例えばイベントや直接呼び出しを介して)、証明を計算し、その後リレーが dApp コントラクトのコールバック関数を結果と証明とともに呼び出します。この非同期モデルは、証明が複雑さによって数秒から数分かかる可能性があるため必要です。これはレイテンシー (および証明者が応答するという活性仮定) を導入しますが、FHE-VM の計算はブロック内で同期的に行われます。この非同期ワークフロー (おそらくオラクルの応答に似ています) を処理するようにアプリケーションを設計することは、ZK コプロセッサを使用する一部です。

注目すべき ZK コプロセッサプロジェクト

Axiom: Axiom はイーサリアムに特化した ZK コプロセッサで、当初は履歴オンチェーンデータのクエリを証明することに焦点を当てていました。Halo2 証明フレームワーク (Plonk-ish SNARK) を使用して、イーサリアムの暗号構造を組み込んだ証明を作成します。Axiom のシステムでは、開発者は 「ブロック N でのコントラクト X の状態はどうだったか？」 のようなことをクエリしたり、ある範囲のすべてのトランザクションにわたる計算を実行したりできます。内部では、Axiom のサーキットはイーサリアムの状態/トライロジックを実装する必要があり、再帰をサポートするためにサーキット内で楕円曲線演算や SNARK 検証さえも実行していました。Trail of Bits は監査で、Axiom の Halo2 サーキットがブロック全体と状態をモデル化する複雑さを指摘しました。監査後、Axiom はその技術を OpenVM に一般化し、同じ Halo2 ベースのインフラで任意の Rust コードを証明できるようにしました。(これは、ドメイン固有のサーキットからより一般的な ZKVM アプローチへの移行というトレンドを反映しています。) Axiom チームは、イーサリアムがネイティブでは実行できない ZK クエリを実証し、暗号的な完全性を備えたあらゆる履歴データへの ステートレスアクセス を可能にしました。彼らはまた、セキュリティを重視し、制約不足のサーキットバグを捕捉・修正し、健全性を確保しました。Axiom の初期製品はピボット中にシャットダウンされましたが、そのアプローチは ZK コプロセッサにおける画期的なものとして残っています。
RISC Zero Bonsai: RISC Zero は RISC-V アーキテクチャに基づく ZKVM です。彼らの zkVM は任意のプログラム (Rust, C++ および RISC-V にコンパイルされる他の言語で書かれたもの) を実行し、実行の STARK 証明を生成できます。Bonsai は RISC Zero のクラウドサービスであり、この証明をオンデマンドで提供し、スマートコントラクトのコプロセッサとして機能します。これを使用するには、開発者はプログラム (例えば、複雑な数学計算を実行したり、オフチェーン API の応答を検証したりする関数) を書き、それを Bonsai サービスにアップロードし、対応する検証者コントラクトをデプロイします。コントラクトがその計算を必要とするとき、Bonsai リレーを呼び出し、それが証明生成をトリガーし、コールバックを介して結果を返します。実証されたアプリケーションの一例は、オフチェーンでのガバナンス計算でした。RISC Zero は、DAO が Bonsai を使用して票を集計し、複雑な投票メトリクスをオフチェーンで計算し、その後、オンチェーンの Governor コントラクトが最小限のガス費用で結果を信頼できるように証明を投稿する様子を示しました。RISC Zero の技術は、開発者が使い慣れたプログラミングパラダイムを使用できることを強調しています。例えば、何かを計算するための Rust 関数を書き、サーキット作成の重労働は zkVM が処理します。しかし、証明は大きくなる可能性があるため、前述のように、オンチェーン検証のために SNARK 圧縮を実装しました。2023 年 8 月、彼らはイーサリアムの Sepolia テストネットで RISC Zero の証明を正常に検証し、証明あたり 30 万ガス程度のコストがかかりました。これにより、イーサリアム dApp がスケーリングおよびプライバシーソリューションとして Bonsai を今日使用する道が開かれました。(Bonsai はまだアルファ版であり、本番環境には対応しておらず、セレモニーなしの一時的な SNARK セットアップを使用しています。)
その他: 他にも多数のプレイヤーや研究イニシアチブがあります。Expansion/Xpansion (ブログで言及) は、埋め込み DSL アプローチを使用しており、開発者は特殊な言語でオンチェーンデータに対するクエリを記述でき、内部で証明生成を処理します。StarkWare の Cairo や Polygon の zkEVM はより一般的な ZK ロールアップ VM ですが、その技術は L1 コントラクト内で証明を検証することにより、コプロセッサのような用途に再利用できます。また、ZKML (ZK 機械学習) ドメインのプロジェクトも見られます。これらは、ML モデルの推論やトレーニング結果をオンチェーンで検証するためのコプロセッサとして効果的に機能します。例えば、zkML セットアップは、入力を明らかにしたり、オンチェーンで計算を行ったりすることなく、「プライベート入力に対するニューラルネットワークの推論が分類 X を生成した」 ことを証明できます。これらは、AI に適用されたコプロセッサコンセプトの特殊なケースです。

信頼の仮定: ZK コプロセッサは、暗号証明の健全性に依存しています。証明システムが安全であれば (そして、信頼されたセットアップが正直に行われていれば)、受け入れられた証明は計算が正しかったことを保証します。証明者に対する追加の信頼は不要です。悪意のある証明者でさえ、偽のステートメントを検証者に納得させることはできません。しかし、活性仮定があります。誰かが実際にオフチェーン計算を実行し、証明を生成しなければなりません。実際には、これは分散型ネットワーク (インセンティブや手数料で作業を行う) または単一のサービスオペレーターかもしれません。誰も証明を提供しない場合、オンチェーンのリクエストは未解決のままになる可能性があります。もう一つの微妙な信頼の側面は、ブロックチェーン上にないオフチェーン入力のデータ可用性です。計算が何らかのプライベートまたは外部データに依存する場合、検証者は、追加の措置 (データコミットメントやオラクル署名など) が使用されない限り、そのデータが正直に提供されたかどうかを知ることができません。しかし、純粋にオンチェーンデータの計算については、説明されたメカニズムがチェーン自体と同等のトラストレス性を保証します (Axiom は、彼らの証明が履歴クエリに対して「イーサリアムと暗号的に同等のセキュリティ」を提供すると主張しました)。

プライバシー: ゼロ知識証明は本質的にプライバシーもサポートします。証明者は、それらに関するステートメントを証明しながら、入力を隠しておくことができます。コプロセッサの文脈では、これは、証明がコントラクトにプライベートデータから導出された結果を使用させることを可能にすることを意味します。例えば、証明は、実際のクレジットスコアや生データを明らかにすることなく、「ユーザーのクレジットスコア > 700 なので、ローンを承認する」 ことを示すことができます。Axiom のユースケースは、公に知られているデータ (ブロックチェーンの履歴) に関するものであったため、プライバシーは焦点ではありませんでした。しかし、RISC Zero の zkVM は、ユーザーが提供した秘密データに関するアサーションを証明するために使用できます。データはオフチェーンに留まり、必要な結果のみがオンチェーンに渡されます。FHE とは異なり、ZK 証明は通常、状態の継続的な機密性を提供しないことに注意する価値があります。それは一度きりの証明です。ワークフローがトランザクション間で秘密の状態を維持する必要がある場合、コントラクトに状態への コミットメント を保存させ、各証明が古いコミットメントから新しいコミットメントへの有効な状態遷移を示し、秘密は隠されたままにすることで構築できます。これは本質的に、プライベートトランザクションのための zk-ロールアップ (Aztec や Zcash のような) が機能する方法です。したがって、ZK コプロセッサは完全にプライベートなステートマシンを促進 できます が、実装は簡単ではありません。多くの場合、入力または出力 (あるいはその両方) が必要に応じてプライベートにできる 一度きりの計算 に使用されます。

開発者体験: ZK コプロセッサを使用するには、通常、新しいツールを学ぶ必要があります。カスタムサーキットを書くこと (上記のオプション (1)) は非常に複雑で、通常は狭い目的のためにのみ行われます。DSL や zkVM のような高レベルのオプションは生活を楽にしますが、それでもオーバーヘッドを追加します。開発者はオフチェーンコードを書いてデプロイし、その相互作用を管理しなければなりません。FHE-VM では暗号化がほとんど裏で処理され、開発者は通常のスマートコントラクトコードを書くのに対し、ここでは開発者はロジックを分割し、オフチェーン部分のために異なる言語 (Rust など) で書く必要があるかもしれません。しかし、Noir, Leo, Circom DSL や RISC Zero のアプローチのようなイニシアチブは、アクセシビリティを急速に向上させています。例えば、RISC Zero はテンプレートと Foundry の統合を提供しており、開発者はオフチェーンコードをローカルでシミュレートし (正当性のために)、その後 Bonsai のコールバックを介してシームレスに Solidity のテストにフックすることができます。時間が経つにつれて、ロジックの一部が ZK 証明を介して実行されるかオンチェーンで実行されるかを抽象化する開発フレームワークが期待できます。コンパイラやツールがコストに基づいて決定するかもしれません。

FHE-VM vs ZK-コプロセッサ: 比較

FHE-VM と ZK コプロセッサはどちらも 「オンチェーンの保証付きでプライベートデータ上で計算する」 という形態を可能にしますが、アーキテクチャが根本的に異なります。以下の表は、主な違いをまとめたものです：

側面	FHE-VM (暗号化されたオンチェーン実行)	ZK-コプロセッサ (オフチェーンでの証明)
計算が行われる場所	直接オンチェーン (すべてのノードが暗号文に対して準同型操作を実行)。	オフチェーン (証明者またはネットワークがプログラムを実行し、証明のみがオンチェーンで検証される)。
データ機密性	完全な暗号化: データはオンチェーンで常に暗号化されたまま。バリデーターは平文を見ることがない。復号鍵の所有者のみが出力を復号できる。	ゼロ知識: 証明者のプライベート入力はオンチェーンで公開されない。証明は公開出力に含まれるもの以外の秘密を明かさない。ただし、オンチェーンの状態に影響を与える必要のある計算で使用されるデータは、出力またはコミットメントにエンコードする必要がある。秘密はデフォルトでオフチェーンに留まる。
信頼モデル	コンセンサス実行と暗号技術への信頼: バリデーターの大多数がプロトコルに従えば、暗号化された実行は決定論的で正しい。計算の正当性に外部の信頼は不要 (すべてのノードが再計算するため)。プライバシーのためには FHE スキームのセキュリティ (通常は格子困難性に基づく) を信頼する必要がある。一部の設計では、十分な数のバリデーターが共謀して閾値鍵を悪用しないことも信頼する必要がある。	証明システムのセキュリティ (SNARK/STARK の健全性) への信頼。証明が検証されれば、結果は暗号的な確実性をもって正しい。オフチェーンの証明者は数学をごまかすことはできない。証明者が実際に作業を行うという活性仮定がある。信頼されたセットアップ (例: SNARK SRS) を使用する場合、それが正直に生成されたことを信頼するか、透明/セットアップ不要のシステムを使用する必要がある。
オンチェーンコストとスケーラビリティ	トランザクションあたりのコストが高い: 準同型操作は計算コストが非常に高く、すべてのノードが実行する必要がある。ガス費用は高い (例: 8 ビット加算 1 回で 10 万ガス以上)。複雑なコントラクトは、すべてのバリデーターが 1 ブロックで計算できる範囲に制限される。スループットは、特殊なハードウェアが採用されない限り、通常のスマートコントラクトよりもはるかに低い。スケーラビリティは、より高速な暗号技術とハードウェアアクセラレーションによって向上するが、基本的には各操作がチェーンのワークロードを増加させる。	検証コストが低い: 簡潔な証明の検証は効率的でサイズが一定であるため、オンチェーンのガスは控えめ (どんなサイズの計算でも数十万ガス)。これにより、複雑さがオンチェーンのリソース制限から切り離される。大規模な計算でもオンチェーンの追加コストはない。したがって、オンチェーンの負荷という点でスケールする。オフチェーンでは、証明時間はかなり長くなる可能性があり (巨大なタスクでは数分以上)、強力なマシンが必要になるかもしれないが、これはブロックチェーンを直接遅くするものではない。証明が時間内に生成できる限り (並列証明者ネットワークの可能性)、全体的なスループットは高くなる可能性がある。
レイテンシー	計算が実行中に行われるため、結果は同じトランザクション/ブロックですぐに利用可能。追加のラウンドトリップは不要 – 同期操作。ただし、FHE 操作が遅い場合、ブロック処理時間が長くなり、ブロックチェーンのレイテンシーが増加する可能性がある。	本質的に非同期。通常、リクエストのための 1 つのトランザクションと、後で証明/結果を提供するためのトランザクション (またはコールバック) が必要。これにより遅延が発生する (証明の複雑さと証明ハードウェアによっては数秒から数時間)。単一トランザクションの即時ファイナリティには適していない – むしろ非同期ジョブモデルに近い。
プライバシー保証	強力: すべて (入力、出力、中間状態) がオンチェーンで暗号化されたままにできる。複数のトランザクションがそれを明らかにすることなく更新する、長期間存続する暗号化状態を持つことができる。承認された復号アクション (もしあれば) のみが結果を明らかにし、それらは鍵/ACL を介して制御できる。ただし、ガス使用量やイベントログのようなサイドチャネルの考慮事項は、パターンが漏洩しないように管理する必要がある (fhEVM 設計は、漏洩を避けるためにデータ非依存の実行と操作のための定数ガスを目指している)。	選択的: 証明は、公開出力にあるもの、または検証に必要なもの (例: 初期状態へのコミットメント) を明らかにする。設計者は、意図した結果のみが明らかにされ、他のすべての入力がゼロ知識で隠されたままであることを保証できる。しかし、FHE とは異なり、ブロックチェーンは通常隠された状態を保存しない – プライバシーはデータを完全にオフチェーンに保つことによって達成される。永続的なプライベート状態が必要な場合、コントラクトはそれに対する暗号コミットメントを保存することがある (そのため、状態更新は毎回新しいコミットメントを明らかにする)。プライバシーは証明することを選択したものによって制限される。例えば、正確な値を明らかにすることなく閾値が満たされたことを証明する柔軟性がある。
完全性の強制	設計上、すべてのバリデーターは次の状態を準同型的に再計算するため、悪意のあるアクターが間違った暗号文の結果を提供した場合、他のバリデーターは不一致を検出し、全員が同じ結果を得ない限りコンセンサスは失敗する。したがって、完全性は冗長な実行によって強制される (通常のブロックチェーンと同様、ただし暗号化データ上)。バリデーターは平文の条件を直接チェックできないため、ビジネスルール (例: ユーザーが制約に違反できなかった) を強制するために追加の ZK 証明がしばしば使用される。	完全性は、ZK 証明をチェックする検証者コントラクトによって強制される。証明が検証される限り、結果はオフチェーンプログラムの何らかの有効な実行と一致することが保証される。正当性のために正直な多数派の仮定は不要 – 単一の正直な検証者 (コントラクトコード自体) で十分。オンチェーンコントラクトは、不正な証明や欠落した証明を単に拒否する (無効な署名を拒否するのと同様)。考慮事項: 証明者が中止または遅延した場合、コントラクトにはフォールバックロジックが必要になるかもしれないが (またはユーザーが後で再試行する必要があるかもしれないが)、不正な結果は受け入れない。
開発者体験	長所: 拡張機能を使えば、使い慣れたスマートコントラクト言語 (Solidity など) をほぼ使用できる。機密性はプラットフォームによって処理される – 開発者は主に何を暗号化し、誰が鍵を持つかを心配する。暗号化されたコントラクトと通常のコントラクトの構成が可能で、DeFi の構成可能性を維持する (ただし暗号化された変数を使用)。短所: FHE の制限を理解する必要がある – 例: 特別な処理なしでは秘密データに対する直接の条件分岐はできない、サーキットの深さが限られる (ただし TFHE のブートストラップは時間と引き換えに任意の長さの計算を可能にする)。暗号化されたロジックのデバッグは、鍵なしではランタイム値を簡単に内省できないため、トリッキーになる可能性がある。また、鍵管理と権限設定はコントラクト設計に複雑さを加える。	長所: オフチェーン部分には任意のプログラミング言語を使用できる可能性がある (特に zkVM を使用する場合)。オフチェーンプログラムで既存のコード/ライブラリを活用できる (ZK 互換性の注意点あり)。汎用 ZKVM を使用する場合、開発者によるカスタム暗号技術は不要 – 通常のコードを書き、証明を得る。また、重い計算は、オンチェーンでは決して実行できないライブラリ (例: 機械学習コード) を使用できる。短所: 開発者はオフチェーンインフラを調整するか、証明サービスを使用する必要がある。非同期ワークフローの処理とオンチェーンロジックとの統合には、より多くの設計作業が必要 (例: 保留中の状態の保存、コールバックの待機)。効率的なサーキットや zkVM コードを書くには、新しい制約を学ぶ必要があるかもしれない (例: 浮動小数点数なし、固定小数点または特殊プリミティブを使用、証明時間を爆発させる重い分岐を避ける、制約数に最適化する)。また、証明の失敗やタイムアウトなどに対処する負担もあり、これらは通常の Solidity では懸念事項ではない。ツールのエコシステムは成長しているが、多くの人にとって新しいパラダイムである。

両アプローチは積極的に改善されており、収束も見られます。前述のように、ZKPs は FHE-VM 内部で特定のチェックに使用され、逆に一部の研究者は ZK で証明者の入力をプライベートに保つために FHE を使用することを提案しています (クラウド証明者があなたの秘密データを見ないように)。将来のシステムがこれらを組み合わせることは考えられます。例えば、オフチェーンで FHE を実行し、その正当性をチェーンに証明したり、オンチェーンで FHE を使用し、暗号化操作が正しく行われたことをライトクライアントに ZK 証明したりするなどです。各技術には強みがあります。FHE-VM は重い計算を犠牲にして 継続的なプライバシーとリアルタイムの相互作用 を提供し、ZK コプロセッサはレイテンシーと複雑さを犠牲にして スケーラビリティと柔軟性 を提供します。

ユースケースと影響

プログラマブルプライバシーの出現は、業界全体で新しいブロックチェーンアプリケーションの富を解き放ちます。以下では、FHE-VM と ZK コプロセッサ (またはハイブリッド) が、プライバシーを保護するスマートコントラクトと安全なデータエコノミーを可能にすることで、さまざまなドメインをどのように強化できるかを探ります。

機密 DeFi と金融

分散型金融において、プライバシーはフロントランニングを軽減し、取引戦略を保護し、必要な場合には透明性を犠牲にすることなくコンプライアンスを満たすことができます。機密 DeFi は、ユーザーが自分のポジションを世界に公開することなくプロトコルと対話することを可能にします。

プライベートトランザクションと隠蔽残高: FHE を使用すると、機密トークン転送 (暗号化された ERC-20 残高とトランザクション) やブロックチェーン L1 上のシールドプールを実装できます。観察者はあなたがどのトークンをどれだけ保有しているか、または転送したかを見ることができず、保有量に基づく標的型攻撃のリスクを排除します。ZK 証明は、残高が同期を保ち、二重支払いが発生しないことを保証できます (Zcash に似ていますが、スマートコントラクトプラットフォーム上です)。一例として、プールリザーブと取引がオンチェーンで暗号化される機密 AMM (自動マーケットメーカー) があります。裁定取引者やフロントランナーは、取引が決済されるまで価格の滑りを見ることができないため、プールを悪用できません。MEV を削減します。一定の遅延後、またはアクセス制御されたメカニズムを介してのみ、監査のために一部のデータが公開される場合があります。
MEV 耐性のあるオークションと取引: マイナーやボットは、トランザクションの透明性を利用して取引をフロントランします。暗号化を使用すると、注文が暗号文で送信される暗号化メンプールやバッチオークションを持つことができます。オークションがクリアされた後にのみ、取引が復号されます。このコンセプトは、公正な注文フロー とも呼ばれ、閾値復号 (複数のバリデーターが集合的にバッチを復号) や、個々の入札を明らかにすることなく ZK を介してオークションの結果を証明することで達成できます。例えば、ZK コプロセッサは、オフチェーンで封印された入札のバッチを受け取り、オークションのクリア価格を計算し、その価格と勝者だけを証明付きで出力することができます。これにより、敗者の入札の公平性とプライバシーが保護されます。
機密レンディングとデリバティブ: DeFi レンディングでは、ユーザーはローンや担保の規模を公開したくない場合があります (市場心理に影響を与えたり、悪用を招いたりする可能性があるため)。FHE-VM は、各ローンの詳細が暗号化された暗号化されたローンブックを維持できます。スマートコントラクトロジックは、暗号化された健全性係数上で操作することにより、清算条件のようなルールを引き続き強制できます。ローンの担保比率が閾値を下回った場合、コントラクトは (ZK 証明の助けを借りて) 正確な値を公開することなく清算のためにフラグを立てることができます。平文でイエス/ノーのフラグを生成するだけかもしれません。同様に、秘密のデリバティブやオプションポジションをオンチェーンで管理し、集計されたリスクメトリクスのみを公開することができます。これにより、コピートレーディングを防ぎ、独自の戦略を保護し、より多くの機関投資家の参加を促すことができます。
コンプライアンスを遵守したプライバシー: すべての金融コンテキストが完全な匿名性を望んでいるわけではありません。規制のために 選択的開示 が必要な場合があります。これらのツールを使用すると、規制されたプライバシーを実現できます。例えば、取引は一般にはプライベートですが、規制された取引所は特定のプロパティについて復号したり、証明を受け取ったりできます。ZK を介して、「この取引はブラックリストに載っているアドレスを含まず、両当事者は KYC 認証済みである」 ことを、チェーンに身元を明かすことなく証明できます。このバランスは、他のすべての人に対してユーザーの身元とポジションを機密に保ちながら、マネーロンダリング対策 (AML) ルールを満たすことができます。FHE は、オンチェーンのコンプライアンスオフィサーコントラクトが、リスクシグナルのために暗号化されたトランザクションをスキャンすることを可能にします (例えば、裁判所命令の下でのみアクセス可能な復号鍵を使用して)。

デジタルアイデンティティと個人データ

アイデンティティシステムは、オンチェーンのプライバシー技術から大きな利益を得ることができます。現在、個人の資格情報や属性を公開台帳に載せることは、プライバシー法やユーザーの抵抗のために非現実的です。FHE と ZK を使用すると、自己主権型アイデンティティをプライバシーを保護する方法で実現できます：

ゼロ知識クレデンシャル: ZK 証明 (一部のアイデンティティプロジェクトではすでに一般的) を使用すると、ユーザーは他の個人情報を一切明かすことなく、「私は 18 歳以上です」、「有効な運転免許証を持っています」、または 「(信用スコアリングのために) 5 万ドル以上の収入があります」 のようなステートメントを証明できます。ZK コプロセッサは、オフチェーンでより複雑なチェックを処理することでこれを強化できます。例えば、Axiom のような方法でプライベートな信用データベースをクエリし、ユーザーのクレジットスコアが閾値以上であることを証明し、ブロックチェーンにはイエス/ノーのみを出力します。
DeFi における機密 KYC: 法律によりユーザーが KYC 認証済みであることを確認しなければならない DeFi プロトコルを想像してみてください。FHE-VM を使用すると、ユーザーの資格情報をオンチェーンで暗号化して保存 (または DID を介して参照) し、スマートコントラクトが FHE 計算を実行して KYC 情報が要件を満たしていることを検証できます。例えば、コントラクトは、暗号化されたユーザープロファイルの名前と SSN が、制裁対象ユーザーリスト (これも暗号化) と一致するか、またはユーザーの国が制限されていないかを準同型的にチェックできます。コントラクトは暗号化された「合格/不合格」のみを取得し、これはネットワークバリデーターによってブール値フラグに閾値復号できます。ユーザーが許可されているかどうかの事実のみが明らかにされ、PII の機密性を保護し、GDPR の原則に沿っています。この選択的開示は、コンプライアンスとプライバシーを保証します。
属性ベースのアクセスと選択的開示: ユーザーは、検証可能な資格情報 (年齢、市民権、スキルなど) の束を暗号化された属性として保持できます。彼らは、すべてを開示することなく、特定の dApp がそれらに対して計算を実行することを許可できます。例えば、分散型採用 dApp は、(FHE を使用して) 暗号化された履歴書で検索を実行し (例: 経験年数を数える、資格を確認する)、一致が見つかった場合にのみ、オフチェーンで候補者に連絡することができます。候補者のプライベートな詳細は、彼らが公開を選択しない限り暗号化されたままです。ZK 証明はまた、ユーザーが属性の組み合わせ (例: 21 歳以上かつ特定の郵便番号内) を持っていることを、実際の値を明らかにすることなく選択的に証明することを可能にします。
多者間本人確認: 時には、ユーザーの身元が複数の当事者によって審査される必要があります (例えば、会社 A による身元調査、会社 B による信用調査)。準同型および ZK ツールを使用すると、各検証者は暗号化されたスコアまたは承認を提供でき、スマートコントラクトはこれらを集計して最終決定を下すことができます。個々の貢献を公開することなく。例えば、3 つの機関が暗号化された「合格/不合格」ビットを提供し、3 つすべてが合格であればコントラクトが承認を出力します。ユーザーまたは依拠当事者は最終結果のみを見ることができ、どの特定の機関が不合格にしたかはわからず、各機関でのユーザーの記録のプライバシーを保護します。これにより、例えば、1 つの不合格が特定の問題を明らかにするという偏見や汚名を減らすことができます。

ヘルスケアと機密データ共有

ヘルスケアデータは非常に機密性が高く、規制されていますが、複数のソースからのデータを組み合わせることで、(研究、保険、個別化医療のために) 大きな価値を生み出すことができます。プライバシーが解決されれば、ブロックチェーンはデータ交換のための信頼層を提供できます。機密スマートコントラクトは、新しい健康データエコシステムを可能にする可能性があります：

安全な医療データ交換: 患者は、自分の医療記録への参照を暗号化された形式でオンチェーンに保存できます。FHE 対応のコントラクトにより、研究機関は患者データのコホートに対して、それを復号することなく 分析を実行できます。例えば、コントラクトは、暗号化された患者の転帰にわたる薬剤の平均有効性を計算できます。集計された統計結果のみが復号されて出力され (そしておそらく、再識別を防ぐために最小数の患者が含まれている場合にのみ)、出力されます。患者は、自分のプライバシーが保護されていることを知っているため、暗号化されたデータを研究に提供することでマイクロペイメントを受け取ることができます。ブロックチェーンや研究者でさえ、暗号文または集計証明しか見ないためです。これは、プライバシーを尊重するヘルスケア向けデータマーケットプレイスを育成します。
プライバシーを保護する保険金請求: 健康保険の請求処理は、保険会社にデータを公開することなく医療データの条件を検証するスマートコントラクトを介して自動化できます。請求には、暗号化された診断コードと暗号化された治療費が含まれる場合があります。コントラクトは、FHE を使用して、その暗号化されたデータに対してポリシールール (例: 補償範囲、免責金額) をチェックします。保険会社のブロックチェーンに実際の診断を明らかにすることなく、承認と支払額を出力できます (患者と医師のみが鍵を持っていました)。ZK 証明は、患者のデータが認定病院の記録から来たことを示すために使用されるかもしれません (Axiom のようなものを使用して病院の署名や記録の包含を検証する)、記録自体を明らかにすることなく。これにより、不正を防ぎながら患者のプライバシーを確保します。
ゲノムおよび個人データ計算: ゲノムデータは非常に機密性が高いです (文字通り、個人の DNA の青写真です)。しかし、ゲノムを分析することで、貴重な健康上の洞察を得ることができます。企業は FHE-VM を使用して、ユーザーがアップロードした暗号化されたゲノムに対して計算を実行できます。例えば、スマートコントラクトは、暗号化されたゲノムデータと暗号化された環境データ (おそらくウェアラブルから) に対して遺伝子-環境リスクモデルを実行し、ユーザーのみが復号できるリスクスコアを出力できます。ロジック (多遺伝子リスクスコアアルゴリズムなど) はコントラクトにコーディングされ、準同型的に実行されるため、ゲノムデータは平文で現れることはありません。このようにして、ユーザーは企業に生の DNA データを与えることなく洞察を得ることができます。プライバシーとデータ所有権の両方の懸念を軽減します。
疫学と公衆衛生: パンデミックのような状況では、データ共有は病気の蔓延をモデル化するために不可欠ですが、プライバシー法がデータ共有を妨げる可能性があります。ZK コプロセッサにより、公衆衛生当局は、「地域 X で過去 24 時間に陽性反応を示した人の数」 のようなクエリを、証明を介して病院のデータネットワークに送信できます。各病院は患者の検査記録をオフチェーンに保持しますが、誰であるかを明らかにすることなく、陽性者の数を当局のコントラクトに証明できます。同様に、接触追跡は、暗号化された位置情報の軌跡を照合することで行うことができます。コントラクトは、患者の暗号化された位置情報の履歴の交差点を計算してホットスポットを特定し、ホットスポットの場所のみを出力します (そしておそらく、保健部門のみが復号できる影響を受けた ID の暗号化リストも)。個人の生の位置情報の軌跡はプライベートなままです。

データマーケットプレイスとコラボレーション

データを明らかにすることなく計算できる能力は、データ共有に関する新しいビジネスモデルを開きます。エンティティは、独自のデータが公開されないことを知っている上で、計算で協力できます：

安全なデータマーケットプレイス: 販売者は、ブロックチェーンマーケットプレイスで暗号化された形式でデータを利用可能にすることができます。購入者は、スマートコントラクトを介して暗号化されたデータセットに対して特定の分析や機械学習モデルを実行するためにお金を払い、トレーニング済みのモデルまたは集計された結果のいずれかを取得します。販売者の生データは、購入者や一般に公開されることはありません。購入者はモデルのみを受け取るかもしれません (それでも重みにいくつかの情報が漏れる可能性がありますが、差分プライバシーや出力の粒度を制御するなどの技術でこれを軽減できます)。ZK 証明は、約束されたデータセットに対して計算が正しく行われたことを購入者に保証できます (例えば、販売者は証明がコミットされた暗号化データセットに結びついているため、ダミーデータでモデルを実行してごまかすことはできません)。このシナリオはデータ共有を促進します。例えば、企業は、データを渡すことなく、承認されたアルゴリズムが暗号化の下で実行されることを許可することで、ユーザー行動データを収益化できます。
連合学習と分散型 AI: 分散型機械学習では、複数の当事者 (例えば、異なる企業やデバイス) が、互いにデータを共有することなく、結合されたデータで共同でモデルをトレーニングしたいと考えています。FHE-VM はここで優れています。各当事者のモデル更新がコントラクトによって準同型的に集計される連合学習を可能にします。更新は暗号化されているため、参加者は他の人の貢献を知ることはありません。コントラクトは、トレーニングループの一部 (勾配降下ステップなど) をオンチェーンで暗号化の下で実行し、承認された当事者のみが復号できる更新されたモデルを生成することさえできます。ZK は、各当事者の更新がトレーニングアルゴリズムに従って計算されたことを証明することでこれを補完できます (悪意のある参加者がモデルを汚染するのを防ぎます)。これは、グローバルモデルがオンチェーンで完全な監査可能性をもってトレーニングできることを意味しますが、各貢献者のトレーニングデータはプライベートなままです。ユースケースには、銀行間で共同で不正検出モデルをトレーニングしたり、多くのユーザーからのデータを使用して AI アシスタントを改善したりすることが含まれますが、生データは集中化されません。
組織横断的な分析: パートナーシップキャンペーンのために、顧客リスト全体を互いに公開することなく、顧客の共通部分を見つけたい 2 つの会社を考えてみましょう。彼らはそれぞれ顧客 ID リストを暗号化し、コミットメントをアップロードできます。FHE 対応のコントラクトは、暗号化されたセット上で共通部分を計算できます (FHE を介したプライベート集合交差のような技術を使用して)。結果は、相互に信頼された第三者 (または顧客自身、何らかのメカニズムを介して) のみが復号できる共通の顧客 ID の暗号化リストになる可能性があります。あるいは、ZK アプローチ: 一方の当事者が他方の当事者にゼロ知識で 「我々は N 人の共通の顧客を持っており、ここにそれらの ID の暗号化がある」 ことを証明し、その暗号化が確かに共通のエントリに対応していることの証明を付けます。このようにして、彼らは完全なリストを平文で交換することなく、それらの N 人の顧客へのキャンペーンを進めることができます。同様のシナリオ: 個々のサプライヤーの詳細を明らかにすることなく競合他社間でサプライチェーンメトリクスを計算したり、完全なクライアントデータを共有することなく銀行が信用情報を照合したりします。
ブロックチェーン上の安全な多者間計算 (MPC): FHE と ZK は、本質的に MPC の概念をオンチェーンにもたらします。複数の組織にまたがる複雑なビジネスロジックは、各組織の入力が秘密共有または暗号化されるようにスマートコントラクトにエンコードできます。コントラクトは (MPC ファシリテーターとして)、利益分配、コスト計算、または共同リスク評価のような、誰もが信頼できる出力を生成します。例えば、いくつかのエネルギー会社が電力取引の市場を決済したいとします。彼らは暗号化された入札とオファーをスマートコントラクトオークションに供給できます。コントラクトは暗号化された入札でクリア価格と割り当てを計算し、各会社の割り当てとコストをその会社だけに (公開鍵への暗号化を介して) 出力します。どの会社も他社の入札を見ることはなく、競争情報を保護しますが、オークションの結果は公正で検証可能です。この ブロックチェーンの透明性と MPC のプライバシーの組み合わせ は、現在信頼された第三者に依存しているコンソーシアムや企業コンソーシアムを革命的に変える可能性があります。

分散型機械学習 (ZKML と FHE-ML)

検証可能でプライベートな方法で機械学習をブロックチェーンにもたらすことは、新たなフロンティアです：

検証可能な ML 推論: ZK 証明を使用すると、x (プライベートデータの場合) または f の内部動作 (モデルの重みが独自の場合) のいずれも明らかにすることなく、「機械学習モデル f が入力 x を与えられたときに出力 y を生成する」 ことを証明できます。これは、ブロックチェーン上の AI サービスにとって重要です。例えば、予測や分類を提供する分散型 AI オラクルなどです。ZK コプロセッサは、モデルをオフチェーンで実行し (モデルは大きく、評価にコストがかかるため)、結果の証明を投稿できます。例えば、オラクルは、炭素クレジット契約をサポートするために、衛星画像や場合によってはモデルさえも明らかにすることなく、「提供された衛星画像は少なくとも 50% の樹木被覆を示している」 というステートメントを証明できます。これは ZKML として知られており、プロジェクトはサーキットフレンドリーなニューラルネットワークの最適化に取り組んでいます。これにより、スマートコントラクトで使用される AI 出力の完全性が保証され (不正や任意の出力なし)、入力データとモデルパラメータの機密性を保護できます。
プライバシーと監査可能性を備えたトレーニング: ML モデルのトレーニングはさらに計算集約的ですが、達成可能であれば、ブロックチェーンベースのモデルマーケットプレイスを可能にします。複数のデータプロバイダーが、トレーニングアルゴリズムが暗号化データ上で実行されるように、FHE の下でモデルのトレーニングに貢献できます。結果は、購入者のみが復号できる暗号化されたモデルになる可能性があります。トレーニング中、トレーニングがプロトコルに従っていることを証明するために ZK 証明が定期的に提供される可能性があります (悪意のあるトレーナーがバックドアを挿入するのを防ぐなど)。完全にオンチェーンでの ML トレーニングはコストを考えるとまだ先ですが、ハイブリッドアプローチでは、重要な部分に ZK 証明を使用したオフチェーン計算を使用できます。参加者がプライベートデータセットでモデルをトレーニングし、暗号化されたテストデータでのモデルの精度の ZK 証明を提出して勝者を決定する、分散型の Kaggle のようなコンペティションを想像できます。データセットやテストデータを明らかにすることなく。
パーソナライズされた AI とデータ所有権: これらの技術により、ユーザーは個人データの所有権を保持し、それでも AI の恩恵を受けることができます。例えば、ユーザーのモバイルデバイスは FHE を使用して使用状況データを暗号化し、それを分析コントラクトに送信して、彼らのためだけのパーソナライズされた AI モデル (推奨モデルなど) を計算できます。モデルは暗号化されており、ユーザーのデバイスのみが復号してローカルで使用できます。プラットフォーム (ソーシャルネットワークなど) は生データやモデルを見ることはありませんが、ユーザーは AI の恩恵を受けます。プラットフォームが集計された洞察を望む場合、個々のデータにアクセスすることなく、コントラクトから特定の集計パターンの ZK 証明を要求できます。

その他の分野

ゲーム: オンチェーンゲームは、秘密情報 (隠されたカードの手札、戦略ゲームの戦場の霧など) を隠すのに苦労することがよくあります。FHE は、ゲームロジックが暗号化された状態で実行される隠蔽状態ゲームを可能にします。例えば、ポーカーゲームのコントラクトは、暗号化されたカードをシャッフルして配ることができます。プレイヤーは自分のカードの復号を取得しますが、コントラクトや他の人は暗号文しか見ません。ベッティングロジックは ZK 証明を使用して、プレイヤーがアクションについてブラフをしていないことを保証したり (または、最後に勝利の手札を検証可能な公正な方法で明らかにしたり) できます。同様に、NFT のミンティングやゲームの結果のためのランダムシードは、シードを公開することなく生成され、公正であることが証明できます (操作を防ぎます)。これにより、ブロックチェーンゲームが大幅に強化され、従来のゲームと同じダイナミクスをサポートできるようになります。
投票とガバナンス: DAO は、オンチェーンでの秘密投票のためにプライバシー技術を使用し、票の買収や圧力を排除できます。FHE-VM は、暗号化された形式で投じられた票を集計し、最終的な合計のみが復号されます。ZK 証明は、各票が有効であったこと (資格のある有権者からであり、二重投票していない) を、誰が何に投票したかを明らかにすることなく保証できます。これにより、個々の投票を秘密に保ちながら、検証可能性 (誰もが証明と集計を検証できる) を提供します。これは、偏りのないガバナンスにとって重要です。
安全なサプライチェーンと IoT: サプライチェーンでは、パートナーは競合他社に完全な詳細を公開することなく、特定のプロパティ (原産地、品質メトリクス) の証明を共有したい場合があります。例えば、食品輸送の IoT センサーは、暗号化された温度データを継続的にブロックチェーンに送信できます。コントラクトは FHE を使用して、輸送中に温度が安全な範囲内にとどまっていたかどうかを確認できます。閾値を超えた場合、アラートやペナルティをトリガーできますが、温度ログ全体を公に公開する必要はありません。証明または 「90 パーセンタイルの温度」 のような集計のみかもしれません。これにより、プロセスデータの機密性を尊重しながら、サプライチェーンオートメーションへの信頼を構築します。

これらのユースケースはそれぞれ、データを明らかにすることなくデータを計算または検証するという中核的な能力を活用しています。この能力は、分散型システムにおける機密情報の扱い方を根本的に変えることができます。これにより、プライベートデータを扱う分野でのブロックチェーンの採用を制限してきた、透明性とプライバシーの間のトレードオフが減少します。

結論

ブロックチェーン技術は、データ機密性とスマートコントラクト機能が密接に関連する、プログラマブルプライバシーの新時代に突入しています。FHE-VM と ZK コプロセッサのパラダイムは、技術的には異なりますが、どちらも 何を計算できるか と 何を明らかにしなければならないか を切り離すことで、ブロックチェーンアプリケーションの範囲を拡大しようとしています。

完全準同型暗号仮想マシンは、計算をオンチェーンで暗号化されたままにし、分散化と構成可能性を維持しますが、効率の向上を要求します。ゼロ知識コプロセッサは、重い処理をオフチェーンにシフトし、暗号的な保証の下で事実上無制限の計算を可能にし、スケーリングとイーサリアムの強化においてすでにその価値を証明しています。それら (およびそのハイブリッド) の間の選択は、ユースケースに依存します。プライベート状態とのリアルタイムの相互作用が必要な場合は、FHE アプローチがより適しているかもしれません。非常に複雑な計算や既存のコードとの統合が必要な場合は、ZK コプロセッサが適切な方法かもしれません。多くの場合、それらは補完的です。実際、ZK 証明が FHE の完全性を強化し、FHE が証明者のためのプライベートデータを処理することで ZK を助ける可能性があることがわかります。

開発者にとって、これらの技術は新しい設計パターンを導入します。私たちは、dApp アーキテクチャの第一級の要素として、暗号化された変数と証明検証の観点から考えるようになります。ツールは急速に進化しています。高レベルの言語と SDK は、暗号の詳細を抽象化しています (例えば、Zama のライブラリは FHE 型をネイティブ型と同じくらい簡単にし、RISC Zero のテンプレートは証明リクエストを容易にします)。数年後には、機密性の高いスマートコントラクトを書くことは、通常のものを書くのとほとんど同じくらい簡単になり、プライバシーがデフォルトで「組み込まれている」と感じられるようになるかもしれません。

データエコノミーへの影響は甚大です。個人や企業は、その可視性を制御できる場合、データやロジックをオンチェーンに置くことにもっと意欲的になるでしょう。これにより、プライバシーの懸念のために以前は実現不可能だった、組織横断的なコラボレーション、新しい金融商品、AI モデルが解き放たれる可能性があります。規制当局も、暗号的な手段 (例えば、すべてのトランザクションを公開することなく、オンチェーンで税金が正しく支払われたことを証明する) を介してコンプライアンスチェックと監査を可能にするため、これらの技術を受け入れるようになるかもしれません。

私たちはまだ初期段階にいます。現在の FHE-VM プロトタイプにはパフォーマンスの制限があり、ZK 証明は以前よりもはるかに高速になりましたが、非常に複雑なタスクにとっては依然としてボトルネックになる可能性があります。しかし、継続的な研究とエンジニアリングの努力 (Optalysys のような企業が光学 FHE アクセラレーションを推進していることに見られるように、特殊なハードウェアを含む) は、これらの障壁を急速に取り除いています。この分野に注ぎ込まれる資金 (例えば、Zama のユニコーンステータス、Paradigm の Axiom への投資) は、プライバシー機能が Web1/2 にとって透明性がそうであったように、Web3 にとっても基本的になるという強い信念を裏付けています。

結論として、FHE-VM と ZK コプロセッサを介したプログラマブルプライバシーは、トラストレスで、分散化され、機密性の高い新しいクラスの dApp の到来を告げます。詳細を明かさない DeFi 取引から、患者データを保護する健康研究、生データを公開することなく世界中でトレーニングされる機械学習モデルまで、可能性は広大です。これらの技術が成熟するにつれて、ブロックチェーンプラットフォームはもはや実用性とプライバシーの間のトレードオフを強制しなくなり、機密性を必要とする業界でのより広範な採用を可能にします。Web3 の未来は、*ユーザーと組織が、ブロックチェーンが完全性を検証し、彼らの秘密を安全に保つことを知っている上で、機密データをオンチェーンで自信を持って取引し、計算できる世界です*。

出典: このレポートの情報は、この分野の主要プロジェクトの技術文書および最近の研究ブログから引用されています。これには、Cypher と Zama の FHEVM ドキュメント、Trail of Bits による Axiom のサーキットに関する詳細な分析、RISC Zero の開発者ガイドとブログ投稿、および機密ブロックチェーン技術のユースケースを強調する業界記事が含まれます。これらの出典などは、さらなる読書と、説明されたアーキテクチャおよびアプリケーションの証拠を提供するために、全体を通して引用されています。

Ethereum の匿名性神話：研究者がバリデータの 15% を特定した方法

2025年4月21日 · 約7分

Dora Noda

Software Engineer

ブロックチェーン技術、特に Ethereum が提供する主な約束のひとつは、ある程度の匿名性です。バリデータと呼ばれる参加者は、暗号的な仮名の背後で活動し、現実世界の身元とそれに伴うセキュリティを保護するとされています。

しかし、ETH Zurich などの研究者が執筆した最近の論文「Deanonymizing Ethereum Validators: The P2P Network Has a Privacy Issue」では、この前提に致命的な欠陥があることが示されました。彼らは、バリデータの公開識別子と実行マシンの IP アドレスを直接結びつける、シンプルかつ低コストな手法を実証しています。

要するに、Ethereum バリデータは多くの人が考えるほど匿名ではありませんでした。この発見は Ethereum Foundation からバグ賞金を受け取るほどの重要性が認められました。

脆弱性の仕組み：ゴシップの欠陥

脆弱性を理解するには、まず Ethereum バリデータがどのように通信しているかを簡単に把握する必要があります。ネットワークは 100 万を超えるバリデータで構成され、彼らは常にチェーンの状態に「投票」しています。この投票は アテステーション と呼ばれ、ピアツーピア（ $P2P$ ）ネットワークを通じて全ノードにブロードキャストされます。

バリデータが多数いるため、全員が全投票を全員に送信するとネットワークは瞬時に飽和してしまいます。そこで Ethereum の設計者は賢いスケーリング手法を導入しました。ネットワークは 64 個の独立した通信チャネル、すなわち サブネット に分割されています。

デフォルトでは、各ノード（バリデータソフトウェアを実行するコンピュータ）は 64 個のサブネットのうち 2 つ のみを購読します。ノードの主な役割は、その 2 つのチャネル上のすべてのメッセージを忠実に中継することです。
バリデータが投票を行う際、アテステーションはランダムに 64 個のサブネットのいずれかに割り当てられてブロードキャストされます。

ここに脆弱性があります。 たとえば、チャネル 12 と 13 のトラフィック管理を担当しているノードが、突然チャネル 45 のメッセージを送ってきたとします。

これは強力な手がかりです。なぜそのノードが自分の担当外のチャネルのメッセージを処理するのか？最も論理的な結論は そのノード自体がメッセージを生成した ということです。つまり、チャネル 45 のアテステーションを作成したバリデータは、まさにそのマシン上で動作していると推測できます。

研究者はこの原理をそのまま利用しました。自前のリスニングノードを設置し、ピアがどのサブネットからアテステーションを送ってくるかを監視したのです。ピアが公式に購読していないサブネットからメッセージを送ったとき、高い確信を持ってそのピアが元のバリデータをホストしていると推測できました。

この手法は驚くほど効果的でした。4 台のノードを 3 日間稼働させるだけで、チームは 161,000 を超えるバリデータ の IP アドレスを特定し、全 Ethereum ネットワークの 15% 以上 を露出させました。

なぜ重要か：匿名性除去のリスク

バリデータの IP アドレスが公開されることは決して軽視できません。個々のオペレーターだけでなく、Ethereum ネットワーク全体の健全性を脅かす標的型攻撃の入口となります。

1. 標的型攻撃と報酬の盗難
Ethereum は次にブロックを提案するバリデータを数分前に公表します。このバリデータの IP アドレスが分かれば、攻撃者は DDoS 攻撃 を仕掛け、トラフィックで埋め尽くしてオフラインにできます。バリデータが 4 秒間の提案ウィンドウを逃すと、次のバリデータに権利が移ります。もし攻撃者がその次のバリデータであれば、被害者が本来得るべきブロック報酬や取引手数料（MEV）を奪取できます。

2. ネットワークのライブネスと安全性への脅威
資金力のある攻撃者はこの「スナイプ」攻撃を繰り返し、ブロックチェーン全体を遅延させたり停止させたりする ライブネス攻撃 を実行できます。さらに深刻なシナリオでは、取得した情報を用いてネットワーク分断攻撃を仕掛け、チェーン履歴に対する合意が崩れ、安全性攻撃 が成立する恐れがあります。

3. 中央集権的現実の露呈
研究はネットワークの分散性に関する不快な真実も明らかにしました：

極端な集中：ある IP アドレスが 19,000 台以上 のバリデータをホストしているケースが発見されました。単一マシンの障害がネットワーク全体に過大な影響を与える可能性があります。
クラウド依存：特定されたバリデータの 90% が AWS や Hetzner といったクラウドプロバイダー上で稼働しており、個人のホームステーカーではありません。これは重要な集中点です。
隠れた依存関係：大手ステーキングプールは独立した運営と主張しますが、研究では競合プールのバリデータが 同一物理マシン 上で動作している事例が見つかり、見えないシステムリスクが潜んでいることが判明しました。

対策：バリデータはどう守るべきか？

幸いなことに、この匿名性除去手法に対抗する方法はいくつか存在します。研究者は以下の緩和策を提案しています：

ノイズを増やす：バリデータは 2 つ以上、場合によっては全 64 のサブネットを購読できます。これにより、観測者が中継メッセージと自生成メッセージを区別しにくくなります。
複数ノードの活用：オペレーターはバリデータの役割を異なる IP を持つ複数マシンに分散させられます。たとえば、1 台のノードでアテステーションを処理し、別のプライベートノードだけで高価値ブロックの提案を行う、といった構成です。
プライベートピアリング：バリデータは信頼できる仲間ノードとプライベート接続を確立し、メッセージをリレーさせることで、真の送信元を小さな信頼グループ内に隠すことができます。
匿名ブロードキャストプロトコル：Dandelion のように、メッセージをランダムな「ステム」経路で伝搬させてから広範にブロードキャストする手法を導入すれば、送信元特定をさらに困難にできます。

結論

この研究は、分散システムにおけるパフォーマンスとプライバシーのトレードオフを鮮明に示しています。スケーラビリティを追求した結果、Ethereum の $P2P$ ネットワークは最も重要な参加者の匿名性を犠牲にした設計となっていました。

脆弱性を公にしたことで、研究者は Ethereum コミュニティに対し、問題解決に必要な知識とツールを提供しました。彼らの取り組みは、将来に向けてより堅牢で安全、そして真に分散化されたネットワークを構築するための重要な一歩です。

TEE とブロックチェーンプライバシー：ハードウェアと信頼の交差点

2024年12月6日 · 約7分

ブロックチェーン業界は2024年に重要な転換点に直面しています。ブロックチェーン技術の世界市場は2030年までに $469.49 億に達すると予測されているものの、プライバシーは根本的な課題のままです。Trusted Execution Environments（TEE）は潜在的な解決策として浮上しており、TEE 市場は2023年の$ 1.2 億から2028年には $3.8 億へと成長すると見込まれています。しかし、このハードウェアベースのアプローチはブロックチェーンのプライバシーパラドックスを本当に解決するのか、あるいは新たなリスクをもたらすのか？

ハードウェアの基盤：TEE の約束を理解する

Trusted Execution Environment は、コンピュータ内の銀行の金庫のように機能しますが、重要な違いがあります。銀行の金庫が単に資産を保管するだけであるのに対し、TEE は機密操作をシステム全体から完全に遮断された隔離された計算環境で実行できるようにします。たとえシステムが侵害されても、TEE 内の処理は保護され続けます。

現在、市場は以下の 3 つの主要実装に支配されています。

Intel SGX（Software Guard Extensions）
- 市場シェア：サーバー向け TEE 実装の 45%
- パフォーマンス：暗号化操作で最大 40% のオーバーヘッド
- セキュリティ機能：メモリ暗号化、リモート証明
- 主な利用者：Microsoft Azure Confidential Computing、Fortanix
ARM TrustZone
- 市場シェア：モバイル向け TEE 実装の 80%
- パフォーマンス：ほとんどの操作で <5% のオーバーヘッド
- セキュリティ機能：セキュアブート、バイオメトリック保護
- 主な利用分野：モバイル決済、DRM、セキュア認証
AMD SEV（Secure Encrypted Virtualization）
- 市場シェア：サーバー向け TEE 実装の 25%
- パフォーマンス：VM 暗号化で 2‑7% のオーバーヘッド
- セキュリティ機能：VM メモリ暗号化、ネストされたページテーブル保護
- 主な利用者：Google Cloud Confidential Computing、AWS Nitro Enclaves

現実のインパクト：データが語る

TEE がすでにブロックチェーンを変革している 3 つの主要ユースケースを見てみましょう。

1. MEV 保護：Flashbots ケーススタディ

Flashbots が TEE を導入した結果、顕著な成果が得られました。

TEE 前（2022 年）
- 平均日次 MEV 抽出額： $ 7.1M
- 集中抽出者：MEV の 85%
- サンドイッチ攻撃によるユーザー損失： $ 3.2M/日
TEE 後（2023 年）
- 平均日次 MEV 抽出額： $ 4.3M（‑39%）
- 分散抽出：単一エンティティが MEV の 15% 超を占めない
- サンドイッチ攻撃によるユーザー損失： $ 0.8M/日（‑75%）

Flashbots 共同創業者の Phil Daian は次のように述べています。「TEE は MEV の風景を根本的に変えました。ユーザーへの被害が大幅に減少し、より民主的で効率的な市場が実現しています。」

2. スケーリングソリューション：Scroll のブレークスルー

Scroll は TEE とゼロ知識証明（ZK Proof）を組み合わせたハイブリッドアプローチで、以下の指標を達成しています。

トランザクションスループット：3,000 TPS（Ethereum の 15 TPS と比較）
1 トランザクションあたりコスト： $ 0.05（Ethereum メインネットの $ 2‑20 と比較）
検証時間：15 秒（純粋な ZK ソリューションは数分）
セキュリティ保証：TEE + ZK の二重検証で 99.99%

UC Berkeley のブロックチェーン研究者 Dr. Sarah Wang は次のように指摘しています。「Scroll の実装は、TEE が暗号的解決策を置き換えるのではなく、補完できることを示しています。パフォーマンス向上は顕著でありながら、セキュリティを犠牲にしていません。」

3. プライベート DeFi：新興アプリケーション

いくつかの DeFi プロトコルがプライベート取引に TEE を活用しています。

Secret Network（Intel SGX 使用）
- 500,000 件以上のプライベート取引を処理
- プライベートトークン転送額： $ 150M
- フロントランニング削減率：95%

技術的現実：課題と解決策

サイドチャネル攻撃の緩和

最新の研究では、脆弱性とそれに対する対策が明らかになっています。

電力解析攻撃
- 脆弱性：鍵抽出成功率 85%
- 解決策：Intel の最新 SGX アップデートで成功率 <0.1% に低減
- コスト：パフォーマンスオーバーヘッド 2% 追加
キャッシュタイミング攻撃
- 脆弱性：データ抽出成功率 70%
- 解決策：AMD のキャッシュ分割技術
- 効果：攻撃面を 99% 削減

中央集権リスク分析

ハードウェア依存は特有のリスクを伴います。

ハードウェアベンダー市場シェア（2023 年）
- Intel：45%
- AMD：25%
- ARM：20%
- その他：10%

この中央集権リスクに対処するため、Scroll などのプロジェクトはマルチベンダー TEE 検証を実装しています。

2 つ以上の異なるベンダー TEE の合意が必須
非 TEE ソリューションとのクロスバリデーション
オープンソースの検証ツールの提供

市場分析と将来予測

ブロックチェーンにおける TEE の採用は急速に拡大しています。

現在の実装コスト
- サーバー向け TEE ハードウェア： $ 2,000‑5,000
- 統合コスト： $ 50,000‑100,000
- メンテナンス： $ 5,000/月
コスト削減予測
- 2024 年：‑15%
- 2025 年：‑30%
- 2026 年：‑50%

業界専門家は 2025 年までに次の 3 つの重要な展開を予測しています。

ハードウェアの進化
- TEE 専用プロセッサの登場
- パフォーマンスオーバーヘッド <1% に低減
- サイドチャネル保護の強化
市場の統合
- 標準化の進展
- クロスプラットフォーム互換性の確立
- 開発者向けツールの簡素化
アプリケーションの拡大
- プライベートスマートコントラクトプラットフォーム
- 分散型アイデンティティソリューション
- クロスチェーンプライバシープロトコル

今後の道筋

TEE は魅力的なソリューションを提供しますが、成功には以下の重要領域への対応が不可欠です。

標準化の推進
- 業界ワーキンググループの結成
- ベンダー横断的なオープンプロトコルの策定
- セキュリティ認証フレームワークの整備
開発者エコシステムの構築
- 新規ツールと SDK の提供
- トレーニング・認定プログラムの実施
- 参照実装の公開
ハードウェアイノベーション
- 次世代 TEE アーキテクチャの開発
- コストとエネルギー消費の削減
- セキュリティ機能の強化

競合環境

TEE は他のプライバシーソリューションと競合しています。

ソリューション	パフォーマンス	セキュリティ	分散性	コスト
TEE	高	中‑高	中	中
MPC	中	高	高	高
FHE	低	高	高	非常に高
ZK プルーフ	中‑高	高	高	高

結論

TEE はブロックチェーンプライバシーに対する実用的なアプローチであり、即時のパフォーマンス向上を提供しつつ、中央集権リスクへの対策も進めています。Flashbots や Scroll といった主要プロジェクトが採用し、セキュリティと効率性の測定可能な改善を実現していることから、TEE はブロックチェーンの進化において重要な役割を果たすと考えられます。

しかし、成功は保証されていません。今後 24 ヶ月は、ハードウェア依存、標準化の取り組み、そしてサイドチャネル攻撃という永続的な課題に業界がどう対処するかが鍵となります。ブロックチェーン開発者や企業にとっては、TEE の強みと限界を正しく理解し、単なる万能薬ではなく包括的なプライバシー戦略の一部として実装することが重要です。

TL;DR​

ポリシーロジックは Move に記述​

しきい値暗号が鍵管理を担う​

開発者体験: SDK とセッションキー​

Seal を設計に組み込むためのベストプラクティス​

今後の展望​

1. TEE 技術の概要​

2. Web3 における TEE の応用​

プライバシー保護スマートコントラクト​

スケーラビリティとオフチェーン計算​

セキュアオラクルとデータ完全性​

オフチェーンでのデータ完全性と検証可能性​

3. TEE を活用する注目の Web3 プロジェクト​

Secret Network​

Oasis Network​

Sanders Network​

iExec​

その他のプロジェクトとエコシステム​

4. 分散環境における TEE の利点と課題​

利点と技術的強み​

信頼の前提とセキュリティ脆弱性​

構成可能性とエコシステムの制限​

5. TEE vs 他のプライバシー保護技術 (ZKP, FHE, MPC)​

6. 主要なブロックチェーンエコシステムにおける採用​

Ethereum (および一般的なレイヤー 1)​

Cosmos エコシステム​

Polkadot と Substrate​

その他のエコシステムと一般的な採用​

7. ビジネスおよび規制上の考慮事項​

プライバシーコンプライアンスと機関投資家の採用​

信頼と責任​

エコシステムとコストの考慮事項​

規制の不確実性​

市場の差別化と新しいサービス​

結論​

完全準同型暗号仮想マシン (FHE-VM)​

FHE-VM のアーキテクチャと設計​

正当性とプライバシーの確保​

ゼロ知識コプロセッサ (ZK-Coprocessors)​

アーキテクチャとワークフロー​

注目すべき ZK コプロセッサプロジェクト​

FHE-VM vs ZK-コプロセッサ: 比較​

ユースケースと影響​

機密 DeFi と金融​

デジタルアイデンティティと個人データ​

ヘルスケアと機密データ共有​

データマーケットプレイスとコラボレーション​

分散型機械学習 (ZKML と FHE-ML)​

その他の分野​

結論​

脆弱性の仕組み：ゴシップの欠陥​

なぜ重要か：匿名性除去のリスク​

対策：バリデータはどう守るべきか？​

結論​

ハードウェアの基盤：TEE の約束を理解する​

現実のインパクト：データが語る​

1. MEV 保護：Flashbots ケーススタディ​

2. スケーリングソリューション：Scroll のブレークスルー​

3. プライベート DeFi：新興アプリケーション​

技術的現実：課題と解決策​

サイドチャネル攻撃の緩和​

中央集権リスク分析​

市場分析と将来予測​

今後の道筋​

競合環境​

結論​

TL;DR

ポリシーロジックは Move に記述

しきい値暗号が鍵管理を担う

開発者体験: SDK とセッションキー

Seal を設計に組み込むためのベストプラクティス

今後の展望

1. TEE 技術の概要

2. Web3 における TEE の応用

プライバシー保護スマートコントラクト

スケーラビリティとオフチェーン計算

セキュアオラクルとデータ完全性

オフチェーンでのデータ完全性と検証可能性

3. TEE を活用する注目の Web3 プロジェクト

Secret Network

Oasis Network

Sanders Network

iExec

その他のプロジェクトとエコシステム

4. 分散環境における TEE の利点と課題

利点と技術的強み

信頼の前提とセキュリティ脆弱性

構成可能性とエコシステムの制限

5. TEE vs 他のプライバシー保護技術 (ZKP, FHE, MPC)

6. 主要なブロックチェーンエコシステムにおける採用

Ethereum (および一般的なレイヤー 1)

Cosmos エコシステム

Polkadot と Substrate

その他のエコシステムと一般的な採用

7. ビジネスおよび規制上の考慮事項

プライバシーコンプライアンスと機関投資家の採用

信頼と責任

エコシステムとコストの考慮事項

規制の不確実性

市場の差別化と新しいサービス

結論

完全準同型暗号仮想マシン (FHE-VM)

FHE-VM のアーキテクチャと設計

正当性とプライバシーの確保

ゼロ知識コプロセッサ (ZK-Coprocessors)

アーキテクチャとワークフロー

注目すべき ZK コプロセッサプロジェクト

FHE-VM vs ZK-コプロセッサ: 比較

ユースケースと影響

機密 DeFi と金融

デジタルアイデンティティと個人データ

ヘルスケアと機密データ共有

データマーケットプレイスとコラボレーション

分散型機械学習 (ZKML と FHE-ML)

その他の分野

結論

脆弱性の仕組み：ゴシップの欠陥

なぜ重要か：匿名性除去のリスク

対策：バリデータはどう守るべきか？

結論

ハードウェアの基盤：TEE の約束を理解する

現実のインパクト：データが語る

1. MEV 保護：Flashbots ケーススタディ

2. スケーリングソリューション：Scroll のブレークスルー

3. プライベート DeFi：新興アプリケーション

技術的現実：課題と解決策

サイドチャネル攻撃の緩和

中央集権リスク分析

市場分析と将来予測

今後の道筋

競合環境

結論