a16z：Jolt zkVM に関する考察と説明
TechFlow厳選深潮セレクト
a16z：Jolt zkVM に関する考察と説明
zkVMのコストは、特定のアプリケーションの特性ではなく、主にサイクル数に依存するということは、小さな奇跡と言える。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Justin Thaler、a16z リサーチパートナー
翻訳：xiaozou、金色財経
昨年夏のテーマ論文およびLasso導入以降、先月の完全オープンソースなJolt実装のリリースに至るまで、我々は一貫してLasso+Jolt（革新的でシンプルかつ高性能なlookup argumentおよびzkVM）技術の研究開発を進め、着実な進展を遂げてきました。
既存技術と比較しても、この実装はJoltの明るい将来性を示しており、SNARK設計における多くの従来の常識に挑戦しています。リリース以降も継続的に更新を重ね、Rust標準ライブラリのサポートを追加し、10名以上の貢献者による改良を取り込み、約50件のpull requestをマージするとともに、コードベースのモジュール性、パフォーマンス、拡張性を向上させました。
Joltのさらなる強化を進める一方で、外部からの疑問や誤解に対して応えるとともに、いくつかの重要な課題について私の見解を共有したいと思います。本稿では以下の四つのトピックを扱います。（1）sum-checkプロトコルとBiniusコミットメント方式の関係、（2）Joltにおけるsum-checkとlookupsの役割、（3）楕円曲線とハッシュ、（4）zkVMに関連するプリコンパイルについてです。
1. Sum-checkプロトコルとBiniusコミットメント方式
コミットメント方式は通常、SNARKのキーコンポーネントと見なされています。しかし、もう一つ同様に重要な構成要素があります。それは多項式IOP（Interactive Oracle Proof）です。たとえば、多線形多項式に基づくBiniusコミットメント方式は大きな進歩ですが、それが実際に証明者の主張を検証できることを保証するためには、多項式IOPと組み合わせる必要があります。
Biniusのコミットメント方式は、sum-checkプロトコルを使用するPIOPと非常に高い互換性を持っています。その理由は明確です（sum-checkは単一変数多項式ではなく多線形多項式に依存しており、FRI-Biniusでさえ内部的にsum-checkを利用している）。また、より繊細な点として、sum-check PIOPは任意の標数体上で自然に動作するため、これはBiniusの新性能を最大限に活用するために不可欠です。一方、現在最も一般的なPIOPとは互換性がなく、残念ながらそれらはsum-checkを使用していません。
高速なPIOPを設計するには、「sum-checkを使う」という言葉以上の洞察が必要です。Biniusはsum-checkプロトコルを用いて効率的な多項式IOPを実現しています。Binius論文の第4および第5章は、コミットメント方式と統合可能な新しい効率的なsum-checkベースのPIOPの設計に捧げられています。
Biniusのコミットメント方式とJoltの相性は、ピーナッツバターとジャムのように抜群です。なぜならJoltは現時点で唯一、完全にsum-checkプロトコルに依存するzkVMだからです。現在Joltは楕円曲線暗号に基づくコミットメント方式を使用していますが、Biniusコミットメント方式の統合は我々の最優先事項です。
2. Sum-check、lookups、パフォーマンス、簡潔性
Joltを他と差別化しているのは何でしょうか？ Joltが最初であり、そして現時点では唯一の、sum-checkベースの多項式IOPを専用に使用するzkVMであるからか？ あるいは、ほぼすべての処理を制約（constraint）システムや回路ではなくlookupsによって行う「lookup特異点」を実現したからか？ 答えは両方です。先行するzkVMと比較して、Joltの簡潔性の大部分はlookupsに由来し、パフォーマンス上の利点はlookupsとsum-checkの組み合わせによるものです。
純粋なlookupアプローチは、非常に小さな回路を持たない命令にとっては有利ですが、非常に小さな回路を持つ他の命令にとっては逆に不利になる可能性もあります。しかし全体としては、少なくとも256ビット体においては、純粋なlookupアプローチはパフォーマンスに対して悪影響を与えることはありません。現在、Joltのproverは20%の時間を「命令実行」のlookupに、40%の時間を制約の検証に費やしています。lookupの数を減らすためにさらに制約を追加しても何の意味もありません。
大まかに言えば、JoltはCPUのフェッチ・デコード・実行サイクルの「フェッチ」と「実行」部分にlookupを使用しています。これらのlookupは十分に高速であり、結果としてproverの大部分の時間が「デコード」の実行証明に費やされることになります。これは従来の制約システムによって処理されます。
純粋なlookupアプローチは、より簡潔で監査しやすい実装を促進します。こうした利点は定量化が難しく、時間とともにしか認識されません。しかし、コード行数（Joltのコードベースは約2.5万行で、先行するRISC-V zkVMより2〜4倍少ない）や開発期間といった観点では、Joltは顕著な成果を上げています。このような改善はパフォーマンスの向上よりもはるかに難しいものです。今後数ヶ月でzkVMのprover速度が2023年8月比で約100倍になると考えられますが、zkVMのコード行数が10倍減少する日が来るとは到底想像できません。
3. 楕円曲線
公共の議論では、楕円曲線向けの高速zkVMの利点が過小評価されています。これは一部、Biniusのようなハッシュベースのコミットメント方式に対する熱意の高さに起因しています。
楕円曲線暗号に関する主張を証明する際、楕円曲線ベースのzkVMは非ネイティブ体アルゴリズムを回避できます。非ネイティブ体アルゴリズムは証明時間に数百倍から数千倍のオーバーヘッドを生じさせるため、これは重要です。該当する用途には、多数のデジタル署名（ブロックチェーンライトクライアントやSNARKベースのブリッジの主要タスク）、Plonk/Groth16/Nova/Honk証明の集約、Verkle木認証パスの証明などが含まれます。
私は楽観的に考えています。コミュニティは、多くのアプリケーションにおいてSNARKを実行する正しい方法として、sum-checkベースのPIOPとFRI-Biniusコミットメント方式の組み合わせに注目することになると。仮にそうなったとしても、世界中が完全に楕円曲線暗号を放棄しない限り（例えば社会全体が非量子安全な暗号システムから移行した後でなければ）、高速な楕円曲線ベースのSNARKは依然として有用です。
まとめ：
楕円曲線ベースのコミットメント方式は、現存する他のすべてのzkVMと競合します（他のすべてのzkVMはすでに小規模体向けにハッシュコミットメント方式を使用しています）。
楕円曲線に関する主張を証明する際には（少なくとも非ネイティブ体アルゴリズムに画期的な進展がない限り）、楕円曲線を組み込んだJoltを使用したいと考えるでしょう。
純粋なzkVMとして、JoltとBiniusコミットメント方式の組み合わせは、他の代替案よりもはるかに高速になります。ただし、楕円曲線に関する主張の証明や小規模体の証明の場合には、楕円曲線対応のJoltを使用するでしょう。それ以外の場合は、JoltとBiniusコミットメント方式の組み合わせが選ばれます。
チェーン上に証明を公開する前に、証明サイズと検証コストを圧縮するために、楕円曲線ベースのSNARKは引き続き使用されます。この場合、大規模体を扱うzkVMが役立ちます。今日においてさえ、ハッシュベースのzkVMプロジェクトが実際にはBN254曲線上で定義されたzkVMを再帰プロセスの一部として使用していると考えられています。
4. プリコンパイルとzkVMベンチマーク
プリコンパイルおよびそれがzkVMやベンチマークにおいて果たす役割については、すでにいくつかの議論があります。説明に入る前に、まず「プリコンパイル」とは何であるかを説明しておくとよいでしょう。というのも、「プリコンパイル」という語は文脈により異なる意味を持つためです。
（1）イーサリアムにおける「プリコンパイル」
イーサリアム仮想マシン（EVM）において、プリコンパイルとは頻繁に実行される操作であり、効率を高めるためにネイティブにサポートされています。これにより、冗長なEVMオペコード列を通じてこれらの操作を実行する際に発生する大きなオーバーヘッドと過度なガスコストを回避できます。
「EVMプリコンパイル」と「基本命令」（オペコード）の違いは、主に意味論的なものです。たとえば、Keccakハッシュ関数はEVMのオペコードですが、SHA-2はEVMプリコンパイルです。プリコンパイルもオペコードも、いずれも頻繁に実行される操作であり、イーサリアムは同じ目的——効率とガスコストの最適化——のためにこれらをネイティブにサポートしています。確かにプリコンパイルはEVMの一部であり、EVMという語は通常、オペコード以上に広範なイーサリアム実行環境を指すのに使われます。
EVMの機能がオペコードと基本的に同じなのに、なぜプリコンパイルが必要なのでしょうか？ 主に慣例の問題です。別の可能性として、将来的に変更が必要になるかもしれない暗号プリミティブなど、比較的複雑な操作で構成されるため、オペコードを割り当てずにおけば将来の変更が容易になる、という点が挙げられます。
（2）zkVM設計における「プリコンパイル」
zkVM設計において、プリコンパイルとは特定の関数（KeccakやSHAハッシュなど）または特定の楕円曲線操作のグループに対して特別に最適化されたSNARKを指します。現在のSNARKプリコンパイルは、通常手動で最適化された制約システムによって実現されています（ただし、コミュニティがsum-checkベースのSNARKへ移行するにつれて、これらの制約システムの性質および証明方法も変わるでしょう）。
EVMプリコンパイルとzkVMプリコンパイルには深い類似性があります。Joltのリリース以前、zkVMは各命令ごとに手動で最適化された制約システムを用いて基本命令を実装していました。これはまさにプリコンパイルの実装方法と同じでした。つまり、いわゆるzkVMプリコンパイルと基本命令との違いは、純粋に意味論的なもので、実際の差異はありません。
Joltでは、伝統的な制約システムを使わず、lookupsによって基本命令を実装しています。ただし、一部の基本命令を制約によって実装することを選んでも、特に問題はありません。（実際、lookups自体も一種の制約と見なせます。）実際、前述したように、Biniusコミットメント方式に移行する際には、RISC-Vの加算や乗算に対して伝統的な制約を使用せざるを得なくなるかもしれません。
5. zkVMベンチマーク
以上の背景を踏まえ、zkVMおよびベンチマークに関連するプリコンパイルについて私の見解を述べます。
まず、プリコンパイルなしでさまざまなRISC-V zkVMをベンチマークすることは、まさにRISC-V zkVMのベンチマークの本質です。「zkVM」という語は非公式な呼び名であるため、必然的に解釈の分かれ目が生じますが、私見では、一つ以上のプリコンパイルを持つRISC-V zkVMはもはやRISC-VのzkVMではなく、各プリコンパイルを基本命令として追加した新しい命令セットのzkVMとなります。少なくとも、zkVMに追加される各プリコンパイルは、zkVMパラダイムの価値提案を弱めます。新たな回路が追加されるたびに潜在的なバグ表面積が増加し、既存のプログラムはこれらの新しいプリコンパイルをそのまま利用できなくなります。
また、一部の人々はzkEVMのEVMプリコンパイルの概念と、zkVMのプリコンパイル概念を混同しています。しかし、これらはまったく異なるものです。zkEVMのいくつかの主要操作——Merkleハッシュやデジタル署名の検証など——は確かに初期のRISC-V命令よりも複雑ですが、それによってEVMプリコンパイルと初期EVM命令の間に機能的な差異が生じるわけではありません。zkEVMはEVMと同等であることを主張するために、EVMプリコンパイルをサポートしなければなりません。言い換えれば、EVMプリコンパイルをサポートしないzkEVMは、JoltのようなRISC-V zkVMとは異なり、RISC-Vを超えてプリコンパイルによって命令セットを拡張するものではありません。
もう一つの問題は、zkVMのベンチマークに用いる「公平な」関数セットをどう選ぶかです。しかしRISC-V zkVMの場合、どの関数セットでも公平です。Proverの時間はほとんど完全にRISC-V CPUの実行サイクル数に依存するからです。理由は二つあります。第一に、proverは「フェッチ・デコード・実行」サイクルの「実行」部分にごく短い時間しか費やしません。第二に、異なるRISC-V命令やメモリアクセスの証明時間は非常に似通っています。（Joltでは、これらすべてがオフラインメモリチェック技術で処理されます。）
最後に、プリコンパイルを使用した場合、Joltのパフォーマンスが他の代替案より劣ることはないでしょう。実際、sum-checkベースのプリコンパイルが最も高速になり、Joltにオーバーヘッドなく統合可能であるため、むしろより良い結果になると予想されます。ここで懸念されるのは、楕円曲線コミットメント方式を使用するプリコンパイルが、ハッシュベースの方式に比べて大幅に劣るのではないかということです。現在Joltは楕円曲線を使用していますが、これは必須ではなく、我々は常にBiniusへの移行計画に対してオープンです。
6. ベンチマークに関する広範な考察
我々がベンチマークを行う主な目的は、異なる証明システム間の本質的なパフォーマンス特性を、ある程度実装から切り離して明らかにすることにあります。このアプローチにより、コミュニティは高性能かつ安全なSNARKを設計するための正しい技術に注力し、理解を深めることができます。しかし、2つの異なるSNARKを比較しようとするとき、数え切れないほどの混乱要因が存在し、厳密な比較が不可能になることがよくあります。
工学的努力もそのような混乱要因の一つです。にもかかわらず、コミュニティの多くの人々は逆の立場を取っているように見えます。考え方としては、あるプロジェクトが特定ハードウェア向けのプリコンパイルや最適化といった「機能」を追加すれば、いかなるベンチマークにおいても「名誉ある」結果を得るべきだ、というものです。
両方の見解にはそれぞれ妥当性があります。しかし長期的には、後者の見解は明らかに持続不可能です。新しい手法は、旧来のプロジェクトと比べて開発期間が短いため、あらゆるベンチマークで常に不利な立場に置かれ続けます。このような見方は、進歩を阻害するものです。
時間の経過とともに、ベンチマークに伴う混乱要因は減少していくと予想されます。SNARK開発ツールが成熟すれば、良好なパフォーマンスを得るために必要な工学的努力の量は少なくなります。zkVMのコストは特定アプリケーションの特性ではなく、主にサイクル数に依存する——これは奇跡的なこと（少なくともRISC-Vに関しては）です。もし人々が制約システムの選択（現在のR1CS、AIR、Plonkishなどの断片化された状態ではなく）に注目するようになれば、制約システムサイズの簡単な尺度がサイクル数に代わって、制約システム向けSNARKにも同様の状況が生まれるかもしれません。
それまでは、混在要因の不足と過剰な制御の間で適切なバランスを取ることは困難です。意見の相違は避けられず、開発者たちはコミュニティが理解し議論できるように、各ベンチマークの背後にある全容、詳細、根拠を提供する責任があります。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
a16z
