TEE (Trusted Execution Environment) は、コンピューターやスマートフォン内の特別なボックスのようなものです。これには独自のロックとキーがあり、特定のプログラム (信頼できるアプリケーションと呼ばれる) のみがアクセスできます。これらの信頼できるアプリケーションが TEE 内で実行されると、他のプログラムやオペレーティング システム自体によっても保護されます。
TEE は分離されたシステムであるため、認証における信頼の前提により認証プロセスが侵害されることはありません。 Intel や Apple が作ったので安全だと信じているセキュリティ ドアがあると考えてください。しかし、そのセキュリティ ドアを突破できるセキュリティ ブレーカー (ハッカーやその他のコンピュータを含む) が世界中に十分に存在します。 TEE は「ポスト量子セキュア」ではありません。これは、無制限のリソースを持つ量子コンピューターが TEE のセキュリティを突破できることを意味します。コンピューターが急速に強力になるにつれて、ポスト量子セキュリティを念頭に置いて、長期的なコンピューティング システムと暗号化スキームを構築する必要があります。
IOSG Ventures: イーサリアムのパフォーマンスを解放し、EVM のボトルネックを克服するイノベーションへの道
原著者: Siddharth Rao、IOSG Ventures
この記事に関して貴重なコメントと提案をくださった Lurk Labs の John Burnham に心より感謝いたします。
Ethereum Virtual Machine (EVM) のパフォーマンスについて
イーサリアム メインネット上のすべての操作には一定量のガスがかかります。基本アプリケーションを実行するために必要なすべての計算をチェーン上に置くと、アプリがクラッシュするか、ユーザーが破産するかのどちらかになります。
これにより、L2 が誕生しました。OPRU は、メインネットにコミットする前に多数のトランザクションをバンドルするコレーターを導入しました。これは、アプリがイーサリアムのセキュリティを確保するのに役立つだけでなく、ユーザーのエクスペリエンスを向上させます。ユーザーはトランザクションをより迅速に送信でき、手数料も安くなります。運用コストは低くなりましたが、依然としてネイティブ EVM を実行層として使用します。 ZK ロールアップと同様に、スクロールおよびポリゴン zkEVM は EVM ベースの zk 回路を使用するか、使用する予定であり、zk Proof はその証明者で実行されるすべてのトランザクションまたはトランザクションの大規模なバッチで生成されます。これにより、開発者はアプリケーションを「オンチェーン」で構築できるようになりますが、それでも高パフォーマンスのアプリケーションを実行するのは効率的でコスト効率が高いのでしょうか?
これらの高性能アプリケーションとは何ですか?
ゲーム、オンチェーン注文帳、Web3 ソーシャル、機械学習、ゲノム モデリングなどが最初に思い浮かびます。これらはすべて、L2 で実行すると計算量が多く、コストが高くなります。 EVM のもう 1 つの問題は、計算速度と効率が SVM (Sealevel Virtual Machine) などの他の現在のシステムほど良くないことです。
L3 EVM は計算を安価に行うことができますが、EVM 自体は並列演算を計算できないため、大量の計算を実行するには最適な方法ではない可能性があります。上に新しいレイヤーが構築されるたびに、分散化の精神を維持するために、新しいインフラストラクチャ (新しいノードのネットワーク) を構築する必要がありますが、拡張するにはやはり同じ数のプロバイダー、またはまったく新しいノードのセットが必要です。リソースを提供するプロバイダー (個人/企業)、またはその両方が必要です。
したがって、より高度なソリューションを構築する場合は常に、既存のインフラストラクチャをアップグレードするか、その上に新しいレイヤーを構築する必要があります。この問題を解決するには、量子アルゴリズムを真に効率的に使用して分散型アプリケーションのコンピューティングを実行できる、ポスト量子セキュアで分散型のトラストレスな高性能コンピューティング インフラストラクチャが必要です。
Solana、Sui、Aptos などの Alt-L1 は並列実行が可能ですが、市場センチメント、流動性の欠如、市場の開発者不足により、イーサリアムに対抗することはできません。信頼の欠如と、ネットワーク効果を備えたイーサリアムによって構築された堀がマイルストーンであるためです。今のところ、ETH/EVMキラーは存在しません。ここでの問題は、なぜすべての計算をオンチェーンで行う必要があるのかということです。同様にトラストレスで分散型の執行システムはあるのでしょうか?これが DCompute システムで実現できることです。
DCompute インフラストラクチャは、分散化、ポスト量子安全、トラストレスである必要があり、ブロックチェーン/分散テクノロジーは必要ありませんし、そうすべきではありませんが、計算結果の検証、正しい状態遷移、最終確認が非常に重要です。これが EVM チェーンの仕組みであり、ネットワークのセキュリティと不変性を維持しながら、分散型でトラストレスで安全なコンピューティングをオフチェーンに移行できます。
ここで主に無視しているのは、データの可用性の問題です。 Celestia や EigenDA などのソリューションはすでにこの方向に進んでおり、この投稿ではデータの可用性に焦点を当てていないわけではありません。
1: コンピューティングのみをアウトソーシングする
( 来源：オフチェーン モデルとオフチェーン計算へのアプローチ、Jacob Eberhardt & Jonathan Heiss)
( 来源：オフチェーン モデルとオフチェーン計算へのアプローチ、Jacob Eberhardt & Jonathan Heiss)
私たちがタイプ 1 を見たとき、zk-rollups はすでにこれを行っていましたが、EVM によって制限されていたか、開発者にまったく新しい言語/命令セットを教える必要がありました。理想的なソリューションは、効率的、効果的 (コストとリソース)、分散型、プライベート、検証可能である必要があります。 ZK プルーフは AWS サーバー上に構築できますが、分散化されていません。 Nillion や Nexus のようなソリューションは、分散型の方法で一般的なコンピューティングの問題を解決しようとしています。しかし、これらの解決策は ZK 証明がなければ検証できません。
タイプ 2 では、オフチェーン計算モデルと、分離されたデータ可用性レイヤーを組み合わせますが、計算は依然としてオンチェーンで検証する必要があります。
今日利用可能なさまざまな分散コンピューティング モデルを見てみましょう。これらは完全に信頼できるものではなく、完全にトラストレスである可能性もあります。
代替; 計算
イーサリアムのアウトソーシング コンピューティングの生態マップ (出典: IOSG Ventures)
安全なエンクレーブ計算 / 信頼できる実行環境
TEE (Trusted Execution Environment) は、コンピューターやスマートフォン内の特別なボックスのようなものです。これには独自のロックとキーがあり、特定のプログラム (信頼できるアプリケーションと呼ばれる) のみがアクセスできます。これらの信頼できるアプリケーションが TEE 内で実行されると、他のプログラムやオペレーティング システム自体によっても保護されます。
それは特別な数人の友達だけが入ることができる秘密の隠れ家のようなものです。 TEE の最も一般的な例は Secure Enclave です。これは、Apple の T;1 チップや Intel の SGX などのデバイス上に存在し、FaceID などのデバイス内で重要な操作を実行します。
TEE は分離されたシステムであるため、認証における信頼の前提により認証プロセスが侵害されることはありません。 Intel や Apple が作ったので安全だと信じているセキュリティ ドアがあると考えてください。しかし、そのセキュリティ ドアを突破できるセキュリティ ブレーカー (ハッカーやその他のコンピュータを含む) が世界中に十分に存在します。 TEE は「ポスト量子セキュア」ではありません。これは、無制限のリソースを持つ量子コンピューターが TEE のセキュリティを突破できることを意味します。コンピューターが急速に強力になるにつれて、ポスト量子セキュリティを念頭に置いて、長期的なコンピューティング システムと暗号化スキームを構築する必要があります。
安全なマルチパーティ コンピューティング (SMPC)
SMPC (Secure Multi-Party Computation) もブロックチェーン テクノロジー業界ではよく知られたコンピューティング ソリューションであり、SMPC ネットワークの一般的なワークフローは次の 3 つの部分で構成されます。
自動車の生産ラインを想像してください。自動車のコンポーネント (エンジン、ドア、ミラー) の構築と製造が OEM (OEM) に委託され (ジョブ ノード)、その後にすべてのコンポーネントを組み立てる組立ラインがあります。車を作ります（ノードが生成されます）。
秘密の共有は、プライバシーを保護する分散型コンピューティング モデルにとって重要です。これにより、単一の当事者が完全な「秘密」 (この場合は入力) を取得し、悪意を持って誤った出力を生成することが防止されます。 SMPC はおそらく最も簡単で安全な分散システムの 1 つです。完全に分散化されたモデルは現在存在しませんが、論理的には可能です。
Sharemind のような MPC プロバイダーはコンピューティング用の MPC インフラストラクチャを提供しますが、プロバイダーは依然として集中化されています。プライバシーをどのように確保するか、ネットワーク (または Sharemind) が悪意のある動作をしないようにするにはどうすればよいでしょうか? ここで、zk 証明と zk 検証可能な計算が登場します。
Nil メッセージコンピューティング（NMC）
NMC は、Nillion チームによって開発された新しい分散コンピューティング手法です。これは MPC のアップグレードされたバージョンであり、ノードは結果を介して対話することで通信する必要がありません。これを行うために、彼らはワンタイム マスキングと呼ばれる暗号化プリミティブを使用しました。これは、ワンタイム パディングと同様に、ブラインディング ファクターと呼ばれる一連の乱数を使用してシークレットをマスクします。 OTM は、効率的な方法で正確性を提供することを目的としています。これは、NMC ノードが計算を実行するためにメッセージを交換する必要がないことを意味します。これは、NMC には SMPC のスケーラビリティの問題がないことを意味します。
ゼロ知識検証可能な計算
ZK 検証可能な計算 (ZK Verifiable Computation) は、一連の入力と関数に対するゼロ知識証明を生成し、システムによって実行される計算が正しく実行されることを証明することです。 ZK の概念実証計算は新しいものではありますが、すでにイーサリアム ネットワークのスケーリング ロードマップの非常に重要な部分となっています。
ZK は、さまざまな実装形式があることを証明しています (次の図に示すように、論文「Off-Chaining_Models」の要約に基づいています)。
( 来源：IOSG Ventures、オフチェーン モデルとオフチェーン コンピューティングへのアプローチ、Jacob Eberhardt & Jonathan Heiss)
上記で zk 証明の実装の基本を理解しました。それでは、ZK 証明を使用して計算を検証するための条件は何でしょうか?
開発者のジレンマ - 効率性の証明のジレンマ
もう一つ言わなければならないのは、回路構築の敷居は依然として非常に高く、開発者がSolidityを学ぶのは簡単ではありません。現在、開発者は回路を構築するためにCircomを学ぶか、特定のプログラミング言語（Cairoなど）を学ぶ必要があります。 zk-apps を構築するのは遠い将来のことのように思えます。
（ソース：
（ソース：
上記の統計が示すように、Web3 環境を開発しやすいように改修することは、開発者を新しい Web3 開発環境に導入するよりも持続可能であると思われます。
ZK が Web3 の未来であり、Web3 アプリケーションを既存の開発者のスキルを使用して構築する必要がある場合、ZK 回路は、Java や Rust などの言語で書かれたアルゴリズムによって実行される計算をサポートして証明を生成するように設計する必要があります。 。
このようなソリューションは実際に存在しており、私は RiscZero と Lurk Labs の 2 つのチームを思い浮かべます。両チームは、開発者が急な学習曲線を経ることなく zk-apps を構築できるようにするという非常に似たビジョンを共有しています。
Lurk Labs はまだ初期の段階ですが、チームはこのプロジェクトに長い間取り組んできました。彼らは、汎用回路を通じて Nova Proof を生成することに重点を置いています。 Nova の証明は、カーネギー メロン大学の Abhiram Kothapalli、Microsoft Research の Srinath Setty、およびニューヨーク大学の Ioanna Tziallae によって提案されました。他の SNARK システムと比較して、Nova 証明には、増分検証可能計算 (IVC) の実行において特に利点があります。 Incremental Verifiable Computation (IVC) は、計算全体を最初から再計算することなく計算の検証を可能にすることを目的としたコンピューター サイエンスと暗号化の概念です。計算時間が長くて複雑な場合、証明は IVC 用に最適化する必要があります。
(出典: IOSG ベンチャーズ)
Nova プルーフは、他のプルーフ システムのように「すぐに使える」わけではありません。Nova は単なる折りたたみトリックであり、開発者はプルーフを生成するためのプルーフ システムを依然として必要とします。だからこそ、Lurk Labs は LISP 実装である Lurk Lang を構築しました。 LISP は低レベル言語であるため、汎用回路で証明を生成し、Java に簡単に変換できるため、Lurk Labs は 1,740 万人の Java 開発者からの支持を得ることができます。 Python などの他の一般的な言語の翻訳もサポートされています。
全体として、Nova 証明は優れた独自の証明システムであるようです。欠点は、証明のサイズが計算のサイズに比例して増加することですが、一方で、Nova 証明にはさらに圧縮する余地があります。
STARK 証明のサイズは計算によって増加しないため、非常に大規模な計算の検証により適しています。開発者のエクスペリエンスをさらに向上させるために、RiscZero によって生成された証明によって検証された分散コンピューティング ネットワークである Bonsai Network もリリースしました。これは、RiscZero の Bonsai ネットワークがどのように機能するかを表す簡単な図です。
（ソース：
Bonsai ネットワーク設計の利点は、計算をすべてオンチェーンで初期化、検証、出力できることです。これらすべては理想郷のように聞こえますが、STARK の証明には問題もあります。検証コストが高すぎるということです。
Nova の証明は、繰り返しの計算 (折りたたみスキームはコスト効率が高い) や小規模な計算に適しているようで、Lurrk が ML 推論検証に適したソリューションになる可能性があります。
＃＃ 誰が勝ちましたか？
(出典: IOSG ベンチャーズ)
一部の zk-SNARK システムでは、初期セットアップ段階で信頼できるセットアップ プロセスを必要とし、パラメータの初期セットを生成します。ここでの信頼性の前提は、信頼されたセットアップが悪意のある動作や改ざんなしに正直に実行されるということです。攻撃された場合、無効な証拠の作成につながる可能性があります。
STARK 証明は、多項式の低次の特性を検証するための低次のテストの安全性を前提としています。また、ハッシュ関数がランダムなオラクルのように動作すると仮定しています。
両方のシステムを適切に実装することもセキュリティの前提条件です。
SMPC ネットワークは以下に依存します。
OTM は、参加者のプライバシーを保護するために設計されたマルチパーティ計算プロトコルです。参加者が計算における入力データを公開しないようにすることでプライバシー保護を実現します。したがって、「正直だが好奇心旺盛な」参加者は、基礎となる情報にアクセスしようとして他のノードと通信できないため、存在しません。
明確な勝者はいるのでしょうか? それはわかりません。しかし、それぞれの方法には独自の利点があります。 NMC は SMPC の明らかなアップグレードのように見えますが、ネットワークはまだ稼働しておらず、実戦テストもされていません。
ZK 検証可能な計算を使用する利点は、安全でプライバシーが保護されることですが、秘密共有が組み込まれていないことです。証明の生成と検証の間に非対称性があるため、検証可能なアウトソーシング計算にとって理想的なモデルになります。システムが純粋な zk プルーフ計算を使用する場合、コンピューター (または単一ノード) は多くの計算を実行するために非常に強力でなければなりません。プライバシーを保護しながら負荷分散と分散を可能にするには、秘密の共有が必要です。この場合、SMPC や NMC などのシステムを Lurk や RiscZero などの zk ジェネレーターと組み合わせて、強力な分散型検証可能なアウトソーシング コンピューティング インフラストラクチャを作成できます。
これは、今日の集中型 MPC/SMPC ネットワークではさらに重要になります。現在最大の MPC プロバイダーは Sharemind であり、その上の ZK 検証レイヤーが役立つ可能性があります。分散型 MPC ネットワークの経済モデルはまだ確立されていません。理論的には、NMC モードは MPC システムのアップグレードですが、その成功はまだ見ていません。
ZK 証明スキームの競争では、勝者総取りの状況は存在しない可能性があります。各証明方法は特定のタイプの計算に最適化されており、すべてのタイプのモデルに適合する方法はありません。計算タスクには多くの種類があり、開発者が各証明システムで行うトレードオフにも依存します。著者は、STARK ベースのシステムと SNARK ベースのシステムの両方と、それらの将来の最適化が ZK の将来に役立つと信じています。