IOSG Ventures：ZKコプロセッサーは0から1へ、それは一体何ができるのか？

作者： IOSG Ventures

Celer Network と Brevis の Mo Dong 教授に感謝します。ZK 協処理器の核心概念とユースケースについての深い議論が、このシリーズ記事の創作インスピレーションを刺激しました。

ZK 協処理器は、ブロックチェーン分野におけるエキサイティングな革新です。Brevis、Axiom、Lagrange、Herodotus などのプロジェクトによって初めて導入され、ブロックチェーン上でアプリケーションを開発する方法を根本的に革新することが期待されています。ZK 協処理器を使用することで、開発者はデータ駆動型の dApps を作成でき、omnichain データの履歴を利用して複雑な計算を実行できるようになります。これにより、追加の信頼仮定に依存することなく、重要な計算を行うことが可能になります。さらに重要なのは、これが新しい開発モデルである非同期アプリケーションアーキテクチャを導くことになり、Web 3.0 ソフトウェアフレームワークに前例のない効率とスケーラビリティをもたらすことです。

このシリーズの記事では、ZK 協処理器の神秘的なベールを明らかにします。理念、実際の応用、基礎メカニズム、直面する課題、または市場戦略に興味がある方、あるいは異なるプロジェクトを比較したい方にとって、これらの記事が新たなインスピレーションを提供できることを願っています。

DEX 上に欠けている VIP トレーダープログラムのケース

ZK 協処理器の基本的な考え方を理解するためには、現実世界のインセンティブの例から始める必要があります。

中央集権型取引所（CEX）と分散型取引所（DEX）の間の明らかな違いは、取引量に基づく料金基準、つまり一般的に「VIP トレーダー忠誠度プログラム」と呼ばれるものが存在することです。これらのプログラムは、トレーダーを引き留め、流動性を高め、最終的には取引所の収益を増加させるための強力なツールです。

興味深いことに、すべての CEX が少なくとも1つのそのようなプロジェクトを持っている一方で、DEX にはまったく存在しません。なぜでしょうか？

これは、DEX でこの機能を実現することが CEX よりもはるかに困難であり、コストも高いためです。

CEX では、忠誠度プログラムを実施するために必要なことは：

• 中央集権型データベースにすべてのユーザーの取引履歴を記録すること------これは将来のクエリコストを削減するための便利なタスクです。

• 毎月、高性能の中央集権型データベースで直接クエリを実行し、過去のデータに基づいて各ユーザーの取引量と手数料レベルを特定すること。

しかし、DEX が同じ手順に従おうとすると、重大な課題に直面します：

• ブロックチェーンのストレージコストが非常に高いため、スマートコントラクト内に各ユーザーの取引履歴を直接保存することは不可能です。このロジックを実装することは、ユーザーの各取引の手数料を4倍に引き上げることを意味します。

• たとえ取引記録のデータストレージを行ったとしても、これらのデータに対する統計クエリと計算のコストはさらに高くなります。たとえば、単一のユーザーの10K件の取引の取引量データを計算するには、156M Gas がかかります（そう！計算しました）。

「ちょっと待って、あなたは何を言っているのですか？ブロックチェーン上では、各ユーザーの各取引が自動的に保存されている（だってそれはブロックチェーンだから！）。」ブロックチェーンに生まれたスマートコントラクトは、これらのデータにいつでもアクセスできるはずですよね？

残念ながら、そうではありません！

ブロックチェーンに保存されているデータと、ブロックチェーン仮想マシン内のスマートコントラクトがアクセスできるデータは、まったく別物です。

ブロックチェーンの完全/アーカイブノードにとって、これらはブロックチェーンの歴史における大量のデータを保存しています。これらのノードを通じて、次のことに簡単にアクセスできます：

• 歴史的に任意の時点でのブロックチェーン全体の状態（たとえば、誰が Cryptopunk の最初の所有者であったか）。

• 歴史的に任意の時点での取引と、その取引から生じたイベント（たとえば、Charlie が $1,000 を 0.5 ETH に交換した）。

