10月になると、「TEE（Trusted Execution Environment）」という用語がXフィードで頻繁に登場するようになりました。これは驚きでした。なぜなら、TEEは従来はニッチなトピックであり、主にシステムセキュリティの学術的な議論で扱われていたからです。システムセキュリティの研究を行っていた私としては、この進展を喜んでいました。しかし、なぜTEEが突如Web3の領域で注目を集め始めたのかについては興味がありました。また、一般の人々にTEEの概念をわかりやすく説明するコンテンツが不足していることにも気づきました。それが私がこの記事を執筆する動機となりました。

TEEは、コンピューターサイエンスのバックグラウンドがないと完全に理解することが難しい複雑なコンセプトです。そのため、この記事では基本的なTEEの概念から始め、Web3がTEEを利用することに興味を持っている理由を説明し、そして現在のWeb3プロジェクトにおけるTEEの実装とその制限について議論します。

要約すると、この記事では以下のトピックをカバーします:

• TEEの概念の紹介と現代のTEEの概要についての簡単な概観
• Web3エコシステム内のさまざまなTEEの実装ケース
• TEEの制限とこれらの制限に対する個人的な視点
• Web3エコシステムにおけるTEEの未来

1. TEEとは何ですか？

多くの読者は、TEEが正確に何を意味するのかを完全に理解するために必要な背景知識を持っていないと思います。TEEは、深く探求すると非常に複雑な概念ですので、できるだけ簡単に説明しようと思います。

基本的な概念

ほとんどのWeb2サーバーは、認証設定を通じてデータアクセスを管理します。ただし、このアプローチは純粋にソフトウェアベースであるため、より高いレベルの権限を取得すると本質的に無効になります。たとえば、攻撃者がサーバーのオペレーティングシステムでカーネルレベルの権限を取得した場合、暗号化キーを含むサーバー上のすべての権限制御されたデータにアクセスできる可能性があります。このような極端なシナリオでは、ソフトウェアベースの方法だけではデータの盗難を防ぐ方法はほとんどありません。TEE(Trusted Execution Environment)は、ハードウェアベースのセキュリティを通じてこの問題に根本的に対処しようとします。TEE は "コンフィデンシャル コンピューティング" と呼ばれることがよくありますが、これは ZK、MPC、FHE など、ユーザー データのプライバシーを確保する計算メカニズムを含む、より広い概念です。

source: 呪術廻戦

簡単な類推を使うと、TEEはメモリ内の暗号化されたゾーンのように機能します。TEE内のすべてのデータは暗号化されており、外部からの生データのアクセスが不可能になっています。OSカーネルでさえ、元の形式でそれを読み取ったり変更したりすることはできません。したがって、サーバー上で攻撃者が管理者特権を取得したとしても、TEE内のデータを復号化することはできません。この暗号化された領域はしばしば「エンクレーブ」と呼ばれます。

エンクレーブを作成し、その中でデータを処理するには、オペコードと同様に、特定の命令セットが必要です。これらの命令では、ハードウェアで保護された領域に格納されている暗号化キーを使用して、エンクレーブ内のデータに対して計算を実行します。TEEはハードウェアレベルのセキュリティモジュールであるため、その実装はCPUチップベンダーによって異なります。たとえば、Intel は SGX をサポートし、AMD は SEV をサポートし、ARM は TrustZone をサポートします。より広い視点から見ると、これらの実装は「ハードウェアレベルの暗号化によるメモリの保護」という概念を共有しています。

1.1. TEEがデータを保護する方法

まず、最も一般的なTEEであるIntel SGX、AMD SEV、およびARM TrustZoneの動作を調査し、その後、より最近のTEE実装を紹介します。

1.1.1. OG TEEs

Intel SGX

SGXはプロセスレベルでエンクレーブを作成し、アクセスします。次のイメージは、SGX対応プログラムの動作方法を明確に示しています。

source: https://sgx101.gitbook.io/sgx101/sgx-bootstrap/enclave/interaction-between-pse-and-application-enclaves

開発中、開発者は信頼できるコードと信頼できないコードを区別する必要があります。エンクレーブによって保護される必要がある変数または関数は信頼できるコードとして指定され、他の操作は信頼できないコードとして分類されます。信頼できないコードが信頼できるコードにデータを入力する必要がある場合や、信頼できるコードが信頼できないコードと対話する必要がある場合、ECALLおよびOCALLと呼ばれる特殊なシステムコールが使用されます。

source: https://www.intel.com/content/www/us/ja/developer/articles/training/intel-software-guard-extensions-tutorial-part-7-refining-the-enclave.html

ユーザーがエンクロージャ内のデータと直接やり取りする必要がある場合、たとえば入力を提供したり出力を受け取ったりする場合、SSLなどのプロトコルを使用して確立された安全なチャネルを介して通信することができます。

AMD SEV

SGX がプロセスレベルで enclave を作成するのに対し、SEV は仮想マシンレベルでそれらを作成します。 仮想マシンに割り当てられたメモリは暗号化され、独立したキーで管理され、サーバーのオペレーティングシステムや他の VM からデータを保護します。 仮想マシンは通常、サンドボックス化された隔離により安全であると見なされていますが、この隔離を compromize する脆弱性を完全に排除することはできません。 SEV はそのようなシナリオでセキュリティを提供するよう設計されています。

SEVは、VMの作成中にCPUから物理的に分離されたセキュリティプロセッサを介して暗号鍵を生成します。これらの鍵は、VMメモリの暗号化に使用されます。次の図は、SGXとSEVの違いを示しています。

ソース：10.1109/SRDS.2018.00042

SGXでは、開発者にコードを信頼できないセグメントと信頼できるセグメントに明示的に分けるよう要求します。一方、SEVは仮想マシンのメモリ全体を暗号化し、実装の観点から開発者に比較的少ない努力を要求します。

ARM TrustZone

インテルやAMDとは異なり、主にデスクトップやサーバー向けのCPUを製造する一方、ARMはモバイルや組み込みデバイスなどの軽量システム向けのチップセットを設計しています。そのため、彼らのセキュアエンクレーブの実装は、より高度なアーキテクチャで使用されているSGXやSEVとは少し異なります。

TrustZoneは、ハードウェアレベルでシステムをセキュアワールドと通常ワールドに分割します。TrustZoneを使用する開発者は、セキュアワールドでセキュリティ上重要な機能を実装する必要があり、一般的な機能は通常ワールドで実行されます。これらの2つの世界の移行は、SGXに似た特別なシステムコールであるセキュアモニターコールを介して行われます。

