# Binius STARKsの原理とその最適化思考の解析## 1 はじめに楕円曲線ベースのSNARKとは異なり、STARKはハッシュベースのSNARKと考えることができます。 現在のSTARKの非効率性の主な理由の1つは、forループのインデックス、真と偽の値、カウンターなど、実際のプログラムのほとんどの値が小さいことです。 ただし、マークルツリーベースの証明のセキュリティを確保するために、データがリードソロモンエンコーディングで拡張されると、元の値自体が非常に小さい場合でも、多くの追加の冗長値がドメイン全体を占有します。 この問題を解決するには、ドメインのサイズを小さくすることが重要な戦略になります。表1に示すように、第1世代のSTARKは252ビット、第2世代のSTARKは64ビット、第3世代のSTARKは32ビットです。 対照的に、バイナリドメインは直接的なビットアライメント操作を可能にし、スペースを無駄にすることなくコンパクトで効率的にエンコードできます(つまり、第4世代のSTARK)。表1:STARKsの進化経路| 機能 | 1代目スターク | 第2世代スターク | 3代目スターク | 4代目STARKs(Binius) ||------|-------------|-------------|-------------|---------------------|| コードビット幅 | 252ビット | 64ビット | 32ビット | 1ビット || 代表制 | スタークウェア | プロンキー2 | ベビーベア | ビニウス |近年発見されたGoldilocks、BabyBear、Mersenne31などの有限ドメインと比較すると、バイナリドメインの研究は前世紀の80年代にまでさかのぼることができます。 現在、バイナリドメインは暗号化で広く使用されており、典型的な例は次のとおりです。* F28ドメインに基づくAdvanced Encryption Standard (AES)。* F2128ドメインに基づくガロアメッセージ認証コード(GMAC)。* QRコード、F28ベースのリードソロモンエンコーディングを使用。* オリジナルのFRIプロトコルとzk-STARKプロトコル、およびSHA-3ファイナリストに選ばれたGrøstlハッシュ関数は、F28ドメインに基づいており、再帰に適したハッシュアルゴリズムです。小規模なドメインを使用する場合、セキュリティを確保するためにドメイン運用を拡大することがますます重要になります。 一方、Biniusが使用するバイナリドメインは、そのセキュリティと実際の可用性を確保するために、ドメイン拡張に完全に依存する必要があります。 Prover計算に関与するほとんどの多項式は、拡張ドメインに入る必要はなく、ベースドメインの下で操作するだけでよいため、小さなドメインで高い効率を達成できます。 ただし、必要なセキュリティを確保するためには、ランダムなポイントチェックとFRI計算をより大きな拡張領域にドリルダウンする必要があります。バイナリドメインに基づいて証明システムを構築する場合、2つの実際的な問題があります:STARKでトレース表現を計算するとき、使用されるドメインサイズは多項式の次数よりも大きくなければなりません。 マークルツリーがSTARKで約束されている場合、リードソロモンでエンコードする必要があり、使用されるドメインのサイズはエンコード拡張子のサイズよりも大きくする必要があります。Biniusは、これら2つの問題を別々に扱い、同じデータを2つの異なる方法で表現することでそれを行う革新的なソリューションを提案しています:まず、一変量多項式の代わりに多変量(具体的には多項式)多項式を使用し、全体の計算軌跡を「ハイパーキューブ」上の値で表します。 次に、ハイパーキューブの各次元の長さが2であるため、STARKのように標準のリード・ソロモン拡張を行うことはできませんが、ハイパーキューブはリード・ソロモン拡張に基づく正方形として扱うことができます。 この方法により、セキュリティを確保しながら、エンコード効率とコンピューティングパフォーマンスが大幅に向上します。## 2 原理分析現在のほとんどのSNARKsシステムの構築は、通常、次の2つの部分で構成されています。* PIOP(Information-Theoretic Polynomial Interactive Oracle Proof)は、証明システムの中核としてIOP:P、入力の計算関係を検証可能な多項式に変換します。 さまざまなPIOPプロトコルにより、証明者はバリデータと対話して多項式を段階的に送信でき、バリデータは少数の多項式の評価結果を照会して計算が正しいことを検証できます。 既存のPIOPプロトコルには、PLONK PIOP、Spartan PIOP、HyperPlonk PIOPなどがありますが、これらはすべて多項式を異なる方法で処理するため、SNARKシステム全体のパフォーマンスと効率に影響を与えます。* 多項式コミットメントスキーム(PCS):多項式コミットメントスキームは、PIOPによって生成された多項式方程式が真であるかどうかを証明するために使用されます。 PCS は、証明者が特定の多項式にコミットし、後でその多項式の評価結果を検証し、多項式に関する他の情報を隠蔽できる暗号化ツールです。 一般的な多項式コミットメント スキームには、KZG、Bulletproofs、FRI (Fast Reed-Solomon IOPP)、およびブレーキダウンが含まれます。 PCS が異なれば、パフォーマンス、セキュリティ、およびアプリケーションのシナリオも異なります。特定の要件に応じて、異なるPIOPとPCSを選択でき、適切な有限体または楕円曲線と組み合わせることで、異なる特性を持つ証明システムを構築できます。 例えば：• Halo2：PLONK PIOP と Bulletproofs PCS を組み合わせ、Pasta 曲線に基づいています。Halo2 の設計では、スケーラビリティに重点を置き、ZCash プロトコルの trusted setup を削除しています。• Plonky2: PLONK PIOP と FRI PCS を組み合わせ、Goldilocks ドメインに基づいています。 Plonky2 は効率的な再帰用です。 これらのシステムを設計する際には、選択したPIOPとPCSが、システムの正確性、性能、安全性を確保するために使用される有限領域または楕円曲線と一致する必要があります。 これらの組み合わせの選択は、SNARKの証明サイズと検証効率に影響を与えるだけでなく、システムが信頼できる設定を必要とせずに透明性を実現できるかどうか、および再帰的証明や集約証明などの拡張機能をサポートできるかどうかも決定します。Binius:HyperPlonk PIOP +ブレーキダウンPCS +バイナリドメイン。 具体的には、Biniusには、その効率性と安全性を実現するための5つの主要技術が含まれています。 まず第一に、バイナリフィールドのタワーに基づく算術がその計算の基礎を形成し、バイナリフィールドでの単純化された演算を実現できます。 次に、Biniusは、インタラクティブなOracle Proof Protocol(PIOP)で、HyperPlonk製品と順列チェックを適応させて、変数とその順列との間の安全で効率的な一貫性チェックを確保しました。 第 3 に、このプロトコルでは、小さなドメインでのマルチリニア関係の検証効率を最適化するために、新しいマルチリニア シフト引数が導入されています。 第 4 に、Binius は Lasso ルックアップ引数の改良版を採用しており、ルックアップ メカニズムに柔軟性と強力なセキュリティを提供します。 最後に、このプロトコルはスモールフィールド多項式コミットメントスキーム(スモールフィールドPCS)を使用しているため、バイナリドメインに効率的な証明システムを実装し、大規模なドメインに通常関連するオーバーヘッドを削減できます。### 2.1 有限体:二値体の塔に基づく算術タワーバイナリドメインは、高速な検証可能な計算の鍵であり、これは主に効率的な計算と効率的な算術化という2つの側面に起因します。 バイナリ ドメインは、本質的に非常に効率的な算術演算をサポートしているため、パフォーマンス要件に敏感な暗号化アプリケーションに最適です。 さらに、バイナリドメイン構造は簡略化された算術プロセスをサポートしており、つまり、バイナリドメインで実行される操作は、コンパクトで簡単に検証可能な代数形式で表すことができます。 これらの特徴は、タワー構造を通じてその階層的な性質を最大限に活用する能力と相まって、バイナリドメインをBiniusのようなスケーラブルな証明システムに特に適したものにしていますここで、「canonical」は、バイナリドメイン内の要素の一意で直接的な表現を指します。 たとえば、最も基本的なバイナリ ドメイン F2 では、任意の k ビット文字列を k ビット バイナリ ドメイン要素に直接マップできます。 これは、指定された位置内でそのような正規表現を提供できない素数フィールドとは対照的です。 32 ビットの素数フィールドを 32 ビット システムに含めることができますが、すべての 32 ビット文字列がドメイン要素に一意に対応するわけではなく、バイナリ フィールドにはこの 1 対 1 のマッピングの便利さがあります。 素数領域 Fp では、一般的な縮約法には、バレット縮約法、モンゴメリー還元、およびメルセンヌ-31 や Goldilocks-64 などの特定の有限体に対する特別な簡約法が含まれます。 バイナリドメイン F2k では、一般的に使用される縮約法には、特殊縮約法 (AES など)、モンゴメリー縮約法 (POLYVAL など)、再帰的縮約法 (Tower など) が含まれます。 論文「Exploring the Design Space of Prime Field vs. Binary Field ECC-Hardware Implementations」では、バイナリ領域は加算と乗算の両方でキャリーを導入する必要がなく、バイナリ領域の二乗演算は (X + Y に従うため非常に効率的であると指摘しています )2 = X2 + Y 2です。! [Bitlayer研究:Binius STARKsの原理分析と最適化思考](https://img-cdn.gateio.im/social/moments-5775a629f494c4e01e2b74d864fa4100)図 1 に示すように、128 ビット文字列: この文字列は、バイナリ ドメインのコンテキストでさまざまな方法で解釈できます。 これは、128 ビット バイナリ ドメイン内の一意の要素と見なすことも、2 つの 64 ビット タワー エレメント、4 つの 32 ビット タワー エレメント、16 個の 8 ビット タワー エレメント、または 128 個の F2 ドメイン エレメントとして解決することもできます。 この表現の柔軟性は、計算オーバーヘッドを必要とせず、ビット単位の文字列の型キャストのみを必要とし、これは非常に興味深く便利なプロパティです。 同時に、小さなドメイン要素を大きなドメイン要素にパッケージ化しても、追加の計算オーバーヘッドはありません。 Biniusプロトコルは、この機能を利用して計算効率を向上させます。 さらに、論文「On Efficient Inversion in Tower Fields of Characteristic Two」では、mビットのサブドメインに分解できるnビットタワーバイナリドメインでの乗算、二乗、および反転演算の計算の複雑さを調査しています。### 2.2 PIOP: バイナリドメイン用の適応 HyperPlonk プロダクトと PermutationCheck ------BiniusプロトコルのPIOP設計は、HyperPlonkから借用し、多項式と多変量セットの正確性を検証するための一連のコアチェックメカニズムを採用しています。 これらの主要なテストには、次のものが含まれます。1. GateCheck:機密監視者ωと公開入力xが回路の動作関係C(x、ω) = 0を満たしているかどうかを確認します。2. PermutationCheck:ブールハイパーキューブ上の2つの多変量多項式fとgの評価結果が順列関係であることを確認しますf(x) = 多項式変数間の配置の一貫性を確保するためのf(π(x))。3. LookupCheck:多項式が特定のルックアップテーブル、つまりf(Bμ) ⊆ T(Bμ)で評価され、特定の値が指定された範囲内にあることを確認します。4. MultisetCheck:2つの多変量セットが等しいかどうか、つまり{(x1,i,x2,)}i∈H={(y1,i,y2,)}i∈Hが等しいかどうかを確認します。5. ProductCheck:ブールハイパーキューブ上の有理多項式の評価が宣言値∏x∈Hμ f(x) = sと等しいかどうかをチェックし、多項式積の正確性を確保します。6. ZeroCheck: 多変量多項式がブール hypercube∏x∈Hμ f(x) = 0,∀x ∈ Bμ 上の任意の点でゼロであることを確認して、多項式のゼロ分布を確保します。7. SumCheck:多変量多項式の合計値が宣言された値∑x∈Hμ f(x) = sであるかどうかを確認します。 多変量多項式の評価問題を単変量多項式評価に変換することで、検証器の計算の複雑さが軽減されます。 さらに、SumCheckは、乱数を導入し、線形結合を構築して複数の合計チェックインスタンスのバッチ処理を実現することにより、バッチ処理も可能にします。8. BatchCheck:SumCheckに基づいて、複数の多変量多項式評価の正確性を検証し、プロトコールの効率を向上させます。BiniusはHyperPlonkとプロトコル設計において多くの類似点があるものの、以下の3つの点で改善を行っています：* ProductCheck の最適化: HyperPlonk では、ProductCheck は、分母 U がハイパーキューブ上のすべての場所でゼロ以外であり、製品が特定の値に等しくなければならないことを要求します。 Binius は、この値を 1 に特化することでこのチェックプロセスを簡素化し、計算の複雑さを軽減します。* 除算ゼロ問題の処理: HyperPlonk は除算ゼロの場合を適切に処理できず、その結果、ハイパーキューブ上の U の非ゼロ問題をアサートできなくなります。 Biniusはこれを正しく処理し、BiniusのProductCheckは分母がゼロの場合でも処理を続行するため、任意の製品値への一般化が可能になります。* PermutationCheck: この機能は HyperPlonk では使用できません。 Binius は複数の列間の PermutationCheck をサポートしているため、Binius はより複雑な多項式順列を処理できます。したがって、既存のPIOPSumCheckメカニズムの改善により、Biniusは、特により複雑な多変量多項式検証を処理する場合に、プロトコルの柔軟性と効率を向上させ、より強力な機能サポートを提供します。 これらの改善は、HyperPlonkの制限に対処するだけでなく、将来のためのバイナリベースの基盤も提供します
Binius STARKs解析:バイナリドメインに基づく効率的なゼロ知識証明システム
Binius STARKsの原理とその最適化思考の解析
1 はじめに
楕円曲線ベースのSNARKとは異なり、STARKはハッシュベースのSNARKと考えることができます。 現在のSTARKの非効率性の主な理由の1つは、forループのインデックス、真と偽の値、カウンターなど、実際のプログラムのほとんどの値が小さいことです。 ただし、マークルツリーベースの証明のセキュリティを確保するために、データがリードソロモンエンコーディングで拡張されると、元の値自体が非常に小さい場合でも、多くの追加の冗長値がドメイン全体を占有します。 この問題を解決するには、ドメインのサイズを小さくすることが重要な戦略になります。
表1に示すように、第1世代のSTARKは252ビット、第2世代のSTARKは64ビット、第3世代のSTARKは32ビットです。 対照的に、バイナリドメインは直接的なビットアライメント操作を可能にし、スペースを無駄にすることなくコンパクトで効率的にエンコードできます(つまり、第4世代のSTARK)。
表1:STARKsの進化経路
| 機能 | 1代目スターク | 第2世代スターク | 3代目スターク | 4代目STARKs(Binius) | |------|-------------|-------------|-------------|---------------------| | コードビット幅 | 252ビット | 64ビット | 32ビット | 1ビット | | 代表制 | スタークウェア | プロンキー2 | ベビーベア | ビニウス |
近年発見されたGoldilocks、BabyBear、Mersenne31などの有限ドメインと比較すると、バイナリドメインの研究は前世紀の80年代にまでさかのぼることができます。 現在、バイナリドメインは暗号化で広く使用されており、典型的な例は次のとおりです。
F28ドメインに基づくAdvanced Encryption Standard (AES)。
F2128ドメインに基づくガロアメッセージ認証コード(GMAC)。
QRコード、F28ベースのリードソロモンエンコーディングを使用。
オリジナルのFRIプロトコルとzk-STARKプロトコル、およびSHA-3ファイナリストに選ばれたGrøstlハッシュ関数は、F28ドメインに基づいており、再帰に適したハッシュアルゴリズムです。
小規模なドメインを使用する場合、セキュリティを確保するためにドメイン運用を拡大することがますます重要になります。 一方、Biniusが使用するバイナリドメインは、そのセキュリティと実際の可用性を確保するために、ドメイン拡張に完全に依存する必要があります。 Prover計算に関与するほとんどの多項式は、拡張ドメインに入る必要はなく、ベースドメインの下で操作するだけでよいため、小さなドメインで高い効率を達成できます。 ただし、必要なセキュリティを確保するためには、ランダムなポイントチェックとFRI計算をより大きな拡張領域にドリルダウンする必要があります。
バイナリドメインに基づいて証明システムを構築する場合、2つの実際的な問題があります:STARKでトレース表現を計算するとき、使用されるドメインサイズは多項式の次数よりも大きくなければなりません。 マークルツリーがSTARKで約束されている場合、リードソロモンでエンコードする必要があり、使用されるドメインのサイズはエンコード拡張子のサイズよりも大きくする必要があります。
Biniusは、これら2つの問題を別々に扱い、同じデータを2つの異なる方法で表現することでそれを行う革新的なソリューションを提案しています:まず、一変量多項式の代わりに多変量(具体的には多項式)多項式を使用し、全体の計算軌跡を「ハイパーキューブ」上の値で表します。 次に、ハイパーキューブの各次元の長さが2であるため、STARKのように標準のリード・ソロモン拡張を行うことはできませんが、ハイパーキューブはリード・ソロモン拡張に基づく正方形として扱うことができます。 この方法により、セキュリティを確保しながら、エンコード効率とコンピューティングパフォーマンスが大幅に向上します。
2 原理分析
現在のほとんどのSNARKsシステムの構築は、通常、次の2つの部分で構成されています。
PIOP(Information-Theoretic Polynomial Interactive Oracle Proof)は、証明システムの中核としてIOP:P、入力の計算関係を検証可能な多項式に変換します。 さまざまなPIOPプロトコルにより、証明者はバリデータと対話して多項式を段階的に送信でき、バリデータは少数の多項式の評価結果を照会して計算が正しいことを検証できます。 既存のPIOPプロトコルには、PLONK PIOP、Spartan PIOP、HyperPlonk PIOPなどがありますが、これらはすべて多項式を異なる方法で処理するため、SNARKシステム全体のパフォーマンスと効率に影響を与えます。
多項式コミットメントスキーム(PCS):多項式コミットメントスキームは、PIOPによって生成された多項式方程式が真であるかどうかを証明するために使用されます。 PCS は、証明者が特定の多項式にコミットし、後でその多項式の評価結果を検証し、多項式に関する他の情報を隠蔽できる暗号化ツールです。 一般的な多項式コミットメント スキームには、KZG、Bulletproofs、FRI (Fast Reed-Solomon IOPP)、およびブレーキダウンが含まれます。 PCS が異なれば、パフォーマンス、セキュリティ、およびアプリケーションのシナリオも異なります。
特定の要件に応じて、異なるPIOPとPCSを選択でき、適切な有限体または楕円曲線と組み合わせることで、異なる特性を持つ証明システムを構築できます。 例えば：
• Halo2：PLONK PIOP と Bulletproofs PCS を組み合わせ、Pasta 曲線に基づいています。Halo2 の設計では、スケーラビリティに重点を置き、ZCash プロトコルの trusted setup を削除しています。
• Plonky2: PLONK PIOP と FRI PCS を組み合わせ、Goldilocks ドメインに基づいています。 Plonky2 は効率的な再帰用です。 これらのシステムを設計する際には、選択したPIOPとPCSが、システムの正確性、性能、安全性を確保するために使用される有限領域または楕円曲線と一致する必要があります。 これらの組み合わせの選択は、SNARKの証明サイズと検証効率に影響を与えるだけでなく、システムが信頼できる設定を必要とせずに透明性を実現できるかどうか、および再帰的証明や集約証明などの拡張機能をサポートできるかどうかも決定します。
Binius:HyperPlonk PIOP +ブレーキダウンPCS +バイナリドメイン。 具体的には、Biniusには、その効率性と安全性を実現するための5つの主要技術が含まれています。 まず第一に、バイナリフィールドのタワーに基づく算術がその計算の基礎を形成し、バイナリフィールドでの単純化された演算を実現できます。 次に、Biniusは、インタラクティブなOracle Proof Protocol(PIOP)で、HyperPlonk製品と順列チェックを適応させて、変数とその順列との間の安全で効率的な一貫性チェックを確保しました。 第 3 に、このプロトコルでは、小さなドメインでのマルチリニア関係の検証効率を最適化するために、新しいマルチリニア シフト引数が導入されています。 第 4 に、Binius は Lasso ルックアップ引数の改良版を採用しており、ルックアップ メカニズムに柔軟性と強力なセキュリティを提供します。 最後に、このプロトコルはスモールフィールド多項式コミットメントスキーム(スモールフィールドPCS)を使用しているため、バイナリドメインに効率的な証明システムを実装し、大規模なドメインに通常関連するオーバーヘッドを削減できます。
2.1 有限体:二値体の塔に基づく算術
タワーバイナリドメインは、高速な検証可能な計算の鍵であり、これは主に効率的な計算と効率的な算術化という2つの側面に起因します。 バイナリ ドメインは、本質的に非常に効率的な算術演算をサポートしているため、パフォーマンス要件に敏感な暗号化アプリケーションに最適です。 さらに、バイナリドメイン構造は簡略化された算術プロセスをサポートしており、つまり、バイナリドメインで実行される操作は、コンパクトで簡単に検証可能な代数形式で表すことができます。 これらの特徴は、タワー構造を通じてその階層的な性質を最大限に活用する能力と相まって、バイナリドメインをBiniusのようなスケーラブルな証明システムに特に適したものにしています
ここで、「canonical」は、バイナリドメイン内の要素の一意で直接的な表現を指します。 たとえば、最も基本的なバイナリ ドメイン F2 では、任意の k ビット文字列を k ビット バイナリ ドメイン要素に直接マップできます。 これは、指定された位置内でそのような正規表現を提供できない素数フィールドとは対照的です。 32 ビットの素数フィールドを 32 ビット システムに含めることができますが、すべての 32 ビット文字列がドメイン要素に一意に対応するわけではなく、バイナリ フィールドにはこの 1 対 1 のマッピングの便利さがあります。 素数領域 Fp では、一般的な縮約法には、バレット縮約法、モンゴメリー還元、およびメルセンヌ-31 や Goldilocks-64 などの特定の有限体に対する特別な簡約法が含まれます。 バイナリドメイン F2k では、一般的に使用される縮約法には、特殊縮約法 (AES など)、モンゴメリー縮約法 (POLYVAL など)、再帰的縮約法 (Tower など) が含まれます。 論文「Exploring the Design Space of Prime Field vs. Binary Field ECC-Hardware Implementations」では、バイナリ領域は加算と乗算の両方でキャリーを導入する必要がなく、バイナリ領域の二乗演算は (X + Y に従うため非常に効率的であると指摘しています )2 = X2 + Y 2です。
! Bitlayer研究:Binius STARKsの原理分析と最適化思考
図 1 に示すように、128 ビット文字列: この文字列は、バイナリ ドメインのコンテキストでさまざまな方法で解釈できます。 これは、128 ビット バイナリ ドメイン内の一意の要素と見なすことも、2 つの 64 ビット タワー エレメント、4 つの 32 ビット タワー エレメント、16 個の 8 ビット タワー エレメント、または 128 個の F2 ドメイン エレメントとして解決することもできます。 この表現の柔軟性は、計算オーバーヘッドを必要とせず、ビット単位の文字列の型キャストのみを必要とし、これは非常に興味深く便利なプロパティです。 同時に、小さなドメイン要素を大きなドメイン要素にパッケージ化しても、追加の計算オーバーヘッドはありません。 Biniusプロトコルは、この機能を利用して計算効率を向上させます。 さらに、論文「On Efficient Inversion in Tower Fields of Characteristic Two」では、mビットのサブドメインに分解できるnビットタワーバイナリドメインでの乗算、二乗、および反転演算の計算の複雑さを調査しています。
2.2 PIOP: バイナリドメイン用の適応 HyperPlonk プロダクトと PermutationCheck ------
BiniusプロトコルのPIOP設計は、HyperPlonkから借用し、多項式と多変量セットの正確性を検証するための一連のコアチェックメカニズムを採用しています。 これらの主要なテストには、次のものが含まれます。
GateCheck:機密監視者ωと公開入力xが回路の動作関係C(x、ω) = 0を満たしているかどうかを確認します。
PermutationCheck:ブールハイパーキューブ上の2つの多変量多項式fとgの評価結果が順列関係であることを確認しますf(x) = 多項式変数間の配置の一貫性を確保するためのf(π(x))。
LookupCheck:多項式が特定のルックアップテーブル、つまりf(Bμ) ⊆ T(Bμ)で評価され、特定の値が指定された範囲内にあることを確認します。
MultisetCheck:2つの多変量セットが等しいかどうか、つまり{(x1,i,x2,)}i∈H={(y1,i,y2,)}i∈Hが等しいかどうかを確認します。
ProductCheck:ブールハイパーキューブ上の有理多項式の評価が宣言値∏x∈Hμ f(x) = sと等しいかどうかをチェックし、多項式積の正確性を確保します。
ZeroCheck: 多変量多項式がブール hypercube∏x∈Hμ f(x) = 0,∀x ∈ Bμ 上の任意の点でゼロであることを確認して、多項式のゼロ分布を確保します。
SumCheck:多変量多項式の合計値が宣言された値∑x∈Hμ f(x) = sであるかどうかを確認します。 多変量多項式の評価問題を単変量多項式評価に変換することで、検証器の計算の複雑さが軽減されます。 さらに、SumCheckは、乱数を導入し、線形結合を構築して複数の合計チェックインスタンスのバッチ処理を実現することにより、バッチ処理も可能にします。
BatchCheck:SumCheckに基づいて、複数の多変量多項式評価の正確性を検証し、プロトコールの効率を向上させます。
BiniusはHyperPlonkとプロトコル設計において多くの類似点があるものの、以下の3つの点で改善を行っています：
ProductCheck の最適化: HyperPlonk では、ProductCheck は、分母 U がハイパーキューブ上のすべての場所でゼロ以外であり、製品が特定の値に等しくなければならないことを要求します。 Binius は、この値を 1 に特化することでこのチェックプロセスを簡素化し、計算の複雑さを軽減します。
除算ゼロ問題の処理: HyperPlonk は除算ゼロの場合を適切に処理できず、その結果、ハイパーキューブ上の U の非ゼロ問題をアサートできなくなります。 Biniusはこれを正しく処理し、BiniusのProductCheckは分母がゼロの場合でも処理を続行するため、任意の製品値への一般化が可能になります。
PermutationCheck: この機能は HyperPlonk では使用できません。 Binius は複数の列間の PermutationCheck をサポートしているため、Binius はより複雑な多項式順列を処理できます。
したがって、既存のPIOPSumCheckメカニズムの改善により、Biniusは、特により複雑な多変量多項式検証を処理する場合に、プロトコルの柔軟性と効率を向上させ、より強力な機能サポートを提供します。 これらの改善は、HyperPlonkの制限に対処するだけでなく、将来のためのバイナリベースの基盤も提供します