実際、人気のあるオフチェーンデータインデックスや分析ツール（Nansen や Dune Analytics など）は、この広範なデータセットを利用して深い分析を行うことができます。

しかし、ブロックチェーン仮想マシンに埋め込まれたスマートコントラクトにとって、データアクセスの制限ははるかに大きいです。これらは、外部で生成されたインデックスソリューションのデータを使用できません。なぜなら、これが外部であり、通常は中央集権的なインデックスソリューションに追加の信頼問題をもたらすからです。

実際、スマートコントラクトは、次のデータに簡単かつ信頼なしにアクセスできます：

• 仮想マシンの状態に保存されたデータ（取引やイベントデータは含まれません）。

• 最新のブロック内のデータ（履歴データへのアクセスは制限されています）。

• 「ビュー」機能を介して公開された他のスマートコントラクトのデータ（プライベートまたは内部コントラクトのデータは含まれません）。

上記の説明の重要な微妙な違いは、「簡単」という言葉にあります。

スマートコントラクトは、ブロックチェーン上のすべてのデータを完全に知らないわけではありません。EVM では、スマートコントラクトは最新の256ブロックのブロックヘッダーハッシュにアクセスできます。これらのブロックヘッダーは、現在のブロックまでのブロックチェーン上のすべての活動を含み、マークルツリーと Keccak ハッシュを通じて32バイトのハッシュに圧縮されています。

圧縮されたものは解凍できますが…簡単ではありません ?

最近のブロックヘッダーを利用して、信頼なしに前のブロック内の特定のデータにアクセスしたいと想像してみてください。この方法には、アーカイブノードからオフチェーンデータを取得し、マークルツリーとブロックの有効性証明を構築して、データがブロックチェーン上で真実であることを確認することが含まれます。その後、EVM は有効性証明を処理して検証と解釈を行います。このような操作は煩雑で困難であり、過去のいくつかのトークン残高を取得するためだけに、数千万の Gas を消費する可能性があります。

この課題の根源は、ブロックチェーン仮想マシン自体が、大量のデータと集中的な計算（上記の解凍タスクなど）を処理する能力を持っていないことです。

ZK 協処理器アーキテクチャ（出典：Brevis の ETHSG でのプレゼンテーションスライド）

もし、ブロックチェーンがこのようなデータ集約型の煩雑な計算を委託し、低コストで迅速に結果を得ることができ、追加の信頼仮定を必要としない魔法のようなものがあれば、理想的です。

友よ、これがまさに ZK 協処理器の用途です。

「協処理器」という名称は、コンピュータアーキテクチャの発展の歴史に由来しています。たとえば、CPU の協処理器として GPU が導入されたのは、CPU が特定の高価で自分では実行しにくい重要な計算タスク（グラフィックス計算や人工知能のトレーニングなど）を「補助処理器」である GPU に委託する必要があったからです。

しかし、ZK 協処理器の「ZK」とは何でしょうか？複雑な技術的詳細に深入りする前に、この革新的な技術の広範な意味と可能性を理解しましょう。

Web 3.0 におけるデータ駆動型 dApps の必要性

取引手数料の返還は、非常に良い例です。この考え方に基づいて、ZK 協処理器を使用すれば、多くの DeFi プロトコルにさまざまな忠誠度プログラムをシームレスに導入できます。

しかし、これは DeFi の忠誠度プログラムにとどまりません。今、Web 3.0 の他の分野にも同様の問題が存在することが見えてきたかもしれません。考えてみてください。すべての現代の Web 2.0 アプリケーションはデータ駆動型であり、Web 3.0 アプリケーションも例外ではありません。「キラーアプリ」を作成し、ユーザー体験を従来のインターネットアプリケーションと同等にするためには、このデータ駆動型のアプローチが不可欠です。

DeFi 分野の別の例を見てみましょう：流動性マイニング報酬メカニズムを再設計して流動性効率を向上させること。

現在、AMM DEX の流動性インセンティブメカニズムは「現収現付」モデルを採用しています。このモデルでは、LP が流動性を提供すると、ファーミング報酬が即座に LP に分配されます。しかし、このモデルは最適とは言えません。プロのファーマーは、市場の変動を感じると、無常損失を避けるために流動資金を迅速に引き上げることができます。その結果、彼らがプロトコルに提供する価値は微々たるものですが、依然としてかなりの報酬を得ることができます。