鍵となる違いは、TrustZoneのエンクレーブがCPUやメモリだけでなく、システムバス、周辺機器、割り込みコントローラなど、システム全体を包含していることです。Appleはまた、製品でSecure EnclaveというTEEを利用しており、高レベルではTrustZoneに非常に似ています。

1.1.2. 高度なTEE

後で話すように、Intel SGXを含む多くのオリジナルTEEは、構造上の問題によるサイドチャネルの脆弱性や開発上の課題に直面してきました。これらの問題に対処するために、ベンダーは改良版をリリースしています。安全なクラウドコンピューティングへの需要の高まりに伴い、AWS/Azure/GCPなどのプラットフォームが独自のTEEサービスを提供し始めました。最近では、TEEの概念がGPUにも拡張されています。一部のWeb3ユースケースではこれらの先進的なTEEを実装しており、それについて簡単に説明します。

Cloud TEEs：AWS Nitro、Azure Confidential Computing、Google Cloud Confidential Computing

クラウドコンピューティングサービスの需要が増えるにつれて、プロバイダーは独自のTEEソリューションの開発を始めました。 AWSのNitroは、EC2インスタンスと共に動作するエンクレーブコンピューティング環境です。専用のNitroセキュリティチップを使用して、計算環境の物理的な分離を実現します。 Nitroハイパーバイザは、チップによって提供される機能を使用してエンクレーブメモリ領域を保護し、ユーザーおよびクラウドプロバイダーからの攻撃に対して効果的にシールドします。

Azureは、Intel SGX、AMD SEV-SNP、および独自の仮想化ベースの分離など、さまざまなTEE仕様をサポートしています。このハードウェア環境の柔軟性は、ユーザーにより多くのオプションを提供しますが、複数のTEEを利用する場合には攻撃面が増加する可能性があります。

Google Cloudは、Trusted Execution Environments (TEE) を利用した機密コンピューティングサービスを提供しており、AI/MLワークロードに焦点を当てています。AWS Nitroとは異なり、Google CloudはAzureと同様に既存のTEEインフラストラクチャを使用した仮想化ベースの分離を提供しています。主な違いは、インテル AMXなどのCPUアクセラレータのサポートによる集中型AI/MLタスクの処理と、後述するNVIDIAを通じたGPUベースの機密コンピューティングです。

ARM CCA

ARM CCAは2021年末にリリースされ、TrustZoneとは異なり、クラウド環境に特化しています。TrustZoneは単一の組み込みまたはモバイル環境向けに設計されており、事前に指定されたセキュアメモリ領域を静的に管理します。一方、CCAはRealms（セキュアエンクレーブ）の動的な作成を容易にします。これにより、1つの物理的なセットアップ内で複数の分離された環境を実現することができます。

CCAは、Intel SGXのARMバージョンと見なすことができますが、いくつかの違いがあります。SGXはメモリの制限がありますが、CCAは柔軟なメモリ割り当てを提供します。さらに、CCAは、SGXが指定されたエンクレーブ領域だけでなく、物理メモリ全体を暗号化するという、基本的に異なるセキュリティアプローチを採用しています。

Intel TDX

Intelは、AMDのSEVに類似した、VMレベルでメモリを暗号化するTDXという技術を導入しました。このリリースでは、SGX(v1)の制限事項（256MBのエンクレーブサイズ制限やプロセスレベルのエンクレーブ作成による開発の複雑さの増加など）に対するフィードバックに対応しています。SEVとの主な違いは、TDXがVMリソース管理のためにオペレーティングシステム、特にハイパーバイザを一部信頼することです。さらに、各VMの暗号化メカニズムにも違いがあります。

AMD SEV-SNP

SEV-SNPは既存のSEVモデルのセキュリティを向上させます。元のSEVは信頼モデルに依存しており、ハイパーバイザーがメモリマッピングを変更する可能性がある脆弱性を残していました。SEV-SNPは、メモリ状態を追跡するハードウェアマネージャーを追加することで、この問題に対処しています。

また、ユーザーはリモートアタステーションを直接実行することも可能であり、これにより信頼アンカーを最小限に抑えることができます。SEV-SNPでは、メモリページの状態と所有権を監視するためのリバースマップテーブルも導入されており、悪意のあるハイパーバイザ攻撃モデルに対する防御策を提供しています。

GPU TEE: NVIDIA 機密計算

TEE開発は従来、ハードウェアベンダーに依存しているため、CPUに焦点を当ててきました。しかし、安全なAIトレーニングやトレーニングデータ保護などの複雑な計算を処理する必要性が強調されたことから、GPU TEEの必要性が浮き彫りになりました。これに応えて、NVIDIAは2023年にH100 GPUに機密コンピューティング機能を導入しました。

NVIDIA Confidential Computing は、個別に暗号化および管理された GPU インスタンスを提供し、CPU TEE と組み合わせることでエンドツーエンドのセキュリティを確保します。現在、AMD SEV-SNP または Intel TDX と統合してコンフィデンシャル コンピューティング パイプラインを構築することで、これを実現しています。

1.2. TEEを信頼するにはどうすればいいですか？

Web3プロジェクトを検証する際には、GitHub上でのコードのアップロードによるコミュニティガバナンスの主張をよく見かけます。しかし、サーバーに展開されたプログラムが実際にGitHubのコードと一致しているかどうかをどのように検証できるのでしょうか？

ブロックチェーンは、継続的なコンセンサスにより、スマートコントラクトが常に公開され、変更できない環境を提供します。一方、通常のWeb2サーバーでは、管理者がいつでもプログラムを更新できます。真正性を確認するために、ユーザーはGitHubなどのプラットフォームでオープンソースプログラムからビルドされたバイナリのハッシュ値を比較するか、開発者の署名を通じて整合性を確認する必要があります。

同じ原則は、TEEエンクレーブ内のプログラムにも適用されます。ユーザーがサーバーで展開されたプログラムを完全に信頼するためには、エンクレーブ内のコードとデータが変更されていないことを検証（証明）する必要があります。SGXの場合、特別なエンクレーブに格納されたキーを使用してIAS（Intel Attestation Service）と通信します。IASは、エンクレーブとその内部データの完全性を検証し、その結果をユーザーに返します。要約すると、TEEは、ハードウェアベンダーが提供する証明サーバーと通信してエンクレーブの完全性を確保する必要があります。

2. Web3上のTEE

なぜWeb3上でTEEを使用するのですか？

TEEは一般の人々には馴染みがないかもしれませんが、その知識は通常、専門分野に限定されています。ただし、TEEの登場はWeb3の原則とよく一致しています。TEEを使用する基本的な前提は「誰も信頼しない」です。適切に実装されると、TEEはプログラムの展開者、物理サーバーの所有者、さらにはOSカーネルからユーザーデータを保護することができます。

