オフチェーン計算の革新：ZK協処理器の詳細とDeFiおよびDAOにおける応用の展望
本文は主にコプロセッサの実装方法、さまざまなアプリケーション、および将来の発展方向について議論しています。原文标题：Kernel Ventures：Dappにオフチェーン計算能力を与える --- ZKコプロセッサ
原文作者：Turbo Guo，Kernel Ventures
原文审稿：Mandy，Joshua，Kernel Ventures
TL；DR
ZKコプロセッサはdAppがオフチェーン計算リソースを利用するためのソリューションであり、本記事ではコプロセッサの実装方法、さまざまなアプリケーション、将来の発展方向について主に議論します。主な内容は以下の通りです：
- RISC ZeroのzkVMはZKコプロセッサのソリューションであり、オンチェーン契約がオフチェーンのzkVMで特定のRustコードを実行し、その結果をオンチェーンに返すことを可能にし、計算が正しいかどうかを契約が検証するためのzkpを提供します。
- ZKコプロセッサにはさまざまな実装方法があり、zkVMの他に、ユーザーは独自にプログラムをカスタマイズしたZK回路を書くことも、既製のフレームワークを使用して回路を書くこともでき、これにより契約がオフチェーン計算リソースを利用できるようになります。
- ZKコプロセッサはDeFiで役立つ可能性があり、例えばAMMの計算をオフチェーンで行うことで、プロトコルがMEVのような価値を捕捉したり、AMMが複雑で大量の計算を必要とする実行ロジックを実現したりできます。ZKコプロセッサはまた、貸出プロトコルがリアルタイムで金利を計算したり、マージン計算を透明化したりすることも可能にします。zkAMMには2つの実装方法があり、一つはzkVMを使用し、もう一つはzkOracleを使用します。
- ZKコプロセッサには他の潜在的な用途もあり、例えばウォレットはZKコプロセッサを使用して認証をオフチェーンで実行でき、コプロセッサはオンチェーンゲームがより複雑な計算を実行できるようにし、DAOガバナンスに必要なガスを削減することも可能です。
- ZKコプロセッサの状況は未定ですが、ユーザーが自分で回路を書くよりも、プロジェクトを介してオフチェーンリソースにインターフェースを呼び出す方がよりフレンドリーです。しかし、その「インターフェース」プロジェクトの背後にどの計算サービスプロバイダー（従来のクラウドプロバイダー、分散型リソース共有）が接続されているかは、別の議論の価値があります。
1. ZKコプロセッサの意味と応用
ZKコプロセッサの核心は、オンチェーン計算をオフチェーンに移し、ZK証明によってオフチェーン計算プロセスの信頼性を確保することで、スマートコントラクトが大量の計算を簡単に処理できるようにし、契約が計算の信頼性を検証できるようにすることです。これはzkRollupの考え方に似ていますが、Rollupはチェーンプロトコル層がオフチェーン計算リソースを利用するのに対し、ZKコプロセッサはdAppがオフチェーンリソースを利用します。
ここではRISC Zeroを用いてZKコプロセッサの一つの実装方法を説明しますが、ZKコプロセッサには多くの実装方法があります。後の文でさらに紹介します。RISC ZeroはBonsai ZKコプロセッサアーキテクチャを開発しており、その核心はRISC ZeroのzkVMです。開発者はzkVM上で「特定のRustコードが正しく実行された」ことを証明するためのzkpを生成できます。zkVMを使用することで、ZKコプロセッサの具体的なプロセスは以下の通りです：
- 開発者はBonsaiのリレイ契約にリクエストを送信し、zkVMで開発者が要求するプログラムを実行します。
- リレイ契約はリクエストをオフチェーンリクエストプールに送信します。
- BonsaiはオフチェーンのzkVMでリクエストを実行し、大規模なオフチェーン計算を行い、その後、証明書（receipt）を生成します。
- これらの証明は「レシート」とも呼ばれ、Bonsaiがリレイ契約を通じてオンチェーンに戻されます。
Bonsaiで証明されたプログラムはGuest Programと呼ばれ、証明書（receipt）はguest programが正しく実行されたことを証明するために使用されます。証明書にはジャーナルと印章（seal）が含まれています。具体的には、ジャーナルはzkVMアプリケーションの公共出力を担い、印章は証明書の有効性を証明するために使用され、guest programが正しく実行されたことを証明します。印章自体も証明者によって生成されたzkSTARKです。証明書を検証することで、ジャーナルが正しい回路を使用して構築されたことを保証できます。
Bonsaiは開発者がRustコードからzkVMバイトコードへのコンパイル、プログラムのアップロード、VM内での実行、証明のフィードバックなどのプロセスを簡素化し、開発者がプログラムのロジック設計により集中できるようにします。また、部分的な契約ロジックだけでなく、全体の契約ロジックをオフチェーンで実行することも可能です。RISC Zeroはまた、継続を使用しており、大きな証明生成を多くの部分に分割し、それぞれを個別に証明します。これにより、大規模なプログラムの証明を生成でき、メモリを過度に消費することもありません。RISC Zeroの他にも、IronMill、=nil; Foundation、Marlinなどのプロジェクトも類似の汎用ソリューションを提供しています。
2. ZKコプロセッサのDeFiでの応用
2.1 AMM - Bonsaiをコプロセッサとして
zkUniswapはオフチェーン計算リソースを利用したAMMの一例であり、その核心はスワップの一部計算をオフチェーンで行うことです。また、Bonsaiを使用しています。ユーザーはオンチェーンでスワップリクエストを発行します。Bonsaiのリレイ契約がリクエストを受け取り、オフチェーン計算を開始し、Bonsaiが計算を完了した後、EVM内のコールバック関数に計算結果と証明を返します。証明が成功として検証されれば、スワップが実行されます。
ただし、スワップは一度で完了するわけではなく、リクエストと実行プロセスは異なるトランザクションで行われるため、一定のリスクがあります。リクエストを提出した後、スワップが完了する前にプールの状態が変わる可能性があります。検証はリクエストを提出した時点でのプールの状態に基づいています。リクエストがまだ待機中で、プールの状態が変わった場合、検証は無効になります。
この問題を解決するために、開発者はプールロックを設計しました。ユーザーがリクエストを発行すると、スワップの決済以外のすべての操作がロックされ、オフチェーンでオンチェーンのスワップが成功裏にトリガーされるか、スワップがタイムアウトするまで（この時間は事前に設定されます）ロックされたままになります。時間制限があれば、リレイやzkpに問題が発生しても、プールは常にロックされたままにはなりません。具体的な時間制限は数分かもしれません。
zkUniswapはMEVに特別な設計を持っており、開発者はプロトコルがMEVの価値を捕捉することを望んでいます。理論的にはzkAMMもMEVを持っており、最初に取引を提案した人がロックをかけることができるため、皆がガスを争うことになります。ビルダーもリクエスト取引の順序を決定できます。しかし、zkUniswapはMEVの利益を自ら取り込み、使用する方法は可変金利漸進式オランダオークション（VRGDA）です。
zkUniswapはロックを取り出して自ら値下げオークションを行い、ロックがすぐに売れれば、プロトコルは現在の需要が高いことを知り、自動的に価格を上げます。ロックの販売速度が遅くなると、プロトコルは価格を下げます。これが新たな収入源となります。つまり、プロトコルは取引順序を決定する新しいものを提供し、競争価格の資金が直接新しいものを通じてプロジェクトに渡されるという非常に想像力豊かなアイデアです。
2.2 AMM - zkOracleをコプロセッサとして
zkVMを使用するだけでなく、zkOracleを使用してオフチェーン計算リソースを利用することを提案する人もいます。zkOracleは入力と出力の両方を兼ね備えたオラクルです。一般的なオラクルには2種類あり、一つは入力オラクルで、もう一つは出力オラクルです。入力オラクルはオフチェーンデータを整理（計算）してオンチェーンに提供し、出力オラクルはオンチェーンデータを整理（計算）してオフチェーンに提供します。I/O（入力兼出力）オラクル（zkOracle）は、まず出力を行い、その後入力を行うことで、オンチェーンがオフチェーン計算リソースを利用できるようにします。
zkOracleは一方でオンチェーンデータをデータソースとして使用し、他方でZKを使用してオラクルノードの計算が不正でないことを保証し、コプロセッサの機能を実現できます。したがって、AMMの核心計算をzkOracleに置くことで、従来のAMM機能を実現しつつ、zkOracleを使用してより複雑で計算リソースを消費する操作を実現できます。
2.3 貸出金利計算、マージン計算などの他の応用
実装方法を除けば、ZKコプロセッサを使用することで多くの機能を実現できます。例えば、貸出プロトコルはパラメータを事前に設定するのではなく、リアルタイムの貸出状況に基づいて金利を調整できます。例えば、借り入れ需要が高いときに金利を上げて供給を引き寄せ、需要が減少したときに金利を下げます。これには、貸出プロトコルがリアルタイムでオンチェーンデータを取得し、大量の計算を行って適切なパラメータを導き出す必要があり、オフチェーン計算が必要です（オンチェーンコストが極めて低くない限り）。
マージン残高、未実現の損益、清算額などの複雑な計算もコプロセッサに移行して実行できます。コプロセッサの利点は、これらのアプリケーションをより透明で検証可能にし、マージンエンジンのロジックが秘密のブラックボックスではなくなることです。計算はオフチェーンで行われますが、ユーザーはその実行の正確性を完全に信頼できます。さらに、このアプローチはオプションの計算にも適用できます。
3. ZKコプロセッサの他の応用
3.1 ウォレット - Bonsaiをコプロセッサとして
Bonfire WalletはzkVMを使用して認証計算をオフチェーンに移しました。このウォレットの目標は、ユーザーが生体情報（指紋）や暗号ハードウェアのyubikeyを使用してバーナーウォレットを作成できるようにすることです。
具体的には、Bonfire WalletはWebAuthnという一般的なウェブ認証標準を使用しており、ユーザーはパスワードなしでデバイスを使用してウェブ上の認証を完了できます。したがって、Bonfire Walletでは、ユーザーはWebAuthnを介して公開鍵（オンチェーンではなく、WebAuthn用）を生成し、それを使用してウォレットを作成します。
各バーナーウォレットはオンチェーンに契約を持ち、その中にはWebAuthnの公開鍵が含まれています。契約はユーザーのWebAuthn署名を検証する必要があります。しかし、この計算量は非常に大きいため、Bonsaiを使用して計算をオフチェーンに移し、zkVMゲストプログラムを介してオフチェーンで署名を検証し、オンチェーンで検証するためのzkpを生成します。
3.2 オンチェーンデータの取得 - ユーザー自身がZK回路を書く
AxiomはzkVMを使用せず、別のコプロセッサソリューションを使用するアプリケーションです。まず、Axiomが何をしようとしているのかを紹介します。AxiomはZKコプロセッサを利用して契約が過去のオンチェーン情報を参照できるようにしたいと考えています。実際、契約が過去のデータを読むことは非常に難しいです。なぜなら、スマートコントラクトは一般的にリアルタイムのオンチェーンデータを取得し、それが非常に高価であるため、契約がアカウントの過去の残高や取引記録などの価値のあるオンチェーンデータを取得することは困難です。
Axiomノードは必要なオンチェーンデータにアクセスし、オフチェーンで指定された計算を実行し、その計算に対して零知識証明を生成します。この証明はオンチェーンで検証され、契約がこの結果を信頼できることを保証します。
オフチェーン計算のためにzkpを生成するには、プログラムをZK回路にコンパイルする必要があります。前述のように、これを行うためにzkVMを使用することができますが、Axiomの公式はこの件について多くのソリューションがあり、性能、柔軟性、開発体験のバランスを取る必要があると指摘しています：
カスタム回路：開発者がプログラムのためにカスタム回路を作成する場合、性能は確かに最良ですが、開発に時間がかかります。
eDSL/DSL：開発者は自分で回路を書くが、いくつかのオプションフレームワークが開発者がZK関連の問題を解決するのを助けることで、性能と開発体験のバランスを取ることができます。
zkVM：開発者が既存の仮想マシンでZKを直接実行することができ、非常に便利ですが、Axiomの公式は効率が非常に低いと考えています。
したがって、Axiomは2番目の選択肢を選び、プロジェクト側はユーザーに最適化されたZKモジュールを提供し、ユーザーが自分で回路を設計できるようにしています。
Axiomに類似したプロジェクトにはHerodotusがあり、これはクロスチェーン情報伝送のミドルウェアを目指しています。情報処理がオフチェーンで行われるため、異なるチェーンが処理されたデータを取得するのは非常に合理的な考え方です。もう一つのプロジェクトであるSpace and Timeは、類似のアーキテクチャを使用してデータインデックスを実現しました。
3.3 オンチェーンゲーム、DAOガバナンスなどの他の応用
そのほか、オンチェーンゲームやDAOガバナンスもZKコプロセッサを使用できます。RISC Zeroは、250kガス以上の計算がZKコプロセッサを使用する場合、コストが低くなると考えていますが、具体的にどのように導き出されたかはまだ検討の余地があります。DAOガバナンスもZKコプロセッサを使用でき、複数の人と複数の契約が関与するため、計算リソースを大量に消費します。RISC ZeroはBonsaiを使用することでガス費用を50％削減できると述べています。ZKMLは本質的にZKコプロセッサの考え方でもあり、Modulus LabsやGizaもこの分野のプロジェクトですが、ZKコプロセッサの概念はより広範です。
さらに、ZKコプロセッサの分野にはいくつかの補助的なプロジェクトもあり、例えばezklはZK回路を作成するためのコンパイラ、ZKデプロイメントツールキット、オンチェーン計算をオフチェーンに移すためのツールなどを提供しています。
4. 未来展望
コプロセッサはオンチェーンアプリケーションに「クラウド」のような外部計算リソースを提供し、相対的に安価な大量の計算を提供し、オンチェーンでは必要な計算のみを処理します。実際の状況では、zkVMもクラウド上で実行でき、ZKコプロセッサは本質的にアーキテクチャであり、オンチェーン計算をオフチェーンに移す方法であり、オフチェーン計算リソースは誰が提供するかは制限されません。
本質的に、オフチェーン計算リソースは従来の大手企業、さらには分散型計算リソースの共有、ローカルデバイスのいずれかである可能性があります。この3つの方向性にはそれぞれの違いがあり、従来の大手企業は比較的成熟したオフチェーン計算ソリューションを提供でき、将来的には分散型計算リソースの「ロバスト性」がより強くなる可能性があります。また、ユーザーのローカル計算にも大きな想像の余地があります。しかし、現在、多くのZKコプロセッサプロジェクトは、サービスを提供する段階でクローズドソースを選択しています。この分野の上下流はまだ形成されておらず、サービスを細分化して異なるプロジェクトに提供することができません。将来的には2つの可能性があります：
- ZKコプロセッサの各プロセスに大量のプロジェクトが相互に競争する。
- サービス体験が良好なプロジェクトが市場の大部分を占める。
開発者の観点からすると、ZKコプロセッサを使用する際には、単一の「インターフェース」プロジェクトを使用する可能性が高く、これがAmazon Web Servicesが市場の大部分を占める理由の一つです。開発者は特定のデプロイメント方式に慣れるでしょう。しかし、そのオフチェーン計算リソースの「インターフェース」プロジェクトの背後にどの計算サービスプロバイダー（従来のクラウドプロバイダー、分散型リソース共有）が接続されているかは、別のトラックで議論の価値があります。
