「プライバシー」タグの記事が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 エコシステムにおける信頼実行環境 (TEEs): 深掘り解説

2025年5月17日 · 約105分

1. TEE テクノロジーの概要

定義とアーキテクチャ： 信頼実行環境 (Trusted Execution Environment: TEE) とは、プロセッサ内の安全な領域であり、その内部にロードされたコードとデータを機密性および完全性の観点から保護するものです。実用的には、TEE は CPU 内の隔離された「アンクレイブ (enclave)」として機能します。これは、システムの他の部分から保護された状態で機密性の高い計算を実行できる、一種の 「ブラックボックス」 です。TEE アンクレイブ内で実行されるコードは保護されているため、侵害されたオペレーティングシステムやハイパーバイザであっても、アンクレイブのデータやコードを読み取ったり改ざんしたりすることはできません。TEE が提供する主なセキュリティ特性は以下の通りです。

隔離 (Isolation)： アンクレイブのメモリは他のプロセスや OS カーネルからも隔離されています。攻撃者がマシン上で完全な管理者権限を取得したとしても、アンクレイブのメモリを直接検査したり変更したりすることはできません。
完全性 (Integrity)： ハードウェアによって、TEE で実行されるコードが外部の攻撃によって改変されないことが保証されます。アンクレイブのコードや実行時の状態に対するいかなる改ざんも検出され、侵害された結果が出力されるのを防ぎます。
機密性 (Confidentiality)： アンクレイブ内のデータはメモリ上では暗号化されたまま保持され、CPU 内部で使用されるときのみ復号されるため、秘密データが平文で外部に公開されることはありません。
リモートアテステーション (Remote Attestation)： TEE は、自身が本物であること、および特定の信頼できるコードがその内部で実行されていることをリモートパーティに確信させるための暗号化証明 (アテステーション) を生成できます。これにより、ユーザーは秘密データを提供する前に、アンクレイブが信頼できる状態 (例：正規のハードウェア上で期待通りのコードが実行されている) であることを検証できます。

スマートコントラクト実行のための安全なアンクレイブ「ブラックボックス」としての信頼実行環境の概念図。暗号化された入力 (データとコントラクトコード) は安全なアンクレイブ内で復号および処理され、暗号化された結果のみがアンクレイブから送出されます。これにより、機密性の高いコントラクトデータが TEE 外部の誰に対しても機密に保たれることが保証されます。

内部的には、TEE は CPU におけるハードウェアベースのメモリ暗号化とアクセス制御によって実現されています。例えば、TEE アンクレイブが作成されると、CPU はそのための保護されたメモリ領域を割り当て、専用のキー (ハードウェアに焼き付けられているか、セキュアコプロセッサによって管理されている) を使用して、データを動的に暗号化/復号します。外部ソフトウェアがアンクレイブメモリを読み取ろうとしても、暗号化されたバイト列しか取得できません。この CPU レベルの独自の保護により、ユーザーレベルのコードであっても、特権を持つマルウェアや悪意のあるシステム管理者ですら覗き見や変更ができないプライベートなメモリ領域 (アンクレイブ) を定義することが可能になります。本質的に、TEE は専用のセキュアエレメントやハードウェアセキュリティモジュール (HSM) よりも柔軟でありながら、通常の実行環境よりも高いレベルのセキュリティをアプリケーションに提供します。

主要なハードウェア実装： いくつかのハードウェア TEE テクノロジーが存在し、それぞれアーキテクチャは異なりますが、システム内に安全なアンクレイブを作成するという共通の目的を持っています。

Intel SGX (Software Guard Extensions)： Intel SGX は、最も広く使用されている TEE 実装の 1 つです。アプリケーションがプロセスレベルでアンクレイブを作成することを可能にし、メモリ暗号化とアクセス制御は CPU によって強制されます。開発者は、コードを「信頼できる」コード (アンクレイブ内) と「信頼できない」コード (通常の世界) に分割し、特別な命令 (ECALL/OCALL) を使用してアンクレイブとの間でデータをやり取りする必要があります。SGX はアンクレイブに対して強力な隔離を提供し、Intel のアテステーションサービス (IAS) を介したリモートアテステーションをサポートしています。Secret Network や Oasis Network をはじめとする多くのブロックチェーンプロジェクトは、SGX アンクレイブ上でプライバシー保護スマートコントラクト機能を構築しました。しかし、複雑な x86 アーキテクチャ上での SGX の設計はいくつかの脆弱性を招いており (§4 参照)、Intel によるアテステーションは中央集権的な信頼への依存をもたらします。
ARM TrustZone： TrustZone は、プロセッサの実行環境全体を セキュアワールド (Secure World) と ノーマルワールド (Normal World) の 2 つに分割するという異なるアプローチを取っています。機密性の高いコードは、特定の保護されたメモリや周辺機器にアクセスできるセキュアワールドで実行され、ノーマルワールドでは通常の OS やアプリケーションが実行されます。ワールド間の切り替えは CPU によって制御されます。TrustZone は、モバイルデバイスや IoT デバイスで、セキュアな UI、決済処理、デジタル著作権管理 (DRM) などによく使用されています。ブロックチェーンの文脈では、TrustZone は秘密鍵や機密ロジックをスマートフォンの安全なアンクレイブ内で実行できるようにすることで、モバイルファーストの Web3 アプリケーションを可能にする可能性があります。ただし、TrustZone のアンクレイブは通常、粒度が大きく (OS または VM レベル)、現在の Web3 プロジェクトでは SGX ほど一般的ではありません。
AMD SEV (Secure Encrypted Virtualization)： AMD の SEV テクノロジーは、仮想化環境を対象としています。アプリケーションレベルのアンクレイブを必要とする代わりに、SEV は仮想マシン (VM) 全体のメモリを暗号化できます。組み込みのセキュリティプロセッサを使用して暗号化キーを管理し、メモリの暗号化を実行するため、ホスト側のハイパーバイザに対しても 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 の活用

信頼された実行環境（TEEs）は、Web3 における最も困難な課題のいくつかを解決するための強力なツールとなっています。セキュアでプライベートな計算レイヤーを提供することで、TEE はプライバシー、スケーラビリティ、オラクルのセキュリティ、および整合性の分野において、ブロックチェーンアプリケーションの新たな可能性を切り拓きます。以下に主要な活用領域を紹介します。

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

Web3 における TEE の最も顕著な用途の一つは、機密スマートコントラクト（confidential smart contracts） の実現です。これは、ブロックチェーン上で実行されながらも、プライベートなデータを安全に処理できるプログラムです。Ethereum のようなブロックチェーンは、デフォルトで透明性が高く、すべてのトランザクションデータとコントラクトの状態が公開されています。この透明性は、機密性が必要なユースケース（例：非公開の金融取引、秘密投票、個人データの処理）においては問題となります。TEE は、ブロックチェーンに接続されたプライバシー保護型の計算エンクレーブとして機能することで、このソリューションを提供します。

