ZKコプロセッサのゼロからワン：データドリブン・パラダイムを超えて、Web 3.0非同期モードを開拓する

2023.10.30

共有先

TechFlow厳選深潮セレクト

ZKコプロセッサのゼロからワン：データドリブン・パラダイムを超えて、Web 3.0非同期モードを開拓する

ZKコプロセッサにより、ブロックチェーンはデータ集約型の面倒な計算を委託して、追加的な信頼前提なしに低コストで迅速に結果を得ることが可能になる。

2023.10.30 - 10:47:36

Web3業界の深掘り報道に専念し潮流を洞察

ZK コプロセッサは、ブロックチェーン分野におけるエキサイティングな革新技術です。Brevis、Axiom、Lagrange、Herodotusといったプロジェクトによって先駆けて導入され、ブロックチェーン上でアプリケーションを開発する方法を根本的に変革する可能性を秘めています。ZKコプロセッサがあれば、開発者は信頼性の仮定を追加せずに、omnichainデータの履歴を利用して複雑な計算を実行できるデータ駆動型dAppを作成できます。さらに重要なのは、非同期アプリケーションアーキテクチャという新たな開発モデルを牽引し、Web 3.0ソフトウェアフレームワークに前例のない効率性と拡張性をもたらすことです。

本連載では、ZKコプロセッサの正体に迫ります。その概念や実際のユースケース、基盤となる仕組み、直面する課題、市場戦略、あるいは異なるプロジェクト間の比較に関心がある方々にとって、新たなインスピレーションとなることを願っています。

DEXにVIPトレーダープログラムが存在しない事例

ZKコプロセッサの基本的な考えを理解するには、現実世界のインセンティブ事例から始めましょう。

中央集権型取引所（CEX）と分散型取引所（DEX）の明らかな違いの一つは、「VIPトレーダーロイヤルティプログラム」として知られる取引量に基づく料金体系の有無です。これらのプログラムは、トレーダーの囲い込み、流動性の向上、そして最終的には取引所収益の増加を促進する強力な手段です。

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

それは、DEXでこの機能を実装することは、CEXよりもはるかに難しく、コストも高くなるためです。

CEXの場合、ロイヤルティプログラムを実装するには以下の作業が必要です。

ユーザー全員の取引履歴を中央集権型データベースに記録する――これは将来の照会コストを抑えるために便利な作業です。
高性能な中央集権型データベース内で毎月一度、直接クエリを実行し、過去のデータに基づいて各ユーザーの取引量と手数料レベルを決定する。

しかし、DEXが同じステップを踏もうとする場合、重大な課題に直面します。

ブロックチェーンのストレージコストが高すぎるため、スマートコントラクト内に各ユーザーの取引履歴を直接保存することは現実的ではありません。このようなロジックを実装すると、ユーザーの取引ごとに手数料が4倍以上になる可能性があります。
仮に取引履歴を保存できたとしても、それらのデータを集計・照会するコストはさらに高くなります。たとえば、単一ユーザーの過去1万件の取引量を計算するだけで1億5600万Gasかかる（そうです、実際に計算しました）のです。

「待って、何を言っているんだ？ブロックチェーン上では、すべてのユーザーのすべての取引が自動的に保存されているはずだ（それがブロックチェーンだから！）。ネイティブなスマートコントラクトなら、いつでもこうしたデータにアクセスできるだろう？」と思われるかもしれません。

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

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

ブロックチェーンのフル／アーカイブノードは、ブロックチェーンの歴史にわたる膨大なデータを保持しています。こうしたノードを通じて、以下のような情報を容易に取得できます。

歴史上の任意の時点におけるブロックチェーン全体の状態（たとえば、Cryptopunkの最初の所有者が誰だったか）。
歴史上の任意の時点で行われたトランザクションおよびイベント（たとえば、Charlieが$1,000を0.5ETHに交換した）。

実際、NansenやDune Analyticsなどの一般的なオンチェーン外のデータ索引・分析ツールは、この広範なデータセットを活用して深掘り分析を行っています。

しかし、ブロックチェーン仮想マシンに埋め込まれたスマートコントラクトにとっては、データへのアクセスははるかに制限されます。オンチェーン外の索引ソリューションが生成したデータを利用することはできません。なぜなら、それは外部かつしばしば中央集権的な索引ソリューションに依存することになり、信頼性に関する問題が生じるからです。

実際、スマートコントラクトが容易かつ信頼性を持ってアクセスできるのは、以下のデータに限られます。

仮想マシンの状態に保存されたデータ（トランザクションやイベントデータは含まない）。
最新ブロック内のデータ（履歴データのアクセスは制限される）。
「view」関数を通じて公開された他のスマートコントラクトのデータ（プライベートまたは内部データは含まない）。

ここで重要なニュアンスは「容易に」という語にあります。

スマートコントラクトがブロックチェーン上のすべてのデータをまったく知らないわけではありません。EVMでは、スマートコントラクトは最新256ブロックまでのブロックヘッダハッシュにアクセスできます。これらのブロックヘッダは、現行ブロックまでのすべての活動を包含しており、メルクル木とKeccakハッシュによって32バイトのハッシュ値に凝縮されています。

圧縮されたものは解凍できる…ただし、簡単ではない 😂

たとえば、最近のブロックヘッダを利用して、前のブロック内の特定データに信頼性を持ってアクセスしたいとしましょう。この方法では、アーカイブノードからオンチェーン外のデータを取得し、メルクル木とブロック有効性証明を構築して、データがブロックチェーンに確かに存在することを確認します。その後、EVMがその有効性証明を処理して検証・解釈します。このような操作は非常に煩雑かつ困難であり、過去のいくつかのトークン残高を取得するだけでも、数千万Gasを消費しかねません。

