1. それは協力者であり、それは何ではありませんか？

もしあなたが非技術者や開発者にコプロセッサを1文で説明するよう求められたら、どのように説明しますか？

ドクター・ドン・モーが言ったことは非常に標準的な答えに非常に近いと思います- 正直に言って、共同プロセッサは「スマートコントラクトにDune Analyticsの機能を与えている」と言えます。

この文を解体する方法は？

Duneを使用するシナリオを想像してみてください - Uniswap V3でLPを行い、手数料をいくらか稼ぐことを望んでいるとします。したがって、Duneを開いて、Uniswapのさまざまな取引ペアの直近の取引量、過去7日間の手数料のAPR、主要取引ペアの上下の変動範囲などを見つけます...

または、StepNが人気を博したときに、靴の投機を始めたかもしれませんが、いつ売るべきかわからず、毎日DuneでStepNのデータを見つめ、日々の取引量や新規ユーザー数、靴の床価格などを見て、成長があれば計画していました。トレンドが鈍化したり下がったりしたら、すぐに逃げることを考えていました。

もちろん、あなたはこれらのデータを見つめているだけでなく、UniswapとStepNの開発チームもこれらのデータに注目しています。

このデータは非常に意義深いです- トレンドの変化を判断するだけでなく、主要なインターネット企業が一般的に使用しているように、「ビッグデータ」アプローチを使用して、より多くのトリックを作成するのにも役立ちます。

例えば、ユーザーがよく購入や販売する靴のスタイルや価格に基づいて、似たような靴が推薦されます。

例えば、ユーザーが創始シューズを保有する期間に基づいて、「ユーザー忠誠度リワードプログラム」が立ち上げられ、忠実なユーザーにより多くのエアドロップや特典が提供される予定です。

たとえば、UniswapのLPまたはTraderが提供するTVLまたは取引量に基づいて、Cexに類似したVIPプランを立ち上げることができ、Traderに取引手数料削減やLP手数料シェア増加の特典を提供します。

……

この時、問題が生じる- 主要なインターネット企業が大規模なデータ+AIを扱う際、基本的にはブラックボックスである。彼らはやりたい放題できる。ユーザーはそれを見ることができず、気にも留めない。

しかし、Web3側では、透明性と信頼性は私たちの自然な政治的正しさであり、私たちはブラックボックスを拒否します！

上記のシナリオを実現したい場合、ジレンマに直面することになります。集中手段を通じて実現するか、「手動」でDuneを使用してバックグラウンドでインデックスデータをカウントし、それを展開して実装するか、またはスマートコントラクトを作成して、チェーン上でこれらのデータを自動的にキャプチャし、計算を完了し、ポイントを自動的に展開するか、のいずれかです。

前者はあなたに「政治的に正しくない」信頼の問題を残すことがあります。

後者がチェーン上で生成するガス手数料は天文学的な数字になり、あなたの（プロジェクト側）ウォレットではそれを負担できません。

これは、共同プロセッサーがステージに登場する時です。ちょうど今までの2つの方法を組み合わせ、同時に「バックグラウンドマニュアル」手順を使用して技術手段を通じて「自己証明の無実」を行います。言い換えると、ZKテクノロジーを使用して、チェーン外で「インデックス+」を使用します。そして、「計算」部分で「自己証明の無実」を行い、それをスマートコントラクトに送信します。これにより、信頼問題が解決され、大量のガス手数料がなくなります。完璧です！

なぜそれを「コプロセッサ」と呼ぶのですか？ 実際、これはWeb2.0の開発史における「GPU」から派生しています。当時、GPUがCPUとは独立して存在し、独自の計算ハードウェアとして導入された理由は、その設計アーキテクチャがCPUが基本的に処理しづらいいくつかの計算（大規模な並列繰り返し計算、グラフィック計算など）を処理できるためです。 今日、CG映画、ゲーム、AIモデルなどが素晴らしいものとなっているのは、この「コプロセッサ」アーキテクチャがあるからです。そのため、様々なコプロセッサチームもこのアーキテクチャをWeb3.0に導入したいと考えています。ここでのブロックチェーンは、Web3.0のCPUに似ています。 L1またはL2であっても、「重いデータ」や「複雑な計算ロジック」といったタスクに適していないため、ブロックチェーンのコプロセッサが導入され、そのような計算を処理するのに役立ち、それによってブロックチェーンアプリケーションの可能性が大幅に拡大されています。