現在のブロックチェーンプロジェクトは、重要な構造的な分散化を達成していますが、まだシーケンサ、オフチェーンリレーやキーパーボットなど、オフチェーンのサーバ環境に依存しています。KYCや生体認証データなどの機密ユーザ情報を処理する必要があるプロトコルや、プライベートトランザクションをサポートすることを目指すプロトコルは、サービスプロバイダに対する信頼が必要となる課題に直面しています。これらの問題は、エンクレーブ内でのデータ処理によって大幅に軽減される可能性があります。

その結果、TEEは、データプライバシーや信頼性の高いAIエージェントなどのAI関連テーマに合わせて、今年後半に人気を博しました。しかし、Web3エコシステムにTEEを統合しようとする試みは、それ以前から存在していました。この記事では、AIセクターに限定されず、Web3エコシステムでTEEを採用したさまざまな分野のプロジェクトを紹介します。

2.1. 機密共同処理装置

マーリン

Marlinは、TEEまたはZK技術を使用して安全な計算環境を提供するために設計された検証可能なコンピューティングプロトコルです。彼らの主な目標の1つは、分散型のWebを開発することです。Marlinは、OysterとKalypsoの2つのサブネットを管理し、OysterはTEEベースの共同処理プロトコルとして機能します。

1) オイスター CVM

Oyster CVM（利便性を考慮したOyster）はP2P TEEマーケットプレイスとして機能します。ユーザーはOysterのオフチェーンマーケットプレイスを通じてAWS Nitro Enclaveコンピューティング環境を購入し、そこでプログラムイメージを展開します。以下はOysterの抽象的な構造です。

ソース: https://docs.marlin.org/oyster/protocol/cvm/workflow/

OysterはAkashと非常に類似した構造を持っています。Oysterでは、ブロックチェーンの役割は、各TEEコンピューティング環境が正常に動作しているかどうかを検証することです。これは、プロバイダと呼ばれるオブザーバが行います。プロバイダはリアルタイムでエンクレーブの可用性を継続的にチェックし、その結果をOysterネットワークに報告します。彼らはステークを行います $PONDトークンは、悪質な活動に従事した場合にスラッシュされるリスクがある。さらに、「監査人」と呼ばれるエンティティの分散ネットワークがプロバイダのスラッシュを監督するために存在しています。各エポックごとに、監査人は自分の仕事を割り当てられ、エンクレーブ内で生成されたシードによってランダムに選択されたエンクレーブに監査リクエストを送信します。

しかし、オイスターは「gate」と呼ばれる契約を実装しています。NitroProverリモートアテステーションの結果をチェーン上で検証し、購入したTEEの整合性をチェーン上でユーザーが検証できるようにします。

ユーザーが展開したインスタンスは、スマートコントラクトとWeb2 APIの両方を介してアクセスできます。計算結果は、オラクルとして提示することで契約に統合することができます。ダッシュボードに示されているように、この機能はスマートコントラクトだけでなく、Web2サービスの非集中化にも適しています。

Akashに似て、Oysterはオフチェーンのマーケットプレイスに脆弱性がある場合、攻撃者によるインスタンスの乗っ取りのリスクがあります。このようなシナリオでは、エンクレーブデータは安全なままでも、エンクレーブの外部に格納された生データとサービス操作の権限が危険にさらされる可能性があります。信頼できないメモリに格納され、公開されてはならない機密データの場合、開発者はこれらのデータを暗号化し、別個に保存する必要があります。Marlinは現在、これらのケースを処理するために、MPCベースの永続鍵を持つ外部ストレージを提供しています。

2) オイスターサーバーレス

Oyster CVMはP2P TEEマーケットプレイスとして動作し、Oyster ServerlessはAWS Lambda（またはFunction-as-a-Service）とTEEを似ています。Oyster Serverlessを利用すると、ユーザーはインスタンスを借りずに機能を実行できます。オンデマンドで支払う必要がありません。

Oyster Serverlessの実行フローは次のようになります:

1. ユーザーはRelay契約へのリクエストを作成します
2. オフチェーンのゲートウェイサーバーは、イベントを介してユーザーの要求を監視します
3. ゲートウェイサーバーは、ユーザーの要求をゲートウェイプロトコルに中継します
4. ゲートウェイプロトコルはユーザーの要求に基づいてサーバーレスプロトコルにジョブを作成して割り当てます。
5. エグゼキューターサーバーは、Serverlessプロトコルに割り当てられたジョブを受け付け、ジョブを実行して応答を送信します
6. レスポンス — ユーザーのリクエストの結果 — は順番にユーザーに中継されます

Oyster Serverlessを使用すると、ユーザーはスマートコントラクトを介してWeb2 APIリクエストまたはスマートコントラクト呼び出しを送信できます。実行の整合性はTEEによって保証されます。ユーザーは定期的な実行のためにServerlessを購読することもできます。これはオラクルフェッチャーにとって特に便利です。

Phala Network

Phala、以前に当社のAI X Crypto記事で議論されたものは、AIコプロセッサに焦点を大きく移しています。

Phala Networkの基本設計には、Workersとゲートキーパーが含まれています。Workersは、クライアントのために計算を実行する通常のノードとして機能します。一方、ゲートキーパーは、Workersが暗号化された状態値を復号化して計算するためのキーを管理します。Workersは、Intel SGXを介して暗号化された契約状態値を処理し、これらの値を読み取るか書き込むためにゲートキーパーからキーが必要です。

ソース: https://docs.phala.network/tech-specs/blockchain

Phalaは、Intel TDX環境でConfidential VMのためのSDKをサポートすることで、オファリングを拡大しました。最近、Flashbotとの共同開発で、Dstackをローンチしました。この製品には、Confidential VMに展開された複数のDockerコンテナイメージの運用状況を検証するためのリモートアテステーションAPIが搭載されています。Dstackを通じたリモートアテステーションにより、専用の透明性が確保されます。エクスプローラ.

もう一つの重要な進展は、最近のAIプロジェクトの急増に対応して導入された彼らの機密AI推論製品です。Phala Networkは、比較的新しいNvidiaの機密計算をサポートし、ZK/FHEを使用してAI推論サービスを向上させることを目指しています。この技術は以前、高いオーバーヘッドにより課題に直面しており、その実用性が制限されていました。

source: https://docs.phala.network/overview/phala-network/confidential-ai-inference

このイメージは、Phala Networkの機密AI推論システムの構造を示しています。このシステムは、Intel TDXやAMD SEVなどの仮想マシンレベルのTrusted Execution Environments（TEE）を利用してAIモデルを展開します。Nvidiaの機密計算を介してAI推論を行い、結果をCPUエンクレーブに安全に送信します。この方法は、エンクレーブ計算を2回行うため、通常のモデルに比べてかなりのオーバーヘッドが発生する可能性があります。それにもかかわらず、CPUの性能に完全に依存する既存のTEEベースのAI推論方法と比較して、大幅なパフォーマンス向上が期待されています。紙Phala Networkが公開したLlama3ベースのLLM推論オーバーヘッドは、約6〜8%でした。