この課題の根源は、ブロックチェーン仮想マシン自体が、大量のデータや高密度の計算（上述の解凍タスクなど）を処理できない点にあります。

ZKコプロセッサアーキテクチャ

（出典：BrevisによるETHSGでのプレゼン資料）

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

友よ、まさにそれがZKコプロセッサの役割なのです。

「コプロセッサ」という名称は、コンピュータアーキテクチャの歴史に由来します。たとえば、CPUがグラフィックス計算やAI学習など自身では高価で困難な計算を「補助プロセッサ」であるGPUに委任するために、GPUが導入されました。

しかし、「ZK」は一体何を意味するのでしょうか？複雑な技術的詳細に入る前に、まずはこの革新的技術の広範な意義と可能性について理解しましょう。

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

手数料還元プログラムが良い例です。この視点から見ると、ZKコプロセッサがあれば、さまざまなDeFiプロトコルにシームレスにロイヤルティプログラムを導入できます。

しかし、これはDeFiのロイヤルティプログラムにとどまりません。今や、Web 3.0の他の領域でも同様の問題があることに気づいたかもしれません。考えてみてください。現代のすべてのWeb 2.0アプリケーションはデータ駆動型ですが、Web 3.0アプリケーションは例外なくそうでありません。従来のインターネットアプリと同等のユーザーエクスペリエンスを提供する「キラーアプリ」を構築するには、このようなデータ駆動型アプローチは不可欠です。

DeFi分野でもう一つ例を見てみましょう。流動性マイニング報酬の再設計により、流動性の効率を高める方法です。

現在、AMM DEXの流動性インセンティブは「即時払い」方式を採用しています。この方式では、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のソーシャルアプリやIDアプリも、ZKコプロセッサなしでは機能しえない領域です。

ブロックチェーンの世界では、あなたのデジタルアイデンティティは、過去の行動から織りなされる網のようになっています。

NFT OGであることを証明したいですか？あなたがCryptopunkの初期マイナーの一人であることを証明してください。
大口トレーダーだと自慢しますか？ DEXで100万ドル以上の手数料を支払ったことを証明してください。
Vitalikと親しいですか？彼のアドレスがあなたのアドレスに資金を送ったことを証明してください。

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

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

しかし、前述の取引量の例と同じように、スマートコントラクトにあなたのOG身分を信じさせ、追加の信頼証明なしに新機能を先行体験させたい場合、実は有効な手段はありません。

ZKコプロセッサがあれば、あなた自身の過去の行動に基づく、信頼できる証明を編み出すことができます。それは、どのスマートコントラクトも疑うことなく受け入れる証明です。異なるアプリケーションや異なるブロックチェーンでの相互作用も、巧みに統合されてこの証明となります。

さらに魅力的なのは、ZKが本来持つプライバシー性です。あなたのウォレットアドレスをアイデンティティと公開関連させる必要はありません。たとえば、特定のウォレットアドレスを明かさずに、Cryptopunk NFTを所有していることを証明できます。あるいは、Uniswapで1万回の取引を実行したことを証明しつつ、正確な数字は明らかにしないことも可能です。

ZKコプロセッサは、データ駆動型dAppの構築にまったく新しい領域を開きますが、その意義はそれだけにとどまりません。

データ駆動型パラダイムを超えて：ZKコプロセッサによるWeb 3.0非同期モードの創出

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

ZKコプロセッサの登場は、ブロックチェーン計算に対する私たちの認識を根本的に変え、非同期処理がWeb 3.0の標準となる時代を切り開きます。この変化は、タスクの処理方法を再定義し、専門のプロセッサが独立して動作することで効率を高めます。

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

あるレストランが同期式だと想像してください。一人の人がシェフとウェイターの両方の役割を担っています。あなたが注文すると、彼はすぐに調理を始め、あなたは待たされます。彼はあなたの料理をサーブしてからでないと、次の客に対応できません。この設定はあなたのニーズを満たすかもしれませんが、他の客にとっては効率が低いでしょう。

一方、非同期式のレストランでは、別のシェフと別のウェイターが協働します。ウェイターは注文を受けた後、すぐにシェフに伝えて他の客の対応を続けます。料理が完成すると、シェフがウェイターに合図を送り、ウェイターがあなたにサーブします。

コンピュータシステムでは：

同期アーキテクチャは最初のレストランのように、各タスクが完了するまで次のタスクを待つ方式です。シンプルで明確ですが、一度に一つのタスクしか処理しないため速度が遅くなりがちです。また、その人は優れたウェイターかもしれませんが、優れたシェフではないかもしれません。

非同期アーキテクチャは二番目のレストランのように、独立した専門のシステムコンポーネントがあり、メッセージやタスクをやり取りして調整します。これにより、各コンポーネントが並列に自分のタスクを管理できます。管理がより複雑になる可能性がありますが、このアーキテクチャはより高速で効率的です。

現代のすべてのインターネットアプリケーションは、効率性と拡張性を高めるために非同期アーキテクチャに基づいています。我々も、Web 3.0も同様であるべきだと考えます。

ZKコプロセッサは、この変革の先駆けとなるでしょう。dApp開発者にとって、ブロックチェーンは私たちの非同期レストランのウェイターのようなものです。主に資産所有権の変更など、ブロックチェーンの状態を直接変更する計算を扱います。それ以外のすべての計算は、熟練したシェフのような堅牢なZKコプロセッサに委ねるべきです。非同期処理の力で効率よく結果を「調理」し、ウェイターに送り届けます。

具体的には、ブロックチェーンアプリケーション内の計算が以下の2つの「実行可能条件」のいずれかに当てはまる場合、ZKコプロセッサの利用を検討すべきです。

ZKコプロセッサ利用可能条件：