Cipholio 深度分析：ZKVMのソリューションと未来についての考察

作者： Yolo，Cipholio Ventures

TL; DR

1、ZKの技術はプライバシーとスケーラビリティの2つの主要な使用シーンを持っています。プライバシーについて議論する際には、ZK技術を利用してオフチェーンデータを保護し、取得されないようにします。一方、スケーラビリティについて議論する際には、ZKを利用してオンチェーンの計算スペースを節約します。例えば、あるアカウントに100ドルあることを確認したい場合、従来のブロックチェーンでは各ノードが一度確認する必要がありますが、今では1つのノードだけで、データの完全性を保証しつつ、最近の純流入が100ドルである証拠を見つけることで、アカウントに100ドルがあることを証明できます。前者は大量の計算と証明を必要とし、後者はオフチェーンの証明だけで済みます。

2、ZKVMの発展の核心的なトレードオフは、ZKの潜在能力を発揮することが重要か、現在の開発者リソースを活用することが重要かということです。ZKの潜在能力を発揮することは、CPUレジスタのハードウェアアクセラレーション、IR言語とアセンブリ言語の再編成を意味します。一方、開発者リソースを利用することは、Solidityをバイトコードに変換した後、バイトコードがマッピングするオペコードをZK証明する問題を意味します。

3、モジュール化ブロックチェーンの観点から、L1はコンセンサス問題を解決し、L2は計算と実行の問題を解決し、DA層はデータの可用性と完全性の問題を解決します。ZkタイプのL2はその証明を行います。

4、アセンブリ言語で独立して設計されたZK証明の専用型ZKappは、低い組み合わせ性とデカップリング能力を持つため、将来の発展過程で大きな障害に直面するでしょう。これらのソリューションは、他のZKソリューションと互換性のないVM、互換性のない言語、互換性のない証明を持ち、大きな呼び出しの難しさがあります。

5、依存、時間系列の取引ログ、データの安全性と証明の完全性は、その実行の信頼性を決定します。現在、ZKソリューションの大部分がクローズドソースの状態にある中で、ZKのセキュリティ監査には大きな発展の可能性があります。

6、ZKPはオフチェーンデータに依存しているため、DAチェーンに委ねるとデータのプライバシーが失われます。データのプライバシーとZK証明ノードが悪用しないことを両立させるためには、新しい解決策が必要です。私たちは、MPC/FHEなどの安全計算ソリューションの未来に期待しています。

7、異なるCircuitの成熟が進むにつれて、ZK証明も効率化と分業を迎える可能性があり、ZK証明のハードウェア加速ソリューションや専門のZKマイナーも登場するかもしれません。

8、ZKPの経験の限界問題。典型的な問題には、制約システム（constraint system）がデータを効果的に制約できないこと、複雑な交差命題を証明する際に制約が不十分であること、プライベートデータの漏洩、プライベートデータを公開データとして扱うこと、オフチェーンデータに対する攻撃、契約層の「メタデータ攻撃」、ZK証明ノードの悪用などがあります。

9、短期的には、ZKソリューションの安全性には限界があります。現在、大量のコンセンサスはオフチェーンノードの自律性に基づいており、オフチェーン環境の安全性を保証するための一連の必要なツール（テスト、証明など）が不足しています。

概観

これまでZK技術はその専門用語の多さから、人々がこのテーマを十分に議論することが難しい状況でした。本稿では、エコシステムの発展の観点からZK技術とその応用シーンを分析し、現在のZK関連の競争状況を描写し、将来の発展方向についての展望を述べます。本稿では以下の点について議論します：

1. ZK技術について議論する際、私たちは何を議論しているのか？（知識の前提として、機関投資家は第2部から読むことができます。）
2. 技術発展の観点からgzkvm（generalized zk vm）の発展の法則と構造をどう見るか？
3. 現在の主要なZKvm技術ソリューションの比較は？
4. 分析と展望

一、仮想マシンABC--日常のコンピュータから始める

ZKEVMに関連する知識を紹介する前に、まず私たちの日常のコンピュータの構造について話したいと思います。私たちはコンピュータがソフトウェアとハードウェアの2つの部分から成り立っていることを知っています。ソフトウェアがハードウェア上でスムーズに動作するためには、ソフトウェアに適した実行環境をマッチさせる必要があります。構造的には、実行環境は【ハードウェア+オペレーティングシステム】の2つの部分から成り立っています。

