ABCDEレポート：コプロセッサと各社のソリューションについての詳細な考察
TechFlow厳選深潮セレクト
ABCDEレポート：コプロセッサと各社のソリューションについての詳細な考察
市販されているいくつかのコプロセッサ分野における技術ソリューションを体系的に整理し、市場およびユーザーに対してコプロセッサ分野についてより明確な理解を提供することを目的としています。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Kris & Laobai ABCDE / Mo Dong Celer Network
ここ数ヶ月でコプロセッサのコンセプトが注目を集めており、この新しいZKユースケースはますます多くの関心を集めています。
しかし我々が見受けたところでは、多くの人々にとってコプロセッサという概念は依然としてやや馴染みが薄く、特に「コプロセッサとは何か、また何ではないのか」という正確な位置づけについては曖昧なままです。また、市場に出回っているいくつかのコプロセッサ技術ソリューションを体系的に比較した試みはまだありません。本稿では、市場とユーザーにコプロセッサ分野についてより明確な理解を提供することを目指します。
一．コプロセッサ（Co-Processor）とは何か、また何ではないのか？
非技術者または開発者ではない人に向けて、「コプロセッサ」を一言で説明するとしたら、どのように表現しますか？
董沫博士の次の言葉はおそらく正解に近いでしょう――「要するに、コプロセッサとは『スマートコントラクトにDune Analyticsの能力を与えるもの』だ」。
この一文をどう解釈すればよいでしょうか？
Duneを使う場面を想像してみてください。Uniswap V3でLPをして手数料を稼ぎたいと考え、Duneを開いて最近のUniswapにおける各種取引ペアの取引量や、過去7日間のAPR、主要取引ペアの価格変動幅などを確認します。
あるいはStepNが流行っていた時期に、あなたがシューズのトレードを始め、いつ売却すべきか迷ったとしましょう。毎日Dune上のStepNデータ――日次取引量、新規ユーザー数、シューズのフロアプライスなど――を注視し、成長の鈍化や下落傾向が現れたらすぐに逃げ出すつもりでした。
もちろん、こうしたデータを監視しているのはあなただけではなく、UniswapやStepNの開発チームも同様に注目しているかもしれません。
これらのデータには大きな意味があります。トレンドの変化を判断できるだけでなく、「ビッグデータ」戦略を得意とするインターネット大手企業のように、さらに多彩な活用が可能です。
例えば、ユーザーがよく取引するシューズのスタイルや価格帯に基づき、類似品を推薦する。
創世シューズを保有している期間に基づき、「忠誠度報酬プログラム」を導入し、忠実なユーザーにエアドロや特典を与える。
Uniswap上でLPやトレーダーが提供するTVLや取引量に基づき、CEXのようなVIPスキームを設け、トレーダーには手数料割引を、LPには手数料分配率アップなどの特典を与える……
ここで問題が生じます。インターネット大手企業がビッグデータ＋AIを用いる場合、その処理はほぼブラックボックスであり、ユーザーには見えず、また気にされません。
しかしWeb3の世界では、「透明性」と「信頼不要（trustless）」が当然の政治的正しさであり、ブラックボックスは拒絶されます。
そこで上記のようなシナリオを実現しようとしたとき、二律背反的なジレンマに直面します。一方では中央集権的な方法――つまり「バックエンドで手動」にDuneでインデックスデータを統計処理し、それをもとに展開する方法。他方ではスマートコントラクトを書いて、自動的にオンチェーンからデータを取得・計算し、自動配布する方法です。
前者は「政治的に正しくない」信頼性の問題を引き起こします。
後者はオンチェーンで発生するガス代が天文学的な額になり、プロジェクト側の財布では到底負担できません。
ここで登場するのがコプロセッサです。上記二つの手法を融合し、「バックエンドでの手動操作」という工程を技術的に「自らの清廉さを証明」するのです。言い換えれば、ZK技術を使って「オフチェーンでのインデックス＋計算」の部分を「自らの清廉さを証明」し、それをスマートコントラクトに供給する。これにより信頼問題が解決され、莫大なガス代も消滅します。完璧です！
なぜ「コプロセッサ」と呼ばれるのでしょうか？これはWeb2.0の発展史における「GPU」に由来しています。GPUが当時、CPUとは別に独立した計算ハードウェアとして導入されたのは、CPUでは根本的に処理が難しい並列大量計算やグラフィック計算などを担うための設計だったからです。このような「コプロセッサ」アーキテクチャのおかげで、今日私たちは素晴らしいCG映画、ゲーム、AIモデルなどを享受できているのです。つまり、コプロセッサのアーキテクチャは計算体系における飛躍的進歩だったのです。現在、各コプロセッサチームはこのアーキテクチャをWeb3.0に持ち込もうとしています。ここでブロックチェーンはWeb3.0のCPUのような存在であり、L1でもL2でも、「重データ」や「複雑な計算ロジック」のタスクには本来不向きです。そのため、ブロックチェーンのコプロセッサを導入してこうした計算を支援することで、ブロックチェーンアプリケーションの可能性を大きく広げようとしているのです。
つまり、コプロセッサが行っていることをまとめると、以下の2点です。
-
ブロックチェーンからデータを取得し、ZK証明によって「取得したデータは真正で改ざんされていない」ことを証明する。
-
取得したデータをもとに必要な計算を行い、再度ZK証明によって「計算結果も真正で改ざんされていない」ことを証明する。これにより、計算結果を「低コストかつ信頼不要（trustless）」でスマートコントラクトが呼び出せるようになる。
最近Starkwareで話題になった「Storage Proof（ストレージ証明）」、あるいは「State Proof（ステート証明）」というコンセプトは、基本的に上記のステップ1に相当します。代表例としてはHerodotus、Lagrangeなどがあり、多くのZKベースのクロスチェーンブリッジ技術もこのステップ1に重点を置いています。
コプロセッサは、このステップ1の後にさらにステップ2を加えるだけであり、信頼不要でデータを抽出した上で信頼不要な計算を行う、それだけのことです。
より技術的な言い方をすれば、コプロセッサはStorage Proof／State Proofの上位集合であり、Verifiable Computation（検証可能な計算）の一部であると言えます。
ただし注意すべき点として、コプロセッサはRollupではありません。
技術的には、RollupのZK証明は上記のステップ2に似ていますが、ステップ1の「データ取得」はSequencerが直接行います。分散型Sequencerであっても、何らかの競争や合意形成メカニズムを通じてデータを取得するのであって、Storage ProofのようなZK形式ではありません。さらに重要なのは、ZK Rollupは計算層に加えて、L1ブロックチェーンに類似した永続的なストレージ層も実装しているのに対し、ZKコプロセッサは「ステートレス」であり、計算完了後はすべての状態を保持しません。
用途の観点からは、コプロセッサはあらゆるLayer1／Layer2向けのサービス型プラグインと見なせますが、Rollupは自ら実行レイヤーを再構築し、決済レイヤーの拡張を支援するものです。
二．なぜZKでなければならないのか？OPではいけないのか？
上記を読んだ後で疑問に思うかもしれません。「コプロセッサ」は本当にZKでなければならないのでしょうか？まるで「ZK付きのThe Graph」のように聞こえますが、通常The Graphの結果に対してそれほど強い懐疑感を抱くことはありません。
確かにそう言われればそうですが、それは普段The Graphを使う際には現金に関わる場面がほとんどないためです。こうしたインデックスはすべてオフチェーンサービス向けであり、フロントエンドのUI上に表示される取引量や取引履歴といったデータは、GraphやAlchemy、Zettablockなど複数のインデックスプロバイダーによって提供されています。しかし、こうしたデータをスマートコントラクト内に戻すことはできません。なぜなら、そうすることはインデックスサービスに対する追加的な信頼を必要とするからです。データが現金、特に巨大なTVLと連動するとき、この追加的な信頼は重要になります。友人が100円を借りたいと言えば、即座に貸すかもしれませんが、1万円、あるいは100万円を借りたいと言われたらどうでしょうか？
ただし逆に、コプロセッサのすべてのシナリオに本当にZKが必要なのでしょうか？RollupにはOPとZKの二つの技術路線があり、最近流行りのZKMLにも対応するOPMLという分岐路線のコンセプトが提唱されています。それならば、コプロセッサにもOPの分岐があるのではないでしょうか？例えばOP-Coprocessorなど。
実は、実際にあるのです――ただし詳細はここでは伏せておきます。まもなくより詳しい情報を公開する予定です。
三．コプロセッサの有力プレイヤー――市販されている主な技術ソリューションの比較
Brevis
Brevisのアーキテクチャは3つのコンポーネントから成ります：zkFabric、zkQueryNet、zkAggregatorRollup。
以下はBrevisのアーキテクチャ図です：
zkFabric： すべての接続されたブロックチェーンからブロックヘッダーを収集し、それらの有効性を証明するZKコンセンサス証明を生成します。zkFabricを通じて、Brevisはマルチチェーン間で相互運用可能なコプロセッサを実現しており、あるブロックチェーンが別のブロックチェーンの任意の履歴データにアクセスできるようにしています。
zkQueryNet： dAppからのデータ照会を受け付け、処理するオープンなZK照会エンジンの市場です。照会はzkFabricから提供される検証済みブロックヘッダーを使用して処理され、ZK照会証明を生成します。これらのエンジンは高度に特化した機能を持つものもあれば、汎用的な照会言語を持つものもあり、さまざまなアプリケーションニーズに対応できます。
zkAggregatorRollup： zkFabricとzkQueryNetの集約およびストレージ層として機能するZKロールアップブロックチェーンです。この層は両コンポーネントからの証明を検証し、検証済みデータを保存し、そのzk検証済みのステートルートをすべての接続されたブロックチェーンに提出します。
zkFabricはブロックヘッダーの証明を生成する重要な部分であり、その安全性を確保することが極めて重要です。以下はzkFabricのアーキテクチャ図です：
zkFabricはゼロ知識証明（ZKP）に基づくライトクライアントにより、完全に信頼不要となり、外部の検証エンティティに依存しません。その安全性は基盤となるブロックチェーンと数学的に信頼できる証明にのみ由来するため、外部の検証機関を必要としないのです。
zkFabric Proverネットワークは、各ブロックチェーンのlightclientプロトコルを回路化し、ブロックヘッダーの有効性証明を生成します。証明者はGPU、FPGA、ASICなどのアクセラレータを利用することで、証明時間とコストを最小限に抑えることができます。
zkFabricは基盤ブロックチェーンと基盤暗号プロトコルのセキュリティ仮定に依存しています。ただし、zkFabricの有効性を保証するためには、少なくとも1つの正直なリレーヤーが正しいフォークを同期している必要があります。このため、zkFabricは単一のリレーヤーではなく、分散型のリレーネットワークを採用して有効性を最適化しています。このリレーネットワークは、Celerネットワーク内のステートガーディアンネットワークのような既存の構造を利用することができます。
現在の展開状況：
イーサリアムPoS、Cosmos Tendermint、BNBチェーンなど、さまざまなブロックチェーン向けに実装されたライトクライアントプロトコルを、例示および概念実証として提供しています。
Brevisは現在、uniswap hookと協力関係にあり、hookはカスタムUniswapプールを大幅に拡張しましたが、CEXと比べて、大量のユーザー取引データ（例：取引量に基づくロイヤルティプログラム）に依存する機能を作成するための効果的なデータ処理機能が依然として不足しています。
Brevisの支援により、この課題が解決されました。hookは現在、ユーザーまたはLPの完全な履歴チェーンデータを読み取り、完全に信頼不要な形でカスタマイズ可能な計算を実行できるようになりました。
Herodotus
Herodotusは強力なデータアクセスミドルウェアであり、スマートコントラクトに以下のような、イーサリアムレイヤー横断的な現在および履歴チェーンデータへの同期アクセス機能を提供します。
-
L2からのL1ステート
-
L1および他のL2からのL2ステート
-
L3／App-ChainのステートをL2およびL1へ
Herodotusは「ストレージ証明（Storage Proof）」という概念を提唱しています。ストレージ証明は「包含証明（inclusion proof）」（データの存在を確認）と「計算証明（computation proof）」（多段階ワークフローの実行を検証）を融合させ、イーサリアム全体のブロックチェーンやロールアップなど大規模データセット内の1つ以上の要素の有効性を証明します。
ブロックチェーンの核はデータベースであり、Merkle木やMerkle Patricia木といったデータ構造で暗号保護されています。これらの構造の特徴は、一度データが安全に登録されると、そのデータが構造内に含まれていることを証明する証拠を生成できることです。
Merkle木やMerkle Patricia木の使用はイーサリアムのセキュリティを高めます。各レベルのデータを暗号学的にハッシュすることで、データを改ざんしても発覚しないようにすることは事実上不可能です。特定のデータポイントを変更すれば、対応するハッシュ値からルートハッシュまで変更する必要があり、これはブロックヘッダー内で誰にでも見えるためです。この基本特性により、非常に高いデータ完全性と不変性が保証されています。
さらに、これらの木構造は「包含証明」によって効率的にデータ検証が可能です。例えば、取引の包含やコントラクトのステートを検証する際に、イーサリアム全体を検索する必要はなく、関連するMerkle木内のパスを検証するだけで済みます。
Herodotusが定義するストレージ証明は、以下の要素を融合したものです。
-
包含証明： Merkle木やMerkle Patricia木などの暗号データ構造内に特定のデータが存在することを確認し、関連データがデータセット内に確かに存在することを保証します。
-
計算証明： 多段階のワークフローの実行を検証し、イーサリアム全体やロールアップなど大規模データセット内の1つ以上の要素の有効性を証明します。データの存在を示すだけでなく、そのデータに適用された変換や操作も検証します。
-
ゼロ知識証明： スマートコントラクトが相互作用する必要のあるデータ量を簡素化します。ゼロ知識証明により、スマートコントラクトは基礎となるすべてのデータを処理せずとも、主張の有効性を確認できます。
ワークフロー：
1. ブロックハッシュの取得
ブロックチェーン上のすべてのデータは特定のブロックに属しています。ブロックハッシュはそのブロックの唯一の識別子であり、ブロックヘッダーがその内容を要約しています。ストレージ証明のワークフローでは、まず注目するデータを含むブロックのブロックハッシュを特定・検証することが最初のステップです。
2. ブロックヘッダーの取得
関連するブロックハッシュを取得した後、次にブロックヘッダーにアクセスします。これを行うには、前述のステップで取得したブロックハッシュに対応するブロックヘッダーをハッシュ処理します。その後、提供されたブロックヘッダーのハッシュ値と得られたブロックハッシュ値を比較します。
ハッシュの取得方法には2通りあります。
（1）BLOCKHASH opcode を使用して取得
（2）Block Hash Accumulator から、過去に検証済みのブロックのハッシュを照会
このステップにより、処理中のブロックヘッダーが本物であることが保証されます。このステップが完了すれば、スマートコントラクトはブロックヘッダー内の任意の値にアクセス可能になります。
3. 必要なルートの確定（任意）
ブロックヘッダーを取得すれば、その内容、具体的には以下に深掘りできます。
stateRoot： ブロック生成時の全ブロックチェーン状態の暗号的要約。
receiptsRoot： ブロック内のすべての取引結果（レシート）の暗号的要約。
transactionsRoot： ブロック内で発生したすべての取引の暗号的要約。
これらのルートはデコード可能であり、特定のアカウント、レシート、取引がブロックに含まれているかどうかを検証できます。
4. 選択したルートに基づくデータの検証（任意）
選択したルートを持ち、イーサリアムがMerkle-Patricia Trie構造を採用していることを踏まえると、Merkle包含証明を活用してツリー内にデータが存在するかを検証できます。検証手順はデータの種類やブロック内の深さによって異なります。
現在サポートされているネットワーク：
-
Ethereum → Starknet
-
Ethereum Goerli* → Starknet Goerli*
-
Ethereum Goerli* → zkSync Era Goerli*
Axiom
Axiomは、開発者がイーサリアムの全履歴からブロックヘッダー、アカウント、ストレージ値を照会できる仕組みを提供します。Axiomは暗号学的なリンクに基づく新しいアプローチを導入しており、返されるすべての結果はオンチェーンでゼロ知識証明により検証されるため、スマートコントラクトは追加の信頼前提なしにそれらを利用できます。
Axiomは最近、Halo2-repl をリリースしました。これはJavaScriptで書かれたブラウザベースのHalo2 REPLです。これにより、開発者はRustなどの新しい言語を学ぶことなく、標準的なJavaScriptだけでZK回路を記述できるようになります。証明ライブラリのインストールや依存関係の処理も不要です。
Axiomは2つの主要技術コンポーネントから構成されます。
- AxiomV1 — ジェネシスから始まるイーサリアムブロックチェーンキャッシュ。
- AxiomV1Query — AxiomV1に対して照会を実行するスマートコントラクト。
（1）AxiomV1でのブロックハッシュのキャッシュ：
AxiomV1スマートコントラクトは、ジェネシス以降のイーサリアムブロックハッシュを2つの形式でキャッシュします。
まず、連続する1024ブロックのブロックハッシュのKeccak Merkleルートをキャッシュします。これらのMerkleルートはZK証明によって更新され、ブロックヘッダーハッシュが、EVMで直接アクセス可能な最新256ブロックのいずれか、またはすでにAxiomV1キャッシュに存在するブロックハッシュを終点とするコミットメントチェーンを形成していることを検証します。
次に、AxiomはジェネシスからこれらのMerkleルートのMerkle Mountain Range（MMR）を保存します。このMMRは、キャッシュの第一部分であるKeccak Merkleルートを更新することでオンチェーンで構築されます。
（2）AxiomV1Queryによる照会の実行：
AxiomV1Queryスマートコントラクトは、バッチ照会を可能にし、歴史的なイーサリアムブロックヘッダー、アカウント、アカウントストレージに対する任意のデータへの信頼不要なアクセスを実現します。照会はオンチェーンで行われ、AxiomV1キャッシュのブロックハッシュに対するZK証明によってオンチェーンで完了します。
これらのZK証明は、関連するオンチェーンデータがブロックヘッダーに直接あるか、ブロックのアカウントまたはストレージTrieにあるかをチェックし、Merkle-Patricia Trieの包含（または非包含）証明を検証することで実現します。
Nexus
Nexusはゼロ知識証明を活用して、検証可能なクラウドコンピューティングの汎用プラットフォームを構築しようとしています。現在はmachine architecture agnosticで、RISC-V、WebAssembly、EVMをサポートしています。Nexusはsupernovaの証明システムを採用しており、チームのテストでは証明生成に6GBのメモリが必要でしたが、今後さらに最適化が進められ、一般の端末PCでも証明生成が可能になる予定です。
正確に言えば、アーキテクチャは2部構成です。
-
Nexus Zero： ゼロ知識証明と汎用zkVMによって支えられる、分散型検証可能クラウドコンピューティングネットワーク。
-
Nexus： 多者間計算（MPC）、ステートマシンレプリケーション、汎用WASM仮想マシンによって駆動される、分散型検証可能クラウドコンピューティングネットワーク。
NexusおよびNexus Zeroのアプリケーションは伝統的なプログラミング言語で記述でき、現在はRustをサポートしており、将来的にはさらに多くの言語をサポートする予定です。
Nexusアプリケーションは分散型クラウドコンピューティングネットワーク上で動作し、これは直接イーサリアムに接続された汎用「サーバーレスブロックチェーン」とも言えます。したがって、Nexusアプリケーションはイーサリアムのセキュリティを継承しませんが、その代わりにネットワーク規模の縮小により、より高い計算能力（計算、ストレージ、イベント駆動I/Oなど）を得られます。Nexusアプリケーションは専用クラウド上で動作し、内部で合意形成を行い、イーサリアム上で検証可能な閾値署名によって「証明」（真の証明ではなく）を提供します。
一方、Nexus Zeroアプリケーションは、BN-254楕円曲線上でオンチェーン検証可能なゼロ知識証明を持つ汎用プログラムであるため、イーサリアムのセキュリティを継承しています。
Nexusは複製環境で任意の決定論的WASMバイナリを実行できるため、zk-rollupのsequencer、オプティミスティックrollupのsequencer、Nexus ZeroのzkVM自体などの証明生成アプリケーションの有効性・分散性・フォールトトレランスの源泉として利用されることが期待されています。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
ABCDE