他の人々

AI X Cryptoドメインでは、他のTEEをコプロセッサとして使用する例として、iExec RLC、PIN AI、およびSuper Protocolがあります。iExec RLCとPIN AIはそれぞれ、TEEを介してAIモデルとトレーニングデータを保護することに焦点を当てています。Super Protocolは、Marlinに類似したTEEコンピューティング環境の取引市場を立ち上げる準備をしています。ただし、これらのプロジェクトの詳細な技術情報はまだ公に利用可能ではありません。彼らの製品がローンチされた後に更新情報を提供します。

2.2. セキュアなスマートコントラクト

Oasis (Prev. Rose)

Oasisは、かつてRoseとして知られていたもので、トランザクション中にユーザーのプライバシーを保護するために、実行クライアントをSGXエンクレーブ内で実行するLayer 1のブロックチェーンです。比較的成熟したチェーンではありますが、Oasisは実行レイヤーでのマルチVMのサポートを革新的に実装しています。

Paratime と呼ばれる実行レイヤーには、次の 3 つのコンポーネントが含まれています。Sapphire:EVMベースのコンフィデンシャルVM。Emerald は、標準的な EVM 互換 VM です。Oasisは、スマートコントラクトとその計算プロセスをノードによる任意の変更から根本的に保護し、実行クライアントがTEEエンクレーブ内で動作するようにします。この構造を添付の図に示します。

ソース：https://docs.oasis.io/general/oasis-network/

ユーザーがトランザクションを送信する際、オアシスノードのキーマネージャーがエンクレーブ内で生成した一時鍵を使用してトランザクションデータを暗号化し、計算モジュールに送信します。計算モジュールは、キーマネージャーから一時鍵の秘密鍵を受け取り、エンクレーブ内のデータを復号化し、スマートコントラクトを実行し、ノードの状態値を変更します。トランザクションの実行結果も暗号化された形式でユーザーに配信されるため、オアシスノードクライアントのサーバーまたは外部のエンティティはトランザクションの内容を観察することはできません。

Oasisは、公開ブロックチェーン上で個人情報を扱うDAppsの作成を支援することで、その強みを示しています。Confidential Paratimeを使用することで、この機能により、ソーシャルファイ、クレジット貸付、CEX統合サービス、評判に基づくサービスなど、身元確認が必要なサービスの開発が可能となります。これらのアプリケーションは、安全なエンクレーブ内でユーザーの生体認証情報やKYC情報を安全に受け取り、検証することができます。

Secret Network

Secret Networkは、Cosmosエコシステム内のレイヤー1チェーンであり、最も古いTEEベースのブロックチェーンの1つです。Intel SGXエンクレーブを活用してチェーンの状態値を暗号化し、ユーザーのプライベートトランザクションをサポートしています。

Secret Networkでは、各契約には各ノードのエンクレーブに保存されているユニークな秘密キーがあります。ユーザーが公開鍵で暗号化されたトランザクションを介して契約を呼び出すと、ノードはTEE内でトランザクションデータを復号して契約の状態値とやり取りします。これらの変更された状態値はその後、ブロックに記録され、暗号化されたままとなります。

契約自体は、バイトコードまたはソースコード形式で外部エンティティと共有することができます。ただし、ネットワークは、ユーザーが送信した取引データの直接観察を防止し、外部の観察や現在の契約状態値の改ざんをブロックすることにより、ユーザーの取引プライバシーを保証します。

すべてのスマートコントラクトの状態値は暗号化されているため、それらを表示するには復号化が必要です。Secret Networkは、ビューイングキーを導入することでこれに対処しています。これらのキーは、特定のユーザーパスワードを契約にバインドし、認可されたユーザーのみが契約の状態値を観察できるようにします。

クリック、クエックスプロトコル

以前紹介したTEEベースのL1とは異なり、CliqueとQuex Protocolは、一般的なDAppsがオフチェーンTEE環境にプライベート計算を委任できるようにするインフラストラクチャを提供します。これらの結果は、スマートコントラクトレベルで利用できます。これらは、検証可能なインセンティブ配布機構、オフチェーンオーダーブック、オラクル、KYCデータ保護に特に使用されています。

2.3. 有効性の証明システム

一部のZK L2チェーンでは、ゼロ知識証明の固有の不安定性に対処するために、しばしばTEE証明を組み込んだマルチプルーフシステムを採用しています。現代のゼロ知識証明メカニズムは、安全性のために完全に信頼されるほど成熟していないため、ZK回路の音響に関連するバグが発生した場合、修正にはかなりの努力が必要です。予防策として、ZK証明またはZK-EVMを使用するチェーンでは、エンクレーブ内のローカルVMを介してブロックを再実行することで潜在的なバグを検出するTEE証明を採用しています。現在、Taiko、Scroll、およびTernoaは、TEEを含むマルチプルーフシステムを利用しているL2です。彼らのマルチプルーフシステムを使用する動機と構造を簡単に調べてみましょう。

太鼓

Taikoは現在、最も目立っている（計画中の）Basedロールアップチェーンです。ロールアップチェーンは、別個の中央集権型シーケンサーを維持せずに、Ethereumブロック提案者にシーケンスの委任を行います。TaikoのBased Rollupの図によれば、L2のサーチャーはトランザクションバンドルを構成し、それらをバッチとしてL1に送信します。L1ブロック提案者は、これらとL1のトランザクションを再構築してL1ブロックを生成し、MEVを取り込みます。

source: https://docs.taiko.xyz/core-concepts/multi-proofs/

Taikoでは、TEEはブロック構成の段階ではなく、証明生成の段階で利用されています。分散構造を持つTaikoは、シーケンサの障害の検証を必要としません。ただし、L2ノードクライアントのコードベースにバグがある場合、完全に分散化されたセットアップでは迅速に対応することはできません。これにより、セキュリティを確保するための高レベルの有効性証明が必要となり、他のロールアップに比べてより複雑なチャレンジデザインになります。

Taikoのブロックは提案、証明、検証の3つの段階を経ます。ブロックが提案されるのは、TaikoのL1コントラクト（ロールアップコントラクト）による妥当性のチェックが行われたときです。並列プルーフによって検証されたときに証明された状態に達し、親ブロックが証明されたときに検証された状態に達します。Taikoは、SGX V2ベースのTEEプルーフ、Succinct / RiscZeroベースのZKプルーフ、中央集権型のマルチシグに依存するGuardianプルーフの3種類のプルーフを使用してブロックを検証します。