黄色の部分がハードウェア、緑の部分がオペレーティングシステムです。ここで、ある学生が疑問を持つかもしれません：なぜ実行環境はオペレーティングシステムと同等ではないのか、これは主にオペレーティングシステムがすべてのハードウェアと互換性がないためです。オペレーティングシステムとハードウェアのマッチングがなければ、ソフトウェアにサービスを提供することはできません。この問題については、後でZKVMの発展の道筋でも触れます。

実行環境が整ったら、具体的なソフトウェア（プログラム/app）が必要です。では、プログラムはどのように動作するのでしょうか？

図からわかるように、ソフトウェアはオペレーティングシステムを介してハードウェア層で計算を行う全体のプロセスで、プログラム言語は3つの段階を経て変化します。高級言語はプログラムを書くために実際のニーズを満たし、アセンブリ言語はコンピュータとコミュニケーションを取るために使用され、底層のローカルコード（16進数）はコンピュータによって具体的に実行されます。具体的には、プログラマーがAPPのコードを完成させた後、トランスレーターを介してobj（目的言語）に翻訳されます。これらの離散的な目的言語は、オペレーティングシステム内のリンカーを通じてリンクされ、出力された実行可能なexeファイルはハードディスクに保存されます。

実行時には、exeファイルがデータをメモリに配置し、CPUを介してObjをローカルコード（バイトコード）に変換して計算操作を行い、appのI/Oを実現します。このプロセスには非常に多くの選択肢があり、多様な言語、多様なオペレーティングシステム、多様なハードウェアがあり、商業的な観点からは非常に多くのトレードオフが存在します。これらの選択は最終的にコンパイラのコアLLVM（low level virtual machine）の改善に反映されます。

下の図では、ハードウェア（黄色）とオペレーティングシステムの間に多くの対応関係と制約条件があることがわかります：

同じタイプのハードウェアには複数のオペレーティングシステムをインストールできますが、異なるハードウェアには異なるタイプのオペレーティングシステムが必要です。例えば、同じAT互換機AにはWindowsやLinuxBなどのオペレーティングシステムをインストールできます。また、X86チップのハードウェアにはx86バージョンのWindowsが必要です。これは主にオペレーティングシステムの底層アセンブリ言語がチップとマッチする必要があるためです。

Appの成功した実行にはCPUとのマッチングが必要であり、オペレーティングシステムとのマッチングも必要です。例えば：1、Office 2017の正常な動作を保証するためには、x86CのCPUが必要です；2、一部のAPPはWindows XPでしか動作せず、2000では動作しません。

CPUはその固有の機械語しか解釈できません。異なるCPUが解釈できる機械語の種類も異なります。つまり、異なる高級言語で書かれたAPPが、【オペレーティングシステム】を介してCPUが計算できる言語にコンパイルされない限り、CPUは実行できません。

二、Zk VMとは？

通常、ZKについて議論する際には、3つの文脈があります：

1. ZKをスケーリングソリューションRollupL2として使用する。
2. ZKPを使用して証明するアプリケーション、dydx、Zklinkなど。
3. zkproofを暗号アルゴリズムの一種として。

どの言語を、どの環境で、どのハードウェアで実行するのか？これは広義のVMが解決すべき問題です。

前述の伝統的なオペレーティングシステム（これも一種のVM）を紹介した後、ZKVMを見ると、ZKVMも同様の機能を果たし、ハードウェア層（ネイティブチェーン+ZK証明システム）と高級言語（SolidityまたはネイティブZK言語）とのコミュニケーションを実現しています。その核心はデータの証明と状態の更新です。システムが2種類の入力、原始データ（状態と指令）と証明（状態と指令に関連する証明）を受け取ると、比較計算を行い、指令（状態を更新）とZKP（証明）を出力し、L1に提出してコンセンサスをブロードキャストします。

具体的に見ると、ZK証明は以下のいくつかの部分を経て行われます（by JP Aumasson, Taurus）：

1. ローカルの計算；

2. Circuitの定義。例えば、あなたの財布にお金があるか確認する、情報が完全であるか確認する、署名が正しいか確認する；

3. 算術的証明：数学的方法を用いて計算が実行可能であることを証明します。

4. 算数証明の結果と実際の結果を比較します。

