なぜZKはEnd Gameと言われているのですか？

コプロセッサの歴史的背景

従来のコンピューティング領域において、コプロセッサはCPUの脳が他の複雑なことを処理するのを担当する処理単位です。コプロセッサはコンピュータ領域において非常に一般的で、Appleが2013年にM7モーションコプロセッサを導入することで、スマートデバイスの動きの感度を大幅に向上させました。広く知られているGPUは、Nvidiaが2007年に提唱したコプロセッサであり、CPUがグラフィックスレンダリングなどのタスクを処理するために負担を軽減することができます。GPUは、計算負荷が高く時間がかかるコードの一部をアンロードすることによって、CPU上で実行されるアプリケーションを加速するためのもので、このアーキテクチャは「ヘテロジニアス」/「ハイブリッド」コンピューティングと呼ばれています。

コプロセッサは、複雑で単一のパフォーマンス要件または非常に高いパフォーマンス要件を持つコードをオフロードし、CPUがより柔軟かつ多様な部分を処理することができます。

イーサリアムチェーン上では、アプリケーションの発展を阻害する重大な問題が2つあります：

1. 操作には高額なGas手数料が必要なため、通常の送金は21000 Gasリミットにハードコーディングされています。これはイーサリアムネットワークのGas手数料の下限を示しており、その他の操作、例えばストレージにはより多くのGasが必要となり、それによってオンチェーンアプリの開発範囲が制限されます。ほとんどの契約コードは資産操作に焦点を当てて書かれており、複雑な操作が必要になると大量のGasが必要になります。これはアプリとユーザーの「大規模採用」にとって深刻な障害となります。
2. スマートコントラクトが仮想マシン内に存在するため、実際には最新の256個のブロックデータにしかアクセスできません。特に来年のPectraアップグレードでは、EIP-4444提案が導入され、全ノードは過去のブロックデータを保持しなくなります。そのため、データの欠落により、データベースに基づく革新的なアプリケーションが出るのが遅れています。実際、Tiktok、Instagram、多くのデータを利用したDeFiアプリ、LLMなどはすべてデータに基づいて構築されています。これがLensなどのデータに基づくソーシャルプロトコルがLayer3 Momokaを発表する理由です。なぜなら、ブロックチェーンはデータの流れが非常にスムーズであると考えていますが、実際にはそうではありません。代替資産データはスムーズに流通していますが、基盤設備の未完了により、データ資産は依然として大きな障害となっています。これは「Mass Adoption」製品の出現を深刻に制限します。

この事実から、新しい計算パラダイム「Mass Adoption」の出現を制限するのは、計算とデータの制約であることがわかりました。しかし、これはイーサリアムブロックチェーン自体の欠点であり、大量の計算やデータ集中型のタスクを処理するために設計されたものではありません。しかし、これらの計算やデータ集中型アプリケーションを互換性のあるものにするにはどうすればよいでしょうか？ここで協調プロセッサが登場し、イーサリアムチェーン自体がCPUとして機能し、協調プロセッサはGPUのようなものです。チェーン自体は非計算的でデータ集中型の資産データと単純な操作を処理できますが、アプリケーションがデータや計算リソースを柔軟に使用する場合は協調プロセッサを使用することができます。ZK技術の探索とともに、協調プロセッサがオフチェーンでの計算とデータ使用を信頼せずに行うために、協調プロセッサのほとんどは自然にZKを基礎として開発されています。

ZK Coporcessorの適用範囲は非常に広く、実際のDAppのシナリオをカバーすることができます。例えば、ソーシャル、ゲーム、DeFiブロック、オンチェーンデータに基づくリスク管理システム、オラクル、データストレージ、大規模なモデル言語トレーニング推論など、理論的には、ZK CoporcessorによってWeb2のアプリケーションで可能なことはすべて実現でき、それによってイーサリアムが最終的な決済レイヤーとしてアプリケーションのセキュリティを保護します。

