IOSG: zkVM と zkEVM 間の派閥争いの多次元分析

著者: ブライアン、IOSG ベンチャーズ

2022 年現在、ロールアップに関する議論の主な焦点は ZkEVM にあるようですが、ZkVM も拡張のもう 1 つの手段であることを忘れないでください。 ZkEVM はこの記事の焦点では​​ありませんが、いくつかの側面における ZkVM と ZkEVM の違いを思い出す価値があります。

• 互換性: これらはすべて拡張ですが、焦点は異なります。ZkEVM の焦点は既存の EVM との互換性を直接達成することであり、ZkVM の位置付けは完全な拡張を達成すること、つまり dapps のロジックとパフォーマンスを最適化することです。互換性は主要なものではありません。最下層をセットアップすると、EVM 互換性も実現できます。

• パフォーマンス: どちらも比較的予測可能なパフォーマンスのボトルネックがありますが、ZkEVM の主なボトルネックは EVM との互換性であり、ZK プルーフ システムで生成される追加コストをカプセル化するのには適していません。 ZkVM のボトルネックは、命令セット ISA の導入により、最終出力の制約がより複雑になることです。

• 開発者エクスペリエンス: タイプ II ZkEVM (Scroll、Taiko など) は、EVM バイトコードとの互換性に重点を置いています。言い換えれば、バイトコード レベル以上の EVM コードは、ZkEVM を通じて対応するゼロ知識証明を生成できます。 ZkVM には 2 つの方向性があり、1 つは独自の DSL (Cairo など) を作成する方向、もう 1 つは C++/Rust などの既存の成熟した言語 (Risc 0 など) と互換性を持たせる方向です。将来的には、ネイティブ Solidity Ethereum 開発者が無料で ZkEVM に移行できるようになり、より新しく強力なアプリケーションが ZkVM 上で実行されるようになることが期待されます。

この写真を覚えている人も多いだろうが、CairoVM 自体は何の関係も無く、ZkEVM の派閥争いから乖離した本質的な理由は設計思想の違いにある。

ZkVM について説明する前に、最初に考えるのは、ブロックチェーンに ZK 証明システムを実装する方法です。回路の実装には、大まかに 2 つのアプローチがあります。回路ベースのシステム (回路ベース) と仮想マシン ベースのシステム (vm ベース) です。

まず、回路ベースのシステムの機能は、プログラムを制約に直接変換して証明システムに送信することですが、仮想マシンベースのシステムは命令セット (ISA) を通じてプログラムを実行し、その過程でプログラムを生成します。実行トレース。この実行軌跡は制約にマッピングされ、証明システムに入力されます。

回路ベースのシステムの場合、プログラムの計算は、プログラムを実行する各マシンによって制約されます。仮想マシンをベースにしたシステムの場合、ISA は回路ジェネレータに組み込まれ、プログラム制約を生成しますが、同時に回路ジェネレータには命令セット、動作サイクル、メモリなどの制限があります。仮想マシンは、プログラムの動作条件が上記の制限内であれば、どのマシンでもプログラムを実行できるという汎用性を備えている。

画像の説明

画像クレジット: ブライアン、IOSG Ventures

長所と短所：

• 開発者の観点から見ると、回路ベースのシステムで開発するには、多くの場合、各制約のコストを深く理解する必要があります。ただし、仮想マシン プログラムを作成する場合、回路は静的であるため、開発者は命令をより重視する必要があります。

• 検証者の観点から見ると、同じ純粋な SNARK がバックエンドとして使用されると仮定すると、回線ベースのシステムと仮想マシンは回線の汎用性において大きく異なります。回路システムはプログラムごとに異なる回路を生成しますが、仮想マシンは異なるプログラムに対して同じ回路を生成します。これは、ロールアップでは、回線システムが L1 に複数の検証者コントラクトを展開する必要があることを意味します。

• アプリケーションの観点から見ると、仮想マシンはメモリ モデル (メモリ) を設計に組み込むことでアプリケーションのロジックをより複雑にし、回路システムを使用する目的はプログラムのパフォーマンスを向上させることです。

• システムの複雑さ（complexity）の観点から見ると、仮想マシンは、より単純な回路システムと比較して、メモリモデル、ホスト（ホスト）とクライアント（ゲスト）間の通信など、より複雑なシステムを組み込んでいます。

画像の説明

最初のレベルのタイトル

仮想マシンの設計原則

副題

1. ISA命令セット

回路ジェネレーターの動作方法を指定します。その主な役割は、命令を制約に正しくマッピングし、それを証明システムに入力することです。 zk システムは RISC (Reduced structs Set) を使用します。 ISA には 2 つの選択肢があります。

1 つ目は、Cairo の設計に見られるカスタム ISA (カスタム ISA) を構築することです。一般に、制約ロジックには次の 4 種類があります。

