2024にはzkVMのプロトタイプが多く登場し、zkVMの未来を期待させる先駆けの1年となった。まず、なぜzkVMがこれほどまでに盛り上がっているのか。zkEVMとはどう違うのか。そして2025年にはどうなるのか。
zkVMの盛り上がり
まず、zkVMが盛り上がっているのはなぜだろうか。その背景として最も腑に落ちる説明は、zkSNARK開発言語の限界だ。今日、最も実用的なzkSNARKアプリケーションは言うまでもなくTornado Cashであるが、実はそれ以外に実用化されたアプリケーションは今のところ存在しない。ZKEmail、Myna、TLSNotaryが苦戦している背景には、RSA/ECDSA署名検証などの複雑な命題を実装するのがなかなか難しいからである。
zkVMはさながらzkSNARKの「コンパイラ」に近い。エンジニアがRustやTypeScriptを普段のアプリを開発し、ある変数をプライベート指定するだけでzkアプリケーションを開発することができるようになる。FacebookやTwitterが生まれた背景にJavaという高級言語の存在があったように。zkVMによって開発体験が大きく変わり、革新的なアプリケーションが生まれることが期待される。
その他にも、zkEVMのセキュリティ懸念がある。Linea、zkSync、Polygon zkEVMなどのzkEVMが2024年にローンチされたが、PSEはzkEVMの研究開発をストップした(おそらくScrollも)。その理由は記事の通り、zkVMのほうがセキュリティが安定するからだ。zkEVMはEVMの仕様アップデートに常に追随する必要があり、EVMの変更が目まぐるしい現段階では運用コストが高い。またEVMとRISC-Vのどちらがセキュリティバグが少ないかは明白だろう。zkVMでは、一度zkVMを開発し、セキュリティ保証を実施すれば、あとは安定的に運用することが可能となる。また、相互運用性の観点でもメリットがある。これらの点を踏まえると、将来zkEVMはzkVMに置き換えられるだろう。
2024のzkVM
2024に登場したzkVMは大きく4種類に分類できる。
-
STARK Family:「SP1」「RISC Zero」
SP1はPlonky3ベースのSTARKを採用しており、RISC ZeroはカスタムされたSTARKを採用している。どちらも拡大体上で計算することで、普通の有限体よりも小さいビット数で計算が可能である。しかし、証明集約とSTARK-to-SNARKの変換処理に大きな時間がかかることがデメリットだ。 -
Lookup Family: 「Jolt」
JoltはLasso Lookup Argumentを採用しており、命令を事前計算されたテーブルから取ってくる。そのテーブルを小さなサブテーブルにさらに圧縮することでテーブルサイズを小さくし、コミットメントする値が小さくて済む。しかし、テーブルを保存するために必要なメモリ使用量が大きくなる。 -
Folding Family: 「Nexus」
NexusはNova Folding Schemeを用いて命令ステップ同士のインスタンスを折り畳みながら証明を生成することで証明集約よりも効率的に証明を生成でき、またメモリ使用量も常に小さく一定で済む。Novaは並列化できないと非常に計算時間がかかる。またNexusはNexus VMという独自ISAを採用しており、これによってFolding Schemeの力を最大限発揮できるようにしている反面、プログラムの汎用性に限界がある。 -
GKR Family: 「Ceno」
CenoはGKRを持ちいて、命令回路の入出力だけをコミットし、中間結果はSumcheck Protocolで証明することでコミットメントをスキップすることができる。
主にこれらの4種類が確立されたのが2024だった。しかし現状、大きいプログラムに対しての証明は60分ほどかかる。これは実行継続(Execution Continuation)という並列化手法を用いても、効率化には限界がある。これを10分以下、あるいは10秒以下にするためにさらに証明システムのベースパフォーマンスを革新するのが今年の焦点になるだろう。
2025のzkVM
そして下図の白枠で示している部分が2025に登場するであろうzkVMアプローチだ。主に複合的アプローチの確立が焦点となる。
- STARK + Folding (LatticeFold, CircleSTARK)
STARKの主なボトルネックである証明集約、SNARK-to-STARKの効率化にFolding Schemeを用いる。これにより、SP1、RISC Zeroは10~100倍の高速化が見込まれる。 - Lookup + Folding (NeutronNova)
Joltの主なボトルネックであるメモリ使用量を解決するためにも、Lookup証明を効率的に集約するスキームが必要だ。2024に提案されたNeutronNovaやFLIの実装がフォーカスされるだろう。これによりJoltも並列化パフォーマンスが向上し、100倍は高速になるだろう。 - Others: New STARK, new GKR, GKR + STARK?
とくにSTARKとGKRはまだまだ改善の余地が見られる。2025にさらなる効率的な証明システムの提案がされる可能性は高い。またGKR vs STARKという点で見られがちだが、これらの複合アプローチが提案される可能性もある。そうすればSTARKで計算時間のかかるハッシュ関数の実行が省略され、100倍以上は高速になるだろう。
その他の大きな課題も、2025の研究における焦点となる。たとえば実行継続では実行トレースをいくつかのセグメントに分割する必要があるが、この分割を均等にする方法にはまだまだ改善の余地がある。
引用: https://drive.google.com/file/d/1aTCELr2b2Kc1NS-wZ0YYLKdw1Y2HcLTr/view?pli=1
これらが2025内に解決されると証明生成時間が1分を切り、4GBメモリしか必要なくなる世界線も見えてくる。そうなったら本格的にライトクライアントなどのアプリケーションで実証実験が始まるだろう。