従来の世界では、コプロセッサに明確な定義はありませんでした。協力チップとしてタスクを補助することができれば、すべてコプロセッサと呼ばれます。現在、業界ではZKクエリ、ZK-Oracle、ZKMなどがすべてコプロセッサであると定義されており、オンチェーンの完全なデータ、信頼できるオフチェーンデータ、およびオフチェーンの計算結果をクエリできます。この定義から、実際にはlayer2もEthereumのコプロセッサに相当し、以下ではLayer2と一般的なZKコプロセッサの違いを比較します。

コプロセッサープロジェクトの概要

ZKコプロセッサプロジェクトの一部、出典:Gate Ventures

現在、業界で比較的有名な協同処理は、オンチェーンのデータインデックス、オラクルマシン、ZKMLの3つのアプリケーションシナリオに分かれています。 3つのシナリオに含まれるプロジェクトは、General-ZKMであり、オフチェーンで実行される仮想マシンは、DelphinusがzkWASMに特化し、Risc ZeroがRisc-Vアーキテクチャに特化しています。

コプロセッサ技術アーキテクチャ

General ZKコプロセッサを例に取り、そのアーキテクチャを分析し、読者が技術とメカニズムの設計におけるこの汎用仮想マシンの異同を理解し、将来のコプロセッサの発展傾向を判断するために、Risc Zero、Lagrange、Succinctの3つのプロジェクトを中心に分析します。

リスクゼロ

Risc Zeroでは、そのZK協調プロセッサの名前はBonsaiです。

盆栽建築、写真:Risc Zero

Bonsai コンポーネント、画像: Risc Zero

Bonsaiでは、チェーンに依存しないゼロ知識証明のコンポーネントセットが構築されており、チェーンに依存しないコプロセッサーとなることを目指しています。Risc-V命令セットアーキテクチャをベースにしており、Rust、C++、Solidity、Goなどの言語をサポートしています。主な機能には、次のものがあります：

1. 一般的なzkVMは、ゼロ知識/検証可能な環境で任意の仮想マシンを実行できます。
2. 任意のスマートコントラクトやチェーンに直接統合可能なZK証明生成システム
3. Bonsaiで証明された任意の計算をロールアップし、ネットワークのマイナーが証明を生成できるようにオンチェーンに分散させる汎用のロールアップ。

その構成要素には、

1. 証明者ネットワーク：Bonsai APIを通じて、証明者はネットワークで検証する必要があるZKコードを受け取り、検証アルゴリズムを実行してZK証明を生成します。将来、このネットワークは誰でも利用できるようになります。
2. リクエストプール：このプールはユーザーが発行した証明リクエストを格納するものです（イーサリアムのメンプールに似ており、取引を一時的に保存するためのものです）。その後、このリクエストプールはシーケンサーによってソートされ、ブロックが生成されます。多くの証明リクエストは証明効率を向上させるために分割されます。
3. Rollupエンジン：このエンジンは、証明者ネットワークで収集された証拠結果を収集し、ルート証明としてパッケージ化して、オンチェーンのバリデータがいつでも検証できるようにイーサリアムメインネットにアップロードします。
4. Image Hub: これは開発者向けのビジュアルプラットフォームであり、このプラットフォームでは関数や完全なアプリケーションを保存することができます。したがって、開発者はスマートコントラクトを介して対応するAPIを呼び出すことができ、オンチェーンのスマートコントラクトはオフチェーンプログラムを呼び出す能力を備えています。
5. ステートストア：Bonsaiは、オフチェーンの状態ストアを導入し、データベースにキーバリュー形式で格納されます。これにより、オンチェーンのストレージコストを削減し、ImageHubプラットフォームと連携することで、スマートコントラクトの複雑さを減らすことができます。
6. プルーフィングマーケットプレース：ZK証明産業チェーンの中流、コンピューティングパワーマーケットは、コンピューティングパワーの供給と需要の両方をマッチングするために使用されます。

ラグランジュ

Lagrangeの目標は、コプロセッサと検証可能なデータベースの構築であり、ブロックチェーン上の履歴データを含んでいます。これにより、信頼性のないアプリケーション構築にこれらのデータをスムーズに使用することができます。これにより、計算およびデータ集中型のアプリケーションの開発ニーズが満たされます。