TEE を活用したスマートコントラクトシステムでは、トランザクションの入力値はバリデーターまたはワーカーノード上のセキュアエンクレーブに送信され、外部からは暗号化されたままエンクレーブ内部で処理されます。その後、エンクレーブは暗号化またはハッシュ化された結果をチェーンに返します。復号キーを持つ権限のある当事者（またはコントラクトロジック自体）のみが、平文の結果にアクセスできます。例えば、Secret Network はコンセンサスノードで Intel SGX を使用して、暗号化された入力に対して CosmWasm スマートコントラクトを実行します。これにより、アカウント残高、取引金額、コントラクトの状態などを公開せずに計算に利用することが可能になります。これは、金額が非公開のプライベートトークンスワップや、入札額が暗号化されオークション終了後にのみ公開される秘密オークションなど、秘密 DeFi（secret DeFi） アプリケーションを実現しています。別の例として、Oasis Network の Parcel や機密 ParaTime があります。これらはデータをトークン化し、機密性の制約下でスマートコントラクトで使用できるようにし、プライバシー規制を遵守しながらブロックチェーン上での信用スコアリングや医療データの活用などのユースケースを可能にします。

TEE によるプライバシー保護型スマートコントラクトは、企業や機関によるブロックチェーンの採用において魅力的です。組織は、機密性の高いビジネスロジックやデータを保護しながら、スマートコントラクトを活用できます。例えば、銀行は TEE 対応のコントラクトを使用して、顧客データをオンチェーンにさらすことなくローン申請や取引決済を処理し、同時にブロックチェーンの透明性と整合性のメリットを享受できます。この機能は、GDPR や HIPAA などの規制上のプライバシー要件に直接対応するものであり、ヘルスケア、金融、その他の機密性の高い業界でコンプライアンスを維持したブロックチェーン利用を可能にします。実際、TEE はコンプライアンスを促進します。個人データがエンクレーブ内で処理され、暗号化された出力のみが外部に出ることを保証することで、データが保護されていることを規制当局に示し、データ保護法を満たすことができます。

機密性に加えて、TEE はスマートコントラクトにおける 公平性（fairness） の強制にも役立ちます。例えば、分散型取引所（DEX）はマッチングエンジンを TEE 内部で実行することで、マイナーやバリデーターが保留中の注文を閲覧し、不正にフロントランニング（先回り注文）を行うことを防ぐことができます。要約すると、TEE は Web3 に待望の プライバシーレイヤー をもたらし、これまでパブリックレジャー上では不可能だった機密 DeFi、プライベート投票/ガバナンス、企業向けコントラクトなどのアプリケーションを解き放ちます。

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

TEE のもう一つの重要な役割は、負荷の高い計算をセキュアな環境でオフチェーンに逃がすことで、ブロックチェーンの スケーラビリティ を向上させることです。ブロックチェーンは、パフォーマンスの限界やオンチェーン実行のコストのため、複雑または計算負荷の高いタスクの処理に苦労しています。TEE を活用したオフチェーン計算により、これらのタスクをメインチェーンの外で実行できるようになります（そのため、ブロックのガスを消費せず、オンチェーンのスループットを低下させません）。同時に、結果の正当性については信頼の保証を維持できます。実質的に、TEE は Web3 のための 検証可能なオフチェーン計算アクセラレータ として機能します。

例えば、iExec プラットフォームは TEE を使用して分散型クラウドコンピューティングマーケットプレイスを構築しており、開発者は計算をオフチェーンで実行し、ブロックチェーンから信頼される結果を得ることができます。dApp は、iExec のワーカーノードによって実行される計算（例えば、複雑な AI モデルの推論やビッグデータ分析）をリクエストできます。これらのワーカーノードは SGX エンクレーブ内でタスクを実行し、正当なエンクレーブで正しいコードが実行されたというアテステーション（証明）と共に結果を生成します。その後、結果はオンチェーンに返され、スマートコントラクトは出力を受け入れる前にエンクレーブのアテステーションを検証できます。このアーキテクチャにより、信頼を犠牲にすることなく重いワークロードを処理でき、実質的にスループットを向上させます。iExec Orchestrator と Chainlink の統合がこれを示しています。Chainlink オラクルが外部データを取得し、iExec の TEE ワーカーに複雑な計算（データの集約やスコアリングなど）を渡し、最終的にセキュアな結果がオンチェーンに届けられます。ユースケースには、iExec が実証した分散型保険の計算などがあります。ここでは、膨大なデータ処理を安価にオフチェーンで行い、最終的な結果のみをブロックチェーンに記録します。

TEE ベースのオフチェーン計算は、一部の レイヤー 2（L2）スケーリングソリューション の基盤にもなっています。Oasis Labs の初期のプロトタイプである Ekiden（Oasis Network の前身）は、SGX エンクレーブを使用してトランザクションの実行を並列にオフチェーンで行い、状態ルート（state roots）のみをメインチェーンにコミットしていました。これは本質的にロールアップの概念に似ていますが、ハードウェアの信頼を利用しています。TEE でコントラクトを実行することで、セキュリティを維持しながら高いスループットを実現しました。別の例は、Sanders Network が今後リリースする Op-Succinct L2 です。これは TEE と zkSNARKs を組み合わせたものです。TEE がトランザクションをプライベートかつ迅速に実行し、その後、それらの実行の正当性を Ethereum に対して証明するために ZK 証明（ゼロ知識証明）が生成されます。このハイブリッドアプローチは、スケーラブルでプライベートな L2 ソリューションのために、TEE のスピードと ZK の検証可能性をレバレッジしています。

一般に、TEE は（分離されているだけで実際の CPU 命令を使用するため）ネイティブに近いパフォーマンスで計算を実行できるため、複雑なロジックにおいて、準同型暗号やゼロ知識証明のような純粋な暗号学的代替手段よりも数桁高速です。作業をエンクレーブにオフロードすることで、ブロックチェーンはオンチェーンでは非実用的な複雑なアプリケーション（機械学習、画像/音声処理、大規模分析など）を処理できるようになります。結果はアテステーションと共に返され、オンチェーンのコントラクトやユーザーはそれが信頼されたエンクレーブから発信されたものであることを検証できるため、データの整合性 と正当性が保たれます。このモデルはしばしば 「検証可能なオフチェーン計算（verifiable off-chain computation）」 と呼ばれ、TEE は多くのそのような設計（例：Intel、iExec などによって開発された Hyperledger Avalon の Trusted Compute Framework は、TEE を使用して EVM バイトコードをオフチェーンで実行し、正当性の証明をオンチェーンに投稿します）の要となっています。

セキュアなオラクルとデータの整合性