5. 結果をチェーンに提出します。

Scrollのソリューションの例を挙げると、Gethから出発し、システムはローカルの計算を完了し、取引トレース（取引の履歴ログ）を分解してCircuits演算子に変換し、その後算術的方法（例えば多項式分解、暗号学）を用いてZK証明を得ます。そしてデータと証明を比較し、問題がなければブロードキャストしてチェーンに載せます。この中には、Circuitsを設定する方法、どのような種類のCircuitsがあるか、Circuitsをどのように分解するかなど、多くの重要な技術が含まれています。全体の確認方法は、巨大な表を想像することができ、各変数にはそのパラメータがあり、既知の履歴データの背景の下で特定の結果の必然性を求めます。

例を挙げると、あるアカウントに100ドルあることを確認したい場合、従来のブロックチェーンでは各ノードが一度確認する必要がありますが、今では1つのノードだけで、データの完全性を保証しつつ、最近の純流入が100ドルである証明を加え、確認を行います（このケースは比較的単純で、一目でわかりますが、実際の状況では数学的な計算が必要です）。完了後、アカウントに100ドルがあることを証明できます。前者は各ノードの計算を必要とし、後者は単一ノードの計算とzk証明だけで済みます。この例では、「どのようにオフチェーンでアカウントに十分な残高があることを証明するか」が確認され、証明に必要な制約は「最近の歴史的タイムライン内でアカウントの純流入が100ドルを超える（実質的にはMerkle Rootの証明に基づく）」というものであり、その後ノードの計算結果とZKPを比較して状態が正しいかどうかを決定します。

ZK言語の公約数

MidenVMのまとめによれば、現在市場で主に使用されているZkappのツールはWASMとRISC Vを基にしたアセンブリ言語です。一部のツールキットは、アプリケーションに迅速に「ZK」の概念やラベルを付けることができます。しかし、構造を少し分解すると、従来のスマートコントラクトはL1によって安全性が保証され、全ネットワークのブロードキャストによるコンセンサスの安全性は歴史的に検証されていますが、オフチェーンZKP証明を利用する場合、ZKP証明ノードが悪用していないかの問題が存在します。

Devsが制約（Constraint）を合理的に設定できる能力の問題をさておき、ZKP証明ノードの悪用意欲を防ぐ方法がより重要です。

例を挙げると、一部のZK DEXはCEXとDEXの間でバランスを探しているようです。CEXに比べて、ユーザーは資金を自分のL1アカウントに保管できます。一方でDEXに対しては、より優れた効率を発揮できます。しかし、実際には多くのプロジェクトがオフチェーン証明の安全性のリスクを抱えています。また、APP層からIR層まで、すべてがzkAPPチームによって独立して開発されており、各チームには独自のプログラミング習慣とライブラリがあるため、チーム間での組み合わせ性が難しく、市場の分業とハードウェアの加速を促進することができません。

したがって、市場は暗号学と高級言語の間で共通の基盤を見つけることを模索しています。これにより、さまざまなアプリケーションに共通のフレームワークを提供し、ZK-VMはシステム全体を適応させる重要な部分です。

実行モードの観点から、EVMとJVMは非常に似ています。両者はバイトコードを実行するスタックマシンです。EVMはストレージの概念を追加しており、そのバイトコード命令は契約開発により適しています。

図ではETHを例に挙げ、従来のETHは3つの部分から構成されています。ETHネットワーク（ノード+コンセンサスメカニズム）、EVM、Dapp開発エコシステム。ここでZKが重要な役割を果たしていることが明確にわかります：

1. ZK回路のハードウェア層の観点から：

EVMはすべてを互換できないかもしれません。EVMには可変長の命令がいくつかあり、例えばCALL、DATACOPY、EXP、CREATEなど、これらはZK回路にとって好ましくありません。

2. 開発者の観点から：

言語を再学習する必要がないか（Solidityは依然として互換性があります）、EVMのAPI特性を保持できるかどうか。この場合、エコシステム全体がいくつかのZKアルゴリズムのサポートを失う可能性があります。

それ以外にも、ZKVMは多くの技術的互換性を考慮する必要があります。例えば：

