Celer：万神殿 Pantheon - ZKP開発フレームワーク評価プラットフォーム
本文は、SHA-256がさまざまなzk-SNARKおよびzk-STARK開発フレームワークにおける性能テスト結果を包括的に説明しています。著者：Celer
過去数ヶ月、私たちは大量の時間と労力を投入し、zk-SNARKの簡潔な証明を利用して構築された最前線のインフラを開発しました。この次世代の革新プラットフォームは、開発者が前例のないブロックチェーンアプリケーションの新しいモデルを構築できるようにします。
開発作業の中で、私たちはさまざまなゼロ知識証明（ZKP）開発フレームワークをテストし、使用しました。この旅は非常に有意義でしたが、新しい開発者が特定のユースケースや性能要件に最適なフレームワークを見つけようとする際に、多様なZKPフレームワークがしばしば課題をもたらすことも実感しました。
この痛点を考慮し、私たちは包括的な性能テスト結果を提供できるコミュニティ評価プラットフォームが必要であると考えました。これにより、これらの新しいアプリケーションの開発が大いに促進されるでしょう。
このニーズに応えるために、私たちはゼロ知識証明開発フレームワーク評価プラットフォーム「万神殿 Pantheon」を立ち上げました。この公益コミュニティの取り組みの第一歩は、コミュニティがさまざまなZKPフレームワークの再現可能な性能テスト結果を共有することを奨励します。私たちの最終目標は、低レベルの回路開発フレームワーク、高度なzkVM、コンパイラ、さらにはハードウェアアクセラレーターを評価するための広く認められたテストプラットフォームを共同で作成し、維持することです。
私たちは、この取り組みが開発者がフレームワークを選択する際に、より多くの性能比較の参考を提供し、ZKPの普及を加速することを期待しています。また、一般的に参照可能な性能テスト結果を提供することで、ZKPフレームワーク自体のアップグレードとイテレーションを促進したいと考えています。この計画に大いに取り組み、志を同じくするコミュニティメンバー全員を招待し、この作業に貢献していただきたいと思います！
第一歩：SHA-256を使用した回路フレームワークの性能テスト
この記事では、ZKP Pantheonを構築する第一歩を踏み出し、一連の低レベル回路開発フレームワークにおいてSHA-256を使用して再現可能な性能テスト結果を提供します。他の性能テストの粒度や原語も実行可能であることは認めますが、SHA-256を選択した理由は、ブロックチェーンシステム、デジタル署名、zkDIDなど、幅広いZKPユースケースに適しているからです。
また、私たちのシステムでもSHA-256を使用しているため、非常に便利です！ ?
私たちの性能テストは、SHA-256がさまざまなzk-SNARKおよびzk-STARK回路開発フレームワークでの性能を評価しました。比較を通じて、各フレームワークの効率と実用性に関する洞察を開発者に提供することを目指しています。私たちの目標は、この性能テスト結果が開発者が最適なフレームワークを選択する際の参考となり、賢明な決定を下す手助けとなることです。
証明システム
近年、ゼロ知識証明システムが急増しています。この分野のすべてのエキサイティングな進展に追いつくことは挑戦的であり、私たちは成熟度と開発者の採用状況に基づいて、以下の証明システムをテスト対象として慎重に選びました。私たちの目標は、異なるフロントエンド/バックエンドの組み合わせの代表的なサンプルを提供することです。
++Circom+++ ++snarkjs++/ ++rapidsnark++: Circomは、回路を記述し、R1CS制約を生成するための人気のDSLであり、snarkjsはCircomのためにGroth16またはPlonk証明を生成できます。RapidsnarkもCircomの証明器であり、Groth16証明を生成しますが、ADX拡張を使用しているため、通常snarkjsよりもはるかに高速で、可能な限り証明生成を並列化します。
++gnark++: gnarkは、Consensysからの包括的なGolangフレームワークで、Groth16、Plonk、および多くの高度な機能をサポートしています。
++Arkworks++: Arkworksは、zk-SNARKsのための包括的なRustフレームワークです。
++Halo2 (KZG)++: Halo2は、ZcashとPlonkのzk-SNARK実装です。高度に柔軟なPlonkish算術を備えており、カスタムゲートやルックアップテーブルなど、多くの便利な原語をサポートしています。私たちは、Ethereum FoundationとScrollのサポートを受けたKZGのHalo2フォークを使用しています。
++Plonky2++: Plonky2は、Polygon ZeroのPLONKおよびFRI技術に基づくSNARK実装です。Plonky2は小さなGoldilocksフィールドを使用し、高効率の再帰をサポートします。私たちの性能テストでは、100ビットの推測された安全性を目指し、性能テスト作業で最適な証明時間を生成するパラメータを使用しました。具体的には、28のMerkleクエリ、8の拡大係数、16ビットの作業証明チャレンジを使用しました。さらに、numofwires = 60およびnumroutedwires = 60を設定しました。
++Starky++: StarkyはPolygon Zeroの高性能STARKフレームワークです。私たちの性能テストでは、100ビットの推測された安全性を目指し、最適な証明時間を生成するパラメータを使用しました。具体的には、90のMerkleクエリ、2倍の拡大係数、10ビットの作業証明チャレンジを使用しました。
下表は、上記のフレームワークと私たちの性能テストで使用した関連構成をまとめたものです。このリストは決して網羅的ではなく、今後も多くの最先端のフレームワーク/技術（例：Nova、GKR、Hyperplonk）を研究する予定です。
これらの性能テスト結果は、回路開発フレームワークにのみ適用されることに注意してください。今後、異なるzkVM（例：Scroll、Polygon zkEVM、Consensys zkEVM、zkSync、Risc Zero、zkWasm）およびIRコンパイラフレームワーク（例：Noir、zkLLVM）の性能テストに関する別の記事を公開する予定です。
性能評価方法論
これらの異なる証明システムの性能テストを行うために、NバイトのデータのSHA-256ハッシュ値を計算しました。ここで、N = 64、128、…、64Kについて実験を行いました（Starkyは例外で、回路はSHA-256の固定64バイト入力の計算を繰り返しますが、同じメッセージブロックの総数は維持します）。性能コードとSHA-256回路構成は++このリポジトリ++で見つけることができます。
さらに、以下の性能指標を使用して各システムの性能テストを行いました：
証明生成時間（証明生成時間を含む）
証明生成中のメモリ使用ピーク
証明生成中の平均CPU使用率のパーセンテージ（この指標は、証明生成プロセスの並列化の程度を反映します）
証明サイズと証明検証コストについては、これらの側面がGroth16またはKZGと組み合わせることで軽減できるため、いくつかの「随意」の仮定を行っていることに注意してください。
マシン
私たちは、2台の異なるマシンで性能テストを実施しました：
Linuxサーバー：20コア @2.3 GHz、384GBメモリ
Macbook M1 Pro：10コア @3.2Ghz、16GBメモリ
Linuxサーバーは、CPUコア数が多く、メモリが豊富なシナリオをシミュレートするために使用されました。一方、通常は研究開発に使用されるMacbook M1 Proは、より強力なCPUを持っていますが、コア数は少ないです。
オプションのマルチスレッドを有効にしましたが、この性能テストではGPUアクセラレーションは使用していません。今後、GPU性能テストを行う予定です。
性能評価結果
制約数
詳細な性能テスト結果を議論する前に、まず各証明システムにおける制約数を確認することでSHA-256の複雑性を理解することが有用です。異なる算術スキーム間で制約数を直接比較することはできないことに注意することが重要です。
以下の結果は、64KBの原像サイズに対応しています。他の原像サイズによって結果が異なる可能性がありますが、大まかに線形スケーリングできます。
Circom、gnark、Arkworksは同じR1CSアルゴリズムを使用しており、64KB SHA-256のR1CS制約数はおおよそ30Mから45Mの範囲です。Circom、gnark、Arkworks間の差異は、構成の違いによる可能性があります。
Halo2とPlonky2はPlonkish算術を使用しており、行数は2^22から2^23の範囲です。ルックアップテーブルを使用しているため、Halo2のSHA-256実装はPlonky2よりもはるかに効率的です。
StarkyはAIRアルゴリズムを使用しており、実行トレーステーブルには2^16の変換ステップが必要です。
証明生成時間
[図 1]は、LinuxサーバーでSHA-256の各フレームワークがさまざまな原像サイズでの証明生成時間をテストした結果です。以下の発見が得られました：
SHA-256に関して、Groth16フレームワーク（rapidsnark、gnark、Arkworks）はPlonkフレームワーク（Halo2、Plonky2）よりも証明生成が速いです。これは、SHA-256が主にビット演算で構成されており、線形値が0または1であるためです。Groth16の場合、これにより楕円曲線スカラー乗算から楕円曲線点加算への計算の大部分が削減されます。しかし、連線値はPlonkの計算には直接使用されないため、SHA-256の特別な連線構造はPlonkフレームワークに必要な計算量を削減しません。
すべてのGroth16フレームワークの中で、gnarkとrapidsnarkはArkworksやsnarkjsよりも5倍から10倍速いです。これは、複数のコアを利用して証明生成を並列化する卓越した能力によるものです。Gnarkはrapidsnarkよりも25%速いです。
Plonkフレームワークに関しては、>= 4KBの大きな原像サイズを使用する場合、Plonky2のSHA-256はHalo2のものよりも50%遅いです。これは、Halo2の実装が主にルックアップテーブルを使用してビット演算を加速しているため、行数がPlonky2のものよりも2倍少ないからです。しかし、行数が同じPlonky2とHalo2（例えば、Halo2の2KBを超えるSHA-256とPlonky2の4KBを超えるSHA-256）を比較すると、Plonky2はHalo2よりも50%速いです。Plonky2でルックアップテーブルを使用してSHA-256を実装した場合、Plonky2がHalo2よりも速いことを期待すべきですが、Plonky2の証明サイズは大きくなります。
一方、入力原像サイズが小さい（\<=512バイト）場合、ルックアップテーブルの固定設定コストが大部分の制約を占めるため、Halo2はPlonky2（および他のフレームワーク）よりも遅くなります。しかし、原像が増加するにつれて、Halo2の性能は競争力を持ち、最大2KBの原像サイズに対しては証明生成時間がほぼ線形に拡張されます。
予想通り、Starkyの証明生成時間はどのSNARKフレームワークよりもはるかに短く（5倍から50倍）、ただし、これはより大きな証明サイズの代償です。
さらに注意すべき点は、回路サイズが原像サイズと線形関係にある場合でも、O(nlogn) FFTのため、SNARKの証明生成は超線形に増加することです（ただし、対数スケールのため、この現象はグラフ上では明らかではありません）。
私たちはまた、Macbook M1 Proで証明生成時間の性能テストを実施しました。[図 2]に示されています。ただし、arm64アーキテクチャのサポートが不足しているため、rapidsnarkはこの性能テストに含まれていないことに注意してください。arm64でsnarkjsを使用するためには、WebAssemblyを使用して証明を生成する必要があり、これはLinuxサーバーで使用されるC++証明生成よりも遅くなります。
Macbook M1 Proで性能テストを実行する際のいくつかの追加の観察結果は以下の通りです：
Starkyを除いて、すべてのSNARKフレームワークは原像サイズが大きくなるとメモリ不足（OOM）エラーやスワップメモリの使用（証明時間の遅延を引き起こす）に直面します。具体的には、Groth16フレームワーク（snarkjs、gnark、Arkworks）は原像サイズ>= 8KBでスワップメモリを使用し始め、gnarkは原像サイズ>= 64KBでメモリ不足に陥ります。原像サイズ>= 32KBのとき、Halo2はメモリ制限に直面しました。原像サイズ>= 8KBのとき、Plonky2はスワップメモリを使用し始めます。
FRIベースのフレームワーク（StarkyとPlonky2）は、Macbook M1 ProでLinuxサーバーよりも約60%速く、他のフレームワークは両方のマシンでの証明時間が似ています。したがって、Plonky2でルックアップテーブルを使用していなくても、Macbook M1 ProでHalo2とほぼ同じ証明時間を実現しました。主な理由は、Macbook M1 Proがより強力なCPUを持っているが、コア数が少ないためです。FRIは主にハッシュ計算を行い、CPUクロックサイクルに敏感ですが、KZGやGroth16ほどの並列性はありません。
メモリ使用ピーク
[図 3]と[図 4]は、それぞれLinuxサーバーとMacbook M1 Proで証明生成中のメモリ使用ピークを示しています。これらの性能テスト結果に基づいて、以下の観察結果が得られました：
すべてのSNARKフレームワークの中で、rapidsnarkはメモリ効率が最も高いです。また、ルックアップテーブルの固定設定コストのため、原像サイズが小さいときはHalo2がより多くのメモリを使用しますが、原像サイズが大きいときは全体的に消費するメモリが少なくなります。
Starkyのメモリ効率はSNARKフレームワークよりも10倍以上高いです。その一因は、行数が少ないためです。
原像サイズが大きくなるにつれてスワップメモリを使用するため、Macbook M1 Proでのメモリ使用量のピークは比較的安定しています。
CPU利用率
SHA-256の4KB原像入力の証明生成中の平均CPU利用率を測定することで、各証明システムの並列化の程度を評価しました。下表は、Linuxサーバー（20コア）とMacbook M1 Pro（10コア）での平均CPU利用率を示しています（括弧内は各コアの平均利用率）。
主な観察結果は以下の通りです：
GnarkとrapidsnarkはLinuxサーバーで最高のCPU利用率を示し、マルチコアを効果的に使用し、証明生成を並列化できることを示しています。Halo2も良好な並列化性能を示しました。
大多数のフレームワークは、LinuxサーバーでのCPU利用率がMacbook Pro M1の2倍であり、snarkjsのみが例外です。
FRIベースのフレームワーク（Plonky2とStarky）がマルチコアを効果的に使用するのが難しいと最初は予想されましたが、私たちの性能テストでは、これらのフレームワークのパフォーマンスは一部のGroth16またはKZGフレームワークと同等でした。より多くのコア（例えば100コア）のマシンでCPU利用率に差が出るかどうかは今後の課題です。
結論および今後の研究
この記事は、SHA-256がさまざまなzk-SNARKおよびzk-STARK開発フレームワークでの性能テスト結果を比較的包括的に説明しています。比較を通じて、各フレームワークの効率と実用性について深く理解し、SHA-256操作のために簡潔な証明を生成する必要がある開発者を支援することを目指しています。
私たちは、Groth16フレームワーク（例：rapidsnark、gnark）がPlonkフレームワーク（例：Halo2、Plonky2）よりも証明生成が速いことを発見しました。Plonkish算術におけるルックアップテーブルは、大きな原像サイズを使用する際にSHA-256の制約と証明時間を大幅に削減します。さらに、gnarkとrapidsnarkはマルチコアを利用して並列化する優れた能力を示しました。一方、Starkyの証明生成時間ははるかに短いですが、その代償として証明サイズは大きくなります。メモリ効率の面では、rapidsnarkとStarkyが他のフレームワークよりも優れています。
ゼロ知識証明評価プラットフォーム「万神殿 Pantheon」を構築する第一歩として、私たちは今回の性能テスト結果が最終的に構築したい包括的なテストプラットフォームには遠く及ばないことを認識しています。私たちはフィードバックや批判を歓迎し、すべての人がこの取り組みに貢献できるよう招待します。これにより、開発者がゼロ知識証明をより簡単に、低いハードルで使用できるようになることを目指しています。また、個人の独立した貢献者に対して、大規模な性能テストの計算リソースコストを支払うための資金提供も行います。私たちは、ZKPの効率と実用性を共に向上させ、コミュニティに広く恩恵をもたらすことを期待しています。
最後に、Polygon Zeroチーム、Consensysのgnarkチーム、Pado Labs、Delphinus Labチームに感謝し、性能テスト結果に対する貴重なレビューとフィードバックに感謝します。