これには2つの機能が関係しています：

1. 検証可能なデータベース：インデックスチェーン上のスマートコントラクトのストレージを介して、オンチェーンで生成されたスマートコントラクトの状態をデータベースに格納します。本質的には、ブロックチェーンのストレージ、状態、およびブロックを再構築し、更新された形式でチェーン下のデータベースに格納することです。
2. MapReduce原則の計算：MapReduce原則は、大規模データベースでデータ分離マルチインスタンス並列計算を採用し、最後に結果を一緒に統合することです。そして、この並列実行をサポートするアーキテクチャはLagrangeによってzkMRと呼ばれています。

データベースの設計では、契約のストレージデータ、EOA状態データ、およびブロックデータの3つのオンチェーンデータが関係しています。

ラグランジュデータベース構造、図のソース：ラグランジュ

上記は契約のストレージデータのマッピング構造であり、契約の状態変数が格納され、各契約には独自のストレージトライがあります。このトライはイーサリアム内でMPTツリーの形で格納されています。MPTツリーはシンプルですが、効率が低いため、イーサリアムのコア開発者がVerkleツリーの開発を推進している理由でもあります。Lagrangeでは、各ノードがSNARK/STARKを使用して「証明」でき、親ノードは子ノードの証明を含んでおり、これには再帰的な証明技術が必要です。

アカウントの状態、画像ソース：Lagrange

アカウントはEOA（外部所有者アカウント）とコントラクトアカウントの2つに分かれており、アカウント/ストレージルート（コントラクト変数の格納領域）の形式でアカウントの状態を表すことができますが、Lagrangeではこの部分が完全に設計されていないようです。実際にはState Trie（外部アカウントの状態格納領域）のルートも追加する必要があります。

ブロックデータ構造、画像ソース：Lagrange

Lagrangeは、SNARKsプルーフに対応したブロックデータ構造を新たに作成しました。この木構造では、各葉はブロックヘッダーであり、サイズは固定です。イーサリアムは12秒ごとにブロックを生成するため、このデータベースは約25年間使用できます。

LagrangeのZKMR仮想マシンでは、計算は2つのステップで行われます：

1. マップ：分散型のマシンが全体のデータをマッピングし、キーバリューペアを生成します。
2. リダクション：分散コンピュータがそれぞれ証明を計算し、その後、すべての証明を結合します。

要するに、ZKMRは小規模な計算の証明を組み合わせて全体の計算の証明を作成することができます。これにより、ZKMRは複雑な計算証明を大規模なデータセットで効果的にスケーリングし、複数のステップや複数の層での計算が必要な場合に使用することができます。例えば、Uniswapが100本のチェーン上に展開される場合、100本のチェーン上のあるトークンのTWAP価格を計算するには多くの計算と統合が必要となりますが、このような場合にZKMRはそれぞれのチェーンを個別に計算し、それらを組み合わせて完全な計算の証明を提供できます。

ラグランジュコプロセッサの動作プロセス、出典:ラグランジュ

以上はその実行フローです:

1. 開発者のスマートコントラクト、まずLagrangeに登録し、その後Lagrangeのオンチェーンスマートコントラクトに証明リクエストを提出すると、この時、代理契約が開発者契約とやり取りを行います。
2. オフチェーンのLagrangeは、リクエストを並列可能な小さなタスクに分解して異なるプルーバーに配布し、共同で検証します。
3. このプルーフオブステークは実際にはネットワークであり、そのセキュリティはEigenLayerのRestaking技術によって保護されています。

簡潔

Succinct Networkの目標は、L2、コプロセッサ、クロスチェーンブリッジなどのブロックチェーン開発の各部分にプログラム可能性のある事実を統合することです。

簡潔な操作プロセス、出典:簡潔化

Succinctは、Solidityやゼロ知識領域の専門言語（DSL）などのコードを含むことができ、オフチェーンのSuccinctコプロセッサに渡されます。Succinctは、ターゲットチェーンのデータインデックスを完了し、証明リクエストを証明マーケットに送信できます。CPU、GPU、およびETCなどのチップをサポートするマイニングリグは、証明ネットワークに証明を提出できます。その特徴は、証明マーケットがさまざまな証明システムと互換性があることです。なぜなら、将来はさまざまな証明システムが共存する時期が長くなるからです。

