ここ数ヶ月でコプロセッサの概念が普及するにつれて、この新しいZKユースケースはますます注目を集め始めています。

しかし、ほとんどの人は、コプロセッサの概念、特にコプロセッサの正確な位置付け(コプロセッサとは何か、何がそうでないか)について、まだ比較的馴染みがないことがわかりました。 市場に出回っているいくつかのコプロセッサトラックの技術的ソリューションの比較に関しては、まだ誰も体系的に整理していません。 本稿では、市場とユーザーにコプロセッサトラックをより明確に理解してもらいたいと考えています。

1. コプロセッサとは何か、コプロセッサではないのか?

技術者や開発者以外の人にコプロセッサを一言で説明するように求められたら、どのように説明しますか?

Dong Mo博士が言ったことは、標準的な答えに非常に近いのではないかと思います - 単刀直入に言えば、コプロセッサは「スマートコントラクトにデューン分析を実行する能力を与える」のです。

この文を分解する方法は?

Duneを使用するシナリオを想像してみてください - Uniswap V3でLPをして手数料を稼ぎたいので、Duneを開いて、Uniswapのさまざまな取引ペアの最近の取引量、過去7日間の手数料のAPR、および主流の取引ペアの上下の変動範囲、 等。。。

あるいは、StepNが人気を博した頃、靴に投機し始め、いつ売ればいいのかわからず、毎日DuneのStepNデータ、毎日の取引量、新規ユーザー数、靴の最低価格を見つめていたのかもしれません。そして、成長があったら計画しました。 トレンドが鈍化または下降した場合は、すぐに実行してください。

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

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

たとえば、ユーザーがよく売買する靴のスタイルと価格に基づいて、類似の靴が推奨されます。

例えば、ユーザーがクリエイションシューズを保有している時間の長さに基づいて「ユーザーロイヤルティリワードプログラム」が開始され、ロイヤルユーザーにより多くのエアドロップや特典を提供します。

例えば、Cexと同様のVIPプランは、UniswapまたはTraderでLPが提供するTVLまたは取引量に基づいて開始され、トレーダーに取引手数料の削減や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にはStorage Proofと呼ばれる人気のある概念があり、State Proofとも呼ばれていました。 基本的には、ヘロドトス、ラングラージュなどに代表されるステップ1を実行します。 ZK技術に基づく多くのクロスチェーンブリッジの技術的な焦点もステップ1にあります。1オン。

コプロセッサは、ステップ 1 の後にステップ 2 が続くだけです。信頼せずにデータを抽出した後、信頼のない計算を行うだけです。

したがって、比較的専門的な用語を使用して正確に説明すると、コプロセッサはStorage Proof/State Proofのスーパーセットであり、Verfiable Computationのサブセットである必要があります。

注意すべき点の 1 つは、コプロセッサがロールアップではないということです。

技術的に言えば、Rollup の ZK 証明は上記のステップ 2 と似ており、ステップ 1 の「データの取得」のプロセスはシーケンサーを介して直接実装されます。 分散型シーケンサーでさえ、これを実現するために何らかの競争やコンセンサスメカニズムを使用するだけです。 Storage Proofの代わりに、この形式のZKを取ります。 さらに重要なことは、ZK Rollupは計算レイヤーに加えて、L1ブロックチェーンと同様のストレージレイヤーも実装する必要があるということです。 このストレージは永続的ですが、ZK コプロセッサーは「ステートレス」です。 計算が完了した後、[すべて] ステータスは保持されません。

アプリケーション シナリオの観点からは、コプロセッサはすべてのレイヤ 1/レイヤ 2 のサービス プラグインと見なすことができ、ロールアップは実行レイヤを再作成して決済レイヤの拡張を支援します。

2. なぜZKを使わなければならないのですか? OPを使っても大丈夫ですか?

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

これは、グラフを使用する場合、基本的にリアルマネーが関与しないためです。 これらのインデックスは、オフチェーンサービスを提供します。 フロントエンドのユーザーインターフェースに表示されるのは、取引量、取引履歴などです。 データは、Graph、Alchemy、Zettablockなどの複数のデータインデックスプロバイダーを通じて提供できますが、これらのデータをスマートコントラクトに詰め込むことはできません。 データがリアルマネー、特に大容量のTVLにリンクされている場合、この特別な信頼性が重要になります。 次に友人に100元を借りるように頼まれたとき、まばたきもせずに貸すことができると想像してみてください。 はい、10,000元、あるいは100万元を借りるように頼んだらどうですか?