理想的な AMM 流動性インセンティブメカニズムは、特に市場が大きく変動している間に、LP の堅実性を遡及的に評価します。このような状況で資金プールを常に支援している人々は、最高の報酬を得るべきです。しかし、このモデルにとって重要な LP の過去の行動データを取得することは、今日では不可能です。

これを実現するためには、ZK 協処理器が必要です。

DeFi 分野では、事前に定められたアルゴリズムとルールを使用して積極的に LP ポジションを管理したり、非トークン流動性ポジションを使用して信用枠を構築したり、過去の返済行動に基づいてローンの動的清算の好みを決定したりするなど、同様の例を挙げることができます。

しかし、ZK 協処理器の可能性は DeFi にとどまりません。

ZK 協処理器を利用して優れたユーザー体験を持つオンチェーンゲームを構築する

Web 2.0 ゲームのリアルタイム操作機能の例

新しくインストールした Web 2.0 ゲームに入ると、あなたの一挙手一投足が詳細に記録されます。これらのデータは無駄にされることはなく、あなたのゲーム体験に大きく影響します。いつゲーム内購入オプションを提供するか、いつ報酬ゲームを開始するか、いつ精巧に設計されたプッシュ通知を送信するか、そしてあなたにマッチする対戦相手などを決定します。これらはすべて、ゲーム業界で言うところのリアルタイムオペレーション（LiveOps）の一部であり、プレイヤーの参加度と収益の流れを向上させる基盤です。

完全にオンチェーンのゲームのユーザー体験を Web 2.0 のクラシックゲームと同等にするためには、これらの LiveOps 機能が必要です。これらの機能は、プレイヤーとゲームのスマートコントラクトとの過去のインタラクションと取引に基づくべきです。

残念ながら、ブロックチェーンゲームでは、このような機能は完全に欠如しているか、依然として中央集権的なソリューションによって駆動されています。その理由は、DEX の例と同様に、ブロックチェーン上で過去のゲームデータを掘り起こし、計算することが困難だからです。

そうです、同様に、これを実現するためには ZK 協処理器が必要です。

Web 3.0 のソーシャルおよびアイデンティティアプリケーションも、ZK 協処理器のサポートなしでは機能しない別の領域です。

ブロックチェーンの世界では、あなたのデジタルアイデンティティは、あなたの過去の行動によって織り成されたネットワークです。

• NFT OG であることを証明したいですか？あなたが Cryptopunk の初期マイナーの一人であることを証明する必要があります。

• 大トレーダーであることを自慢したいですか？DEX で100万ドル以上の取引手数料を支払ったことを証明してください。

• Vitalik と親しい関係ですか？彼のアドレスがあなたのアドレスに資金を送ったことを証明してください。

オフチェーンシステム、つまり人間や Web 2.0 アプリケーションは、このような証明を簡単に生成できます。なぜなら、取引量の例と同様に、すべてのデータを含むアーカイブノードにアクセスできるからです。

このような直接データアクセスに基づくアイデンティティ証明は、強力なウォレットアドレスの関連付けを必要とし、そのためにはプライバシーを犠牲にする欠点を伴いますが、実行可能です。

しかし、取引量の例と同様に、スマートコントラクトにあなたの OG アイデンティティを信じさせ、追加の信頼証明を導入せずに新しいものを先取りしたい場合、実際には良い方法はありません。

ZK 協処理器を使用すれば、あなたの過去の行動を証明する信頼できるアイデンティティ証明を織り成すことができます。これは、どのスマートコントラクトでも疑いなく受け入れられる証明です。あなたの異なるアプリケーションや異なるブロックチェーンでのインタラクションを巧妙に統合し、この証明を形成することができます。

さらに魅力的なのは、ZK の固有のプライバシーです。あなたのウォレットアドレスは、あなたのアイデンティティと公開に関連付ける必要はありません。たとえば、具体的なウォレットアドレスを開示することなく、Cryptopunk NFT を所有していることを証明できます。また、具体的な数字を明かさずに、Uniswap で10,000回の取引を行ったことを証明できます。