SuccinctのオフチェーンZKVMはSP（Succinct Processor）と呼ばれ、Rust言語および他のLLVM言語をサポートしています。その主な特徴は次のとおりです:

1.再帰+検証:STARKsテクノロジーに基づく再帰的証明テクノロジーは、ZKの圧縮効率を指数関数的に向上させることができます。 2. SNARKsからSTARKsへのラッパーサポート：SNARKsとSTARKsの利点を同時に取り入れ、証明のサイズと検証時間のトレードオフの問題を解決することができます。 3. 予めコンパイルされた zkVM アーキテクチャ：SHA256、Keccak、ECDSAなどの一般的なアルゴリズムについて、実行時の証明生成時間と検証時間を削減するために事前にコンパイルできます。

比較する

一般的なZKプロセッサの比較を行う際に、私たちは主にMass Adoptionの第一原則を満たすことに焦点を当て、それがなぜ重要かについても説明します。

1. データインデックス/同期の問題：大規模データに基づくアプリケーションの要件を満たすためには、完全なオンチェーンデータと同期されたインデックス機能が必要です。それ以外の場合、アプリケーションの範囲は限定的です。 2.テクノロジーベース:SNARKとSTARKには異なる決定ポイントがあり、中期的にはSNARKが主要なテクノロジーであり、長期的にはSTARKテクノロジーです。
2. 再帰をサポートしていますか：再帰をサポートしている場合のみ、データの圧縮および計算の並行証明を実現できます。したがって、完全な再帰を実現することがプロジェクトの技術的なハイライトです。
3. 証明システム：証明システムは、証明生成のサイズと時間に直接影響を与えます。これは、ZK技術において最も高いコストを要する部分であり、現在は自社のZKクラウド算力市場と証明ネットワークに主に依存しています。
4. エコシステム協力：B端ユーザーに技術方向が認められているかどうかを第三者の真の需要側から判断することができます。
5. サポートされるVCおよび資金調達状況：その後のリソースサポート状況を示す可能性があります。

ソース: Gate Ventures

実際には、全体的な技術の進路は既に非常に明確であり、したがって、ほとんどの技術は同じ方向に向かっています。たとえば、STARKsからSNARKsへのラッパーの使用、STARKsとSNARKsの利点を同時に活用することができ、証明生成時間と検証時間、および量子攻撃に対する耐性を低減します。ZKアルゴリズムの再帰性がZKのパフォーマンスに非常に大きな影響を与えるため、現在の3つのプロジェクトはすべて再帰機能を持っています。ZKアルゴリズムの証明生成は、コストと時間の面で最も負荷がかかるため、これらの3つのプロジェクトは、ZKの計算力に強い需要に依存して、証明者ネットワークとクラウドマイニング市場を構築しています。また、現在の技術の進路が非常に類似しているため、市場シェアを確保するためには、チームとVCのエコシステム協力リソースへの補助により、突破口を作る必要があるかもしれません。

コプロセッサとLayer2の違いと類似点

Layer2とは異なり、コプロセッサはアプリケーションに向けられており、Layer2は依然としてユーザーに向けられています。コプロセッサは、アクセラレーションコンポーネントまたはモジュール化されたコンポーネントとして機能し、以下のようなアプリケーションシナリオを構成できます：

1. ZK Layer2のオフチェーン仮想マシンコンポーネントとして、これらのLayer2は自身のVMをコプロセッサーに交換することができます。
2. 公共チェーン上のアプリケーションをオフチェーンのコプロセッサにアンインストールするためのコンピューティングパワー。
3. 公共チェーンアプリケーションが他のチェーンの検証可能なデータを取得するためのオラクルマシン。
4. 作为两条链上的クロスチェーンブリッジ进行消息的传递。