Taikoは、ブロックの検証に対して競合モデルを採用し、Provers間でセキュリティティアラーキーを確立します: TEE、ZK、ZK+TEE、およびGuardian。この設定により、チャレンジャーは、上位モデルによって生成された不正な証明を特定すると、より大きな報酬を獲得することができます。各ブロックに必要な証明は、以下のウェイト付けでランダムに割り当てられます: SGX+ZKP用に5%、ZKP用に20%、残りはSGXを使用します。これにより、ZK Proversは常に成功したチャレンジに対してより高い報酬を獲得できるようになります。

読者は、SGXプルーフ生成者がどのようにプルーフを生成および検証するか疑問に思うかもしれません。 SGXプルーフ生成者の主な役割は、太鼓のブロックが標準的な計算によって生成されたことを示すことです。これらのプルーフ生成者は、状態値の変更のプルーフを生成し、TEE環境内のローカルVMを介してブロックを再実行することによる環境を検証し、エンクレーブの検証結果とともに使用します。

莫大な計算コストがかかるZKプルーフ生成とは異なり、TEEベースのプルーフ生成は、同様のセキュリティの仮定の下で、はるかに低いコストで計算の完全性を検証します。これらの証明の検証には、証明に使用されているECDSA署名が証明者の署名と一致することを確認するなど、簡単なチェックが含まれます。

結論として、TEEベースの有効性証明は、ZK証明に比べてわずかに低いセキュリティレベルで証明を生成することで、チェーンの整合性を検証する方法と見なすことができますが、コストはかなり低くなります。

スクロール

Scrollは、Multi-proofシステムを採用した注目のロールアップです。これは後で導入される証明書層であるAutomataと協力して、すべてのブロックに対してZK証明とTEE証明を生成します。この協力により、2つの証明の間の衝突を解決するための紛争システムが活性化されます。

源：https://scroll.io/blog/scaling-security

Scrollは、Intel SGX、AMD SEV、およびAWS Nitroを含むさまざまなハードウェア環境（現在はSGXのみ）をサポートする予定です。これにより、ハードウェアの依存性を最小限に抑えることができます。彼らは、しきい値署名を使用して、異なる環境からの証拠を収集することで、TEEにおける潜在的なセキュリティ問題に対処しています。

Ternoa

Ternoaは、実行自体のバグに対処するよりも、一元化されたL2エンティティによる悪意のあるアクションの検出を優先します。既存のZKプルーフを補完するためにTEEプルーバーを使用するTaikoやScrollとは異なり、TernoaはTEEベースの環境でオブザーバーを採用しています。これらのオブザーバーは、L2シーケンサーやバリデーターによる悪意のあるアクションを検知し、トランザクションデータだけでは評価できない領域に焦点を当てます。例としては、RPCノードがIPアドレスに基づいてトランザクションを検閲したり、シーケンサーがシーケンスアルゴリズムを変更したり、バッチデータを意図的に送信しなかったりします。

Ternoaは、ロールアップエンティティに関連する検証タスクのためにIntegrity Verification Chain（IVC）と呼ばれる別のL2ネットワークを運営しています。ロールアップフレームワークプロバイダーは、最新のシーケンサーイメージをIVCに提出します。新しいロールアップの展開をリクエストすると、IVCはTEEに保存されているサービスイメージを返します。展開後、オブザーバーは定期的に展開されたロールアップが意図した通りにシーケンサーイメージを使用しているかを検証します。その後、彼らは自身の検証結果とTEE環境からの証明報告を組み合わせてチェーンの整合性を確認するための整合性証明を提出します。

2.3. Ethereum セキュリティ

2.3.1. ブロックビルダーの分散化

Flashbots BuilderNet

MEVソリューションプロバイダーとして広く認識されているFlashbotsは、ブロックチェーン技術におけるTrusted Execution Environments（TEE）の応用を一貫して探求してきました。注目すべき研究の取り組みには、次のものがあります:

• SGX エンクレーブ内での Geth 実行とその制限の調査
• SGXベースのブロックビルダーの実装
• SGX Enclave内でREVM実行に基づくTEEコプロセッサチェーンを構築し、オートマータ検証レイヤーで補完する

この記事では、Flashbotsの現在の役割について簡単に説明し、ブロック構築の分散化を目的とした最近のイニシアチブであるBuilderNetについて説明します。Flashbotsは、BuilderNetを通じて、既存のソリューションの完全な移行計画を発表しました。

イーサリアムは、Proposer-Builder Separationモデルを採用しています。このシステムは、ブロック作成を2つの役割に分けます - 1)ビルダー:ブロック作成とMEV抽出を担当 2)提案者:ビルダーが作成したブロックに署名して伝播し、MEVの利益を分散化します。この構造により、一部の分散型アプリケーションがオフチェーンのビルダーと共謀して、MEVの実質的な利益を獲得しています。その結果、BeaverbuildやTitan Builderなどの少数のビルダーが、イーサリアムブロックの90%以上を独占的に作成しています。深刻なケースでは、これらのビルダーは任意のトランザクションを検閲することができます。たとえば、Tornado Cashのような規制された取引は、主要なビルダーによって積極的に検閲されています。

BuilderNetは、トランザクションのプライバシーを向上させ、ブロックビルダーの参加の障壁を低減することで、これらの問題に取り組んでいます。その構造は、大まかに以下のように要約されます:

ソース:https://buildernet.org/docs/architecture

ビルダーノード（Orderflow）は、さまざまなノードオペレーターによって管理されます。それぞれのオペレーターは、Intel TDX環境内でオープンソースのビルダーインスタンスを運用しています。ユーザーは、各オペレーターのTEE環境を自由に検証し、暗号化されたトランザクションを送信できます。オペレーターは受け取ったオーダーフローを共有し、MEV-boostリレーにブロックを提出し、ブロックの作成に関わるサーチャーやその他の関係者にブロック報酬を配布します。提出が成功した場合、ビルダーノードはユーザートランザクションを受け取ります。

この構造は、いくつかの分散化のメリットを提供します:

• 検証可能性: 各 Builder インスタンスは TEE 内で動作するため、ユーザーは Builder がトランザクションを検閲したり、クライアントを任意に変更したりしていないことを確認できます。ブロック作成コントリビューターに対する報酬分配ポリシーも、TEE内で透過的です。
• 検閲耐性：BuilderNetでは、複数のオペレーターが実行するビルダーノードで、それぞれ異なる規制ポリシーがあります。この多様性により、彼らは除外するトランザクションを選択します。いくつかのオペレーターがトランザクションを検閲しても、他のオペレーターが選択できます。理論的には、少なくとも1人の検閲しないビルダーがいれば、ユーザーのトランザクションをブロックに含めることができます。BuilderNetはまた、L2の検閲問題の解決策を提供し、ブロック構築をBuilderNetにアウトソーシングすることで、L2はシングルシーケンサーよりも高い検閲耐性を実現できることを示しています（この場合、シーケンサー前のトランザクションをフィルタリングする追加コンポーネントによって検閲耐性のレベルが影響を受ける可能性があります、たとえばファイアウォール）。
• 分散化:現在のブロックビルダーは、中央集権的なインフラストラクチャへの依存という課題に直面しています。BuilderNetは、Beaverbuildをはじめとする様々なビルダーを統合することで、この問題に対処することを目指しています。より多くのブロックビルダーがBuilderNetに参加するにつれて、イーサリアムのPBS構造は分散化が進むでしょう。現在、Beaverbuild、Flashbots、およびNethermindのみがBuilderNetの一部です。他のビルダーは参加するために許可が必要ですが、将来的にはオペレーターのデプロイをパーミッションレスにし、中央集権的なインフラストラクチャを完全に排除する計画があります。

2.3.2. バリデータ保護

Puffer Finance

Puffer Financeは、クライアントのエラーやバグによってイーサリアムのバリデータがスラッシュされるリスクを軽減するために設計されたSecure Signerツールを導入しました。このツールは、セキュリティを強化するために SGX エンクレーブベースの署名者を使用します。

source: https://docs.puffer.fi/technology/secure-signer/

Secure Signerは、SGXエンクレーブ内でBLSバリデーターキーを生成および保存し、必要な時にのみアクセスすることによって動作します。そのロジックはシンプルであり、信頼された実行環境（TEE）によって提供されるセキュリティに加えて、バリデーターのミスや悪意のある行動を検出できます。これは、スロットが厳密に増加してからブロックまたは証明を署名する前に、バリデーターがセキュリティレベルを達成できるようにすることによって達成されます。Puffer Financeは、このセットアップにより、バリデーターがハードウェアウォレットに匹敵するセキュリティレベルを達成できると強調しており、ソフトウェアソリューションが提供する典型的な保護を上回っています。

2.4. L2シーケンサーの分散化

Unichain

来年第1四半期に開始予定のUniswapのEthereumレイヤー2（L2）チェーンであるUnichainは、信頼できる実行環境（TEE）を使用してL2ブロック構築メカニズムを分散化する計画を白書で共有しています。詳細な技術仕様はまだ公開されていませんが、以下に主な提案の概要をまとめました。

• シーケンサービルダーの分離：シーケンシングとL2ブロック生成が集中型シーケンサーによって処理される既存のロールアップ構造を強化するために、UnichainはFlashbotsと提携しました。このパートナーシップは、L2シーケンサーをブロックビルダーから分離することを目指しています。Unichainのブロックビルダーは、Intel TDX内でオープンソースコードを使用して動作し、実行のための証明結果を公開することで透明性を確保しています。
• Flashblock：Unichainは、ロールアップシーケンサーによって提供される現在の事前確認プロセスにおける拡張性の制限を特定し、シリアル化やステートルートの生成などの問題を解決するために「Flashblocks」を導入する予定です。これにより、TEEビルダーを介してトランザクションの順序付け後にすぐに保留中のブロックを受け取ることができます。彼らは、TEE内のシーケンスにより、優先手数料と送信時間に基づくトランザクションの順序付けがシーケンサーの干渉なしで行われるため、より高速な事前確認が可能になると強調しています。

さらに、Unichainは、暗号化されたメモリプール、スケジュールされた取引、およびTEEで保護されたスマートコントラクトなど、さまざまなTEEベースの機能を開発する予定です。

2.5. プライベートRPC

オートマタ

ブロックチェーンは、アーキテクチャの面で相当な分散化を実現していますが、依然として多くの要素がサーバーオペレーターへの依存により十分な検閲耐性を持っていません。Automataは、TEEに基づくブロックチェーンアーキテクチャにおいて、サーバーオペレーターへの依存とデータ露出を最小限に抑えるソリューションを提供することを目指しています。Automataの注目すべき実装には、オープンソースが含まれます。SGX Proverおよび検証者、TEE コンパイル実行可能ファイルとソースコードで展開されたTEE間の一致を検証します。TEE Builderこれは、TEEベースのmempoolとブロックビルダーを通じて、ブロック構築メカニズムにプライバシーを追加します。さらに、Automataでは、TEEのリモート構成証明結果をオンチェーンで投稿できるため、公開して検証し、スマートコントラクトに統合することができます。

Automataは現在、IPやデバイスの詳細などのトランザクション送信者の識別情報を安全なエンクレーブを介して保護するように設計されたTEEベースのRPCサービスである1RPCを運営しています。Automataは、アカウント抽象化の開発によるUserOpの商用化に伴い、RPCサービスがAI統合を介して特定のユーザーのUserOpパターンを推測し、プライバシーを侵害する可能性があるリスクを強調しています。1RPCの構造は単純です。ユーザーとの安全な接続を確立し、トランザクション (UserOp) を TEE に受信し、エンクレーブ内にデプロイされたコードで処理します。ただし、1RPC は UserOp メタデータのみを保護します。実際の関係者とトランザクションの内容は、オンチェーンのエントリポイントとのやり取り中に公開されたままになります。トランザクションのプライバシーを確保するためのより基本的なアプローチには、mempoolとブロックビルダーレイヤーをTEEで保護することが含まれます。これは、AutomataのTEE Builderと統合することで実現できます。

2.6. AIエージェント

ソース:https://x.com/tee_hee_he

Web3でTEEメタが注目されるようになったのは、TEEベースのTwitter AIエージェントの登場でした。多くの人々は、AIエージェントの名前が「gate」のTEEに初めて出会ったと思われます。@tee_hee_heXには10月下旬に登場し、Ethereum上でメームコインを立ち上げました。@tee_hee_heは、Nous ResearchとFlashbotsのTeleportプロジェクトが共同開発したAIエージェントです。これは、当時のトレンドAIエージェントアカウントでは、AIモデルによって生成された結果を実際に中継していることを証明できないという懸念に応えて登場しました。開発者は、Twitterアカウントの設定、暗号ウォレットの作成、AIモデルの結果のリレーなどのプロセスにおける中央集権的なエンティティからの介入を最小限に抑えるモデルを設計しました。

源：@tee_hee_he/setting-your-pet-rock-free-3e7895201f46">https://medium.com/@tee_hee_he/setting-your-pet-rock-free-3e7895201f46