1. レジスタの互換性。マシンタイプ。従来のEVMはスタックベースの状態マシンであり、大量の計算式が連結されており、並行処理ができません。これにより、全体の計算機の原子性が保証されます。このアーキテクチャはZKにとって非常に不利であり、ZKアルゴリズムの全効率を発揮するには、レジスタベースにする必要があります。つまり、CPUレジスタを中心にしたアーキテクチャでVMを設計する必要があります。

2. 言語の互換性。関数呼び出し。VMシステムは底層の特性をAPIにカプセル化し、APIが動的呼び出しをサポートし、Pythonのような高級言語をサポートできるようにする必要があります。

3. コンピュータの底層の互換性。ネイティブフィールド。異なるCPUは異なるビット数を持ち、異なるアルゴリズムでのパフォーマンスが異なります。ZK専用の計算機を計画する必要があります。

4. 従来のパブリックチェーン構造の互換性：シーケンサー/ローラー/マイナー。

三、ZKVMのアーキテクチャ

主流技術ソリューション

どの言語を、どの環境で、どのハードウェアで実行するのか？これは広義のVMが解決すべき問題です。

VMの中で最も重要なコアはLLVM（low-level-virtual-machine）であり、これはコンパイラの最も重要なコアと見なすことができます。図は元のEVMの運用スキームであり、スマートコントラクトはLLVM IRの中間コードを介して変換され、バイトコードに変換されます。これらのバイトコードはブロックチェーンに保存され、スマートコントラクトが呼び出されると、バイトコードは対応するオペコードに変換され、EVMとノードハードウェアによって実行されます。

ZKを組み合わせると、さまざまな解決策はどのように実現されるのでしょうか？

Starkware

StarkwareはZK分野で早くからスタートし、技術的な蓄積が豊富で、一定の技術的先進性を持っています。これは代表的なZK中心主義の技術アーキテクチャであり、ZKを中心にCairo VMとCairo言語を構築しています。しかし、クローズドソースの状態であるため、一部の技術的詳細は不明です。その欠点はCairoの学習コストです。公式もSolidityをCairoに変換するためのいくつかのフレームワークを開発していますが、その底層コアはすべてCairoVMに基づいているため、かなりのSolidity-EVM互換の特徴が失われることを意味します。

Zksync

ZKsyncのフレームワークはEVMとZKの両方の特徴を兼ね備えており、Solidityと独自に開発した回路言語Zincを融合させ、コンパイラ内部で両者をIRレベルで統一しています。その利点は、コンパイラコアのLLVMが多様な言語に対応できることです。Zksyncもクローズドソースのフレームワークです。

Hermez by Polygon

Scroll

HermZとScrollの2つの技術ソリューションは、Ethereumエコシステムに重点を置いており、バイトコードにおいてETHエコシステムと融合しています。EVMは自然にバイトコードとその対応するオペコードをサポートしているため、これらはETHエコシステムと高い融合性を持っています。Solidityはこれらの2つのZKVM上でEVMのAPIを十分に呼び出すことができ、EVMのアーキテクチャの利点を最大限に保持しています。2つのソリューションの違いは、Hermzが内部でオペコードを統一し、その後証明を行うのに対し、Scrollはオペコードを分解して回路を証明し、その後統合します。

なぜEVMとの互換性を選ぶのか？EVMにはいくつかのアーキテクチャが検証されており、安全性が高く、互換性も良好だからです。例えばGethモデルやRPCアーキテクチャ、これらのAPIはEVMによって良好にカプセル化されており、歴史的に検証されています。

まとめると、

• Starkwareは最も底層でWASMと機械コードレベルで統一し、ZKsyncは最も浅いIRレベルで統一し、HermzとScrollはバイトコードで中間的に統一しています；
• Starkwareは技術転換が最も徹底していますが、ユーザーの学習コストが最も高いです。一方、ZKsyncは比較的バランスが取れており、一部のSolidityの特性を保持し、局所的なZK性能を発揮します；
• HermzとScrollは比較的適用しやすく、分解しやすく、バイトコードを全面的に統合し、EVMを統合しています。特にScrollはZK証明をオープンにし、ハードウェア加速の余地を大きくしています。
• 相対的に見て、技術駆動でもエコシステム統合駆動でも、将来にはそれぞれの発展の余地があり、「貿工技」でも「技工貿」でも、自分のシーンを見つけてより大きな価値を発揮する機会があります。