しかし、繰り返しになりますが、上記のすべてのシナリオを共同処理するためにZKを使用する必要があるのでしょうか? 結局のところ、ロールアップにはOPとZKの2つのテクニカルルートがあります。 最近人気のZKMLには、対応する分岐ルートのOPMLコンセプトもあります。 コプロセッサには、OPコプロセッサなどのOPのブランチもありますか?

実際、本当にありますが、今のところ具体的な詳細は秘密にしており、近日中により詳細な情報を公開します。

3. どのコプロセッサーが最適か - 市場に出回っているいくつかの一般的なコプロセッサー技術ソリューションの比較

ブレビス

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

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

zkFabric:接続されているすべてのブロックチェーンからブロックヘッダーを収集し、これらのブロックヘッダーの有効性を証明するZKコンセンサスプルーフを生成します。 ブレビスは、zkFabricを通じて、複数のチェーンに相互運用可能なコプロセッサを実装しており、あるブロックチェーンが別のブロックチェーンの履歴データにアクセスできるようにします。

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プールを大幅に追加するUniswapフックと協力しています。 ただし、CEXと比較すると、UnisWapには、大規模なユーザートランザクションデータ(トランザクション量に基づくロイヤルティプログラムなど)に依存するプロジェクトを作成するための効果的なデータ処理機能がまだありません。 機能。

ブレビスの助けを借りて、フックはこの課題を解決しました。 フックは、ユーザーやLPの完全な履歴チェーンデータから読み取り、完全にトラストレスな方法でカスタマイズ可能な計算を実行できるようになりました。

ヘロドトス

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

1. L2 からの L1 状態
2. L1 と他の L2 の両方からの L2 状態
3. L3/App-Chain の状態から L2 と L1 へ

ヘロドトスは、包含証明(データの存在の確認)と計算証明(多段階のワークフローの実行の検証)を組み合わせて、大規模なデータセット(イーサリアムブロックチェーン全体やロールアップなど)または複数の要素の有効性を証明するストレージ証明の概念を提案しました。

ブロックチェーンの中核となるのはデータベースであり、マークルツリーやマークルパトリシアツリーなどのデータ構造を使用してデータが暗号化および保護されています。 これらのデータ構造のユニークな点は、データが安全にコミットされると、データが構造内に含まれていることを確認するための証拠を生成できることです。

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

第二に、これらのツリーは、包含証明による効率的なデータ検証を可能にします。 例えば、トランザクションの包含やコントラクトの状態を検証する場合、イーサリアムブロックチェーン全体を検索する必要はなく、関連するマークルツリー内のパスのみを検索する必要があります。

ヘロドトスによって定義されたストレージの証明は、次の融合です。

1. 包含証明: これらの証明は、暗号化データ構造 (マークル ツリーやマークル パトリシア ツリーなど) に特定のデータが存在することを確認し、問題のデータがデータセットに実際に存在することを確認します。
2. 計算証明:マルチステップのワークフローの実行を検証し、イーサリアムブロックチェーン全体やアグリゲートなど、幅広いデータセット内の1つ以上の要素の有効性を証明します。 データの存在を示すだけでなく、そのデータに適用された変換や操作も検証します。
3. ゼロ知識証明:スマートコントラクトがやり取りする必要のあるデータの量を簡素化します。 ゼロ知識証明により、スマートコントラクトは、基礎となるデータをすべて処理することなく、請求の有効性を確認することができます。

ワークフロー

1.ブロックハッシュの取得

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

2.ブロックヘッダの取得

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

ハッシュを取得するには、次の 2 つの方法があります。

1. BLOCKHASHオペコードを使用して取得する
2. ブロックハッシュアキュムレータから履歴で検証されたブロックのハッシュを照会します

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

3.必要なルートを決定します(オプション)

ブロックヘッダーが手元にあるので、その内容を具体的に掘り下げることができます。

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

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

TransactionsRoot: ブロック内で発生したすべてのトランザクションの暗号化ダイジェスト。

