ABCDE 研究報告：協処理器および各社のソリューションについての詳細な考察
システムは、市場に出ているいくつかのコプロセッサー分野の技術ソリューションの比較を整理し、市場とユーザーにコプロセッサー分野についてより明確な理解を提供することを希望しています。著者：Kris \& Laobai，ABCDE；Mo Dong，Celer Network
ここ数ヶ月、協力プロセッサの概念が注目を集める中で、この新しいZKユースケースはますます多くの人々の関心を集めています。
しかし、私たちは、多くの人々が協力プロセッサの概念に対してまだ比較的馴染みがなく、特に協力プロセッサの正確な位置付け、つまり協力プロセッサとは何か、また何でないのかがまだ曖昧であることに気付きました。また、市場に出ているいくつかの協力プロセッサの技術的な比較については、まだ誰も体系的に整理したことがありません。この文書は、市場とユーザーに協力プロセッサのトラックについてより明確な理解を提供できることを願っています。
一. 協力プロセッサ Co-Processor とは何か、また何でないのか？
もし、あなたが非技術者や開発者に協力プロセッサを一言で説明しなければならないとしたら、どのように表現しますか？
私は、董沫博士のこの言葉が標準的な答えに非常に近いと思います ―― 協力プロセッサとは「スマートコントラクトにDune Analyticsの能力を与えるもの」です。
この言葉はどのように分解できますか？
Duneを使用するシーンを想像してみてください ―― あなたはUniswap V3でLPを行い、手数料を稼ぎたいと思っています。そこでDuneを開き、最近のUniswapのさまざまな取引ペアの取引量、手数料の過去7日間のAPR、主要な取引ペアの上下の変動範囲などを見つけます…
または、StepNが流行ったとき、あなたはスニーカーを投機し、いつ手放すべきか不安になり、毎日DuneのStepNデータ、日々の取引量、新規ユーザー数、スニーカーのフロア価格を注視し、成長が鈍化したり下落傾向が見られたらすぐに逃げるつもりです。
もちろん、あなただけでなく、UniswapやStepNの開発チームも同様にこれらのデータに注目しています。
これらのデータは非常に重要です ―― トレンドの変化を判断するのに役立つだけでなく、インターネットの大手企業がよく使う「ビッグデータ」戦略のように、より多くのバリエーションを生み出すことができます。
たとえば、ユーザーがよく売買するスニーカーのスタイルや価格に基づいて、類似のスニーカーを推薦することができます。
たとえば、ユーザーが創世スニーカーを保持している期間に基づいて、「ユーザー忠誠度報酬プログラム」を導入し、忠実なユーザーにより多くのエアドロップや特典を提供することができます。
たとえば、Uniswap上のLPやトレーダーが提供するTVLや取引量に基づいて、CexのVIPプランのようなものを導入し、トレーダーに取引手数料の減免やLP手数料のシェア増加の特典を提供することができます…
ここで問題が生じます ―― インターネットの大手企業がビッグデータとAIを使う場合、基本的にブラックボックスで、どう扱っても構わず、ユーザーはそれを見えず、気にもしません。
しかし、Web3の世界では、透明性と信頼の拒否が私たちの自然な政治的正しさであり、ブラックボックスを拒否します！
したがって、上記のシーンを実現しようとすると、二者択一のジレンマに直面します ―― 中央集権的な手段を使って実現するか、「バックエンド手動」でDuneを使ってこれらのインデックスデータを統計し、その後展開するか、またはスマートコントラクトを作成し、自動的にチェーン上でこれらのデータを取得し、計算を完了し、自動的に展開するかです。
前者は「政治的に不正確」な信頼の問題に陥ります。
後者はチェーン上で発生するガス費用が天文学的な数字になるため、あなた（プロジェクト側）の財布は耐えられません。
この時、協力プロセッサの登場です。先ほどの二つの手段を組み合わせ、「バックエンド手動」というステップを技術的手段で「自己証明」し、言い換えれば、ZK技術を使ってオフチェーンの「インデックス + 計算」部分を「自己証明」し、それをスマートコントラクトに供給することで、信頼の問題を解決し、膨大なガス費用も消え、完璧です！
なぜ「協力プロセッサ」と呼ばれるのでしょうか？実際、これはWeb2.0の発展の歴史の中での「GPU」に由来しています。GPUが当時、CPUとは独立した単独の計算ハードウェアとして導入された理由は、その設計アーキテクチャがCPUが根本的に処理しにくい計算、例えば大規模な並列繰り返し計算やグラフィック計算などを処理できるからです。この「協力プロセッサ」のアーキテクチャがあったからこそ、今日の素晴らしいCG映画、ゲーム、AIモデルなどが生まれました。このため、この協力プロセッサのアーキテクチャは、計算体系のアーキテクチャの飛躍的な進化を意味します。現在、各協力プロセッサチームもこのアーキテクチャをWeb3.0に導入しようとしています。ここでブロックチェーンはWeb3.0のCPUに似ており、L1でもL2でも、この「重データ」と「複雑な計算ロジック」のタスクには本質的に適していないため、ブロックチェーン協力プロセッサを導入してこれらの計算を処理し、ブロックチェーンアプリケーションの可能性を大幅に拡大します。
したがって、協力プロセッサが行うことをまとめると、二つのことです：
ブロックチェーンからデータを取得し、ZKを通じて私が取得したデータが本物であることを証明します。
先ほど取得したデータに基づいて相応の計算を行い、再度ZKを通じて私が計算した結果も本物であることを証明し、計算結果はスマートコントラクトによって「低コスト + 信頼なし」で呼び出されることができます。
最近、Starkwareのところで「ストレージ証明」という概念が注目を集めています。これは基本的にステップ1を行い、Herodotus、Langrageなど、多くのZK技術に基づくクロスチェーンブリッジの技術の重点もステップ1にあります。
協力プロセッサは、ステップ1を完了した後にステップ2を追加するだけで、信頼なしでデータを取得した後に信頼なしで計算を行うことができます。
したがって、比較的技術的な言葉で正確に表現すると、協力プロセッサはストレージ証明/ステート証明のスーパーセットであり、検証可能な計算（Verifiable Computation）のサブセットです。
注意すべき点は、協力プロセッサはRollupではないということです。
技術的に言えば、RollupのZK証明は上記のステップ2に類似しており、ステップ1「データを取得する」プロセスはSequencerを通じて直接実現されます。たとえそれが分散型Sequencerであっても、何らかの競争や合意メカニズムを通じてデータを取得するものであり、ストレージ証明のようなZKの形式ではありません。さらに重要なのは、ZK Rollupは計算層の他に、L1ブロックチェーンのようなストレージ層を実現する必要があり、このストレージは永久に存在しますが、ZK Coprocessorは「無状態」であり、計算を完了した後はすべての状態を保持する必要はありません。
アプリケーションシーンから見ると、協力プロセッサはすべてのLayer1/Layer2のサービス型プラグインと見なすことができ、Rollupは自ら新しい実行層を立ち上げ、決済層の拡張を助けます。
二. なぜZKを使わなければならないのか、OPでもいいのでは？
上記を見た後、あなたは疑問を持つかもしれません。協力プロセッサは、ZKを使わなければならないのでしょうか？どうも「ZKを加えたGraph」のように聞こえますが、私たちはGraph上の結果に対して特に「大きな疑念」を持っていないようです。
そう言うのは、普段Graphを使用する際、基本的に真金白銀に関わることが少ないからです。これらのインデックスはオフチェーンサービスを提供するものであり、あなたがフロントエンドユーザーインターフェースで見る取引量や取引履歴などのデータは、Graph、Alchemy、Zettablockなどの複数のデータインデックスプロバイダーを通じて提供されますが、これらのデータをスマートコントラクトに戻すことはできません。なぜなら、一旦戻すと、そのインデックスサービスに対する追加の信頼を増やすことになるからです。データが真金白銀、特に大規模なTVLと連動する場合、この追加の信頼が重要になります。友人が100元を借りたいと言ったら、あなたは目もくれずに貸すかもしれませんが、1万や100万を借りたいと言ったらどうでしょう？
しかし、逆に言えば、協力プロセッサのすべてのシーンが本当にZKを使わなければならないのでしょうか？結局、Rollupの中にはOPとZKの二つの技術ルートがあり、最近流行しているZKMLにも相応の分岐ルートのOPML概念が提案されています。では、協力プロセッサのこの件についてもOPの分岐、例えばOP-Coprocessorがあるのでしょうか？
実際にあります ―― ただし、具体的な詳細についてはここでは秘密にしておきます。すぐにより詳細な情報を発表する予定です。
三. 協力プロセッサはどこが強いのか ―― 市場に見られるいくつかの協力プロセッサ技術の比較
Brevis
Brevisのアーキテクチャは、zkFabric、zkQueryNet、zkAggregatorRollupの3つのコンポーネントで構成されています。
以下はBrevisのアーキテクチャ図です：
zkFabric： すべての接続されたブロックチェーンからブロックヘッダーを収集し、これらのブロックヘッダーの有効性を証明するZKコンセンサス証明を生成します。zkFabricを通じて、Brevisはマルチチェーンの相互運用可能な協力プロセッサを実現し、あるブロックチェーンが別のブロックチェーンの任意の履歴データにアクセスできるようにします。
zkQueryNet： dAppからのデータクエリを受け入れ、処理するオープンなZKクエリエンジン市場です。データクエリは、zkFabricからの検証済みのブロックヘッダーを使用してこれらのクエリを処理し、ZKクエリ証明を生成します。これらのエンジンは、高度に専門化された機能を持つものもあれば、さまざまなアプリケーションニーズに応じた汎用的なクエリ言語を持つものもあります。
zkAggregatorRollup： zkFabricとzkQueryNetの集約およびストレージ層として機能するZK畳み込みブロックチェーンです。これらの2つのコンポーネントからの証明を検証し、検証済みのデータを保存し、zk検証された状態ルートをすべての接続されたブロックチェーンに提出します。
ZK Fabricはブロックヘッダーの証明を生成する重要な部分として、この部分の安全性を確保することが非常に重要です。以下はzkFabricのアーキテクチャ図です：
zkFabricはゼロ知識証明（ZKP）に基づく軽量クライアントであり、完全に信頼を必要とせず、外部の検証エンティティに依存する必要がありません。安全性は完全に基盤となるブロックチェーンと数学的に信頼できる証明から来ています。
zkFabric Proverネットワークは、各ブロックチェーンのlightclientプロトコルの回路を実装し、このネットワークはブロックヘッダーの有効性証明を生成します。証明者はGPU、FPGA、ASICなどのアクセラレーターを利用して、証明時間とコストを最小限に抑えます。
zkFabricはブロックチェーンと基盤となる暗号プロトコルの安全仮定に依存しています。しかし、zkFabricの有効性を確保するためには、少なくとも1つの誠実なリレーターが正しいフォークを同期する必要があります。したがって、zkFabricは単一のリレーターではなく、分散型のリレーネットワークを採用してzkFabricの有効性を最適化しています。このリレーネットワークは、Celerネットワークの状態監視ネットワークなど、既存の構造を利用できます。
証明者の割り当て： 証明者ネットワークは分散型のZKP証明者ネットワークであり、各証明生成タスクのために証明者を選択し、これらの証明者に対して報酬を支払う必要があります。
現在の展開：
現在、さまざまなブロックチェーン（Ethereum PoS、Cosmos Tendermint、BNB Chainを含む）に対して軽量クライアントプロトコルが実装されており、例として概念実証が行われています。
Brevisは現在、uniswap hookとの協力を開始しており、hookはカスタマイズされたuniswapプールを大幅に追加しましたが、CEXと比較すると、UnisWapは依然として大規模なユーザー取引データ（例えば取引量に基づく忠誠度プログラム）に依存する機能を作成するための効果的なデータ処理機能が不足しています。
Brevisの助けを借りて、hookはこの課題を解決しました。hookは現在、ユーザーまたはLPの完全な履歴チェーンデータから読み取り、完全に信頼なしでカスタマイズ可能な計算を実行できます。
Herodotus
Herodotusは強力なデータアクセスミドルウェアであり、スマートコントラクトに対して以下のようなEthereum層間の現在および過去のチェーンデータへの同期アクセス機能を提供します：
L1の状態をL2から取得
L2の状態をL1および他のL2から取得
L3/App-Chainの状態をL2およびL1に取得
Herodotusはストレージ証明という概念を提唱しており、ストレージ証明はデータの存在を確認するための証明（データの存在を確認）と、複数のステップのワークフローの実行を検証するための計算証明（ワークフローの実行を検証）を融合させ、大規模なデータセット（例えば、Ethereumブロックチェーン全体やrollup）内の1つまたは複数の要素の有効性を証明します。
ブロックチェーンの核心はデータベースであり、そのデータはMerkleツリー、Merkle Patriciaツリーなどのデータ構造を使用して暗号的に保護されています。これらのデータ構造の特異性は、一度データが安全にそれらに提出されると、データが構造内に含まれていることを確認する証拠を生成できることです。
MerkleツリーとMerkle Patriciaツリーの使用はEthereumブロックチェーンの安全性を強化します。ツリーの各レベルでデータを暗号的にハッシュ化することで、データを発見されずに変更することはほぼ不可能です。データポイントの変更は、ツリー上の対応するハッシュ値を根ハッシュ値に変更する必要があり、これはブロックチェーンヘッダーに公開されます。このブロックチェーンの基本的な特性は、高レベルのデータ整合性と不変性を提供します。
次に、これらのツリーは包含証明を通じて有効なデータ検証を行うことができます。たとえば、トランザクションの包含や契約の状態を検証する際、Ethereumブロックチェーン全体を検索する必要はなく、関連するMerkleツリー内のパスを検証するだけで済みます。
Herodotusが定義するストレージ証明は以下の内容の融合です：
包含証明：これらの証明は、暗号データ構造（例えばMerkleツリーやMerkle Patriciaツリー）内の特定のデータの存在を確認し、関連データがデータセットに実際に存在することを保証します。
計算証明：複数のステップのワークフローの実行を検証し、広範なデータセット内の1つまたは複数の要素の有効性を証明します。これには、Ethereumブロックチェーン全体やrollupが含まれます。データの存在を示すだけでなく、そのデータに適用される変換や操作を検証します。
ゼロ知識証明：スマートコントラクトが必要とするインタラクションデータの量を簡素化します。ゼロ知識証明により、スマートコントラクトはすべての基礎データを処理することなく、請求の有効性を確認できます。
ワークフロー
- ブロックハッシュを取得
ブロックチェーン上のすべてのデータは特定のブロックに属します。ブロックハッシュはそのブロックの唯一の識別子であり、ブロックヘッダーを通じてそのすべての内容を要約します。ストレージ証明のワークフローでは、まず私たちが興味のあるデータを含むブロックのブロックハッシュを特定し、検証することが必要です。これはプロセス全体の最初のステップです。
- ブロックヘッダーを取得
関連するブロックハッシュを取得したら、次のステップはブロックヘッダーにアクセスすることです。そのためには、前のステップで取得したブロックハッシュに関連するブロックヘッダーをハッシュ処理する必要があります。次に、提供されたブロックヘッダーのハッシュ値を取得したブロックハッシュ値と比較します：
ハッシュを取得する方法は2つあります：
（1）BLOCKHASHオペコードを使用して取得
（2）ブロックハッシュアキュムレーターから、過去に検証されたブロックのハッシュを照会する
このステップにより、処理中のブロックヘッダーが本物であることが確認されます。このステップが完了すると、スマートコントラクトはブロックヘッダー内の任意の値にアクセスできるようになります。
- 必要なルートを決定（オプション）
ブロックヘッダーを取得したら、その内容を詳しく調べることができます。特に：
stateRoot： ブロックチェーンが発生したときの全体のブロックチェーン状態の暗号的要約。
receiptsRoot： ブロック内のすべての取引結果（レシート）の暗号的要約。
トランザクションルート（transactionsRoot）： ブロック内で発生したすべての取引の暗号的要約。
これにより、特定のアカウント、レシート、または取引がブロック内に含まれているかどうかを確認できます。
- 選択したルートに基づいてデータを検証（オプション）
選択したルートを持ち、EthereumがMerkle-Patricia Trie構造を採用していることを考慮すると、Merkle包含証明を利用してツリー内にデータが存在するかどうかを検証できます。検証ステップは、データとブロック内のデータの深さに応じて異なります。
現在サポートされているネットワーク：
EthereumからStarknetへ
Ethereum GoerliからStarknet Goerliへ
Ethereum GoerliからzkSync Era Goerliへ
Axiom
Axiomは、開発者がEthereumの全履歴からブロックヘッダー、アカウント、またはストレージ値をクエリできる方法を提供します。AXIOMは、暗号学に基づくリンクの新しい方法を導入しています。Axiomが返すすべての結果は、ゼロ知識証明によってチェーン上で検証されており、これによりスマートコントラクトは他の信頼仮定なしでそれらを使用できます。
Axiomは最近、Halo2-replを発表しました。これは、ブラウザベースでJavaScriptで書かれたhalo2 REPLです。これにより、開発者は標準のJavaScriptを使用してZK回路を作成でき、Rustなどの新しい言語を学ぶ必要がなく、証明ライブラリをインストールしたり、依存関係を処理したりする必要がありません。
Axiomは2つの主要な技術コンポーネントで構成されています：
- AxiomV1 --- Ethereumブロックチェーンのキャッシュ、創世から始まります。
- AxiomV1Query --- AxiomV1に対するクエリを実行するスマートコントラクト。
（1）AxiomV1でブロックハッシュをキャッシュする：
AxiomV1スマートコントラクトは、創世ブロック以来のEthereumブロックハッシュを2つの形式でキャッシュします：
まず、連続する1024のブロックハッシュのKeccak Merkleルートをキャッシュします。これらのMerkleルートはZK証明を通じて更新され、ブロックヘッダーハッシュがEVMから直接アクセス可能な最近の256のブロックのいずれかを形成するか、AxiomV1キャッシュ内に既に存在するブロックハッシュであることを検証します。
次に、Axiomは創世ブロックからこれらのMerkleルートのMerkle Mountain Rangeを保存します。このMerkle Mountain Rangeは、チェーン上で構築され、キャッシュされた最初の部分のKeccak Merkleルートを更新することによって形成されます。
（2）AxiomV1Queryでクエリを実行：
AxiomV1Queryスマートコントラクトは、歴史的なEthereumブロックヘッダー、アカウント、およびアカウントストレージの任意のデータに対する無信任アクセスを実現するためにバッチクエリを使用します。クエリはチェーン上で実行され、AxiomV1キャッシュのブロックハッシュに対するZK証明を通じてチェーン上で完了します。
これらのZK証明は、関連するチェーン上のデータがブロックヘッダー内に直接存在するか、ブロックのアカウントまたはストレージTrie内に存在するかを検証し、Merkle-Patricia Trieの包含（または不包含）証明を検証することによって実現されます。
Nexus
Nexusは、ゼロ知識証明を利用して検証可能なクラウドコンピューティングのための汎用プラットフォームを構築しようとしています。現在はmachine architecture agnosticで、RISC 5/WebAssembly/EVMをサポートしています。Nexusはsupernovaの証明システムを利用しており、チームは証明生成に必要なメモリを6GBとテストしており、将来的には一般のユーザー端末のコンピュータでも証明を生成できるように最適化する予定です。
正確には、アーキテクチャは2つの部分に分かれています：
Nexus zero：ゼロ知識証明と汎用zkVMによってサポートされる分散型検証可能クラウドコンピューティングネットワーク。
Nexus：マルチパーティ計算、状態機械の複製、および汎用WASM仮想マシンによって駆動される分散型検証可能クラウドコンピューティングネットワーク。
NexusおよびNexus Zeroアプリケーションは、従来のプログラミング言語で記述でき、現在はRustをサポートしており、今後はさらに多くの言語をサポートする予定です。
Nexusアプリケーションは、Ethereumに直接接続された汎用「サーバーレスブロックチェーン」である分散型クラウドコンピューティングネットワークで実行されます。したがって、NexusアプリケーションはEthereumの安全性を引き継がず、代わりにネットワークの規模が縮小されることで、より高い計算能力（計算、ストレージ、イベント駆動I/Oなど）を得ることができます。Nexusアプリケーションは、内部で合意を達成できる専用のクラウド上で実行され、Ethereum内部で検証可能な全ネットワークの閾値署名を通じて検証可能な計算の「証明」（実際の証明ではなく）を提供します。
Nexus Zeroアプリケーションは、ゼロ知識証明を持つ汎用プログラムであり、BN-254楕円曲線上でチェーン上で検証できます。
Nexusは、複製環境で任意の決定論的WASMバイナリファイルを実行できるため、zk-rollupのソーター、オプティミスティックロールアップのソーター、Nexus ZeroのzkVM自体など、証明生成アプリケーションの有効性/分散性/耐障害性のソースとして使用されることが期待されています。