彼らはAIエージェントをIntel TDX環境に展開し、メール、Xアカウントのパスワード、およびブラウザシミュレーションを通じたTwitterアクセスのためのOAuthトークンを生成し、その後すべての回復オプションを削除しました。

最近、AI-PoolでTEEを類似の文脈で使用しました。@123skely資金調達を成功裏に行いました。現在、AIミームコインが契約を展開し、アドレスが公開された後、技術的に優れたスナイパーボットが通常、ほとんどの流動性を確保し、価格を操作します。AI-Poolは、AIが一種のプリセールを実施することで、この問題を解決しようとしています。

源：https://x.com/0xCygaar/status/1871421277832954055

もう1つの興味深い事例はDeepWormです。DeepWormは、ワームの脳を模倣したバイオニューラルネットワークを持つAIエージェントです。他のAIエージェントと同様に、DeepWormはワーム脳のエンクレーブイメージをMarlin Networkにアップロードし、モデルを保護し、その運用の検証性を提供します。

source: https://x.com/deepwormxyz/status/1867190794354078135

Since @tee_hee_heデプロイに必要なすべてのコードをオープンソース化し、信頼性が高く、ラグのない TEE ベースの AI エージェントのデプロイが非常に簡単になりました。最近、Phala Networkはa16zのElizaをTEEに導入しました。a16zが2025年の暗号市場展望レポートで強調したように、TEEベースのAIエージェント市場は、将来のAIエージェントミームコイン市場で不可欠なインフラストラクチャとして機能すると予想されます。

2.7. ソーシャルゲーム

Azuki Bobu

有名なEthereum NFTプロジェクトであるAzukiは、昨年10月にFlashbotsと協力して、ユニークなソーシャルイベントを開催しました。

源：https://x.com/Azuki/status/1841906534151864557

これは、Twitterアカウントのアップロード権限をFlashbotsとBobuに委任し、フラッシュモブのように同時にツイートを投稿するというものでした。下の画像に示すように、イベントは成功しました。

源：https://collective.flashbots.net/t/tee-enabled-social-games-an-experiment-with-bobu-s-magic-show/3963

FlashbotsとAzukiによって設計された、イベントの構造は以下の通りです:

1. Gramin-SGX内でTLSプライベートキーと証明書、およびEthereumプライベートキーを生成します。
2. ユーザーは、1つのツイートを投稿するために制限された権限を持つOAuthトークンを作成し、それらをTLSを介してFlashbotsのTEEに提出しました。
3. Arbitrumでユーザー証明書を管理するために契約が作成され、ユーザーのツイートのアップロード時に二重支払いを防止し、イベント出力を実装しています。

Azukiは、EnclaveのDockerイメージをDocker Hubに公開することで、イベントプロセスの信頼性を確保しました。また、Certificate Transparency、ログ検証スクリプト、TEE環境のリモート構成証明結果をGitHubにアップロードしました。Flashbotsは、RPCとブロックチェーンノードへの依存を残りのリスクとして特定しましたが、これらはTEE RPCまたはUnichainなどのTEEベースのロールアップを使用することで軽減できます。

このプロジェクトは技術的なブレークスルーを達成しませんでしたが、TEEスタックのみを使用して信頼できるソーシャルイベントを実施したことは注目に値します。

3. TEEのセキュリティ

TEEは、ソフトウェアが直接妨害できないハードウェアレベルのセキュリティを提供するため、通常のソフトウェアソリューションと比較してはるかに高いセキュリティを提供します。ただし、TEEはいくつかの制限のために実際の製品への採用が遅れています。これについては後ほど紹介します。

1) 中央集権型の証明メカニズム

前述のように、ユーザーはリモートアテステーションメカニズムを利用して、TEEエンクレーブの整合性と、エンクレーブ内のデータが改ざんされていないことを検証できます。ただし、この検証プロセスは、やはりチップセットメーカーのサーバーに依存することになります。ベンダーによって信頼度はわずかに異なります。SGX/TDXは完全にIntelのアテステーションサーバーに依存し、一方SEVはVMオーナーが直接アテステーションを実行できます。これはTEE構造の本質的な問題であり、TEEの研究者たちは、後に言及するオープンソースTEEの開発によってこれを解決しようと取り組んでいます。

2) サイドチャネル攻撃

TEEは、エンクレーブ内に格納されているデータを決して公開してはなりません。ただし、TEEはエンクレーブ内のデータのみを暗号化できるため、元のデータではなく、副次的な情報を悪用した攻撃によって脆弱性が生じる可能性があります。Intel SGXが2015年に公開されて以来、多くの重大なサイドチャネル攻撃が、主要なシステムセキュリティカンファレンスで取り上げられてきました。以下に、TEEの使用事例における潜在的な攻撃シナリオを、それらの影響に応じてカテゴリ分けしたものを示します。

• 制御フローの漏洩: 悪意のあるオペレーティング システムまたはプログラムは、利用可能な情報を悪用してデータを回復する可能性があります。たとえば、CPUキャッシュのデータアクセスがDRAMのデータアクセスよりもはるかに高速であるという事実を利用することができます。これにより、操作コードの実行パターンを識別し、RSA キーなどの主要なプログラム情報を推測できます。さらに、悪意のある OS がメモリ ページ アクセスを制限し、エンクレーブ コードでページ フォールトが発生してメモリ アクセス パターンが公開されると、攻撃が発生する可能性があります。ブランチ ターゲット バッファーを操作してコード ブランチを予測および管理すると、コード実行フローを明らかにすることもできます。さらに、攻撃者は顕微鏡攻撃でエンクレーブコードを繰り返し実行して情報を推測する可能性があります。
• データ漏洩：エンクレーブデータを漏洩させる脆弱性は、リモートアテステーションを損なう可能性のある重大な攻撃につながることがあります。特に、エンクレーブ内の秘密鍵が、エンクレーブのコードとデータを模倣するシャドウアプリを作成し、それらに対してROP攻撃（Dark-ROP）を実行することで漏洩しています。また、Intel CPUは性能最適化のためにプログラムを仮想的に実行するため、さらなる脆弱性が発生します（Foreshadow）。エンクレーブメモリは暗号化によって保護されていますが、仮想的に実行された命令によってアクセスされたデータは一時的にキャッシュに残ることがあります。これを利用してキャッシュサイドチャネル攻撃を通じてエンクレーブデータを読み取ることができます。
• DoS攻撃：SGXでは、メモリの整合性チェックが改ざんを検出すると、システムは停止します。この脆弱性は、故意に整合性チェックの失敗を引き起こすことでDoS攻撃に悪用されています。攻撃者は特定のDRAM行に繰り返しアクセスすることで隣接する行のビットフリップを誘発し、エンクレーブメモリを損傷する可能性があります。

