ここ数カ月間のコプロセッサのコンセプトの人気により、この新しい ZK の使用例はますます注目を集め始めています。

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

1. コプロセッサーとは何ですか?また、コプロセッサーではないものは何ですか?

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

Dong Mo 博士の言ったことは標準的な答えに非常に近いかもしれないと思います。率直に言うと、コプロセッサーは「スマート コントラクトに Dune Analytics を実行する能力を与えている」のです。

この文をどう分解するか?

Dune を使用するシナリオを想像してください。Uniswap V3 で LP を実行して手数料を稼ぎたいので、Dune を開いて、Uniswap のさまざまな取引ペアの最近の取引量、過去 7 日間の手数料の APR を確認します。と主流の取引ペアの変動幅の上限と下限など...

あるいは、StepN が人気になったときに、靴を検討し始めましたが、いつ売ればよいか分からず、Dune の StepN データ、毎日の取引高、新規ユーザー数、最低価格を毎日眺めていたのかもしれません。靴... 成長が見られたら計画しました。傾向が鈍化するか下降する場合は、すぐに実行してください。

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

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

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

たとえば、ユーザーがChuangshiシューズを保持している時間の長さに基づいて、忠実なユーザーにさらに多くのエアドロップや特典を与える「ユーザーロイヤルティ報酬プログラム」が開始されます。

たとえば、Cex と同様の VIP プランは、Uniswap 上の LP またはトレーダーによって提供される TVL または取引量に基づいて開始でき、トレーダーの取引手数料の削減または LP 手数料のシェア増加のメリットが得られます。

…

このとき、問題は、大手インターネット企業のビッグデータと AI は基本的にブラックボックスであり、彼らがやりたいことを何でもできますが、ユーザーはそれを見ることができず、気にしません。

しかし、Web3 側では、透明性とトラストレス性が私たちの自然なポリティカル コレクトネスであり、ブラック ボックスを拒否します。

したがって、上記のシナリオを実現したい場合は、ジレンマに直面することになります。一元的な手段で実現するか、Dune を「手動で」使用してバックグラウンドでインデックス データをカウントし、デプロイして実装するか、次のように記述するかのいずれかです。 a スマート コントラクトをセットアップして、チェーン上でこれらのデータを自動的に取得し、計算を完了し、ポイントを自動的に展開します。

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

チェーン上の後者によって生成されるガス料金は天文学的な数字になり、あなたの（プロジェクト側）の財布ではそれを支払う余裕はありません。

コプロセッサの出番です。先ほどの 2 つの方法を組み合わせ、同時に「バックグラウンド マニュアル」ステップを使用して、技術的手段で「無実を自己証明」します。つまり、ZK を使用します。チェーンの外側に「インデックス +」する技術。「計算」部分は「無罪を自己証明」し、それをスマート コントラクトにフィードします。このようにして、信頼の問題は解決され、莫大なガス料金がなくなりました。完璧です!

コプロセッサの出番です。先ほどの 2 つの方法を組み合わせ、同時に「バックグラウンド マニュアル」ステップを使用して、技術的手段で「無実を自己証明」します。つまり、ZK を使用します。チェーンの外側に「インデックス +」する技術。「計算」部分は「無罪を自己証明」し、それをスマート コントラクトにフィードします。このようにして、信頼の問題は解決され、莫大なガス料金がなくなりました。完璧です!

なぜ「コプロセッサ」と呼ばれるのでしょうか?実はこれ、Web2.0の開発史における「GPU」に由来しています。当時、GPU が別個のコンピューティング ハードウェアとして導入され、CPU とは独立して存在していた理由は、その設計アーキテクチャが、大規模な並列繰り返し計算やグラフィックスなど、CPU では根本的に処理が困難な一部の計算を処理できるためでした。計算など。まさにこの「コプロセッサ」アーキテクチャのおかげで、今日私たちは素晴らしい CG 映画、ゲーム、AI モデルなどを持っているので、このコプロセッサ アーキテクチャは実はコンピューティング アーキテクチャの飛躍です。現在、さまざまなコプロセッサ チームも、このアーキテクチャを Web3.0 に導入したいと考えています。ここでのブロックチェーンは Web3.0 の CPU に似ています。L1 であっても L2 であっても、本質的にそのような「重いデータ」や「複雑なデータ」には適していません。そこで、そのような計算の処理を支援するためにブロックチェーン コプロセッサが導入され、それによってブロックチェーン アプリケーションの可能性が大幅に広がります。

したがって、コプロセッサが行うことは次の 2 つに要約できます。

少し前に、Starkware には、Storage Proof (State Proof とも呼ばれる) と呼ばれる人気の概念がありました。基本的には、Herodotus、Langrage などに代表されるステップ 1 を実行します。ZK テクノロジーに基づく多くのクロスチェーン ブリッジの技術的焦点も、ステップ 1 にあります。 .1で。

コプロセッサは、ステップ 1 が完了した後にステップ 2 を追加するだけであり、トラストなしでデータを抽出した後、トラストフリーの計算を行うことができます。

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

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

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