カスタム ISA の基本的な設計の焦点は、プログラムの実行と検証の両方が迅速に実行されるように、制約をできるだけ少なくすることです。

副題

2. コンパイラ

大まかに言うと、コンパイラーはプログラミング言語を徐々にマシンコードに変換します。 ZK の文脈では、C、C++、Rust などの高レベル言語を使用して制約システム (R1 CS、QAP、AIR など) にコンパイルされた低レベルのコード表現を指します。方法は2つあり、

• 既存の zk 回路表現に基づいてコンパイラを設計します。たとえば、ZK では、回路表現は Bellman などの直接呼び出し可能なライブラリや Circom などの低レベル言語から始まります。さまざまな表現を集約するために、Zokrates のようなコンパイラー (それ自体が DSL) は、任意の下位レベルの表現にコンパイルできる抽象化レイヤーを提供することを目的としています。

• (既存の) コンパイラ インフラストラクチャ上に構築します。基本的なロジックは、複数のフロントエンドとバックエンドの中間表現を利用することです。

Risc 0 コンパイラは、複数の IR (LLVM と同様) を生成できるマルチレベル中間表現 (MLIR) に基づいています。さまざまな IR には独自の設計重点があるため、さまざまな IR が開発者に柔軟性をもたらします。たとえば、一部の IR はハードウェア専用に最適化されているため、開発者は自分の希望に応じて選択できます。同様のアイデアは、GCC を使用した vnTinyRAM および TinyRAM にも見られます。 ZkSync も、コンパイラ インフラストラクチャを利用するもう 1 つの例です。

さらに、CirC などの zk のコンパイラ インフラストラクチャも確認できます。これも LLVM からいくつかの設計概念を借用しています。

上記の 2 つの最も重要な設計ステップに加えて、他にも考慮すべき点がいくつかあります。

1. システムのセキュリティ（セキュリティ）と検証コスト（検証者コスト）のトレードオフ

システムで使用されるビット数が多いほど (つまり、セキュリティが高いほど)、検証のコストも高くなります。セキュリティは、キー ジェネレーター (楕円曲線を表す SNARK など) に反映されます。

2. フロントエンドとバックエンドの互換性

互換性は、回路の中間表現が利用できるかどうかによって決まります。 IR は、正確性 (プログラムの出力が入力と一致するか、出力が証明システムと一致するか) と柔軟性 (複数のフロントエンドとバックエンドをサポートする) の間のバランスを取る必要があります。 IR がもともと R 1 CS のような低次数制約システムを解決するために設計されたものである場合、AIR などの他の高次制約システムとの互換性は困難です。

3. 効率を上げるには回路の手作りが必要

汎用モデルを使用する欠点は、複雑な命令を必要としない一部の単純な操作の効率が低いことです。

これまでの理論のいくつかを簡単に説明すると、

• ピノキオ プロトコル以前: 検証可能な計算が実現されましたが、検証時間は非常に遅かったです

• ピノキオプロトコル：検証可能性と検証成功率の点で理論的な実現可能性（つまり、検証時間がプログラムの実行時間より短い）を提供し、回路ベースのシステムです

• TinyRAM プロトコル: Pinocchio プロトコルと比較すると、TinyRAM は仮想マシンに似ており、ISA を導入しているため、メモリ アクセス (RAM) や制御フロー (制御フロー) などのいくつかの制限が取り除かれています。

• vnTinyRAM プロトコル: 鍵の生成を各プログラムから独立させ、さらなる汎用性を提供します。拡張された回路ジェネレーター。つまり、より大きなプログラムを処理できます。

上記のモデルはすべて、バックエンド プルーフ システムとして SNARK を使用していますが、特に仮想マシンを扱う場合には、基本的に STARK と Plonk の制約システムが CPU のようなロジックの実装により適しているため、バックエンドとしてより適切であると思われます。

次に、この記事では、Risc 0、MidenVM、CairoVM という 3 つの STARK ベースの仮想マシンを紹介します。つまり、両方とも STARK を証明システムとして使用することを除けば、それぞれにいくつかの違いがあります。

• Risc 0 は Risc-V を利用して命令セットを簡素化します。 R 0 は、Rust、C++ などのいくつかの既存の汎用プログラミング言語をサポートするように設計された LLVM-IR のバリアントである MLIR でコンパイルします。 Risc-V には、ハードウェアに優しいなどの追加の利点もあります。

• Miden は、本質的に EVM のロールアップである Ethereum Virtual Machine (EVM) との互換性を目指しています。 Miden は現在、独自のプログラミング言語を持っていますが、将来的には Move のサポートにも取り組んでいます。

• Cairo VM は Starkware によって開発されました。これら 3 つのシステムで使用される STARK 証明システムは、現在 Starkware の社長である Eli Ben-Sasson によって発明されました。

それらの違いを詳しく見てみましょう。

