IOSG: ゼロ知識証明ハードウェアアクセラレーションに楽観的な理由

GPU はパフォーマンスの点では FPGA より優れていますが、FPGA はエネルギー消費の点では優位性があります。

執筆者：ブライアン、IOSGベンチャーズ

この記事では、主にスケーリング ソリューションとしての ZKP の現在の開発状況について説明し、証明生成プロセスで最適化する必要がある主な側面を理論レベルから説明し、さまざまなスケーリング ソリューションの加速要件について詳しく説明します。次に、ハードウェア ソリューションに焦点を当て、zk ハードウェア アクセラレーションの分野におけるムーアの法則を期待します。最後に、ハードウェア ZK アクセラレーションの分野におけるいくつかの機会と現在の状況について、記事の最後で説明します。まず、証明速度に影響を与える主な要素は、証明システム、証明する回路の規模、アルゴリズムのハードウェアとソフトウェアの最適化の 3 つです。

証明システムについては、楕円曲線 (EC) を使用するすべてのアルゴリズム、つまり Groth 16 (Zcash)、Galo2 (Scroll)、Plonk (Aztec、Zksync) などの市場で主流の zk-snark アルゴリズムは、現在、大きな数の乗算 (MSM) を含む多項式コミットメントを生成するプロセスで長時間かかる (高い計算能力が必要) というボトルネックがあります。 ZK-Stark などの FRI ベースのアルゴリズムの場合、多項式コミットメント生成方法はハッシュ関数であり、EC は使用されないため、MSM 操作は行われません。

証明システムは基礎であり、証明される回路の規模もハードウェア最適化の中核要件の 1 つです。最近話題になっている ZKEVM は、Ethereum との互換性のレベルが異なり、その結果、回路の複雑さのレベルも異なります。たとえば、Zksync/Starkware はネイティブ Ethereum とは異なる仮想マシンを構築し、zk 処理に適さない Ethereum 固有の基礎コードの一部をバイパスして、回路の複雑さを軽減しました。 Scroll/Hermez など、ボトムアップでの互換性を目指す zkevm の回路は、当然ながらより複雑になります。 （回路の複雑さは、バスの座席数に例えると分かりやすいです。例えば、普段は乗る乗客の数は30人未満です。バスによっては30人乗りを選ぶところもあります。こうしたバスはZksync/StarkWareです。また、1年のうちには特に乗客が多くなる日もあり、普通のバスでは対応できないので、座席を多く設計しているバスもあります（Scroll）。ただし、こうした日は乗客が少ないこともあり、平日は空席が多くなります。）ハードウェアアクセラレーションは、より複雑な回路設計の回路ほど緊急性が高いのですが、これはSpecturmの得意分野であり、ZKEVMにも有益です。

さまざまな証明システムの最適化の要件/焦点:

基本:

証明対象が回路（R1CS/QAP など）によって処理されると、スカラーとベクトルのセットが得られ、それを使用して多項式や内積引数（groth16）などの他の代数形式が生成されます。この多項式はまだ非常に長いです。証明を直接生成すると、証明のサイズと検証時間の両方が非常に大きくなります。したがって、この多項式をさらに簡略化する必要があります。ここでの最適化手法は多項式コミットメントと呼ばれ、多項式の特殊なハッシュ値として理解できます。代数ベースの多項式コミットメントには、KZG、IPA、DARK などがあり、いずれも楕円曲線を使用してコミットメントを生成します。

FRI は、コミットメントを生成する主な方法としてハッシュ関数を使用します。多項式コミットメントの選択は、主にセキュリティ、パフォーマンスなどいくつかの点を中心に行われます。ここでの安全性は主にセットアップ段階で考慮されます。秘密を生成するために使用されるランダム性が FRI のように公開されている場合、その設定は透過的であると言えます。秘密を生成するために使用されるランダム性が非公開であり、使用後に証明者によって破棄される必要がある場合、この設定は信頼される必要があります。 MPC はここでの信頼の問題を解決する手段ですが、実際のアプリケーションではユーザーが一定のコストを負担する必要があることがわかります。

前述のFRIは、セキュリティ面では比較的優れていますが、パフォーマンス面では理想的ではありません。同時に、ペアリングに適した楕円曲線のパフォーマンスは比較的優れていますが、再帰を追加すると、適切な曲線があまりないため、かなりのオーバーヘッドも発生します。

画像ソース: https://hackernoon.com

多項式コミットメントに関するジャスティン・ドレイクの講演、パート 1

業界の状況:

