原題:「Lasso、Jolt、SNARK デザインの最近の進歩に関する技術 FAQ」
原作者：Justin Thaler
オリジナルコンピレーション: Luccy、BlockBeats
編集者注: 11 月 20 日、Ulvetanna の Ben Diamond と Jim Posen (DP) は、サム チェックと、より高速な証明者とより大きな証明を組み合わせたコミットメント スキーム Ligero/Brakedown に基づいて多項式 IOP を改善し、それをサム チェック ベースと統合する論文を発表しました。なげなわなどのSNARK。 a16z の研究パートナーである Justin Thaler がこのテクノロジーの詳細な分析を行った後、さまざまな研究者が記事の内容について疑問を提起しました。
関連記事: 「a16z: Lasso+Jolt、迅速なコミットメントに関する新しい視点」
この FAQ には、Jolt Prover のパフォーマンス、DP が Keccak および Grøstl ハッシュ関数を選択した理由、ハッシュベースのコミットメント スキームのセキュリティなど、さまざまな質問に答えるための 13 の質問が統合されています。さらに、この回答では、Lasso と Jolt の基本的な関係、リードソロモン コードを使用するパフォーマンスの利点、FRI に対する Ligero/Brakedown の利点、および DP の GF への取り組みの要素エコノミーの説明もカバーしています[2]。
議論の焦点には、計算全体のブール回路の実装、特徴的な 2 つのフィールドの利点、再帰結合および DP コミットメント スキームと楕円曲線ベースの SNARK の組み合わせによる SNARK 証明の技術的およびコストの問題が含まれます。最後に、この記事は、DP のコミットメント スキームを使用する SNARK が Nova などのフォールディング スキームと併用できるかどうかという問題も提起しています。これらの問題に関する徹底的な研究により、この分野の技術革新とさらなる改善が促進されることが期待されます。
Q1: RISC-V プログラムのネイティブ実行と比較して、DP Promise を使用するために Jolt が再実装されたら、Jolt 証明者はどれくらい高速になると思いますか?
A：ここでは、大まかな推測的な見積もりを提供します。 Jolt 証明者は、RISC-V CPU の各ステップが 32 ビット データ型と乗算拡張を使用して、約 800 ビットのデータをコミットすると予想しています。注意すべき 2 つの点: まず、一部の RISC-V 命令は複数の疑似命令を通じて処理されます。たとえば、除算命令は、証明者に剰余を提供させ、乗算、加算、および不等式のチェックを通じて検証させることによって機能します。第 2 に、この数値推定は、GF [2128] のルックアップ テーブル分解を解析した後にわずかに調整される可能性があります。
DP のコミットメント スキームを使用し、再帰がボトルネックにならないと仮定すると、T ステップ計算における主なコミットメント コストは次のとおりです。
まず、合計約 200T バイトのデータに加算型 FFT が適用されます。より正確には、Ligero/Brakedown 証明者は、長さの O(√T) 個の独立 FFT を実行するよりも、サイズ O(√T) の独立 FFT を O(√T) 個実行します (総作業量が少なく、より効率的に並列化できます)。 O(T))。次に、約 200 テラバイトが Keccak や SHA 2 などの標準ハッシュ関数を使用してハッシュされます。
DP は経験的に、FFT とハッシュの証明時間はほぼ等しいことを発見しました。
Keccak ハッシュを使用すると、1 バイトあたり約 70 RISC-V サイクルと推定され、これらの操作は、実証されていない RISC-V プログラムを実行するよりも約 30,000 倍遅くなることがわかります。言い換えれば、Jolt 証明器が RISC-V プログラム Ψ を正しく実行したことを証明するには、証明器自体 (RISC-V で実装) は Ψ 自体の少なくとも 20,000 倍のサイクルを必要とすることになります。
これらのコミットメントコストは十分に「速い」ため、証明者のボトルネックは、小さな機能ドメインにわたる最適化さえも可能にする、全体的なチェックプロトコルで実行する限られたドメイン操作にある可能性があることを示唆しています。したがって、大まかな見積もりとして、Jolt 証明器 (RISC-V で実装) は、単に RISC-V プログラムを実行する場合よりも約 50,000 倍遅くなると推測します。
全体の計算は少しばかげています。Jolt が展開されるときに証明者自体が RISC-V で実装される可能性は低いです。ただし、zkVM 証明者のコストを見積もる方法についての一般的なアイデアは得られます。
50,000 倍の減速は非常に大きいように思えますが、約 18 か月前に私が楽観的に見積もった 100 万倍のオーバーヘッドよりも 20 倍高速です。この改善の主な理由は、Lasso と Jolt によってロック解除される Promise データが小さくなったこと (および各 Promise 値のサイズが小さくなったこと) です。残りはコミットメントスキームの改善によるものです（高速ハッシュ関数を使用し、ハッシュベースのSNARKで小さいサイズのコミットメント値を活用する能力の向上など）。
Q2: DP は Keccak と Grostl に高速 SNARK を提供します。なぜこれらのハッシュ関数が選ばれたのでしょうか?これらの手法に適した他のハッシュ関数は何ですか? BlockBeats 注: Grøstl は暗号化ハッシュ関数です
A：Keccak/SHA 3 は、NIST 標準、Ethereum プリコンパイル、および Type-1 zkEVM にとって重要なボトルネックであるため、当然の選択です。 SHA 3 は公式の NIST 標準であり、Kecck はプリコンパイルされたイーサリアムであり、SNARK コストとは関係ありません。
DP は、Kecchak の利点の多くを維持しながら、より高速な証明者につながるはずであるため、Grøstl を検討しました。特に、Grøstl は、NIST の SHA-3 コンテストの最終ラウンドに進出し、AES S-box を使用していたため、最終的には選ばれませんでしたが、強力な暗号解読の精査に耐えました。 AES アクセラレーション命令 AES-NI のおかげで、Grøstl は Intel チップ上の Keccak よりもさらに高速に実行されます。
Grøstl は基本的に GF [28] 上でネイティブに定義されているため、DP の証明器は Keccak よりも Grøstl の方が高速であるはずです。これは、DP の証明器がコミットできるドメイン要素が Keccak よりも少ないことを意味します。 (これが証明者にどのようなメリットをもたらすかについては、Q9 を参照してください。) 全体として、Grøstl は証明者とチップの両方で高速であるため、Kecchak よりも (再帰的) SNARK に適しているはずです。
DP の SNARK は Keccak と Grostl とは何の関係もありません。これらの手法は、他の多くのハッシュ関数にも適用できるはずです。たとえば、DP は SHA 2 も Keccak と同じくらい優れているはずだと考えていますが、まだ詳細には研究していません。
Q3: Lasso/Jolt は楕円曲線に基づくコミットメント ソリューションだと思いましたか?
A：いいえ、Lasso と Jolt は特にカーブベースのコミットメント スキームを対象としていません。しかし、数か月前の場合、以前の研究と比較して、その利点は、曲線ベースのプロミスと組み合わせて使用したときに最も顕著になります。これは、証明者がランダムなドメイン要素にコミットしなければならない場合、曲線ベースのコミットメントが特に高い代償を払うためであり、これを回避する Lasso/Jolt の新しい機能は、これらのコミットメントが使用されるときに最も説得力のあるパフォーマンスを発揮するためです。
つまり、約束されている小さな値を利用するカーブ プロミスに基づいて SNARK を設計した人は誰もいませんが、これを利用する小さなフィールドで動作するハッシュ ベースのプロミスはある程度すでに存在します。
ただし、ハッシュベースの Promise を使用した場合でも、Lasso と Jolt は両方の点で以前の作業よりも改善されています。まず、DP は、ハッシュ ベースのコミットメントでは、小さなドメイン要素のみをコミットすることで、以前に知られていたアプローチよりも堅牢なメリットが得られることを示しています。たとえば、今日のコミットメント スキームでは、1 ビット値のコミットと 32 ビット値のコミットに同じ証明者コストがかかりますが、DP のスキームは 1 ビット値のコミットに比べてほぼ 32 倍安価です。第 2 に、Lasso と Jolt は、証明者が小さなドメイン要素のみにコミットすることを保証するだけでなく、証明者が非サムチェックベースの SNARK よりも少ないドメイン要素にコミットすることも保証します。実際、Jolt では、すべての Promise ドメイン要素のビット複雑さの合計を注意深く計算し、それが既存の zkVM で実行される作業よりもはるかに小さいことを確認しました。
Lasso/Jolt が数か月前にリリースされたとき、別の技術的な問題が曲線ベースのコミットメントを前面に押し出しました。対数多項式の証明サイズ FRI を持つ唯一のハッシュベースのコミットメント スキームは一変量多項式用であり、Lasso/Jolt は多線形多項式を使用します。 。 FRI を多線形多項式に適したコミットメント スキームに適応させるいくつかの変換が知られていますが、これらの変換は証明時間、証明サイズ、またはその両方の点でオーバーヘッドを追加し、非常に望ましくないものと考えられます。 BaseFold では、対数多項式の証明サイズを使用した「直接」多線形コミットメントが可能になりましたが、結果として得られる証明は Brakedown よりも遅く、FRI よりも大きくなります。
FRI とは異なり、Ligero/Brakedown コミットメント スキームは多線形多項式に直接適用され、非常に高速な証明を備えています。しかし、以前は、バリデーターが大量のハッシュ操作を実行し、再帰のコストが高かったため、再帰を適用して証明サイズを削減することは困難でした。 DP の取り組みにより、ハッシュの SNARK が高速化され、この再帰のコストが大幅に削減されます。
Q4: カーブベースのコミットメントスキームはハッシュベースのスキームより速いと言いませんでしたか(Lasso/Joltなど、小さな値のみが約束される場合)?これは、DP の SNARK を支持していることと矛盾しませんか?
A：まず、前に述べたように、楕円曲線グループの基礎となるドメインで作業することが合理的であるため、ハッシュ ベースの SNARK が明らかに最良のパフォーマンスの選択肢ではない重要な SNARK アプリケーション シナリオがいくつかあります。これらのドメインを使用すると、曲線ベースの Promise が高速になります。楕円曲線暗号システムに関するあらゆるステートメントの証明 (ブロックチェーン トランザクションを承認する ECDSA デジタル署名に関する知識を含む) は、このカテゴリに分類されます。
第 2 に、小さな機能ドメインを合理的に使用するアプリケーションであっても、ハッシュ ベースのスキームとカーブ ベースのスキームのパフォーマンス比較は複雑です。たとえば、ハッシュベースのスキームで使用されるハッシュ関数の速度に大きく依存します。現在、多くの (すべてではありません) プロジェクトは、Poseidon などの低速のハッシュ関数を使用して再帰を実装しています。このようなハッシュ関数を使用すると、小さな値 (Lasso/Jolt など) をコミットする場合、ハッシュ ベースのスキームはカーブ ベースのスキームよりも大幅に遅くなります。高速なハッシュ関数があっても、それが高速であるかどうかは明らかではありません (前のコメントで述べたように)。
ただし、DP は、FRI などの既存のハッシュ ベースのスキームと比較して、ハッシュ ベースのコミットメントを高速化し、特性 2 のドメインを使用する場合のコミットメントの効率を高め、証明者が小さいサイズのコミットメント値をより効果的に活用できるようにします。したがって、私の現在の予想は、有限ドメイン上のローカル定義でそうでないことが証明されない限り、特性 2 を持つドメインでは Ligero/Brakedown が前進するだろうということです。
結論として、今日に至るまで、一般にハッシュベースのコミットメントスキームがカーブベースのスキームよりも速いと考えられている主な理由は、Plonk のような人気のある SNARK では証明者が小さなドメイン要素ではなくランダムなドメイン要素にコミットする必要があるためです。この場合、曲線ベースの Promise ソリューションは非常に遅くなります。 Lasso と Jolt は、証明者がランダムなドメイン要素にコミットする必要がないことを示しました。この場合、比較は少なくともより微妙なものになります。今日まで、曲線ベースのソリューションは実際には高速でしたが、DP の改善により、状況は逆転しました (大規模なドメインでローカルに定義されている場合を除く)。
Q5: ハッシュベースのコミットメントスキームは安全性が低いと言いませんでしたか?
A：FRI や Ligero/Brakedown のようなハッシュベースのコミットメント スキームには、本質的に安全でないものは何もありません。ただし、プロジェクトは通常、既知の攻撃が実行可能に近い構成に FRI を展開し、FRI に対するこれらの既知の攻撃がたまたま最適であると想定することで、セキュリティよりもパフォーマンスを優先します。
Ligero/Brakedown コミットメント スキームの利点の 1 つは、FRI に関する主な予想、つまりジョンソン境界の外側の隣接パラメーターでの予想の安全性が関連しないことです。そのため、SNARK 設計者が安全性に基づいて推測するために FRI を使用するインセンティブがありません。 。
同様に、私は長い間、SNARK 展開における表向き「SNARK フレンドリーな」ハッシュ関数 (Poseidon など) の使用について懸念していました。これらのハッシュ関数 (最も古くから存在するハッシュ関数であっても) のセキュリティは、Kecchak のような標準的なハッシュ関数よりもはるかに精査されていません。
どちらの場合も、プロジェクトは今日の SNARK パフォーマンスの欠点を隠すことによってセキュリティを侵害していると思います。これらの慣行を排除する最も簡単な方法は、よりパフォーマンスの高い SNARK を開発することです。
これに関連して、「SNARK フレンドリーな」仮想マシン (VM) とこれらの VM を実装する制約システムを手作業で設計する現在の慣行は、重大なセキュリティ上の問題 (および開発者リソースの多大な浪費) であると私は考えています。高レベル言語開発からカスタム VM への新しいコンパイラからアセンブリ コードにはエラーが発生しやすい性質があります。私は、Jolt が、標準命令セットが確かに同様に SNARK フレンドリーであることを示し、これらの命令セットを実装する制約システムを手作業でエンジニアリングする必要性やインセンティブを排除することで、この慣行を時代遅れにすることを願っています。
セキュリティに悪影響を与える慣行を排除する方法は、その慣行を意味のないものにする、よりパフォーマンスの高い SNARK を考案することです。
Q6: DP は多項式コミットメント方式の実装にリードソロモン コードを使用しましたが、Brakedown は任意のコードを使用できます。パフォーマンス上の利点を得るために他のコードを検討する価値はあるでしょうか?
A：はい。
Q 7: リジェロ/ブレークダウンは、証明者にとって FRI よりもどのような点で有益ですか?
A：非常に小さな値をコミットする際の DP の証明者時間が大幅に改善されたのは、少なくとも現時点では Ligero/Brakedown に特有のものです。さらに: DP は、小さな値をコミットする際の証明者の時間を短縮するだけでなく、証明者のスペースも改善します。これは、特にハッシュベースの SNARK の場合、大きなボトルネックになります。たとえば、Polygon の zkEVM 証明器は現在、約 1,000 万ガスのトランザクション バッチを処理する回路を証明するために 250 GB 以上を必要とします。
Ligero/Brakedown は、エラー修正コードの使用における柔軟性を高めます。実際、小さな値へのコミットにおける DP の改善の多くは、Ligero/Brakedown 内で連結コードを使用するだけで実現できます。
リードソロモン符号を使用する場合、Ligero/Brakedown 証明者は 1 つの大きな FFT ではなく、多数の小さな FFT を実行します。これにより、FFT 実行時間が 2 倍節約され、並列化により適しています。
技術レベルでは、FRI では FFT と IFFT の両方を実行する必要もあります (技術的には、FRI は多くの点でコミットされた多項式を実際に評価する必要があるためです)。 Ligero/Brakedown の証明者は IFFT をスキップできます (技術レベルで IFFT をスキップできるのは、Ligero/Brakedown のエラー訂正コードの選択における優れた柔軟性に由来します)。 「リードソロモンインフレ係数」2 (証明者の時間を最適化するインフレ係数) を使用すると、証明者の時間をさらに 33% 節約できます。
Ligero/Brakedown の評価証明では、証明者が追加のマークル ハッシュを実行する必要はありません。ただし、FRI のほとんどの呼び出しでは、多くのコミットされた多項式に対する証明を評価するコストが償却されますが、FRI は必要となります。
Q8: DP が、コミットされた GF[2] 要素がコミットされた GF[2^2] 要素よりも安く、コミットされた GF[2^4] 要素よりも安価であることなどをどのように保証するかについて概説できますか?
A：DP のコミットメント スキームを使用して証明者が一連の値をコミットするのにかかる時間は、値の指定に必要な総ビット数のみにほぼ依存します。ここで、b ビットは 0 から 2b までの値を指定するために使用されます。 DP の SNARK における追加の証明者のコストは、それらのビットのエンコードに使用されるフィールド要素の数に応じて増加します (詳細については、下記 #9 を参照)。 DP がこれをどのように実現しているかは次のとおりです。
Brakedown の多項式コミットメント スキームは、必要なエラー修正コードを使用して、コミットされる値のサブベクトルをエンコードします。コミットされる値の束が GF[2] にあるとしますが、エンコーディング自体はより大きなドメイン GF[2^16] で動作するようにしたいとします。これを行うには多くの技術的な理由があります。実際、長さ 216 までのベクトルに何らかのエンコーディングを適用する場合には、これが必要になります。
これを実現するには、コード連結を使用するだけです。これには、すべての GF[ 2 ] 値をサイズ 16 のチャンクに分割し、16 個の GF[ 2 ] 値の各チャンクを単一の GF[ 2 ] に「パック」することが含まれます。 ^ 16 ] フィールド要素。これにより、コミットされるフィールド要素の数が 16 分の 1 に減ります。その後、フィールド GF[2^16] に作用する任意のエラー訂正コードを適用できます。これは「外部コード」と呼ばれます。結果のコードワードの各シンボルは 16 個の GF[2] 要素に「アンパック」され、その結果は GF[2] で定義された「内部コード」を使用してエンコードされます。
事実上、連結法ではコミットメント ベクトルの長さ (フィールド要素の数で測定) が 16 分の 1 に削減されますが、証明者はパッキングおよびアンパッキング操作を実行し、内部コードを適用する必要があります。
連結されたコードを使用してブレーキダウンを適用するこのシンプルなアプローチにより、DP 作業の利点の多くが実現されました。しかし、DP は異なるアプローチを採用しており、結果として証明者が高速になります (証明のサイズが若干大きくなります)。たとえば、DP の実際的なアプローチでは、外部コードワードのアンパックされた各シンボルに内部コードを適用するコストが回避されます。
Q 9: DP のコミットメント スキームにより、{ 0, 1 } の値をコミットするのが非常に安価になるため、証明者に計算に現れるすべての値のビットごとの分解だけをコミットさせてみてはどうでしょうか?つまり、ブール回路を使用して計算全体を実装し、回路内の各入力ビットとゲートに「完全な」フィールド要素を SNARK に割り当てさせてはどうでしょうか?
A：Keccak の SNARK では、DP は証明者に { 0, 1 } の値のみをコミットさせていますが、これは一般的なケースでは必ずしも良いアイデアではありません。
実際、DP のコミット時間は、それらの値がいくつのフィールド要素に分散されているかには関係なく、すべてのコミットされた値のビット複雑さの合計にほぼ比例します (これが、1 ビット値のみをコミットするのが合理的な理由です) Keccak の SNARK アイデアで)。
ただし、これは、すべてのコストがコミットされたフィールド要素の数に依存しないことを意味するわけではありません。特に、コミットメントスキームの評価証明のサイズは、コミットメントフィールド要素の数（の平方根）に比例します。
コミットされたフィールド要素の数に比例するもう 1 つのコストは、DP の SNARK の合計チェック プロトコルの一部のアプリケーションで合計する必要がある項の数です。大まかに言えば、x 倍のフィールド要素をコミットするということは、x 倍の項を合計する必要があることが合計チェックによって証明されることを意味します。このオーバーヘッドを軽減するために利用できる最適化がいくつかありますが、軽減は完全ではありません。つまり、x 個の 1 ビット値であっても、値を単一の x ビット フィールド要素にパックした後にコミットする場合と比較して、サム チェックはおそらく依然として遅いことがわかります。
DP は、コミット後に多くの 1 ビット値を単一のフィールド要素にパックするサムチェックベースのプロトコルを提供することで、多くの 1 ビット値をコミットする後者のコストを軽減します。これにより、多くのコミットされた値のサムチェック証明時間の多すぎるという代償を技術的に支払うことを避けることができ、同時にその利点を享受することができます (特に、ビット分解されたコミットメントがサム チェックによって証明されると、ビットごとの AND などの特定の演算が実行されます)。証明された場合、追加のコミットメント費用は発生しません)。
Q1 0: 2 つの特徴を持つ分野を活用した DP の具体的なメリットは何ですか?
A：たくさんありますが、ここではいくつかの例を示します。
DP はタワーフィールド建設を多用しました。特性 2 を持つフィールドのコンテキストでは、これは、GF[2] の 2 次拡張として GF[22] を構築し、次に GF[4] の 2 次拡張として GF[24] を構築し、次に GF[28 ] を構築することを指します。 GF[ 24 ] の二次拡張としてなど。特に特性 2 の分野では、非常に効率的なタワー構造が存在することが知られています。
合計チェック プロトコルは、多変量多項式 g の ∑x∈ 0, 1 ^ng(x) を計算します。ブール ハイパーキューブ { 0, 1 }n (およびそのサブキューブ) のサイズは 2 のべき乗であるため、サブフィールドはサブキューブと適切に位置合わせされます。 DP はこれを利用して、多くの小さなフィールド要素をより大きな拡張フィールドの 1 つの要素にパッケージ化することを容易にします。
DP は現在、Ligero/Brakedown 多項式コミットメント スキームでリードソロモン符号化を使用しています。効率的なリードソロモン符号化には加算型 FFT が必要です。これは特性が 2 のフィールドでは非常に効率的ですが、他のフィールドではあまり効果的ではありません。ただし、他のエンコーディングを使用すると、FFT の必要性を完全に回避できます。
特性 2 を持つフィールドは、実際のハードウェアで適切に処理されます。現実世界のコンピューターは、2 のべき乗のサイズのデータ型に基づいています。最大の情報をパディングせずにレジスターやキャッシュラインなどに完全に収めることができます。 Intel は、GF で特に高速な演算を実行するための基本命令 (ガロア体新命令 [GFNI]) をチップに組み込みました [28]。タワー構築を使用する場合、これを使用して、k > 8 の場合でも、非常に高速な GF[2k] 演算を実装できます。
Q1 1: DP のコミットメント スキームを使用して SNARK 証明をそれ自体と再帰的に組み合わせることで、SNARK 証明の制約が弱くなる可能性はありますか?
A：はい、Ligero/Brakedown コミットメントを使用する SNARK の「再帰しきい値」は比較的高いです。再帰的しきい値は、検証者に Brakedown/Ligero ベースの SNARK を再帰的に適用することによって、より短い証明を生成できないような証明のサイズを指します。再帰のしきい値は数 MB 程度になると予想されます。
より小さな証明を取得したい場合は、SNARKと他の小さな証明を組み合わせることで実現できると思いますので、詳しくはQ1 2を参照してください。この仮定が間違っていることが判明した場合、それは Binius の失敗としてではなく、今日人気のある SNARK のスケーラビリティに対する非難として見られるべきです。数 MB のデータが適切な時間内にハッシュされたことを証明できなければ、どうやってスケーラブルであると言えるでしょうか?
いずれにせよ、証明サイズの削減以外にも、再帰的合成を高速化する重要な理由は他にもあります。最も重要なことは、これはプルーフ スペース要件を制御するための重要なツールであるということです。 (非再帰的な) SNARK は証明者にとって多くのスペースを占めるため、人々は大規模な計算を小さなチャンクに分割し、各チャンクを個別に証明し、再帰的証明を使用してチャンクを「連鎖」させます。 DP の標準ハッシュ関数 (Kecck など) 用の高速 SNARK を使用すると、証明サイズが多少大きい場合でも、このような再帰的証明を迅速に完了できます。
Q1 2: DP のコミットメント スキームと楕円曲線ベースの SNARK (Plonk や Groth 16 など) を組み合わせて、チェーン上でプルーフを公開する前に検証者のコストを削減したいとします。これには「非ローカル」フィールド演算が関与しているという証明が必要ではないでしょうか? DP の検証器は GF[2^128] で動作するのに対し、曲線ベースの SNARK は大きな素数次数フィールドを使用するためです。
A：はい、これは潜在的な課題ですが、解決策は見つかると信じています。
1 つの可能性は、まず短い証明を持つハッシュ ベースの多項式コミットメント スキーム (おそらく多線形多項式コミットメント スキームまたは BaseFold に変換された FRI) を使用して SNARK と結合し、次に曲線ベースの SNARK と結合することです。 FRI は機能 2 のフィールドでネイティブに実行できることに注意してください。実際、このケースは元の FRI 論文で検討されていました。これらのフィールドの使用に対する現在一般的な SNARK の制限は、FRI 自体とは異なり、合計チェックに基づいていない多項式 IOP の使用に起因しています。
これによって非ローカル フィールド演算の問題が解消されるわけではありませんが、多項式が十分に大きい場合、FRI バリデーターが実行する合計演算数が少なく、特に Ligero/Brakedown バリデーターが実行するフィールド演算数よりも少ないため、この問題は大幅に軽減できます。 。
Q1 3: DP のコミットメント スキームを使用した SNARK は、Nova などのフォールディング スキームと併用できますか?
A：これには、Q1 2 と同じ問題が発生します。つまり、フォールディング スキームでは通常、大きな素数次数フィールドで定義される楕円曲線が使用されますが、DP のコミットメント スキームでは 2 のべき乗のサイズのフィールドが使用されます。
私は、折り畳み方式が大幅に進歩し、将来の SNARK の設計において重要な役割を果たすことを期待しています。ただし、非常に小さな特徴を持つフィールドでは、ハッシュ ベースの SNARK とうまく組み合わせられない場合があります。
現時点では、楕円曲線ベースの Promise と折り畳みスキームは、大規模なフィールド上のローカル定義を含むステートメントが含まれる場合、または証明者空間が重要な場合 (Nova のような折り畳みスキームは他の SNARK よりも証明者空間においてはるかに優れています) に使用する必要があります。大規模な計算を他の SNARK よりもはるかに小さな部分に分割できます)。他の場合、特に小さな特徴フィールドの場合は、ハッシュベースのスキームを使用する必要があります。
同様に、将来的にフォールディング スキームがさらに開発されると、ハッシュ ベースのスキームを超えたものになる可能性があります。実際、一部のベンチマークでは、Nova はすでに現行世代のハッシュ ベースの SNARK よりも高速です (ただし、現在のハッシュ ベースの SNARK はカーブ ベースの SNARK よりも高速であるという主張は数多くあります)。
IOS
Android