オラクル はブロックチェーンと現実世界のデータを橋渡ししますが、信頼に関する課題が生じます。オフチェーンのデータフィードが正しく、改ざんされていないことをスマートコントラクトはどうやって信頼すればよいのでしょうか？ TEE は、オラクルノードのためのセキュアなサンドボックスとして機能することで、この解決策を提供します。TEE ベースのオラクル ノードは、外部ソース（API、ウェブサービス）からデータを取得し、ノードオペレーターやノード上のマルウェアによってデータが操作されていないことを保証するエンクレーブ内で処理できます。エンクレーブは、提供するデータの真実性を署名または証明（アテスト）できます。これにより、オラクルの データの整合性と信頼性 が大幅に向上します。たとえオラクルオペレーターが悪意を持っていたとしても、エンクレーブのアテステーションを壊さずにデータを変更することはできません（これはブロックチェーンによって検知されます）。

注目すべき例は、コーネル大学で開発されたオラクルシステム Town Crier です。これは Intel SGX エンクレーブを使用して認証済みデータを Ethereum コントラクトに提供した最初期の例の一つです。Town Crier は（HTTPS ウェブサイトなどから）SGX エンクレーブ内でデータを取得し、データがソースから直接取得され偽造されていないという証拠（エンクレーブ署名）と共にコントラクトに届けます。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 は実行しているコードを（アテステーションを通じて）証明でき、干渉なしにコードが実行されることを保証できるため、一種の 検証可能なコンピューティング（verifiable computing） を提供します。ユーザーやスマートコントラクトは、アテステーションが正当であれば、あたかもオンチェーンで計算されたかのように TEE からの結果を信頼できます。この整合性の保証こそが、TEE がオフチェーンのデータや計算に 「信頼のアンカー（trust anchor）」 をもたらすと言われる理由です。

ただし、この信頼モデルは一部の前提をハードウェアにシフトさせている点に注意が必要です（§4 参照）。データの整合性は、TEE のセキュリティと同じ強さしか持ちません。エンクレーブが侵害されたり、アテステーションが偽造されたりすれば、整合性は損なわれる可能性があります。それでも、実際には（最新の状態に保たれている場合）TEE は特定の攻撃を著しく困難にします。例えば、DeFi のレンディングプラットフォームは、TEE を使用してユーザーのプライベートデータからオフチェーンで信用スコアを計算し、スマートコントラクトは有効なエンクレーブアテステーションが伴う場合にのみそのスコアを受け入れることができます。これにより、コントラクトは、ユーザーやオラクルを盲目的に信頼するのではなく、承認されたアルゴリズムによって実際のデータに基づいてスコアが計算されたことを知ることができます。

TEE は、台頭しつつある 分散型 ID（DID） や認証システムにおいても役割を果たします。プライベートキー、個人データ、および認証プロセスを安全に管理し、ユーザーの機密情報がブロックチェーンや dApp プロバイダーにさらされることがないようにします。例えば、モバイルデバイス上の TEE が生体認証を処理し、生体認証がパスした場合にのみブロックチェーンのトランザクションに署名することができます。これらすべてをユーザーの生体情報を明かすことなく行えます。これは、Web3 がパスポート、証明書、KYC データなどをユーザー主権の形で扱うために不可欠な、セキュリティとプライバシーの両方を提供します。

要約すると、TEE は Web3 における多目的なツールとして機能します。オンチェーンロジックの 機密性 を可能にし、オフチェーンのセキュア計算による スケーリング を許可し、オラクルやブリッジの 整合性 を保護し、プライベート ID からコンプライアンスを遵守したデータ共有まで、新たな用途を切り拓きます。次に、これらの機能を活用している特定のプロジェクトを見ていきましょう。

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

数多くの主要なブロックチェーンプロジェクトが、信頼実行環境（TEE）を中心にコアサービスを構築しています。以下では、いくつかの注目すべきプロジェクトを取り上げ、それぞれがどのように TEE 技術を使用し、どのような独自の価値を付加しているかを詳しく見ていきます。

Secret Network

Secret Network は、TEE を使用してプライバシーを保護するスマートコントラクトを開拓した（Cosmos SDK で構築された）レイヤー 1 ブロックチェーンです。Secret Network のすべてのバリデータノードは Intel SGX エンクレーブを実行しており、スマートコントラクトのコードを実行することで、コントラクトの状態や入力・出力がノード運用者に対しても暗号化されたまま維持されます。これにより、Secret は最初期の プライバシー優先のスマートコントラクトプラットフォーム の一つとなりました。プライバシーはオプションの追加機能ではなく、プロトコルレベルでのネットワークのデフォルト機能です。

Secret Network のモデルでは、ユーザーは暗号化されたトランザクションを送信し、バリデータはそれを実行のために SGX エンクレーブにロードします。エンクレーブは入力を復号し、コントラクト（修正された CosmWasm ランタイムで記述）を実行し、ブロックチェーンに書き込まれる暗号化された出力を生成します。正しい閲覧キー（または内部キーを持つコントラクト自体）を持つユーザーのみが、実際のデータを復号して表示できます。これにより、アプリケーションは機密データを公開することなくオンチェーンで使用できるようになります。

このネットワークは、いくつかの斬新なユースケースを実証しています。

Secret DeFi: 例として SecretSwap（AMM）があります。ユーザーの口座残高や取引額が非公開であるため、フロントランニングを軽減し、取引戦略を保護します。流動性提供者やトレーダーは、競合他社に自分の動きをすべて知られることなく活動できます。
Secret Auctions: オークションが終了するまで入札額が秘密にされるオークションコントラクトで、他者の入札に基づく戦略的行動を防ぎます。
プライベートな投票とガバナンス: トークン保有者は自分の投票選択を明かすことなく提案に投票でき、集計結果は検証可能です。これにより、公平で脅迫のないガバナンスが保証されます。
データマーケットプレイス: 機密性の高いデータセットを、購入者やノードに生データをさらすことなく取引し、計算に使用できます。

Secret Network は本質的に、プロトコルレベルで TEE を組み込む ことで、「プログラマブル・プライバシー」という独自の価値提案を生み出しています。彼らが取り組んでいる課題には、分散型バリデータセット間でのエンクレーブ・アテステーション（証明）の調整や、バリデータに秘密を保持しつつコントラクトが入力を復号できるようにするためのキー配布の管理などがあります。あらゆる面で、Secret はパブリックブロックチェーン上での TEE を活用した機密保持の実行可能性を証明し、この分野のリーダーとしての地位を確立しました。

Oasis Network

Oasis Network もスケーラビリティとプライバシーを目的としたレイヤー 1 であり、そのアーキテクチャにおいて TEE（Intel SGX）を広範囲に活用しています。Oasis は、コンセンサスと計算を分離 し、コンセンサス層（Consensus Layer） と ParaTime 層（ParaTime Layer） と呼ばれる異なる層に分ける革新的な設計を導入しました。コンセンサス層はブロックチェーンの順序付けとファイナリティを処理し、各 ParaTime はスマートコントラクトのランタイム環境となります。特に、Oasis の Emerald ParaTime は EVM 互換環境であり、Sapphire は TEE を使用してスマートコントラクトの状態を非公開に保つコンフィデンシャル EVM です。