現在、Plonk (matterlabs) または Ultra-Plonk (Scroll、PSE) のどちらに基づいているかにかかわらず、最終的な多項式コミットメントは KZG に基づいているため、証明者の作業のほとんどは、大量の FFT 計算 (多項式の生成) と ECC ポイント乗算 MSM 操作 (多項式コミットメントの生成) を伴います。純粋な plonk モードでは、コミットする必要があるポイントの数が少なく、Prove 時間における MSM 操作の割合が高くないため、FFT パフォーマンスを最適化すると、短期的にはパフォーマンスが大幅に向上します。しかし、UltraPlonk（halo2）フレームワークでは、カスタマーゲートの導入により、証明フェーズで設計されるコミットポイントの数が増加し、MSM操作のパフォーマンス最適化も非常に重要になります。 (現在、MSM 操作が pippenger によって最適化された後でも、log(P(logB)) が必要です (B は exp の上限、p は MSM に参加するポイントの数です)。

新しい世代の Plonky2 証明システムでは、KZG ではなく、STARK システムで一般的な FRI が使用されています。これは、Plonky2 証明者が MSM を考慮する必要がなくなったことを意味します。理論的には、システムのパフォーマンス向上は、MSM 関連のアルゴリズムの最適化に依存しなくなります。 plonky2 の作者である Mir (現在は Polygon Zero) は、このシステムを積極的に推進しています。しかし、plonky2 が使用する数体 Goldilocks Field は、楕円関連のハッシュ アルゴリズム (ECDSA など) に関連する回路の記述に特に適しているわけではないため、Goldilocks Field にはマシン ワード操作における明らかな利点があるにもかかわらず、Mir と PSE/Scroll のどちらのソリューションが優れているかを判断するのは依然として困難です。

Plonk、Ultraplonk、Plonky2 の Prove アルゴリズムを総合的に考慮すると、ハードウェア アクセラレーションを必要とするモジュールは、FFT、MSM、HASH の 3 つの方向に集中する可能性が高くなります。

Prover のもう一つのボトルネックは、証人の生成です。通常の非 ZK 計算では、通常、多数の中間変数が省略されますが、ZK 証明プロセスでは、すべての証人を記録する必要があり、後続の FFT 計算に参加します。したがって、証人計算を効率的に並列化する方法も、証明マイナーが考慮する必要がある潜在的な方向性になります。

ZKP を高速化する試み: 再帰的証明 - StarkNet のフラクタル L3 コンセプトは再帰的証明の概念に基づいており、Zksync のフラクタル ハイパースケーリング、および Scroll にも同様の最適化があります。

> 再帰的 zkSNARK の概念は、証明 A の検証プロセスを証明し、それによって別の証明 B を生成することです。検証者が B を受け入れることができる限り、それは A を受け入れることと同等です。再帰的 SNARK は、複数の証明を集約することもできます。たとえば、A1 A2 A3 A4 の検証プロセスを B に集約します。再帰的 SNARK は長い計算プロセスをいくつかのステップに分解することもでき、各ステップの計算証明 S1 は次のステップの計算証明で検証される必要があります。つまり、1 つのステップを計算し、1 つのステップを検証してから、次のステップを計算します。これにより、検証者は最後のステップのみを検証し、不定の長さの大きな回路を構築するという困難を回避できます。

理論的には、すべての zkSNARK は再帰をサポートします。一部の zkSNARK スキームでは、回路を使用して Verifier を直接実装できますが、他の zkSNARK では、Verifier アルゴリズムを回路化しやすい部分と回路化しにくい部分に分割する必要があります。後者は、遅延集約検証の戦略を採用し、検証プロセスを検証プロセスの最後のステップに配置します。

L2 の将来のアプリケーションでは、再帰の利点により、証明を伴う帰納法を通じてコストとパフォーマンス要件をさらに削減できます。

最初のケース (アプリケーションに依存しない) は、状態の更新や Merkle ツリーなど、さまざまなことが証明される場合です。これら2つの証明は1つの証明にまとめることができますが、出力結果は2つあります（検証に使用される公開鍵）

2 番目のケース (応用再帰) は、同じ種類の事柄が証明される場合です。たとえば、両方が状態の更新である場合、証明を生成する前にこれら 2 つの事柄を集約することができ、出力結果は 2 回の更新後の状態の差である 1 つのみになります。 (Zksync のアプローチも同様で、ユーザーコストは状態の違いのみに影響します)

以下で説明する再帰的証明とハードウェア アクセラレーションに加えて、カスタム ゲート、FFT (OlaVM の理論的基礎) の削除など、ZKP を高速化する他の方法もありますが、この記事ではスペースの制約によりそれらについては説明しません。

ハードウェアアクセラレーション

ハードウェア アクセラレーションは、RSA (RSA の基礎となる数学的ロジックは楕円曲線のロジックに似ており、複雑な大規模演算も多数含まれています) や、zcash/filecoin の zk-snark の初期の GPU ベースの最適化方法など、暗号化における暗号証明を高速化するための一般的な方法でした。

ハードウェアの選択

イーサリアムの統合後、大量のGPUコンピューティングパワーが必然的に余剰となる（イーサリアムのコンセンサスの変化の影響もあり、GPU大手のNvidiaの株価は年初から50％下落しており、在庫の余剰も増加している）。下の図は、NvidiaのGPU主力製品であるRTX 3090の取引価格を示しており、これも買い手の力が比較的弱いことを示しています。

GPU の価格が低く、多くの GPU コンピューティング能力がアイドル状態にあるため、GPU が zk を高速化するのに適したハードウェアであるかどうかという疑問が自然に生じます。ハードウェアには、GPU/FPGA/ASIC という 3 つの主なオプションがあります。

FPGA と GPU

まずは概要を見てみましょう。以下は、trapdoor-tech による GPU (Nvidia 3090 を例に) と FPGA (Xilinx VU9P を例に) のいくつかの側面の概要です。非常に重要な点は、GPU はパフォーマンス (証明の生成速度) の点で FPGA よりも優れている一方で、FPGA はエネルギー消費の点で優れているということです。

より直感的な例は、Ingoyama の特定の操作結果です。

特に、より高いビット幅 (2^20) の操作では、GPU は FPGA よりも 5 倍高速ですが、消費電力ははるかに多くなります。

一般的なマイナーにとって、コストパフォーマンスもどのハードウェアを使用するかを決定する重要な要素です。 U55C（4795ドル）にしろ、VU9P（8394ドル）にしろ、GPU（RTX 3090：1860ドル）に比べると価格ははるかに高いです。

理論的には、GPU は並列コンピューティングに適しており、FPGA はプログラマビリティを追求していますが、これらの利点はゼロ知識証明生成の環境では完全には適用できません。例えば、GPU に適用可能な並列コンピューティングは、大規模なグラフィックス処理を目的としています。ロジックは MSM の処理方法に似ていますが、適用範囲 (浮動小数点数) が zkp が対象とする特定の有限体と一致しません。 FPGA の場合、複数の L2 が存在する場合のプログラマビリティのアプリケーション シナリオは明確ではありません。これは、L2 マイナーの報酬が単一の L2 によって実行される需要にリンクされていることを考慮すると (POW とは異なり)、セグメント化されたトラックで勝者がすべてを獲得する状況が発生する可能性があり、その結果、マイナーがアルゴリズムを頻繁に変更する必要がある可能性があるためです。

ASIC はパフォーマンスとコストのバランス（スループット、レイテンシなどを含む）に優れたソリューションですが、それが最適なソリューションであるかどうかはまだ不明です。問題点は次のとおりです:

開発期間が長い - チップの設計からチップの製造まで完全なプロセスが必要です。たとえチップが設計されていたとしても、チップの生産は時間がかかり、生産量が一定しない高価なプロセスです。ファウンドリリソースの点では、TSMC と Samsung が最高のチップファウンドリです。現在、TSMCの発注は2年後に予定されている。ファウンドリリソースをめぐって ZK チップと競合する製品は AI チップと電気自動車チップであり、これらは web2 が早期に設計し、需要が実証されている製品です。比較すると、ZK チップの需要は明確ではありません。

第二に、チップ全体のパフォーマンスは、20nm や 18nm と呼ばれることが多い単一チップのサイズと負の相関関係にあります。つまり、チップが小さくなればなるほど、ウェーハに収容できるチップの数が増え、チップ全体の性能が高くなります。現在、ハイエンドチップの製造技術は独占されています（例えば、チップ製造の最も複雑な部分であるリソグラフィー技術は、オランダのASMLによって独占されています）。一部の中小規模のファウンドリ（中国の SMIC など）では、この技術はトップクラスより 1 世代か 2 世代遅れており、歩留まり率とチップ サイズの点ではトップクラスのファウンドリに遅れをとっています。つまり、ZK チップの場合、最適ではないソリューションしか探すことができません。もちろん、需要側がそれほど明確でない場合は、コストを考慮して、28nm 前後の非ハイエンド チップを選択します。

現在の ASIC ソリューションは、ZK 回路で比較的高い計算能力を必要とする 2 つの一般的な演算子である FFT と MSM を主に処理します。特定のプロジェクト向けに設計されたものではないため、実際の運用効率は理論上最高にはなりません。例えば、Scroll の証明器の論理回路はまだ完全に実現されていないため、当然ながら、それに 1 つ 1 つ一致するハードウェア回路は存在しません。さらに、ASIC はアプリケーション固有であり、後続の調整をサポートしていません。ノードクライアントのアップグレードなど、ロジック回路の変更があった場合に、それにも対応できるソリューションがあるかどうかは現時点では不明です。

同時に、ZK チップ業界では人材不足も現実です。暗号化とハードウェアを理解している人を見つけるのは簡単ではありません。適切な候補者は、深い数学的知識と、ハードウェア製品の設計および保守における長年の経験の両方を備えた人です。

まとめ - 証明者開発動向EigenDA

以上が、ZKP を加速させるための業界の考えと試みです。究極的な意味は、証明者を実行するためのしきい値がどんどん低くなるということです。定期的に、証明者は次の 3 つの段階を経る必要があります。

フェーズ I: クラウドベースの証明者

クラウドベースの証明者は、Web2 の AWS/Google Cloud と同様に、サードパーティの証明者 (非ユーザー/プロジェクト関係者) の参入障壁を大幅に高めることができます。ビジネス モデルの観点から見ると、プロジェクト所有者はいくらかの報酬を失うことになりますが、分散化された物語の観点から見ると、これは経済レベルと実行レベルでより多くの参加者を引き付ける方法です。クラウド コンピューティング/クラウド サービスは、Web2 の既存のテクノロジー スタックです。開発者が利用できる成熟した開発環境があり、クラウド特有の低い敷居と高いクラスタリング効果を活かすことができます。短期的には証明アウトソーシングの選択肢となります。現在、Ingoyama もこの領域で実装を行っています (最新の F1 バージョンは pipeMSM のベンチマーク速度の 2 倍に達します)。ただし、これは依然として単一の証明者が証明全体を実行するのに対し、フェーズ II では、証明はより多くの参加者による分割可能な形式で存在できます。

フェーズ II: 証明者マーケットプレイス

証明生成のプロセスにはさまざまな操作が含まれ、効率を優先するものもあれば、コスト/エネルギー消費の要件があるものもあります。たとえば、MSM 計算には事前計算が含まれており、さまざまな事前計算のスカラー粒子をサポートするために一定量のメモリが必要になります。すべてのスカラーが 1 台のコンピューターに保存される場合、コンピューターのメモリ要件が高くなります。異なるスカラーが複数のサーバーに保存されると、このタイプの計算の速度が向上するだけでなく、参加者の数も増加します。

マーケットプレイスは、前述のアウトソーシングコンピューティングのビジネスモデルにおける大胆な考え方です。しかし実際には、暗号通貨の世界には前例があります。それは、異なるチェーン上の異なる取引ペアの価格フィードもマーケットプレイスの形で存在する Chainlink のオラクル サービスです。同時に、Aleo の創設者 Howard Wu 氏は、分散型台帳のゼロ知識証明生成方法である DIZK の共同著者でもあり、理論的には実現可能です。

そうは言っても、これはビジネスモデルの観点からは非常に興味深いアイデアですが、実際に導入するとなると実装に大きな困難が伴う可能性があります。たとえば、完全な証明を生成するためにこれらの操作を調整する方法には、時間とコストの点で少なくともフェーズ I と同等以上のものが必要です。

フェーズIII: 全員が証明器を実行する

将来的には、Prover はユーザー側 (Web 上またはモバイル上) でローカルに実行されるようになります。例えば、Zprize では、WebAssembly/Android 実行環境をベースにした ZKP アクセラレーション関連のコンテストや報酬が用意されており、ユーザーのプライバシーがある程度確保されることになります (現在の集中型証明器は拡張用であり、ユーザーのプライバシーを保証するものではありません)。最も重要なことは、ここでのプライバシーはオンチェーンの行動に限定されるのではなく、オフチェーンの行動も含まれるということです。

考慮しなければならない問題の 1 つは、Web 側のセキュリティです。 Web 側の実行環境は、ハードウェアよりも高いセキュリティ要件を備えています (業界の証人は、ハードウェア ウォレットよりも安全性が低い metmask などの Web ウォレットです)。

オンチェーンデータのオフチェーン証明に加えて、ユーザーのプライバシーを 100% 保護しながらオフチェーンデータを ZKP 形式でチェーンにアップロードすることは、このフェーズでのみ可能です。現在のソリューションは、必然的に次の 2 つの問題に直面します。1. 集中化​​。つまり、ユーザー情報が検閲されるリスクが依然として残ります。 2. 検証可能なデータ形式は単一です。オフチェーン データは多様かつ標準化されていないため、検証可能なデータ形式は単一の形式でありながら、多くのクリーニング/スクリーニングが必要になります。ここでの課題は、生成された環境を証明することだけではありません。また、アルゴリズムに互換性があるかどうか（最初に透過的なアルゴリズムを使用する必要があります）、およびコスト/時間/効率も考慮する必要があります。しかし、需要もまた前例のないほど大きいのです。検閲されるリスクなしに、分散型の方法で現実の信用を担保にして、チェーン上で借り入れや貸し出しができることを想像してみてください。