※上記フォームの読み方は？いくつかのメモ...

• ワード サイズ - これらの仮想マシンのベースとなる制約システムは AIR であるため、CPU アーキテクチャと同様に機能します。したがって、CPU ワード長 (32/64 ビット) を選択する方が適切です。

• メモリ アクセス (メモリ読み取り) - Risc 0 がレジスタを使用する理由は、主に Risc-V 命令セットがレジスタに基づいているためです。 AIR はスタックのように機能するため、Miden は主にデータの保存にスタックを使用します。 CairoVM は、Cairo モデルのメモリ アクセス (メイン メモリ) のコストが低いため、汎用レジスタを使用しません。

• プログラム フィード (プログラムの実行) - さまざまな方法にはトレードオフがあります。例えば、マストルート法は命令処理時にデコードする必要があるため、ステップ数の多いプログラムでは証明コストが高くなります。

• ブートローディングのアプローチでは、プライバシーを維持しながら証明者のコストと検証者のコストのバランスを取ろうとします。

• 非決定性 - 非決定性は NP 完全問題の重要な特性です。非決定論を活用すると、過去の実行を迅速に検証できます。その結果、制約がさらに追加されるため、検証にある程度の妥協が生じることになります。

• 複雑な操作の高速化 - 一部の計算は CPU 上で非常に遅く実行されます。たとえば、XOR や AND などのビット演算、ECDSA などのハッシュ プログラム、範囲チェックなどは、ほとんどがブロックチェーン/暗号化にネイティブですが、CPU ネイティブの演算ではありません (ビット演算を除く)。 DSL を介してこれらの操作を直接実装すると、証明のサイクルが枯渇してしまうことが容易に起こります。

• 順列/マルチセット (順列/複数列の組み合わせ) - ほとんどの zkVM で頻繁に使用され、2 つの目的があります - 1. 完全な実行トレース (実行トレース) のストレージを削減することで検証者のコストを削減します。 2. 検証者が知っていることを証明します。完全な実行トレース

記事の最後に、著者は Risc 0 の現在の開発状況と、Risc 0 が私を興奮させる理由について話したいと思います。

R 0 の現在の開発:

a. 自社開発の「Zirgen」コンパイラ インフラストラクチャは開発中です。 Zirgen のパフォーマンスを既存の zk 固有のコンパイラと比較してみると興味深いでしょう。

b. フィールド拡張などのいくつかの興味深い技術革新は、より強固なセキュリティ パラメータを実現し、より大きな整数を操作できます。

c. ZK Hardware 企業と ZK Software 企業の統合に見られる課題を目の当たりにして、Risc 0 はハードウェア側での開発を改善するためにハードウェア抽象化レイヤーを使用しています。

d.Still a work-in-progress! まだ開発中です!

• 手作りの回路と複数のハッシュ アルゴリズムをサポートします。現在、専用の SHA 256 回路が実装されていますが、すべての要件が満たされているわけではありません。どの回路を最適化するかの選択は、Risc 0 が提供するユースケースに依存すると著者は考えています。 SHA 256 は出発点として非常に適しています。一方、ZKVM は人々に柔軟性を提供するように位置付けられています。たとえば、Kecchak を使いたくない場合は気にしなくてもよいです :)

• 再帰: これは大きなトピックなので、このレポートでは深く掘り下げるつもりはありません。 Risc 0 はより複雑なユースケース/プログラムをサポートする傾向があるため、再帰の必要性がより緊急であることに注意してください。再帰をさらにサポートするために、現在、ハードウェア側の GPU アクセラレーション ソリューションに取り組んでいます。

• 非決定論への対処: これは ZKVM が対処しなければならない特性ですが、従来の仮想マシンにはこの問題はありません。非決定性により、仮想マシンのパフォーマンスが向上します。 MLIR は従来の仮想マシンの問題を扱うのに比較的優れており、Risc 0 が非決定論を ZKVM システム設計にどのように組み込むかは楽しみに値します。

WHAT EXCITES ME:

a. シンプルで検証可能！

分散システムでは、人々は他人を信頼しないため、PoW には高レベルの冗長性が必要です。そのため、合意に達するために同じ計算を繰り返し実行する必要があります。そして、ゼロ知識証明を利用することで、状態の実現は 1+1=2 に同意するのと同じくらい簡単になるはずです。

b. より実用的な使用例:

最も直接的な拡張に加えて、ゼロ知識機械学習やデータ分析など、より興味深いユースケースが実現可能になります。 Cairo などの特定の ZK 言語と比較して、Rust/C++ はより多用途かつ強力であり、より多くの Web2 ユースケースが Risc 0 VM 上で実行されます。

c. より包括的で成熟した開発者コミュニティ:

STARK とブロックチェーンに興味のある開発者は、DSL を再学習する必要はなく、Rust/C++ を使用するだけで済みます。