Oasis による TEE の使用は、大規模な機密計算 に焦点を当てています。重い計算を（多くのノードで実行可能な）並列化可能な ParaTime に分離することで高いスループットを実現し、それらの ParaTime ノード内で TEE を使用することで、機密データを明かすことなく計算に含めることができます。例えば、金融機関は Oasis 上で機密データをコンフィデンシャル ParaTime に投入することで、信用スコアリングアルゴリズムを実行できます。データは（エンクレーブ内で処理されるため）ノードに対して暗号化されたままであり、スコアのみが出力されます。一方、Oasis のコンセンサスは、計算が正しく行われたという証明のみを記録します。

技術的には、Oasis は標準的な SGX 以上のセキュリティレイヤーを追加しました。彼らは「層状の信頼の基点（layered root of trust）」を実装しました。これは、Intel の SGX Quoting Enclave とカスタムの軽量カーネルを使用してハードウェアの信頼性を検証し、エンクレーブのシステムコールをサンドボックス化するものです。これにより、アタックサーフェス（攻撃対象領域）が縮小され（エンクレーブが実行できる OS コールをフィルタリングするため）、既知の特定の SGX 攻撃から保護されます。また、Oasis は、エンクレーブが再起動後も状態を維持できる 永続的エンクレーブ（durable enclaves） や、ノードが古いエンクレーブ状態を再生しようとするロールバック攻撃を軽減するための セキュアロギング などの機能を導入しました。これらの革新は彼らの技術論文で説明されており、Oasis が TEE ベースのブロックチェーンコンピューティングにおいて研究主導型のプロジェクトと見なされる理由の一部となっています。

エコシステムの観点から、Oasis は プライベート DeFi（銀行が顧客データを漏洩させることなく参加できるようにする）や データのトークン化（個人や企業が AI モデルに機密性を保ったままデータを提供し、ブロックチェーンを通じて報酬を得る）などの分野で地位を確立しています。また、企業とのパイロットプロジェクト（例えば BMW とのデータプライバシーに関する取り組みや、医療研究データの共有など）でも協力しています。全体として、Oasis Network は、TEE とスケーラブルなアーキテクチャを組み合わせることで、プライバシーとパフォーマンスの両方の課題をどのように解決できるかを示しており、TEE ベースの Web3 ソリューションにおける重要なプレーヤーとなっています。

Sanders Network

Sanders Network は、Polkadot エコシステムにおける分散型クラウドコンピューティングネットワークであり、TEE を使用して機密性が高く高性能な計算サービスを提供します。これは Polkadot の パラチェーン であり、Polkadot のセキュリティと相互運用性の恩恵を受けつつ、セキュアエンクレーブ内でのオフチェーン計算のための独自のランタイムを導入しています。

Sanders の中心的なアイデアは、サンダーズ・マイナー（Sanders miners） と呼ばれるワーカーノードの大規模なネットワークを維持することです。これらのノードは 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 とゼロ知識証明（ZKP）の組み合わせ（言及されているように、彼らの次期 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 内部のデータに対して実行するアルゴリズムを送信できます（これにより、プロバイダーの生データは決して明かされず、知的財産が保護され、アルゴリズムの詳細も隠すことができます）。計算結果は購入者に返され、データプロバイダーへの適切な支払いはスマートコントラクトを介して処理されます。この仕組みは セキュア・データ・エクスチェンジ とも呼ばれ、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 – TEE を活用してプライベートトランザクション、匿名投票、MEV 耐性のあるトランザクション処理を実現する Web3 プライバシー用ミドルウェアプロトコルです。Automata はオフチェーンネットワークとして動作し、プライベート RPC リレーなどのサービスを提供しており、シールドされたアイデンティティやガスレスのプライベートトランザクションなどに TEE を使用していると言及されています。
Hyperledger Sawtooth (PoET) – エンタープライズ領域では、Sawtooth が SGX に依存した Proof of Elapsed Time（経過時間証明）と呼ばれるコンセンサスアルゴリズムを導入しました。各バリデータはランダムな時間待機して証明を生成するエンクレーブを実行し、待機時間が最も短いバリデータがブロックを「獲得」します。これは SGX によって強制される公平な抽選です。Sawtooth はそれ自体が Web3 プロジェクトではありませんが（エンタープライズブロックチェーン寄り）、コンセンサスのための TEE の独創的な活用例です。
企業向け・コンソーシアムチェーン – 多くのエンタープライズブロックチェーンソリューション（ConsenSys Quorum や IBM Blockchain など）は、承認されたノードのみが特定のデータを見ることができる機密コンソーシアムトランザクションを可能にするために TEE を組み込んでいます。例えば、Enterprise Ethereum Alliance の Trusted Compute Framework（TCF）のブループリントは、TEE を使用してプライベートコントラクトをオフチェーンで実行し、マークルプルーフをオンチェーンに提供します。

これらのプロジェクトは、TEE の汎用性をまとめて示しています。TEE はプライバシー重視の L1 全体に電力を供給し、オフチェーンネットワークとして機能し、オラクルやブリッジなどのインフラストラクチャを保護し、コンセンサスアルゴリズムの基盤にさえなります。次に、分散型の設定で TEE を使用することの広範な利点と課題について検討します。

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

ブロックチェーンシステムに信頼実行環境（TEE）を導入することには、大きな 技術的利点 と、注目すべき 課題およびトレードオフ が伴います。ここでは、TEE が分散型アプリケーションに提供するものと、その使用から生じる問題やリスクの両側面を検討します。

利点と技術的強み