Windowsの歴史を振り返ると、強力なオペレーティングシステムが登場する前は、異なる開発者が異なるハードウェアに対して異なる開発ツールを習得する必要がありました。 アセンブリを習得せず、コンピュータの底層を理解していない開発者は、開発プロセスで非常に多くの挫折に直面することになります。オペレーティングシステムはハードウェアの中で最大の公約数を見つけ、CPU以外のI/Oシステムを統一されたインターフェースにカプセル化します。これらの技術的蓄積により、ソフトウェア開発のハードルが大幅に低下し、大部分のプログラマーは高級言語を理解するだけで済むようになり、アセンブリや底層コードの知識がなくても美しいAppを書くことができるようになりました。

ZKVMの発展を振り返ると、現在のZKappが従来のプログラマー+アセンブリ+暗号学の知識を必要とする場合、将来的にはZKVMの成熟に伴い、ますます多くの底層技術が高級言語にカプセル化され、開発のハードルが徐々に低下し、エコシステムの繁栄が見込まれます。

創業者にとって、注意すべき点が2つあります：

1. ZK技術はオンチェーンのコンセンサスをオフチェーンの証明に変えています。現在、証明技術は比較的成熟していますが、証明の分解やデータストレージの安全性にはまだ多くのリスクがあります。関連する監査機関やテストツールには空白の欠落があります。

2. ZK技術の使用シーンはまだ発掘されていません。汎用型ZKVMが急ピッチで開発されており、ZKに対応する高級言語も技術者の学習を待っています。技術が成熟し問題を解決するまでにはまだ時間がかかります。ZKで問題を解決したい場合、創業者は次の質問に答える必要があります：もしそれが細分化されたシーンであれば、自分でWASMを使って構築する必要があるのか？ZKVMが成熟した場合、自分の技術的蓄積には先発優位性があるのか？他のZKappの呼び出しをサポートしているのか？

展望と結論

ZKの技術はプライバシーとスケーラビリティの2つの主要な使用シーンを持っています。プライバシーについて議論する際、私たちは実際にはオフチェーンデータを保護し、取得されないようにしています。一方、スケーラビリティについて議論する際には、ZKを利用してオンチェーンの計算スペースを節約しています。

1. ZKVMの発展の核心的なトレードオフは技術と開発者です。ZKの潜在能力を発揮することは、CPUレジスタのハードウェアアクセラレーション、IR言語とアセンブリ言語の再編成を意味します。一方、開発者リソースを利用することは、Solidityをバイトコードに変換した後、バイトコードがマッピングするオペコードをZK証明する問題を意味します。
2. アセンブリ言語で独立して設計されたZK証明の専用型ZKappは、低い組み合わせ性とデカップリング能力を持つため、将来の発展過程で大きな障害に直面するでしょう。これらのソリューションは、他のZKソリューションと互換性のないVM、互換性のない言語、互換性のない証明を持ち、大きな呼び出しの難しさがあります。
3. モジュール化ブロックチェーンの観点から、L1はコンセンサス問題を解決し、L2は計算と実行の問題を解決し、DA層はデータの可用性と完全性の問題を解決します。Zkタイプのデータの安全性と証明の完全性は、その実行の信頼性を決定します。ここには矛盾があり、オフチェーンノードを信頼せず、データをDAに独立して保存したい場合、DAチェーンに対して安全性の要求が生じます；もしローカルに存在し、データが改ざんされないことを保証する必要がある場合、証明ノード自体が悪用しないことを証明する必要があります。これらはすべてMPC/FHEソリューションへの需要を高めています。
4. 現在、ZKソリューションの大部分がクローズドソースの状態にある中で、大量のコンセンサスはオフチェーンノードの自律性に基づいており、オフチェーン環境の安全性を保証するための一連の必要なツール（テスト、証明など）が不足しています。将来的には制約設計と代数証明が2つの主要な監査プロセスとなるでしょう。
5. ZKエコシステムの主要なリスク。典型的な問題には、制約システム（constraint system）が不十分であることがあります。複雑な交差命題を証明する際に制約が不十分である問題、プライベートデータの漏洩、プライベートデータを公開データとして扱うこと、オフチェーンデータに対する攻撃、契約層の「メタデータ攻撃」、ZK証明ノードの悪用などがあります。
6. 異なるCircuitの成熟が進むにつれて、シーケンサー/ローラー/マイナーも効率化と分業を迎え、ZK証明のハードウェア加速の機会を期待しています。