コプロセッサーの役割は、2つに要約することができます:

1. ブロックチェーンからデータを取得し、ZKを介してそのデータが真実であり改ざんされていないことを証明します;
2. 私がさっき手に入れたデータをもとに対応する計算を行い、再度ZKを使用して、計算した結果が真実であり不正がないことを証明します。計算結果はスマートコントラクト「Low Fee + Trustless」と呼ばれることができます。

以前、Starkwareは「ストレージプルーフ」と呼ばれる人気のあるコンセプトがありました。これは基本的にヘロドトス、ラングラージなどによって表されるステップ1、またはステートプルーフとも呼ばれます。ZKテクノロジーに基づく多くのクロスチェーンブリッジの技術的焦点もステップ1にあります。

コプロセッサは、ステップ1が完了した後のステップ2の追加以上のものではありません。信頼性のないデータの抽出後、信頼性のない計算を行うことができます。

比較的専門的な用語を使用して正確に説明すると、コプロセッサは、ストレージプルーフ/ステートプルーフのスーパーセットであり、検証可能な計算のサブセットであるはずです。

注意すべきことは、コプロセッサーがRollupではないということです。

技術的に言えば、RollupのZKプルーフは上記のステップ2に類似しており、ステップ1の「データの取得」プロセスはシーケンサを介して直接実装されます。分散型シーケンサであっても、ある種の競争またはコンセンサスメカニズムのみを使用します。ZKの形式のストレージプルーフの代わりにそれを取る。さらに重要なのは、計算レイヤーに加えて、ZK RollupはL1ブロックチェーンに類似したストレージレイヤーを実装する必要があることです。このストレージは永続的であり、ZK Coprocessorは「ステートレス」です。計算が完了すると、すべての状態が保持されません。

アプリケーションシナリオの観点から、CoprocessorはすべてのLayer1/Layer2のためのサービスプラグインとして見なすことができ、一方、Rollupは決済レイヤーを拡張するための実行レイヤーを再作成します。

2. なぜZKを使用する必要がありますか？OPを使用しても大丈夫ですか？

上記を読んだ後、ZKをコプロセッサとして使用する必要があるのか疑問に思うかもしれません。これはまるで「ZKを追加したグラフ」のようで、グラフの結果については「大きな疑問」がないようです。

なぜなら、Graph を使用すると、基本的に実際のお金は関与しません。これらの指標はオフチェーンサービスを提供します。フロントエンドユーザーインターフェースに表示されるのは取引量、取引履歴などです。データは、Graph、Alchemy、Zettablock など、複数のデータ指標プロバイダーを介して提供できますが、このデータをスマート契約に戻すことはできません。なぜなら、それを戻すと、インデックスサービスへの追加信頼が増します。データが実際のお金にリンクされると、特に大口の TVL の場合、この追加の信頼が重要になります。友達が次に100元を借りるよう頼んできたら、たぶん瞬時に貸してしまうでしょう。しかし、私が10,000元、あるいは100万元を借りるよう頼んだらどうでしょうか？

しかし、上記のすべてのシナリオを共同処理するために本当にZKを使用する必要があるのでしょうか？ 結局のところ、RollupにはOPとZKの2つの技術経路があります。 最近人気のあるZKMLには、対応するブランチ経路のOPMLコンセプトもあります。 CoprocessorにもOPのブランチがあるのでしょうか、例えばOP-Coprocessorなどがありますか？

実際には、特定の詳細情報は現時点では機密として保持しており、近日中により詳細な情報を公開します。

3. どのコプロセッサーがより優れていますか - 市場で一般的ないくつかのコプロセッサー技術ソリューションの比較