アプリケーション シナリオの観点から見ると、コプロセッサはすべての Layer1/Layer2 のサービス プラグインとみなすことができますが、Rollup は決済層の拡張を支援するために実行層を再作成します。

2. なぜ ZK を使用しなければならないのですか? OP を使用しても問題ありませんか?

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

それは、Graph を使用する場合、基本的に実際のお金が関与しないためです。これらのインデックスはオフチェーン サービスとして機能します。フロントエンドのユーザー インターフェイスに表示されるのは、トランザクション量、トランザクション履歴などです。データは複数のデータを通じて提供できます。 Graph、Alchemy、Zettablock などのインデックス プロバイダーを使用できますが、このデータをスマート コントラクトに戻すことはできません。一度戻すと、インデックス サービスの信頼性がさらに高まるからです。データが実際のお金、特に大容量の TVL にリンクされている場合、この特別な信頼が重要になります。次に友人に 100 元を貸してと頼まれたら、瞬きもせずに貸すかもしれないと想像してください。 1万元、あるいは100万元でも貸してくださいとお願いしますか？

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

実際には存在しますが、具体的な詳細については今のところ機密としており、より詳細な情報は近々公開する予定です。

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

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

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

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

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

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

ZK Fabric は、ブロック ヘッダーのプルーフを生成する重要な部分です。この部分のセキュリティを確保することが非常に重要です。次は、zkFabric のアーキテクチャ図です。

zkFabric の Zero-Knowledge Proof (ZKP) ベースのライト クライアントは、外部検証エンティティに依存することなく、完全にトラストフリーになります。そのセキュリティは完全に基盤となるブロックチェーンと数学的に信頼できる証明によってもたらされるため、外部の検証エンティティに依存する必要はありません。

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

zkFabric は、ブロックチェーンと基盤となる暗号化プロトコルのセキュリティの前提条件、および基盤となる暗号化プロトコルのセキュリティの前提条件に依存します。ただし、zkFabric の有効性を確保するには、正しいフォークを同期するために少なくとも 1 つの正直なリレーが必要です。したがって、zkFabric は、単一リレーの代わりに分散型リレー ネットワークを使用して、zkFabric の効率を最適化します。この中継ネットワークは、Celer ネットワークの状態監視ネットワークなどの既存の構造を利用できます。

証明者の割り当て: 証明者ネットワークは、証明生成タスクごとに証明者を選択し、これらの証明者に料金を支払う必要がある分散型 ZKP 証明者ネットワークです。

現在の展開:

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

現在の展開:

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

Brevis は現在、カスタム uniswap プールを大幅に追加する uniswap フックと連携していますが、CEX と比較すると、UnisWap には大規模なユーザー トランザクション データに依存するプロジェクト (トランザクション量に基づくロイヤルティ プログラムなど) を作成するための効果的なデータ処理機能がまだ不足しています。 。

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

2.ヘロドトス

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

L2 からの L1 状態

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

L3/App-Chain 状態から L2 および L1 へ

ヘロドトスは、プルーフ・オブ・ストレージの概念を提案しました。これは、プルーフ・オブ・インクルージョン (データの存在の確認) とプルーフ・オブ・コンピューティング (複数ステップのワークフローの実行の検証) を組み合わせて、大規模なデータ・セット (イーサリアム・ブロックチェーン全体など) が有効であることを証明します。またはロールアップ）、または複数の要素の有効性。

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

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

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

ヘロドトスが定義した Proof of storage は、次のものを融合したものです。

ワークフロー:

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

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

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

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

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

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

(2) Block Hash Accumulator から履歴で検証されたブロックのハッシュを問い合わせる

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

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

(2) Block Hash Accumulator から履歴で検証されたブロックのハッシュを問い合わせる

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

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

ブロック ヘッダーを入手すると、その内容を詳しく調べることができます。具体的には次のとおりです。

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

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

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

をデコードして、特定の口座、領収書、または取引がブロックに含まれているかどうかを検証できます。

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

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

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

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

Ethereum Goerli* から Starknet Goerli* へ

Ethereum Goerli* から zkSync Era Goerli* へ

3.公理

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

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

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

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

AxiomV1 — Genesis から始まるイーサリアム ブロックチェーン キャッシュ。

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

(1) ブロックのハッシュ値を AxiomV1 にキャッシュします。

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

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

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

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

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

これらの ZK 証明は、マークル-パトリシア トライの包含 (または非包含) 証明を検証することによって、関連するオンチェーン データがブロック ヘッダーに直接配置されているか、ブロックのアカウントまたはストレージ トライに配置されているかを確認します。

4.ネクサス

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

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

Nexus zero: ゼロ知識証明とユニバーサル zkVM を利用した分散型の検証可能なクラウド コンピューティング ネットワーク。

Nexus: マルチパーティ コンピューティング、ステート マシン レプリケーション、およびユニバーサル WASM 仮想マシンを活用した、分散型の検証可能なクラウド コンピューティング ネットワーク。

Nexus および Nexus Zero アプリケーションは従来のプログラミング言語で作成でき、現在は Rust をサポートしていますが、さらに多くの言語が登場する予定です。

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

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

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