強固なセキュリティとプライバシー: 最も重要な利点は、機密性と完全性 の保証です。TEE を使用すると、外部のマルウェアによって監視されたり改ざんされたりすることなく、機密性の高いコードを実行できることが保証されます。これにより、以前は不可能だったオフチェーン計算における信頼レベルが提供されます。ブロックチェーンにとって、これはセキュリティを犠牲にすることなく、プライベートデータを利用できる（dApp の機能を強化できる）ことを意味します。信頼できない環境（クラウドサーバー、第三者が運営するバリデーターノード）であっても、TEE は秘密を安全に保ちます。これは、暗号資産システム内での秘密鍵、ユーザーデータ、独自のアルゴリズムの管理に特に有益です。例えば、ハードウェアウォレットやクラウド署名サービスは、秘密鍵がプレーンテキストで公開されないように TEE を使用して内部でブロックチェーン取引に署名し、利便性とセキュリティを両立させることができます。
ネイティブに近いパフォーマンス: ゼロ知識証明（ZK 証明）や準同型暗号のような、安全な計算のための純粋に暗号学的なアプローチとは異なり、TEE のオーバーヘッドは比較的小さいです。コードは CPU 上で直接実行されるため、エンクレーブ内での計算は、外部で実行するのとほぼ同じ速さになります（エンクレーブの遷移やメモリの暗号化による、通常は SGX で数パーセント程度の速度低下というオーバーヘッドはあります）。これは、TEE が 計算集約型のタスクを効率的に処理できる ことを意味し、暗号プロトコルで行うと桁違いに遅くなるようなユースケース（リアルタイムのデータフィード、複雑なスマートコントラクト、機械学習など）を可能にします。エンクレーブの 低レイテンシ は、高速なレスポンスが必要な場面（例：TEE によって保護された高頻度取引ボット、あるいは遅延が大きいとユーザー体験が損なわれるインタラクティブなアプリケーションやゲーム）に適しています。
スケーラビリティの向上（オフロードによる）: 重い計算をオフチェーンで安全に行えるようにすることで、TEE はメインチェーンの混雑とガス代の軽減に役立ちます。これにより、ブロックチェーンを検証や最終的な決済のみに使用し、計算の大部分を並列化されたエンクレーブで行うレイヤー 2 設計やサイドプロトコルが可能になります。このモジュール化（計算集約型のロジックは TEE で、コンセンサスはオンチェーンで）により、分散型アプリのスループットとスケーラビリティを劇的に向上させることができます。例えば、DEX は TEE を使用してオフチェーンでマッチングを行い、一致した取引のみをオンチェーンに投稿することで、スループットを向上させ、オンチェーンのガス代を削減できます。
ユーザー体験と機能性の向上: TEE を使用することで、dApp は機密保持や複雑な分析などの機能を提供でき、より多くのユーザー（機関投資家を含む）を惹きつけることができます。また、TEE は、プライベートトランザクションのガス代を削減するための Automata の取り組みに見られるように、オフチェーンで安全に実行してから結果を提出することで、ガスレスまたはメタトランザクション を可能にします。さらに、機密性の高いステート（状態）をエンクレーブ内のオフチェーンに保存することで、オンチェーンで公開されるデータを削減でき、これはユーザーのプライバシーとネットワーク効率（保存・検証するオンチェーンデータが少なくなる）にとって有益です。
他の技術とのコンポーザビリティ（構成可能性）: 興味深いことに、TEE は他の技術を補完することができます（これは TEE 単体固有の利点ではなく、組み合わせによるものです）。TEE はハイブリッドソリューションをまとめる接着剤として機能します。例えば、エンクレーブ内でプログラムを実行し、同時にその実行の ZK 証明を生成する場合、エンクレーブが証明プロセスの一部を支援して高速化させることができます。あるいは、MPC（マルチパーティ計算）ネットワークで TEE を使用して、少ない通信ラウンドで特定のタスクを処理することもできます。比較については第 5 節で説明しますが、多くのプロジェクトは、TEE が暗号技術を 置き換える 必要はなく、セキュリティを強化するために並行して機能できることを強調しています（Sanders の理念：「TEE の強みは、他を置き換えることではなく、他をサポートすることにある」）。

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

その強みにもかかわらず、TEE は特定の信頼の前提を導入するものであり、無敵ではありません。以下の課題を理解することが極めて重要です。

ハードウェアへの信頼と中央集権化: TEE を使用することは、本質的に シリコンベンダー と、そのハードウェア設計およびサプライチェーンのセキュリティを信頼することを意味します。例えば、Intel SGX を使用するということは、Intel にバックドアがなく、製造が安全であり、CPU のマイクロコードがエンクレーブの隔離を正しく実装していることを信頼することを意味します。これは、純粋な暗号技術（全ユーザーに分散された数学的仮定に依存する）と比較して、より中央集権的な信頼モデルです。さらに、SGX のアテステーション（証明）は歴史的に Intel のアテステーションサービスへの問い合わせに依存しており、もし Intel がオフラインになったり、鍵を無効にすることを決定したりすれば、世界中のエンクレーブが影響を受ける可能性があります。このように特定の企業のインフラに依存することは懸念を引き起こします。単一障害点（SPOF）になる可能性や、政府規制の対象になる可能性さえあります（例：理論上、米国の輸出規制によって、強力な 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 をこれらに対して強化するための活発な研究分野です（例えば、定数時間演算によるエンクレーブコードの設計、秘密に依存するメモリアクセスパターンを避けること、Oblivious RAM のような技術の使用など）。一部のプロジェクトでは、ZK 証明と組み合わせたり、異なるハードウェアベンダーの複数のエンクレーブを実行して単一チップのリスクを低減したりするなど、二次的なチェックで TEE を補強しています。
パフォーマンスとリソースの制約: TEE は CPU バウンドなタスクに対してネイティブに近い速度で動作しますが、いくつかのオーバーヘッドと制限があります。エンクレーブへの切り替え（ECALL）と切り出し（OCALL）にはコストがかかり、メモリページの暗号化・復号も同様です。これは、エンクレーブの境界を頻繁に跨ぐ処理のパフォーマンスに影響を与える可能性があります。また、エンクレーブには メモリサイズの制限 があることが多いです。例えば、初期の SGX ではエンクレーブページキャッシュが制限されており、エンクレーブがより多くのメモリを使用すると、ページのスワップ（暗号化を伴う）が発生し、パフォーマンスが大幅に低下しました。新しい TEE であっても、システム RAM の すべて を簡単に使用できるわけではなく、上限がある可能性のある安全なメモリ領域が存在します。これは、非常に大規模な計算やデータセットをすべて TEE 内部で処理するのが難しい場合があることを意味します。Web3 の文脈では、これによりエンクレーブで実行できるスマートコントラクトや ML モデルの複雑さが制限される可能性があります。開発者はメモリを最適化し、場合によってはワークロードを分割する必要があります。
アテステーションと鍵管理の複雑さ: 分散型の設定で TEE を使用するには、堅牢なアテステーションのワークフローが必要です。各ノードは、期待されるコードを含む本物のエンクレーブを実行していることを他者に証明する必要があります。この オンチェーンでのアテステーション検証 の設定は複雑になる可能性があります。通常、ベンダーの公開アテステーションキーまたは証明書をプロトコルにハードコーディングし、検証ロジックをスマートコントラクトやオフチェーンクライアントに記述する必要があります。これはプロトコル設計にオーバーヘッドをもたらし、いかなる変更（Intel がアテステーション署名キーの形式を EPID から DCAP に変更するなど）もメンテナンスの負担となります。さらに、TEE 内での鍵の管理（データの復号や結果の署名用）も複雑さを増大させます。エンクレーブの鍵管理におけるミスは、セキュリティを根底から覆す可能性があります（例：バグによってエンクレーブが誤って復号鍵を公開してしまった場合、その機密性の約束はすべて崩壊します）。ベストプラクティスとしては、TEE のシーリング API を使用して鍵を安全に保存し、必要に応じて鍵をローテーションすることが挙げられますが、これも開発者による慎重な設計が必要です。
サービス拒否（DoS）と可用性: あまり議論されない問題かもしれませんが、TEE は可用性の面では役に立たず、むしろ新しい DoS の経路を導入する可能性があります。例えば、攻撃者は、エンクレーブがオペレーターによって簡単に検査されたり中断されたりできないことを逆手に取り（隔離されているため）、処理コストの高い入力を TEE ベースのサービスに送りつける可能性があります。また、脆弱性が見つかりパッチを適用するためにファームウェアのアップデートが必要になった場合、そのサイクル中、ノードにパッチが適用されるまで、多くのエンクレーブサービスが（セキュリティのために）一時停止しなければならず、ダウンタイムが発生する可能性があります。ブロックチェーンのコンセンサスにおいて、もし重大な SGX のバグが見つかった場合、Secret Network のようなネットワークは、エンクレーブへの信頼が損なわれるため、修正されるまで停止しなければならないかもしれません。分散型ネットワークにおいてこのような対応を調整することは困難です。