1. ブレビス:

Brevisのアーキテクチャは、zkFabric、zkQueryNet、zkAggregatorRollupの3つのコンポーネントで構成されています。

以下は、Brevisアーキテクチャ図です：

zkFabric：すべての接続されたブロックチェーンからブロックヘッダーを収集し、これらのブロックヘッダーの妥当性を証明するZKコンセンサス証明を生成します。zkFabricを介して、Brevisは複数のチェーンに対して相互運用可能なコプロセッサを実装し、1つのブロックチェーンが他のブロックチェーンの任意の過去データにアクセスできるようにします。

zkQueryNet：dAppsからデータクエリを受け入れ、それらを処理するオープンZKクエリエンジンマーケットプレイス。これらのエンジンは、zkFabricから検証されたブロックヘッダを使用してこれらのクエリを処理し、ZKクエリ証明を生成します。これらのエンジンには、さまざまなアプリケーションのニーズに対応する高度に特殊化された機能と一般的なクエリ言語の両方が備わっています。

zkAggregatorRollup: zkFabricとzkQueryNetの集約およびストレージレイヤーとして機能するZK畳み込みブロックチェーン。両コンポーネントから証明を検証し、検証済みデータを保持し、そのzk検証済み状態ルートをすべての接続されたブロックチェーンにコミットします。

ZK Fabricはブロックヘッダーの証明を生成するための重要な部分です。この部分のセキュリティを確保することは非常に重要です。次に、zkFabricのアーキテクチャ図が示されています。

zkFabricのゼロ知識証明（ZKP）ベースの軽量クライアントは、外部の検証エンティティに依存せず、完全に信頼できます。ブロックチェーンの基盤と数学的に信頼性のある証明からセキュリティが完全に得られるため、外部の検証エンティティに頼る必要はありません。

zkFabric Proverネットワークは、各ブロックチェーンのライトクライアントプロトコルのための回路を実装し、ネットワークはブロックヘッダーの妥当性証明を生成します。プロバーは、GPU、FPGA、ASICなどのアクセラレータを活用して、証明の時間とコストを最小限に抑えることができます。

zkFabricは、ブロックチェーンと基礎となる暗号化プロトコルのセキュリティの前提条件と基礎となる暗号化プロトコルのセキュリティの前提条件に依存しています。しかし、zkFabricの効果を確保するためには、少なくとも1つの誠実なリレーヤーが正しいフォークを同期させる必要があります。そのため、zkFabricは、zkFabricの効果を最適化するために単一のリレーではなく分散型のリレーネットワークを採用しています。このリレーネットワークは、Celerネットワークのステートガードネットワークなどの既存の構造を活用することができます。

プロバー割り当て：プロバーネットワークは、各証明生成タスクに対してプロバーを選択し、これらのプロバーに手数料を支払う分散型ZKPプロバーネットワークです。

現在の展開:

Ethereum PoS、Cosmos Tendermint、およびBNB Chainなど、さまざまなブロックチェーンに実装されているライトクライアントプロトコルは、実例およびコンセプトの証明として機能しています。

Brevisは現在、uniswap hookと協力しており、これによりカスタムuniswapプールが大幅に追加されています。 ただし、CEXと比較して、Uniswapにはまだ大規模なユーザートランザクションデータに依存するプロジェクトを作成するための効果的なデータ処理機能が不足しています（取引量に基づくロイヤルティプログラムなど）。 機能。

Brevisの助けを借りて、hookは課題を解決しました。Hooksは今やユーザーやLPの完全な履歴チェーンデータから読み取り、カスタマイズ可能な計算を完全に信頼できる方法で実行できます。

1. ヘロドトス

Herodotusは、スマートコントラクトに次の機能を提供する強力なデータアクセスミドルウェアであり、イーサリアムレイヤー全体でチェーン上の現在および過去のデータに同期してアクセスする機能を提供します。

L1はL2からの状態

L1からのL2の状態と他のL2の状態

L3/App-ChainはL2およびL1に状態を示します