デコードできるため、特定のアカウント、レシート、またはトランザクションがブロックに含まれているかどうかを検証できます。

4.選択したルートに対してデータを検証する(オプション)

選択したルートで、イーサリアムがマークル・パトリシア・トライ構造を使用していることを考慮すると、マークル包含証明を使用して、データがツリーに存在することを確認できます。 検証手順は、データとブロック内のデータの深さによって異なります。

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

1. イーサリアムからスターネットへ
2. イーサリアムGoerli からStarknet Goerliへ
3. イーサリアムGoerli からzkSync Era Goerliへ

公理

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

Axiom は最近、Javascript で記述されたブラウザベースの halo2 REPL である Halo2-repl をリリースした。 これにより、開発者はRustなどの新しい言語を学習したり、プルーフライブラリをインストールしたり、依存関係を処理したりすることなく、標準のJavascriptを使用してZK回路を記述できます。

Axiom は、2 つの主要なテクノロジ コンポーネントで構成されています。

1. AxiomV1 — Genesis から始まるイーサリアムブロックチェーンキャッシュ。
2. AxiomV1Query — AxiomV1 に対してクエリを実行するスマートコントラクト。

AxiomV1でのブロックハッシュのキャッシュ:

AxiomV1スマートコントラクトは、ジェネシスブロック以降のイーサリアムブロックハッシュを2つの形式でキャッシュします。

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

第二に、Axiom は、これらのマークルの根のマークル山脈をジェネシスブロックから格納します。 マークル山脈は、キャッシュの最初の部分であるKeccak Merkleルートを更新することでオンチェーンで構築されています。

AxiomV1Query でクエリを実行します。

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

これらのZKプルーフは、Merkle-Patriciaトライのインクルージョン(またはインクルージョンなし)プルーフを検証することで、関連するオンチェーンデータがブロックヘッダーに直接配置されているか、ブロックのアカウントまたはストレージトライにあるかを確認します。

ネクサス

Nexusは、ゼロ知識証明を使用して、検証可能なクラウドコンピューティングのためのユニバーサルプラットフォームを構築しようとしています。 現在、マシンのアーキテクチャーにとらわれず、risc 5/ WebAssembly / EVMをサポートしています。 ネクサスは超新星の証明システムを使用しています。 チームは、証明の生成に必要なメモリが6GBであることをテストしました。 将来的には、通常のクライアントデバイスコンピュータが証明を生成できるように、これに基づいて最適化されます。

正確には、アーキテクチャは 2 つの部分に分かれています。

1. ネクサスゼロ:ゼロ知識証明とユニバーサルzkVMを搭載した分散型検証可能なクラウドコンピューティングネットワーク。
2. Nexus: マルチパーティ計算、ステートマシンレプリケーション、ユニバーサルWASM仮想マシンを搭載した分散型の検証可能なクラウドコンピューティングネットワーク。

NexusとNexus Zeroのアプリケーションは、従来のプログラミング言語で記述でき、現在Rustをサポートしており、今後さらに多くの言語がサポートされる予定です。

Nexusアプリケーションは、基本的にイーサリアムに直接接続された汎用の「サーバーレスブロックチェーン」である分散型クラウドコンピューティングネットワーク上で実行されます。 したがって、Nexusアプリケーションはイーサリアムのセキュリティを継承しませんが、その代わりに、ネットワークのサイズが小さくなるため、より高いコンピューティングパワー(コンピューティング、ストレージ、イベントドリブンI/Oなど)にアクセスできます。 Nexusアプリケーションは、内部コンセンサスを達成し、イーサリアム内の検証可能なネットワーク全体のしきい値署名を通じて、(真の証明ではなく)検証可能な計算の「証明」を提供する専用クラウド上で実行されます。

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

Nexusは、複製された環境で任意の決定論的WASMバイナリを実行できるため、zk-rollupシーケンサー、楽観的ロールアップシーケンサー、およびNexus ZeroのzkVM自体などの他の証明サーバーを含む、生成されたアプリケーションの有効性/分散/フォールトトレランスの証明のソースとして使用されることが期待されています。

免責事項：

1. この記事は[panewslab]からの転載です。 すべての著作権は原著作者に帰属します [ABCDE]。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。