コンポーザビリティとエコシステムの制限

他のコントラクトとのコンポーザビリティの制限: Ethereum のようなパブリックなスマートコントラクトプラットフォームでは、コントラクトは他のコントラクトを簡単に呼び出すことができ、すべてのステートが公開されているため、「DeFi のマネーレゴ」や豊かな構成が可能です。TEE ベースのコントラクトモデルでは、機密性を損なうことなく プライベートなステートを自由に共有したり構成したりすることはできません。例えば、エンクレーブ内のコントラクト A がコントラクト B と対話する必要があり、両方が機密データを保持している場合、それらはどのように連携するのでしょうか？複雑なセキュアマルチパーティプロトコルを実行するか（これでは TEE のシンプルさが損なわれます）、あるいは 1 つのエンクレーブに統合するか（モジュール性が低下します）のどちらかが必要です。これは Secret Network などが直面している課題です。プライバシーを維持したままのコントラクト間の呼び出しは容易ではありません。一部のソリューションでは、単一のエンクレーブで複数のコントラクトの実行を処理し、内部で共有秘密を管理できるようにしていますが、これによってシステムがよりモノリシックになる可能性があります。したがって、プライベートコントラクトのコンポーザビリティはパブリックなものよりも制限される か、新しい設計パターンが必要になります。同様に、既存のブロックチェーン dApp に TEE ベースのモジュールを統合するには、慎重なインターフェース設計が必要です。多くの場合、エンクレーブの結果（SNARK やハッシュなど）のみがオンチェーンに投稿され、他のコントラクトはその限られた情報しか利用できません。これは確かにトレードオフです。Secret のようなプロジェクトは、ビューイングキーを提供し、必要最小限の範囲で秘密の共有を許可していますが、通常のオンチェーンコンポーザビリティほどシームレスではありません。
標準化と相互運用性: TEE エコシステムは現在、ベンダー間での統一された標準が欠如しています。Intel SGX、AMD SEV、ARM TrustZone はすべて、プログラミングモデルやアテステーション方法が異なります。この断片化は、SGX エンクレーブ向けに書かれた dApp が TrustZone などに簡単に移植できないことを意味します。ブロックチェーンにおいて、これはプロジェクトを特定のハードウェアに縛り付ける可能性があります（例：Secret と Oasis は現在 x86 サーバーの SGX に紐付けられています）。将来的に ARM ノード（例えばモバイル上のバリデーター）をサポートしたい場合、追加の開発や異なるアテステーション検証ロジックが必要になります。アテステーションやエンクレーブ API を標準化しようとする取り組み（Confidential Computing Consortium (CCC) など）はありますが、まだ完全には至っていません。標準の欠如は開発ツールにも影響します。成熟した 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 が不滅であると仮定しない）を採用し、信頼されるコンピューティングベース（TCB）を最小限に抑え、ユーザーに対して信頼の前提を透明にすること（例えば、ブロックチェーンのコンセンサスに加えて Intel のハードウェアを信頼していることを明確にするなど）が重要です。

5. TEE と他のプライバシー保護技術（ZKP、FHE、MPC）の比較

信頼実行環境（TEE）は、Web3 においてプライバシーとセキュリティを実現するためのアプローチの 1 つですが、他にも ゼロ知識証明（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 はハードウェアのバグやサイドチャネル攻撃によって損なわれる可能性があります。ZKP や FHE のセキュリティは、基礎となる数学（楕円曲線や格子問題など）が突破された場合に損なわれますが、これらは十分に研究された問題であり、攻撃は気づかれやすい傾向にあります（また、パラメータの選択によって既知のリスクを軽減できます）。MPC のセキュリティは、プロトコルがそれに対応して設計されていない場合、アクティブな攻撃者によって破られる可能性があります（一部の MPC プロトコルは参加者が「誠実だが好奇心が強い」ことを前提としており、誰かが露骨に不正を働くと失敗する可能性があります）。ブロックチェーンの文脈では、TEE の侵害はより壊滅的になる可能性があります（パッチが適用されるまで、すべてのエンクレーブベースのコントラクトがリスクにさらされる可能性があります）。一方、ZK の暗号学的な破綻（例：ZK ロールアップで使用されているハッシュ関数の欠陥の発見）も壊滅的ですが、より単純な仮定に基づいているため、一般的には可能性が低いと考えられています。攻撃の対象面は大きく異なります。TEE は電力解析などを心配する必要がありますが、ZK は数学的な画期的進歩を心配する必要があります。
データプライバシー： FHE と ZK は、データが暗号学的に保護され続けるため、最も強力なプライバシー保証を提供します。MPC はデータが秘密共有されることを保証するため、単一の当事者がそれを見ることはありません（ただし、出力が公開されたり、プロトコルが慎重に設計されていなかったりすると、一部の情報が漏洩する可能性があります）。TEE は外部に対してデータを非公開に保ちますが、エンクレーブの内部ではデータは復号されます。もし誰かが何らかの方法でエンクレーブの制御を奪えば、データの機密性は失われます。また、TEE は通常、コードがデータに対して何でも行うことを許可します（コードが悪意を持っている場合、サイドチャネルやネットワークを通じて意図せずデータを漏洩させることも含まれます）。そのため、TEE ではハードウェアだけでなく、エンクレーブの コード も信頼する必要があります。対照的に、ZKP は秘密を一切明かすことなくコードの特性を証明するため、コード自体を信頼する必要さえありません（証明された特性を実際に持っていること以外は）。もしエンクレーブアプリケーションにログファイルへデータを漏洩させるバグがあったとしても、TEE ハードウェアはそれを防げません。一方、ZK 証明システムは、意図された証明以外は何も明らかにしません。これは微妙なニュアンスです。TEE は外部の攻撃者からは保護しますが、エンクレーブプログラム自体のロジックバグからは必ずしも保護しません。一方で ZK の設計は、より宣言的なアプローチを強制します（意図したものだけを証明し、それ以外は何も証明しない）。
コンポーザビリティと統合： TEE は既存のシステムへの統合が比較的容易です。既存のプログラムを取り込み、エンクレーブに入れることで、プログラミングモデルを大きく変えることなくセキュリティ上の利点を得ることができます。ZK や FHE は、プログラムを回路や制限された形式に書き換える必要があり、これには多大な労力がかかることがよくあります。例えば、単純な AI モデルの検証を ZK で記述する場合、それを一連の算術演算と制約に変換する必要があります。これは、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 は控えめな仮定（ハードウェアへの信頼）に基づいた、安全な計算への非常に 実用的で即時性のある道 を提供します。一方、ZKP と FHE はより 理論的でトラストレスな道 を提供しますが、高い計算コストがかかります。そして MPC は、ネットワークコストを伴う 分散型の信頼の道 を提供します。Web3 における適切な選択は、アプリケーションの要件に依存します：