TEEはすべての攻撃ベクトルを無効化するシステムではなく、基本的な特性によりさまざまなレベルの情報が漏れる可能性がありますが、これらの攻撃には、攻撃者と被害者のコードが同じCPUコア上で実行されるなどの強力な前提条件が必要です。これが、一部の人々が「Glockを持つ男」と形容するセキュリティモデルにつながっています。

source: https://x.com/hdevalence/status/1613247598139428864

しかし、TEEの基本原則は「誰も信用しない」ということなので、TEEはセキュリティモジュールとしての役割を十分に果たすために、このモデルの中でもデータを保護できるはずだと考えています。

3) TEEにおける現実世界/最近の攻撃

TEE の実装、特に SGX では多数のバグが発見されており、そのほとんどにパッチが適用されています。ただし、TEE システムのハードウェア アーキテクチャが複雑なため、ハードウェアがリリースされるたびに新しい脆弱性が出現する可能性があります。学術研究以外にも、Web3プロジェクトに影響を与える実際のエクスプロイトがあり、詳細な調査が必要です。

• Secret Network: 本プロジェクトは、2022年に発見されたÆPIC Leakage攻撃によって、本物のTEEの脆弱性の被害者の一つとなりました。この攻撃は、最近のIntel CPUのAVX（Advanced Vector Extensions）命令セットを標的としました。これは、AVX操作中のスペキュラティブ実行パターンを悪用して、エンクレーブ領域に保存されている暗号化キーを回復しました。Secret Networkは、バリデータがプライベートトランザクションを復号化するためのコンセンサスシードを使用していました。攻撃者はこのシードを抽出し、ネットワーク上のすべての過去のプライベートトランザクションを復号化することに成功しました。脆弱性の詳細については、sgx.fail.
• SGXルートキーの公開:8月、セキュリティ研究者のMark Ermolov氏は、SGXの暗号化信頼モデルに不可欠なコンポーネントであるSGXのルートプロビジョニングキーとルートシーリングキーの復号化に成功したと発表しました。これらのキーは、通常、物理的な Fuse Controller デバイス内の複雑なロジックによって保護されます。しかし、操作中にこれらのキーのコピーが内部バッファに残るという重大な脆弱性が見つかりました。これら 2 つのキーを所有しているだけでは SGX が完全に侵害されるわけではありませんが、グローバル ラッピング キーを取得すると、SGX システム全体が脆弱性にさらされる可能性があります。SGX は 2021 年以降にリリースされた商用 Intel CPU で非推奨になりましたが、いくつかのプロジェクトがまだ利用しているため、依然として実行可能な攻撃ベクトルです。
• AMD SEV-SNPの脆弱性: AMD SEVは比較的新しいTEEの実装であり、仮想マシンレベルで広範な保護範囲を持っており、SGXと比較して脆弱性が少ないことが過去に示されてきました。しかし、IEEE S&P 2025での「BadRAM」というAMD SEV-SNPを標的とした脆弱性を議論する論文の受け入れは、現代のTEE実装であってもセキュリティ上の欠陥に免疫がないことを示しています。BadRAMはDDR4およびDDR5メモリモジュールを悪用して物理メモリ上のアドレス空間エイリアシングを作成します。約10ドルで入手できるRaspberry Pi Picoを使用することで、攻撃者はメモリチップを改変してCPUを物理メモリサイズについて欺くことができます。これにより、AMD SEV-SNPのRMP（逆マップテーブル）保護機構が回避されます。脆弱性の詳細については、以下で説明されています。badram.eu.

これらのケースは、「完全に安全なTEE」は実現不可能であり、ユーザーは新しいハードウェアリリースに潜在的な脆弱性があることを認識する必要があります。

4. 結論:オープンソースは未来である

11月に、ParadigmのGeorgios Konstantopoulosが概要を示しました。フレームワーク機密ハードウェアの進化について、セキュアハードウェアを5つの異なるレベルに分類します:

• レベル1：オラクルやブリッジアプリケーションに十分な機密性を提供し、セキュリティは供給チェーンに依存しています。例にはSGXが含まれます。
• レベル2：テレポートで見られるように、OAuthアカウント委任などの高度なアプリケーションをサポートし、開発者エクスペリエンスを向上させながら、レベル1のセキュリティを維持します。Gramine SGXがこれを示しています。
• レベル 3: GPU のサポートによりレベル 1 のセキュリティを拡張し、プライベートで検証可能な機械学習などの高度なアプリケーションを可能にします。Intel TDX + Nvidia Confidential Computing は、このレベルを表します。
• レベル4:OpenTEEが実証したように、公開されている検証可能な製造プロセスでオープンソースの命令セットを利用し、ハードウェアベンダーへの依存を排除します。
• レベル5:複数のOpenTEEがFHE/MPCを介して連携し、個々のハードウェアユニットが侵害されても整合性を維持する理想的な状態を実現します。

現在、Phala Networkの機密AI推論などのプロジェクトはレベル3で動作していますが、ほとんどのサービスはクラウドTEEまたはIntel TDXを使用したレベル2で動作しています。Web3 TEEベースのプロジェクトは最終的にレベル4のハードウェアに進化する必要がありますが、現在の性能制限から、これは実用的ではありません。ただし、Paradigmなどの主要なVCやFlashbots、Nethermindなどの研究チームがTEEの民主化に取り組んでおり、TEEがWeb3の原則と一致することを考慮すると、Web3プロジェクトにとって必要不可欠なインフラストラクチャになる可能性があります。

ChainLightについて

Ecosystem Explorerは、ChainLightのレポートであり、セキュリティの観点からWeb3エコシステムのトレンドプロジェクトに関する内部分析を紹介しています。当社のリサーチアナリストによって執筆されています。セキュリティ研究者や開発者が共同で学習し、成長し、Web3をより安全な場所にするために貢献することを支援する使命を持ち、定期的に無料でレポートを公開しています。

受賞した専門家によって実施された最新の研究とレポートを受け取るには:

👉 フォロー@ChainLight_io @c4lvin

2016年に設立されたChainLightの受賞歴のある専門家は、スマートコントラクトのセキュリティソリューションを提供し、ブロックチェーンで繁栄するための支援を行っています。

免責事項：

1. この記事は[から転載されていますチェーンライト]. すべての著作権は元の作者に帰属します [c4lvin*]。この転載に異議がある場合は、連絡してください。ゲート ラーンチーム、そして彼らは迅速にそれを処理します。
2. 責任の免責事項：この記事で表現されている意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. Gate Learnチームは、記事を他の言語に翻訳しました。翻訳された記事のコピー、配布、または盗用は、明示されていない限り禁止されています。