これらのアプリケーションシナリオは単なる一部分を列挙したものであり、協力プロセッサに関しては、リアルタイムの同期データと高性能低コストの信頼性のある計算をもたらす可能性を理解する必要があります。ほぼすべてのブロックチェーンミドルウェアを安全に再構築することができます。ChainlinkやThe Graphは現在、独自のZKオラクルおよびクエリの開発も進めています。一方で、WormholeやLayerzeroなどの主要なクロスチェーンブリッジもZKに基づいたクロスチェーンブリッジ技術の開発を行っており、オフチェーンのLLMs（Large Model Oracles）のトレーニングおよび信頼できる推論なども行われています。

コプロセッサーが直面する問題

1. 開発者が抵抗に直面しています。 ZKテクノロジーは理論的には可能ですが、現在は技術的な課題がまだ多く、外部からの理解も難解です。したがって、新しい開発者がエコシステムに参加する際には、特定の言語と開発者ツールをマスターする必要があるため、それは大きな抵抗となる可能性があります。
2. 赛道は非常に早い段階にあり、zkVMのパフォーマンスは非常に複雑で、ハードウェア、単一ノードと複数ノードのパフォーマンス、メモリ使用、再帰コスト、ハッシュ関数の選択など、多くの要素に関わります。現時点では、各次元でプロジェクトが構築されていますが、赛道は非常に早い段階にあり、状況はまだ明確ではありません。
3. ハードウェアなどの先決条件はまだ確立されておらず、ハードウェアの観点からは、現在、主流のハードウェアはASICおよびFPGAによって構築されており、Ingonyama、Cysicなどのメーカーが含まれていますが、まだ実験室の段階にあり、商業化されておらず、私たちはハードウェアがZK技術が大規模に確立される前提であると考えています。
4. 技術の経路が類似しているため、技術的な世代交代リードが非常に難しいです。現在は主に背後のVCリソースとチームのBD能力を競っており、主要なアプリケーションやパブリックチェーンのエコシステムの地位を獲得できるかどうかが問題となっています。

総括と今後の展望

ZK技術は非常に汎用性があり、イーサリアムエコシステムが分散化から信頼度の高い価値観に移行するのを支援しています。“信じるのではなく、検証する”という言葉がZK技術の最良の実践です。ZK技術はクロスチェーンブリッジ、オラクルマシン、オンチェーンクエリー、オフチェーン計算、仮想マシンなど、さまざまなアプリケーションシーンを再構築することができます。そして、汎用性の高いZK CoprocessorはZK技術の実装におけるツールの一つです。ZK Coporcessorに関しては、そのアプリケーションの範囲が非常に広く、どんな実際のdappアプリケーションシナリオでもカバーできます。理論的には、Web2のアプリケーションが実現できることは、ZKコプロセッサがあればすべて実現できます。

テクノロジー導入曲線、出典:Gartner

古来より、技術の発展は常に人々の美しい生活の想像に遅れを取ってきました（例えば、嫦娥が月へ飛び、アポロが月面に立つ）。もしも何かが本当に革新的で破壊的で、かつ必要性があるならば、必ず技術が実現するものです。ただし、時間の問題です。私たちは、汎用ZKコプロセッサがこの発展のトレンドに従っていると考えています。私たちは、ZKコプロセッサの「Mass Adoption」について2つの指標を持っています：リアルタイムで証明可能なデータベースと低コストのオフチェーン計算です。データ量が十分であり、リアルタイムに同期し、低コストでオフチェーンで検証可能な計算が行われる場合、ソフトウェアの開発パラダイムが完全に変わることができます。ただし、この目標はゆっくりとしたイテレーションですので、私たちはこれらの2つのトレンドや価値志向に合致するプロジェクトを重視して探しています。また、ZKパワーチップの実現は、ZKコプロセッサの大規模な商業化の前提です。このサイクルでは革新が足りないため、次世代の「Mass Adoption」技術とアプリケーションを構築するためのウィンドウ期間です。次のサイクルでは、ZK産業チェーンが商業化されると予想しています。したがって、現在はWeb3が10億人のオンチェーンインタラクションを実現する本当の技術に再び焦点を当てる時期です。