プライベートなデータに対する高速で複雑な計算（AI、大規模データセットなど）が必要な場合 — 現在、TEE（または少数の当事者による MPC）が唯一の実行可能な方法です。
最大限の分散化と検証可能性 が必要な場合 — ZK 証明が適しています（例えば、Zcash のようなプライベートな暗号資産取引では、ユーザーは数学以外何も信頼したくないため、ZKP が好まれます）。
複数のステークホルダー間での協調計算 が必要な場合 — MPC が自然に適しています（マルチパーティのキー管理やオークションなど）。
極めて機密性の高いデータがあり、長期的なプライバシーが必須 な場合 — パフォーマンスが向上すれば FHE が魅力的になります。なぜなら、数年後に誰かが暗号文を入手したとしても、鍵がなければ何も知ることができないからです。一方、エンクレーブが侵害された場合、ログが保存されていれば過去に遡って秘密が漏洩する可能性があります。

ブロックチェーン領域では、これらすべての技術が並行して積極的に探求されていることは注目に値します。今後、組み合わせ が増えていくでしょう。例えば、TEE を統合した Layer 2 ソリューション で取引のシーケンシングを行い、TEE がルールに従ったことを ZKP で証明する（イーサリアムの研究で探求されている概念）、あるいは 各ノードで TEE を使用する MPC ネットワーク により、各ノードが内部的に安全で複数の当事者をシミュレートできるため、MPC プロトコルの複雑さを軽減する、といった手法です。

最終的に、TEE vs ZK vs MPC vs FHE はゼロサムの選択ではありません。これらはそれぞれ、セキュリティ、パフォーマンス、トラストレス性 というトライアングルの異なるポイントをターゲットにしています。ある記事が指摘したように、4 つすべてがパフォーマンス、コスト、セキュリティの「不可能なトライアングル」に直面しており、すべての面において優れた単一のソリューションは存在しません。最適な設計とは多くの場合、問題の適切な部分に適切なツールを使用することです。

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

Trusted Execution Environments（TEE）は、各コミュニティの優先事項や統合の容易さに影響され、様々なブロックチェーンエコシステムで異なるレベルの採用が進んでいます。ここでは、主要なエコシステムである Ethereum、Cosmos、Polkadot、およびその他のネットワークにおいて、TEE がどのように使用（または検討）されているかを評価します。

Ethereum（および一般的なレイヤー 1）

Ethereum のメインネット自体では、TEE はコアプロトコルの一部ではありませんが、アプリケーションやレイヤー 2（L2） で使用されています。Ethereum の哲学は暗号学的なセキュリティ（例：台頭しつつある ZK ロールアップ）に依存していますが、TEE は Ethereum のオラクルやオフチェーン実行において役割を見出しています。

オラクルサービス: 前述の通り、Chainlink は Town Crier のような TEE ベースのソリューションを組み込んでいます。すべての Chainlink ノードがデフォルトで TEE を使用しているわけではありませんが、追加の信頼が必要なデータフィードのための技術は存在します。また、API3（別のオラクルプロジェクト）も、API を実行しデータの真正性を保証するために Intel SGX を使用することに言及しています。これらのサービスは、より強力な保証を伴うデータを Ethereum のコントラクトに提供します。
レイヤー 2 とロールアップ: Ethereum コミュニティでは、ロールアップのシーケンサーやバリデーターに TEE を使用することについて、継続的な研究と議論が行われています。例えば、ConsenSys の「ZK-Portal」コンセプトなどは、オプティミスティック・ロールアップにおける正しい順序付けの強制や、シーケンサーを検閲から保護するために TEE を使用することを提案しています。ある Medium の記事では、2025 年までに、高頻度取引の保護などのために TEE が一部の L2 でデフォルトの機能になる可能性さえ示唆されています。Catalyst（高頻度取引 DEX）や Flashbots（MEV リレー用）のようなプロジェクトは、トランザクションがブロックチェーンに到達する前に、それらの公正な順序付けを強制するために TEE を検討してきました。
エンタープライズ Ethereum: コンソーシアム型または許可型の Ethereum ネットワークでは、TEE はより広く採用されています。Enterprise Ethereum Alliance（EEA）の 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）もありました。より最近では、Oasis Ethereum ParaTime（Oasis Sapphire）により、Oasis の TEE バックエンドを使用して機密性を保ちながら Solidity コントラクトを実行し、Ethereum で決済を行うことが可能になっています。また、医療データの共有やゲーミングなど、一部の Ethereum ベースの DApp は、コントラクトとやり取りするオフチェーンのエンクレーブコンポーネントを持たせることで TEE を試験的に導入しています。

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

Cosmos エコシステム

Cosmos エコシステムは、モジュール式の SDK とソブリンチェーンにより実験に対して寛容であり、Secret Network（前述）は Cosmos における TEE 採用の代表的な例です。Secret Network は実際には Tendermint コンセンサスを備えた Cosmos SDK チェーンであり、バリデーターに SGX を義務付けるように変更されています。これはメインの Cosmos Hub に次いで最も著名な Cosmos ゾーンの一つであり、そのコミュニティにおいて TEE 技術が大きく採用されていることを示しています。インターチェーン・プライバシーを提供する Secret Network の成功（IBC 接続を通じて、Secret は他の Cosmos チェーンのプライバシーハブとして機能できる）は、レイヤー 1（L1）における TEE 統合の注目すべき事例です。

もう一つの Cosmos 関連プロジェクトは Oasis Network です（Cosmos SDK で構築されているわけではありませんが、Tendermint に貢献した一部の人々によって設計され、モジュール型アーキテクチャという同様の理念を共有しています）。Oasis は独立していますが、ブリッジなどを通じて Cosmos に接続できます。Secret と Oasis はどちらも、Cosmos 圏において TEE による「機能としてのプライバシー」という考え方が、専用ネットワークを正当化するのに十分な牽引力を得たことを示しています。