ヘロドトスは、ストレージの証明の概念を提案しました。これは、データの存在を確認する包含の証明と、複数段階のワークフローの実行を検証する計算の証明を組み合わせて、大規模なデータセット（例えば、全てのEthereumブロックチェーンやロールアップ）や複数の要素の有効性を証明するものです。

ブロックチェーンのコアはデータベースであり、データはMerkleツリーやMerkle Patriciaツリーなどのデータ構造を使用して暗号化され保護されています。これらのデータ構造の特長は、データが安全にそれにコミットされると、その構造内にデータが含まれていることを確認するための証拠を生成できることです。

MerkleツリーとMerkle Patriciaツリーの使用は、Ethereumブロックチェーンのセキュリティを向上させます。 ツリーの各レベルでデータを暗号的にハッシュ化することにより、データを検出せずに変更することはほぼ不可能です。 データポイントへの変更には、対応するツリーのルートハッシュに対するハッシュを変更する必要があり、これはブロックチェーンヘッダーで公開されています。 このブロックチェーンの基本的な機能は、高いレベルのデータ整合性と不変性を提供します。

これらの木は、インクルージョンプルーフを介した効率的なデータ検証を可能にします。たとえば、トランザクションのインクルージョンや契約の状態を検証する際に、イーサリアムブロックチェーン全体を検索する必要はなく、関連するMerkle木内のパスのみを検索すればよいのです。

ヘロドトスによって定義された記憶の証明は、次のものの融合です:

• コンテインメントプルーフ：これらの証明は、暗号データ構造（マークルツリーやマークルパトリシアツリーなど）内の特定のデータの存在を確認し、そのデータが実際にデータセット内に存在していることを保証します。
• 計算証明：複数のステップワークフローの実行を検証し、広範なデータセット（たとえば、全体のEthereumブロックチェーンまたは集計など）の1つ以上の要素の妥当性を証明します。データの存在を示すだけでなく、そのデータに適用された変換や操作も検証します。
• ゼロ知識証明：スマートコントラクトが相互作用する必要のあるデータ量を簡素化します。ゼロ知識証明により、スマートコントラクトは、すべての基礎データを処理せずに主張の妥当性を確認することができます。

ワークフロー：

1. ブロックハッシュを取得する

ブロックチェーン上のすべてのデータは特定のブロックに属しています。ブロックハッシュは、ブロックのユニークな識別子として機能し、ブロックヘッダーを介してすべての内容を要約します。ストレージの証明ワークフローでは、まず、興味のあるデータを含むブロックのブロックハッシュを決定して検証する必要があります。これは全体のプロセスの最初のステップです。

1. ブロックヘッダーを取得する

関連するブロックハッシュが取得されたら、次のステップはブロックヘッダーにアクセスすることです。これを行うには、前のステップで取得したブロックハッシュに関連付けられたブロックヘッダーをハッシュする必要があります。提供されたブロックヘッダーのハッシュは、その結果のブロックハッシュと比較されます:

ハッシュを取得する方法は2つあります:

(1) BLOCKHASHオペコードを使用して取得します

(2) ブロックハッシュアキュムレータから過去に検証されたブロックのハッシュをクエリします

このステップによって、処理されているブロックヘッダーが本物であることが確認されます。このステップが完了すると、スマートコントラクトはブロックヘッダー内の任意の値にアクセスできます。

1. 必要なルートを決定します（オプション）

ブロックヘッダーを手に入れたら、その内容、具体的には次のように探求できます。

stateRoot: ブロックチェーンが発生した時点でのブロックチェーン全体の状態の暗号ダイジェスト。

receiptsRoot: ブロック内のすべてのトランザクション結果（レシート）の暗号化されたダイジェスト。

TransactionsRoot: ブロックで発生したすべての取引の暗号ダイジェスト。

特定のアカウント、領収書、または取引がブロックに含まれているかどうかを検証することができるため、デコードされる可能性があります。

1. 選択したルートに対してデータを検証します（オプション）

