オンチェーン計算の革新：ZKコプロセッサとそのDeFiおよびDAOにおける応用展望
TechFlow厳選深潮セレクト
オンチェーン計算の革新：ZKコプロセッサとそのDeFiおよびDAOにおける応用展望
本稿は、コプロセッサの実装方法、各種アプリケーションおよび将来の発展方向について主に論じている。
Web3業界の深掘り報道に専念し潮流を洞察著者：Kernel Ventures Turbo Guo
査読：Kernel Ventures Mandy, Kernel Ventures Joshua
TL;DR
ZK協プロセッサは、dAppがオフチェーンの計算リソースを利用できるようにする仕組みであり、本稿ではその実装方法、応用例、将来の展望について議論する。主な内容は以下の通り：
-
RISC ZeroのzkVMはZK協プロセッサの解決策の一つであり、オンチェーンのコントラクトがオフチェーンのzkVM上で特定のRustコードを実行し、その結果と計算が正しく行われたことを証明するzkpをオンチェーンに返すことを可能にする。
-
ZK協プロセッサには複数の実装方法がある。zkVM以外にも、ユーザーが独自のZK回路を設計したり、事前に用意されたフレームワークを使って回路を書くことで、コントラクトがオフチェーンの計算リソースを利用できるようになる。
-
ZK協プロセッサはDeFi分野でも活用可能である。例えばAMMの計算をオフチェーンで行い、MEVのような価値をプロトコルが獲得できるようにしたり、計算量の多い複雑なロジックを実現できる。また、貸借プロトコルにおいてリアルタイムな金利計算や、担保評価の透明化なども可能になる。zkAMMにはzkVMを使う方法とzkOracleを使う方法の2種類がある。
-
その他の潜在的な用途として、ウォレットにおける認証処理のオフチェーン化、オンチェーンゲームでの高度な計算実行、DAOガバナンスにおけるガスコスト削減などが挙げられる。
-
ZK協プロセッサの市場構造はまだ定まっていないが、独自に回路を開発するよりも、あるプロジェクトを通じてオフチェーンリソースを呼び出す方が開発者にとって使いやすい。ただし、その「インターフェース」プロジェクトがどの計算サービスプロバイダー（従来のクラウドベンダーや分散型リソース共有）と連携しているかは、別の重要な議題となる。
1. ZK協プロセッサの意味と応用
ZK協プロセッサの核心は、オンチェーンの計算をオフチェーンに移し、ZKによりその計算の信頼性を証明することで、スマートコントラクトが大量の計算を容易に扱えるようにしつつ、その正確性を検証できるようにすることにある。これはzkRollupと似た考えだが、Rollupはレイヤー1プロトコルがオフチェーン計算を利用するのに対し、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と呼ばれ、レシートはそれが正しく実行されたことを証明する。レシートはjournalとseal（印章）からなる。journalにはzkVMアプリケーションの公開出力が含まれ、sealはレシートの有効性、つまりGuest Programが正しく実行されたことを証明するものであり、seal自体は証明者によって生成されるzkSTARKである。レシートの検証により、journalが正しい回路で構築されたことが保証される。
Bonsaiは、RustコードからzkVMバイトコードへのコンパイル、プログラムのアップロード、VM内での実行、証明のフィードバックまでの一連のプロセスを簡素化しており、開発者がよりロジック設計に集中できるようにしている。さらに、コントラクトの一部だけでなく、全体のロジックをオフチェーンで実行することも可能である。 RISC Zeroはcontinuationsも採用しており、大きな証明を複数の断片に分割し、それぞれを個別に証明する。これにより、大規模なプログラムでもメモリ使用量を抑えながら証明を生成できる。RISC Zero以外にも、IronMill、=nil; Foundation、Marlinなどが同様の汎用的ソリューションを提供している。
2. ZK協プロセッサのDeFiにおける応用
2.1 AMM - Bonsaiを協プロセッサとする場合
zkUniswapはオフチェーン計算リソースを利用するAMMの一つであり、swapの計算部分をオフチェーンに置き、Bonsaiを利用している。ユーザーがオンチェーンでswapリクエストを送ると、Bonsaiの中継コントラクトがそれを取得し、オフチェーンでの計算を開始する。Bonsaiが計算を終えたら、EVM内のcallback関数に計算結果と証明を返す。証明が検証されれば、swapが実行される。
しかし、リクエストと実行は異なるトランザクションで行われるため、リスクが生じる。リクエスト提出後からswap完了までの間に、プールの状態が変化する可能性がある。なぜなら検証はリクエスト提出時のプール状態に基づいて行われるため、待機中に状態が変われば検証が失敗する。
この問題を解決するために、開発者はプールのロック機構を導入した。ユーザーがリクエストを送ると、swap決済以外のすべての操作がロックされ、オフチェーンがオンチェーンのswapを正常にトリガーするか、またはタイムアウトするまで解除されない。タイムアウト時間を設定することで、中継やzkpに問題があってもプールが永久にロックされることはない。通常のタイムアウト時間は数分程度と想定される。
zkUniswapはMEVに対しても独自の設計を持っている。つまり、プロトコル自体がMEVの価値を吸収することを目指している。理論的にはzkAMMにもMEVが存在する。最初にトランザクションを送った者がロックを獲得できるため、依然としてガス代競争が発生し、builderがリクエストの順序を調整できる。しかし、zkUniswapはそのMEV利益を自ら取り込むために、VRGDA（Variable Rate Gradual Dutch Auction）という可変レートの段階的オランダ式オークションを採用している。
zkUniswapはロックを自ら割引価格でオークションに出す。もしロックがすぐに売れた場合、プロトコルは需要が高いと判断して自動的に価格を引き上げる。逆に販売速度が落ちれば価格を下げる。これが新たな収益源となり、プロトコルが取引順序を決定する新しい手段を提供し、その競争資金が直接プロジェクト側に入るという点に大きな想像力がある。
2.2 AMM - zkOracleを協プロセッサとする場合
zkVMではなく、zkOracleを利用してオフチェーン計算リソースを活用する案もある。zkOracleは入力と出力を兼ね備えたオラクルである。一般的なオラクルには2種類あり、入力オラクルはオフチェーンデータを整理・計算してオンチェーンに提供し、出力オラクルはオンチェーンデータを整理・計算してオフチェーンに提供する。I/O（入出力兼用）オラクル（zkOracle）は、まず出力を行い、次に入力を行うことで、オンチェーンがオフチェーンの計算リソースを利用できるようにする。
zkOracleはオンチェーンデータをソースとして利用すると同時に、ZKによってオラクルノードの計算が改ざんされていないことを保証し、協プロセッサとしての機能を果たせる。したがって、AMMの核心計算をzkOracle内に置くことで、従来のAMM機能を維持しつつ、より複雑で計算負荷の高い操作も実現できる。
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が目指すものを紹介する。それは、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は、25万gasを超える計算であればZK協プロセッサを使った方がコストが安くなると考えているが、その根拠についてはさらなる検証が必要である。DAOガバナンスも多人数・多コントラクトにまたがるため計算負荷が高く、ZK協プロセッサの適用が有効である。RISC Zeroによれば、Bonsaiを利用することでガス費用を50%削減できるという。ZKMLも本質的にはZK協プロセッサと同じ考え方に基づいており、Modulus LabsやGizaもこの分野のプロジェクトである。ただし、ZK協プロセッサという概念はより広範である。
また、この分野にはezklのような補助的プロジェクトもあり、ZK回路作成のためのコンパイラ、ZK展開ツールキット、オンチェーン計算をオフチェーンに移すツールなどを提供している。
4. 今後の展望
協プロセッサにより、オンチェーンアプリケーションはあたかも「クラウド」のような外部計算リソースを持つことになり、比較的安価な大量計算が可能となる。一方で、オンチェーンは必要最小限の計算のみを処理する。実際には、zkVM自体もクラウド上で動作させることができ、ZK協プロセッサはあくまでアーキテクチャであり、計算をオンチェーンからオフチェーンに移す枠組みにすぎない。オフチェーンの計算リソースを誰が提供するかは問われない。
本質的には、オフチェーンの計算リソースは、従来の大手ベンダー、分散型の共有リソース、あるいはユーザーのローカルデバイスのいずれからも提供され得る。これら3つの方向性にはそれぞれ特徴があり、大手ベンダーは成熟したオフチェーン計算ソリューションを提供できるが、将来的には分散型リソースの方が「堅牢性（robustness）」を持つ可能性があり、ユーザーのローカル計算も大きな可能性を秘めている。しかし現時点では、多くのZK協プロセッサプロジェクトがサービスを非公開で提供している段階であり、サプライチェーンが整っていないため、サービスを細分化して異なるプロジェクトに委ねることが難しい。将来は以下の2つの可能性がある：
-
ZK協プロセッサの各工程に多数のプロジェクトが競合する
-
使い勝手の良い単一のプロジェクトが市場の大部分を占める
開発者の視点からは、ZK協プロセッサを使う際にも一つの「インターフェース」プロジェクトだけを使う傾向がある。これはAmazon Web Servicesが市場を支配しているのと同じ理由である。開発者は特定の展開方法に慣れてしまう。しかし、その「インターフェース」プロジェクトが裏でどの計算サービスプロバイダー（従来のクラウドベンダー、分散型リソース共有）と接続しているかは、別途議論すべき重要なテーマである。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
Kernel Ventures