Cosmos には、インターチェーン・アプリケーション向けの「プライバシープロバイダー」という概念さえあります。例えば、あるチェーン上のアプリが IBC 経由で Secret Network 上のコントラクトを呼び出して機密計算を実行し、その結果を書き戻すといったことが可能です。このようなコンポーザビリティ（相互運用性）が現在現れつつあります。

さらに、Anoma プロジェクト（厳密には Cosmos ではありませんが、相互運用性の意味で関連がある）は、インテント中心（intent-centric）のアーキテクチャに 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 または Crust?: いくつかの Polkadot 関連プロジェクトでは、分散型ストレージやランダムビーコンに TEE を使用するアイデアがありました。例えば、Crust Network（分散型ストレージ）は当初 TEE ベースのストレージ証明を計画していました（後に別の設計に移行しました）。また、Polkadot のランダムパラチェーン（Entropy）では、TEE と VRF の比較検討が行われました。

Polkadot はオンチェーンガバナンスとアップグレードに依存しているため、パラチェーンは新しい技術を迅速に取り入れることができます。Sanders と Integritee はどちらも、TEE 統合を改善するためのアップグレード（新しい SGX 機能のサポートやアテステーション方法の洗練など）を行ってきました。Web3 Foundation も、TEE 内でのオフチェーンコントラクト実行とオンチェーン検証を実証した初期のプロトタイプである SubstraTEE のような、Substrate ベースの TEE プロジェクトへの初期の取り組みに資金を提供しました。

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

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

エンタープライズとコンソーシアム: パブリックな暗号資産の枠を超えて、Hyperledger やエンタープライズチェーンは許可型の設定で TEE を着実に採用してきました。例えば、バーゼル委員会は TEE ベースの貿易金融ブロックチェーンをテストしました。一般的なパターンとして、プライバシーやデータの機密性が必須であり、参加者が既知である場合（ハードウェア・セキュリティ・モジュールに共同で投資することさえある場合）、TEE は適した解決策となります。これらは暗号資産のニュースで大きく取り上げられることはないかもしれませんが、サプライチェーン、銀行コンソーシアム、ヘルスケアデータ共有ネットワークなどの分野では、TEE がしばしば第一選択肢となります（単に第三者を信頼したり、重い暗号技術を使用したりする代わりの手段として）。
Ethereum 以外のレイヤー 1: いくつかの新しい L1 が TEE を試行しています。NEAR Protocol には、プライベートコントラクトのための TEE ベースのシャードという初期のコンセプトがありました（まだ実装されていません）。Celo は、ライトクライアントの証明に TEE を検討しました（彼らの Plumo 証明は現在 SNARK に依存していますが、一時期モバイル向けにチェーンデータを圧縮するために SGX を検討していました）。規制に準拠したプライバシー L1 である Concordium は、匿名性のために ZK を使用していますが、本人確認（Identity Verification）のために 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 年）では、少なくとも 3〜4 のパブリックチェーン（Secret、Oasis、Sanders、Integritee、およびオフチェーンとしての Automata）が明示的に TEE を使用しており、主要なオラクルネットワークもそれを組み込んでいます。また、大手テック企業もコンフィデンシャル・コンピューティングを後押ししています（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 のエンクレーブにおける「 durable logging （永続的ロギング）」は、機密性の高い操作の改ざん耐性のあるログを提供します。企業はそのログを規制当局に提示し、許可されたコードのみが実行され、顧客データに対して特定のクエリのみが行われたことを証明できます。このような 認証された監査 は、システム管理者のログを信頼する従来のシステムよりも規制当局を満足させる可能性があります。

信頼と責任

反面、 TEE の導入はブロックチェーン・ソリューションにおける信頼構造、ひいては 責任モデル を変化させます。 DeFi プラットフォームが TEE を使用しており、ハードウェアの欠陥によって何らかの不具合が生じた場合、誰が責任を負うのでしょうか？例えば、 Intel SGX のバグによって秘密のスワップ取引の詳細が漏洩し、ユーザーが資金を失った（フロントランニングなど）シナリオを考えてみましょう。ユーザーはプラットフォームのセキュリティの主張を信頼していました。これはプラットフォームの責任でしょうか、それとも Intel の責任でしょうか？法的には、ユーザーはプラットフォームを追求する可能性があり（プラットフォームは今度は Intel を追求しなければならないかもしれません）、セキュリティ・モデルに サードパーティのテクノロジー・プロバイダー （ CPU ベンダー）が深く関わっているため、事態は複雑になります。 TEE を使用するビジネスは、契約やリスク評価においてこれを考慮する必要があります。一部の企業は、クリティカルなインフラで TEE を使用する場合、ハードウェア・ベンダーからの保証やサポートを求めるかもしれません。

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

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

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

ビジネスの観点からは、 TEE の使用はブロックチェーン運用の コスト構造 に影響を与える可能性があります。ノードは特定の CPU （高価であったり、エネルギー効率が悪かったりする可能性があります）を搭載している必要があります。これは、クラウド・ホスティング費用の増加や資本支出を意味する可能性があります。例えば、あるプロジェクトがすべてのバリデーターに Intel Xeon with SGX を義務付けた場合、それは制約となります。バリデーターは 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 の設計では、 Intel 自身でさえエンクレーブ・メモリを復号することはできません（ Intel は処理を行う 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 のリーチを拡大させることができるでしょう。

結論

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

技術的には、 TEE は速度と強力なデータ機密性という魅力的なメリットを提供しますが、同時に独自の課題も伴います。ハードウェアベンダーへの信頼の必要性、潜在的なサイドチャネル脆弱性、そして統合とコンポーザビリティにおけるハードルです。 TEE を暗号学的代替手段（ ZKP 、 FHE 、 MPC ）と比較した結果、それぞれに独自の役割があることがわかりました。 TEE はパフォーマンスと使いやすさにおいて際立っており、一方で ZK と FHE は高いコストと引き換えに最大限のトラストレス性を提供し、 MPC は参加者間で信頼を分散させます。実際、多くの最先端のソリューションはハイブリッド型であり、 TEE と暗号学的手法を併用することで両方の長所を取り入れています。

TEE ベースのソリューションの採用は着実に進んでいます。 Ethereum の dApps はオラクルのセキュリティやプライベートな計算に 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 の強みと限界を正しく理解し、単なる万能薬ではなく包括的なプライバシー戦略の一部として実装することが重要です。

API Marketplace Featured

TL;DR​

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

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

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

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

今後の展望​

1. TEE テクノロジーの概要​

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

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

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

セキュアなオラクルとデータの整合性​

オフチェーンにおけるデータの整合性と検証可能性​

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

Secret Network​

Oasis Network​

Sanders Network​

iExec​

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

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

利点と技術的強み​

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

コンポーザビリティとエコシステムの制限​

5. TEE と他のプライバシー保護技術（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 と他のプライバシー保護技術（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：新興アプリケーション

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

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

中央集権リスク分析

市場分析と将来予測

今後の道筋

競合環境

結論