ZK 協処理器は、データ駆動型の dApp 構築に新たな領域を開きますが、その意義はそれだけではありません。

データ駆動型パラダイムを超えて：ZK 協処理器で Web 3.0 の非同期モデルを開創する

データ駆動型の dApp モデルは魅力的ですが、氷山の一角に過ぎません。

ZK 協処理器の登場は、ブロックチェーン計算に対する私たちの見方を根本的に変え、非同期処理が Web 3.0 の標準となる時代を切り開くことになります。この変革は、タスクの処理方法を再定義し、専用のプロセッサが独立して動作することで効率を向上させます。

まず、非同期処理とは何かを理解しましょう。

想像してみてください、同期型のレストランでは、一人の人間がシェフとウェイターの役割を同時に果たしています。あなたが料理を注文すると、彼は準備を始め、あなたを待たせます。彼はあなたの料理を提供した後でなければ、別の客を接待することができません。このような設定はあなたのニーズを満たすかもしれませんが、他の人にとっては効率を向上させるのが難しいです。

対照的に、非同期型のレストランでは、異なるシェフと異なるウェイターが協力して働きます。ウェイターはあなたの注文を受け取った後、迅速にその注文をシェフに渡し、同時に他の顧客にサービスを提供します。料理が完成すると、シェフはウェイターに合図を送り、ウェイターはあなたに料理を提供します。

コンピュータシステムにおいて：

同期アーキテクチャは、最初のレストランのように、一人の人間が各タスクが完了するのを待ってから次に進みます。このアーキテクチャはシンプルで明確ですが、速度が遅くなる可能性があります。なぜなら、一度に一つのタスクしか処理しないからです。そして、その人は良いウェイターかもしれませんが、良いシェフではないかもしれません。

非同期アーキテクチャは、第二のレストランのように、いくつかのデカップリングされた専用のシステムコンポーネントがあり、相互に情報やタスクを送信して調整します。これにより、各コンポーネントが自分のタスクラインを同時に管理できるようになります。より複雑な管理方法が必要かもしれませんが、このアーキテクチャはより速く、効率的です。

すべての現代のインターネットアプリケーションは、効率とスケーラビリティを向上させるために非同期アーキテクチャに基づいて構築されており、私たちは Web 3.0 も同様であるべきだと考えています。

ZK 協処理器は、この変革の先駆者となるでしょう。dApp 開発者にとって、ブロックチェーンは私たちの非同期レストランのウェイターのようなものです。ブロックチェーンは、主にブロックチェーンの状態を直接変更する計算を処理します。すべての他の計算は、堅牢な ZK 協処理器に委ねられるべきです。これらは、非同期処理の強力な機能を通じて、効率的に結果を調理し、ウェイターに送信します。

具体的には、ブロックチェーンアプリケーション内の計算が次の2つの「実行可能条件」のいずれかを満たす場合、ZK 協処理器の使用を検討すべきです。

ZK 協処理器が実行できる条件：

• チェーン上の計算コスト > （チェーン外 ZK 協処理器計算（証明生成を含む）+ チェーン上の検証コスト）

• チェーン上の計算遅延 > （チェーン外 ZK 協処理器計算（証明生成を含む）+ チェーン上の検証遅延）

たとえそれらがそのうちの一つを満たしているだけでも、検討する価値があります！

今、あなたはそれが単なるデータ駆動型の dApps ではないことがわかります！それは、ML などの高度な汎用計算をブロックチェーンに導入する新しい方法ですが、さらに重要なのは、dApp を構築するための非同期アーキテクチャを導入することです。これは以前には実現不可能でした。

次の章….

もし私たちが ZK 協処理器が深遠な影響をもたらすアイデアであるとあなたを納得させることに成功したなら、今こそそれらがどのように機能するのかについて話す時かもしれません。次のブログでは、ZK 協処理器の重要なアーキテクチャを探り、この分野にまだ存在する最大の技術的課題について議論します。