選択したルートと、EthereumがMerkle-Patricia Trie構造を使用していることを考慮すると、Merkle包含証明を使用してデータが木に存在することを検証できます。検証手順は、データとブロック内のデータの深さに応じて異なります。

現在サポートされているネットワーク：

イーサリアムからスタークネットへ

From Ethereum GoerliStarknet Goerliへ

From Ethereum Goerlito zkSync Era Goerli

1. アクシオム

Axiomは、開発者がイーサリアムの全履歴からブロックヘッダー、アカウント、またはストレージ値をクエリする方法を提供します。AXIOMは、暗号技術に基づく新しいリンク方法を導入しています。Axiomによって返されるすべての結果は、ゼロ知識証明を介してチェーン上で検証されます。つまり、スマートコントラクトは追加の信頼の前提なしにそれらを使用できます。

Axiom最近リリースされましたHalo2-repl、Javascriptで書かれたブラウザベースのhalo2 REPLです。これにより、開発者はRustのような新しい言語を学ぶ必要なく、証明ライブラリをインストールしたり、依存関係を扱ったりせずに、標準のJavascriptだけを使用してZK回路を作成できます。

アクショムは2つの主要な技術コンポーネントから成り立っています:

AxiomV1 — イーサリアムブロックチェーンキャッシュ、ジェネシスから開始します。

AxiomV1Query — AxiomV1に対してクエリを実行するスマートコントラクト。

(1) AxiomV1でのキャッシュブロックハッシュ値：

AxiomV1スマートコントラクトは、創世ブロック以来のEthereumブロックハッシュを2つの形式でキャッシュします。

最初に、1024連続するブロックハッシュのKeccak Merkleルートがキャッシュされます。これらのMerkleルートはZKプルーフを介して更新され、ブロックヘッダーハッシュがEVMから直接アクセス可能な最新の256ブロックの1つで終わるコミットメントチェーンを形成していることを検証します。またはAxiomV1キャッシュにすでに存在するブロックハッシュ。

第二に、アクシオムはこれらのマークルルートのマークルマウンテンレンジをジェネシスブロックから格納します。マークルマウンテンレンジは、キャッシュの最初の部分、Keccakマークルルートの更新によってオンチェーン上に構築されます。

(2) AxiomV1Query でクエリを実行します:

AxiomV1Queryスマートコントラクトは、過去のEthereumブロックヘッダー、アカウント、およびアカウントに格納された任意のデータへのトラストレスアクセスを可能にするバッチクエリに使用されます。クエリはオンチェーンで行われ、AxiomV1のキャッシュされたブロックハッシュに対するZKプルーフを使用してオンチェーンで完了されます。

これらのZK証明は、Merkle-Patricia Trieの包含（または非包含）証明を検証することにより、オンチェーンデータがブロックヘッダー内に直接配置されているか、ブロックのアカウントまたはストレージトライ内にあるかを確認します。

1. ネクサス

Nexusは、ゼロ知識証明を使用して検証可能なクラウドコンピューティングのための共通プラットフォームを構築しようとしています。現在、それは機械アーキテクチャに関係なく、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内で内部合意を達成し、Ethereum内でネットワイドな閾値署名を通じて検証可能な「証明」（真の証明ではない）を提供するプライベートクラウド上で実行されます。

Nexus Zeroアプリケーションは、BN-254楕円曲線上でチェーン上で検証できるゼロ知識証明を持つユニバーサルプログラムであるため、Ethereumのセキュリティを継承します。

Nexusは任意の確定的なWASMバイナリを複製された環境で実行できるため、zk-rollupシーケンサー、楽観的なrollupシーケンサー、Nexus ZeroのzkVM自体など、生成されたアプリケーションの正当性/分散/障害耐性の証明元として使用されることが期待されています。

免責事項：

1. この記事は[から転載されていますメディア]. すべての著作権は元の著者に帰属します[ABCDE]. If there are objections to this reprint, please contact the Gate Learnチームが迅速に対応します。
2. 責任の免除: この記事で表現されている見解や意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. 記事の翻訳は、Gate Learnチームによって行われます。特に記載がない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。