Celer「Pantheon」の詳細説明：ゼロ知識証明開発フレームワーク評価プラットフォーム
最初のレベルのタイトル
ゼロ知識証明開発フレームワーク評価プラットフォーム「Pantheon」
過去数か月間、私たちは zk-SNARK の簡潔な証明で構築された最先端のインフラストラクチャの開発に多大な時間と労力を投資してきました。この次世代の革新的なプラットフォームにより、開発者はブロックチェーン アプリケーションの前例のない新しいパラダイムを構築できます。
開発作業では、さまざまなゼロ知識証明 (ZKP) 開発フレームワークをテストして使用しました。この取り組みはやりがいのあるものでしたが、特定のユースケースやパフォーマンス要件に最適なフレームワークを見つけようとする新しい開発者にとって、さまざまな ZKP フレームワークがしばしば課題となることも認識しています。この問題点を考慮すると、これらの新しいアプリケーションの開発を大幅に促進する、包括的なパフォーマンス テスト結果を提供できるコミュニティ評価プラットフォームが必要であると考えています。
このニーズを満たすために、私たちはゼロ知識証明開発フレームワーク評価プラットフォーム「Pantheon」この公益コミュニティの取り組み。この取り組みの最初のステップでは、コミュニティが共有することを奨励します。再現可能なパフォーマンステスト結果。私たちの最終的な目標は、協力して広く認知されているテスト プラットフォーム、最初のレベルのタイトル
ステップ 1: SHA-256 を使用した回路フレームワークのパフォーマンス テスト
この記事では、一連の低レベル回路開発フレームワークで SHA-256 を使用して、再現可能な一連のパフォーマンス テスト結果を提供する、ZKP Pantheon 構築の最初のステップを実行します。他のパフォーマンス テストの粒度やプリミティブも可能であることは承知していますが、ブロックチェーン システム、デジタル署名、zkDID などを含む幅広い ZKP ユースケースに適しているため、SHA-256 を選択しました。また、私たち自身のシステムでも SHA-256 を使用しているため、これは私たちにとっても便利であることにも言及する価値があります。
副題
証明システム
近年、ゼロ知識証明システムの急増が観察されています。この分野のすべての刺激的な進歩に追いつくことは困難ですが、私たちは成熟度と開発者の導入に基づいて、テスト用に次の実証システムを厳選しました。私たちの目標は、さまざまなフロントエンドとバックエンドの組み合わせの代表的なサンプルを提供することです。
Circom + snarkjs / rapidsnark: Circom は、回路を作成して R 1 CS 制約を生成するための人気のある DSL であり、snarkjs は Circom 用の Groth 16 または Plonk 証明を生成できます。 Rapidsnark は Circom の証明者でもあり、Groth 16 証明を生成します。また、ADX 拡張機能を使用し、証明の生成を可能な限り並列化するため、多くの場合 snarkjs よりもはるかに高速です。
gnark:gnark は、Groth 16、Plonk、およびより多くの高度な機能をサポートする Consensys の包括的な Golang フレームワークです。
Arkworks: Arkworks は、zk-SNARK 用の包括的な Rust フレームワークです。
Halo 2 (KZG): Halo 2 は、Zcash と Plonk の zk-SNARK 実装です。柔軟性の高い Plonkish 演算を備えており、カスタム ゲートウェイやルックアップ テーブルなどの多くの便利なプリミティブをサポートしています。私たちは、Ethereum Foundation と Scroll サポートを備えた KZG の Halo 2 フォークを使用しています。
Plonky 2 : Plonky 2 は、Polygon Zero の PLONK および FRI テクノロジーに基づいた SNARK 実装です。 Plonky 2 は小さな Goldilocks フィールドを使用し、効率的な再帰をサポートします。当社のパフォーマンス テストでは、100 ビットの投機のセキュリティを目標とし、パフォーマンス テストの取り組みに最適な証明時間をもたらすパラメーターを使用します。具体的には、28 のマークル クエリ、増幅率 8、および 16 ビットのproof-of-work チャレンジを使用しました。また、num_of_wires = 60 および num_routed_wires = 60 に設定します。
Starky: Starky は Polygon Zero の高性能 STARK フレームワークです。当社のパフォーマンス テストでは、100 ビットの投機の安全性を目標としており、最良の証明時間をもたらすパラメーターを使用します。具体的には、90 個のマークル クエリ、2 倍の増幅率、および 10 ビットのproof-of-work チャレンジを使用しました。
以下の表は、パフォーマンス テストで使用した上記のフレームワークと関連構成をまとめたものです。このリストは決して網羅的なものではなく、将来的には多くの最先端のフレームワーク/テクノロジー (Nova、GKR、Hyperplonk など) も調査する予定です。
これらのパフォーマンス テストの結果は、回路開発フレームワークのみを対象としていることに注意してください。今後、さまざまな zkVM (Scroll、Polygon zkEVM、Consensys zkEVM、zkSync、Risc Zero、zkWasm など) および IR コンパイラー フレームワーク (Noir、zkLLVM など) のパフォーマンス テストを含む別の記事を公開する予定です。
業績評価方法
これらのさまざまな証明システムでパフォーマンス テストを実行するために、N バイトのデータの SHA-256 ハッシュを計算します。N = 64、128、...、64 K で実験します (Starky は例外で、回路はSHA-256 の計算では 64 バイトの入力が固定されていますが、メッセージ ブロックの合計数は同じに保たれます)。許容できるこのリポジトリパフォーマンス コードと SHA-256 回路構成は、 にあります。
さらに、次のパフォーマンス指標を使用して各システムでパフォーマンス テストを実行しました。
証拠作成時間（証人の作成時間を含む）
プルーフの生成中にメモリ使用量が急増する
証明書生成中の CPU 使用率の平均パーセンテージ。 (このメトリクスはプルーフ生成プロセスの並列化の度合いを反映します)
副題
機械
2 つの異なるマシンでパフォーマンス テストを実行しました。
Linux サーバー: 20 コア @ 2.3 GHz、384 GB RAM
Macbook M 1 Pro: 10 コア @ 3.2 Ghz、16 GB RAM
Linux サーバーは、多数の CPU コアと十分なメモリを備えたシナリオをシミュレートするために使用されます。通常、研究開発に使用される Macbook M 1 Pro は、より強力な CPU を搭載していますが、コア数は少なくなっています。
副題
文章
拘束量
詳細なパフォーマンス テストの結果に進む前に、まず各証明システムの制約の数に注目して SHA-256 の複雑さを理解することが役立ちます。異なる算術スキームの制約の数は直接比較できないことに注意することが重要です。
以下の結果は、64 KB のプリイメージ サイズに対応します。結果は他のプリイメージ サイズによって異なる場合がありますが、ほぼ線形にスケールされます。
Circom、gnark、Arkworks はすべて同じ R1 CS アルゴリズムを使用しており、64 KB SHA-256 を計算するための R1 CS 制約の数は、およそ 30 M から 45 M の間です。 Circom、gnark、Arkworks の違いは、設定の違いが原因である可能性があります。
Halo 2 と Plonky 2 はどちらも Plonkish 算術を使用しており、行数は 2^22 から 2^23 の範囲になります。 Halo 2 の SHA-256 の実装は、ルックアップ テーブルを使用しているため、Plonky 2 よりもはるかに効率的です。
文章
証拠生成時間
[図 1] Linux サーバーを使用して、さまざまなオリジナル画像サイズにおける SHA-256 の各フレームのプルーフ生成時間をテストしました。次のような結果が得られます。
SHA-256 の場合、Groth 16 フレームワーク (rapidsnark、gnark、および Arkworks) は、Plonk フレームワーク (Halo 2 および Plonky 2) よりも速くプルーフを生成しました。これは、SHA-256 はほとんどがビット単位の演算で構成されており、ワイヤーの値は 0 または 1 であるためです。 Groth 16 の場合、これにより、楕円曲線のスカラー乗算から楕円曲線の点の加算まで、ほとんどの計算が削減されます。ただし、ワイヤー値は Plonk の計算に直接使用されないため、SHA-256 の特別なワイヤー構造は Plonk フレームワークで必要な計算量を削減しません。
すべての Groth 16 フレームワークの中で、gnark および Rapidsnark は、Arkworks および snarkjs より 5 ～ 10 倍高速です。これは、複数のコアを活用してプルーフ生成を並列化する優れた能力によるものです。 Gnark は Rapidsnark より 25% 高速です。
Plonk フレームワークの場合、4 KB 以上の大きなプリイメージ サイズを使用すると、Plonky 2 の SHA-256 は Halo 2 より 50% 遅くなります。これは、Halo 2 の実装では主にルックアップ テーブルを使用してビット単位の操作を高速化するため、行数が Plonky 2 よりも 2 倍少なくなるからです。ただし、同じ行数で Plonky 2 と Halo 2 を比較すると (たとえば、Halo 2 では 2 KB を超える SHA-256 に対して、Plonky 2 では 4 KB を超える SHA-256)、Plonky 2 は Halo より 50% 高速です。 2.ルックアップ テーブルを使用して Plonky 2 に SHA-256 を実装する場合、Plonky 2 のプルーフ サイズは大きいにもかかわらず、Plonky 2 の方が Halo 2 よりも高速であることが期待されます。
一方、入力プリイメージ サイズが小さい (<= 512 バイト) 場合、制約の大部分を占めるルックアップ テーブルの固定セットアップ コストにより、Halo 2 は Plonky 2 (および他のフレームワーク) より遅くなります。ただし、Halo 2 のパフォーマンスは、プリイメージ サイズが大きくなるにつれて競争力が増し、実証済みの生成時間は、図に示すように、プリイメージ サイズが 2 KB まではほぼ直線的に変化しても一定のままです。
予想通り、Starky の証明生成時間はどの SNARK フレームワークよりもはるかに短い (5 倍から 50 倍) が、その代わりに証明サイズが大きくなります。
また、回路サイズはプリイメージ サイズに比例して増加しますが、SNARK のプルーフ生成は O(nlogn) FFT により超線形に増加することにも注意してください (ただし、対数スケールが明らかなため、この現象はグラフには示されていません)。
[図 2] に示すように、Macbook M 1 Pro でプルーフ生成時間のパフォーマンス テストも実施しました。ただし、arm 64 アーキテクチャがサポートされていないため、rapidsnark はこのベンチマークに含まれていないことに注意してください。 arm 64 で snarkjs を使用するには、WebAssembly を使用して監視を生成する必要があります。これは、Linux サーバーで使用される C++ 監視の生成よりも遅くなります。
Macbook M 1 Pro でパフォーマンス テストを実行すると、さらにいくつかの観察結果が得られます。
Starky を除いて、すべての SNARK フレームワークは、プリイメージ サイズが大きくなるにつれて、メモリ不足 (OOM) エラーが発生したり、スワップ メモリを使用したりします (その結果、校正時間が遅くなります)。具体的には、Groth 16 フレームワーク (snarkjs、gnark、Arkworks) はプレイメージ サイズ >= 8 KB でスワップ メモリの使用を開始しますが、gnark はプレイメージ サイズ >= 64 KB でメモリ不足になります。 Halo 2 は、プリイメージ サイズが 32 KB 以上の場合にメモリ制限に達しました。 Plonky 2 は、プリイメージのサイズが 8 KB 以上の場合にスワップ メモリの使用を開始します。
副題
ピーク時のメモリ使用量
[図 3] と [図 4] は、それぞれ Linux Server と Macbook M 1 Pro でのプルーフ生成時のピーク メモリ使用量を示しています。これらのパフォーマンス テストの結果から、次のことがわかります。
すべての SNARK フレームワークの中で、rapidsnark が最もメモリ効率が高くなります。また、プリイメージのサイズが小さい場合、ルックアップ テーブルのセットアップ コストが固定されているため、Halo 2 はより多くのメモリを使用しますが、プリイメージのサイズが大きい場合、全体のメモリ消費量が少なくなることがわかります。
Starky は、SNARK フレームワークよりもメモリ効率が 10 倍以上優れています。その理由の 1 つは、使用する行が少ないためです。
副題
CPU使用率
4 KB のプリイメージ入力に対するプルーフ生成中の SHA-256 の平均 CPU 使用率を測定することにより、各プルーフ システムの並列化の程度を評価します。以下の表は、Linux Server (20 コア) と Macbook M 1 Pro (10 コア) の平均 CPU 使用率 (括弧内はコアごとの平均使用率) を示しています。
主な所見は次のとおりです。
Gnark と Rapidsnark は、Linux サーバー上で最も高い CPU 使用率を示し、複数のコアを効率的に使用し、プルーフ生成を並列化できることを示しています。 Halo 2 は、優れた並列化パフォーマンスも示しました。
Linux サーバー上のほとんどのフレームワークの CPU 使用率は、snarkjs を除き、Macbook Pro M 1 の 2 倍です。
最初のレベルのタイトル
結論と今後の研究
この記事では、さまざまな zk-SNARK および zk-STARK 開発フレームワークでの SHA-256 のパフォーマンス テスト結果を包括的に比較します。比較を通じて、SHA-256 操作の簡潔な証明を生成する必要がある開発者を支援することを期待して、各フレームワークの効率と有用性についての洞察が得られます。 Groth 16 フレームワーク (rapidsnark、gnark など) は、Plonk フレームワーク (Halo 2、Plonky 2 など) よりも証明の生成が速いことがわかりました。 Plonkish 算術のルックアップ テーブルは、より大きなプリイメージ サイズを使用する場合に、SHA-256 制約と証明時間を大幅に削減します。さらに、gnark と Rapidsnark は、複数のコアを活用して操作を並列化する優れた機能を示します。一方、Starky のプルーフ生成時間ははるかに短くなりますが、その代わりにプルーフ サイズが大幅に大きくなります。メモリ効率の点では、rapidsnark と Starky は他のフレームワークよりも優れています。
ゼロ知識証明評価プラットフォーム「Pantheon」構築の第一歩として、このパフォーマンス テストの結果が、最終的に構築したい包括的なテスト プラットフォームになるには程遠いことを認めます。私たちはフィードバックや批判を歓迎し、ゼロ知識証明をよりアクセスしやすく、開発者にとって参入障壁を低くするために、この取り組みに参加してくださる皆様を招待します。また、大規模なパフォーマンス テストのための計算リソースのコストをカバーするために、個々の独立した貢献者に助成金を提供する用意もあります。私たちは協力して ZKP の効率と有用性を向上させ、より広範囲にコミュニティに利益をもたらすことができることを願っています。
最後に、パフォーマンス テスト結果に関する貴重なレビューとフィードバックをくださった Polygon Zero チーム、Consensys の gnark チーム、Pado Labs、および Delphinus Lab チームに感謝いたします。
