ここで「canonical」とは、バイナリフィールド内の要素のユニークで直接的な表現方法を指します。たとえば、最も基本的なバイナリフィールドF2では、任意のkビットの文字列は直接kビットのバイナリフィールド要素にマッピングできます。これは素数フィールドとは異なり、素数フィールドは指定されたビット数内でこのような標準的な表現を提供することができません。32ビットの素数フィールドは32ビット内に含まれることができますが、すべての32ビットの文字列が唯一のフィールド要素に対応するわけではなく、バイナリフィールドはこの一対一のマッピングの利便性を備えています。素数フィールドFpにおける一般的な簡約方法には、Barrett簡約、Montgomery簡約、およびMersenne-31やGoldilocks-64などの特定の有限体に対する特別な簡約方法が含まれます。バイナリフィールドF2kにおける一般的な簡約方法には、特別な簡約(AESで使用されるもの)、Montgomery簡約(POLYVALで使用されるもの)、および再帰的簡約(Towerなど)が含まれます。論文『Exploring the Design Space of Prime Field vs. Binary Field ECC-Hardware Implementations』では、バイナリフィールドは加算および乗算の演算においてキャリーを導入する必要がなく、バイナリフィールドの平方演算は非常に効率的であると指摘されています。なぜなら、それは(X + Y )2 = X2 + Y 2の簡略化されたルールに従うからです。
図1に示すように、128ビットの文字列:この文字列は、バイナリ領域の文脈においてさまざまな方法で解釈できます。128ビットのバイナリ領域のユニークな要素と見なすことができるほか、2つの64ビットタワー領域の要素、4つの32ビットタワー領域の要素、16の8ビットタワー領域の要素、または128のF2領域の要素として解析することもできます。この表現の柔軟性は、計算コストを必要とせず、単にビット文字列の型変換(typecast)であり、非常に興味深く有用な特性です。同時に、小さな領域の要素は、追加の計算コストなしにより大きな領域の要素にパッケージ化できます。Biniusプロトコルは、この特性を利用して計算効率を向上させています。さらに、論文「On Efficient Inversion in Tower Fields of Characteristic Two」では、nビットのタワー型バイナリ領域(mビットのサブ領域に分解可能)における乗算、平方、逆演算の計算複雑度について探求しています。
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Binius STARKs: 二進数ドメインの最適化による効率的な証明システム
Binius STARKsの原理とその最適化思考の解析
1. はじめに
楕円曲線に基づくSNARKsとは異なり、STARKsはハッシュベースのSNARKsと見なすことができます。現在、STARKsの効率が低い主要な理由の一つは、実際のプログラムにおける大多数の数値が小さいことです。例えば、forループ内のインデックス、真偽値、カウンターなどです。しかし、Merkleツリーに基づく証明の安全性を確保するために、Reed-Solomon符号を使用してデータを拡張する際、多くの追加の冗長値が全体の領域を占めてしまいます。たとえ元の値自体が非常に小さくてもです。この問題を解決するために、領域のサイズを小さくすることが重要な戦略となりました。
第1世代STARKsのエンコーディングビット幅は252ビット、第2世代STARKsのエンコーディングビット幅は64ビット、第3世代STARKsのエンコーディングビット幅は32ビットですが、32ビットのエンコーディングビット幅にはまだ大量の無駄なスペースが存在します。それに比べて、バイナリフィールドはビットを直接操作することを可能にし、エンコーディングはコンパクトで効率的であり、余分な無駄なスペースがありません。つまり、第4世代STARKsです。
Goldilocks、BabyBear、Mersenne31など、近年の新しい研究で発見された有限体と比較して、二進数体の研究は1980年代にまでさかのぼります。現在、二進数体は暗号学で広く利用されており、典型的な例には以下が含まれます:
F28ドメインに基づくAdvanced Encryption Standard (AES)。
Galoisメッセージ認証コード(GMAC)、F2128域に基づいて;
QRコードは、F28ベースのリード-ソロモン符号を使用しています;
原始FRIおよびzk-STARKプロトコル、さらにSHA-3ファイナリストのGrøstlハッシュ関数は、F28体に基づいており、再帰に非常に適したハッシュアルゴリズムです。
小さな体を使用する場合、拡張体の操作はセキュリティを確保するためにますます重要です。Biniusが使用する二進数体は、セキュリティと実際の可用性を保証するために完全に拡張体に依存する必要があります。ほとんどのProver計算に関連する多項式は、拡張体に入る必要がなく、基本体の下で操作するだけで、高効率を実現します。しかし、ランダムポイントチェックとFRI計算は、必要なセキュリティを確保するために、より大きな拡張体に深く入る必要があります。
バイナリーフィールドに基づいて証明システムを構築する際、2つの実際的な問題があります:STARKsにおいてトレース表現を計算する際に使用するフィールドのサイズは、多項式の階数よりも大きくする必要があります;STARKsにおいてメルクルツリーをコミットする際には、リード-ソロモン符号化を行う必要があり、使用するフィールドのサイズは符号化拡張後のサイズよりも大きくする必要があります。
Biniusは、これら2つの問題をそれぞれ処理する革新的なソリューションを提案し、同じデータを2つの異なる方法で表現することを実現しました:まず、単一変数の多項式の代わりに多変数(具体的には多線形)多項式を使用し、その値を「超立方体」(hypercubes)上で取ることで、全体の計算軌跡を表現します。次に、超立方体の各次元の長さが2であるため、STARKsのように標準のReed-Solomon拡張を行うことはできませんが、超立方体を正方形(square)として考え、その正方形に基づいてReed-Solomon拡張を行うことができます。この方法は、安全性を確保しながら、エンコーディング効率と計算性能を大幅に向上させます。
2. 原理分析
現在のほとんどのSNARKsシステムの構築には通常、以下の2つの部分が含まれます:
情報理論的多項式インタラクティブオラクル証明(Information-Theoretic Polynomial Interactive Oracle Proof, PIOP):PIOPは証明システムの核心として、入力された計算関係を検証可能な多項式等式に変換します。異なるPIOPプロトコルは検証者とのインタラクションを通じて、証明者が段階的に多項式を送信できるようにし、検証者は少量の多項式の評価結果を照会することで計算が正しいかどうかを検証します。既存のPIOPプロトコルには、PLONK PIOP、Spartan PIOP、HyperPlonk PIOPなどがあり、それぞれ多項式表現の処理方法が異なり、全体のSNARKシステムの性能と効率に影響を与えます。
多項式コミットメントスキーム(Polynomial Commitment Scheme, PCS):多項式コミットメントスキームは、PIOPによって生成された多項式等式が成立するかどうかを証明するために使用されます。PCSは暗号学的ツールの一つで、証明者は特定の多項式にコミットし、後でその多項式の評価結果を検証することができ、同時に多項式のその他の情報を隠すことができます。一般的な多項式コミットメントスキームにはKZG、Bulletproofs、FRI(Fast Reed-Solomon IOPP)、Brakedownなどがあります。異なる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ビットの文字列が唯一のフィールド要素に対応するわけではなく、バイナリフィールドはこの一対一のマッピングの利便性を備えています。素数フィールドFpにおける一般的な簡約方法には、Barrett簡約、Montgomery簡約、およびMersenne-31やGoldilocks-64などの特定の有限体に対する特別な簡約方法が含まれます。バイナリフィールドF2kにおける一般的な簡約方法には、特別な簡約(AESで使用されるもの)、Montgomery簡約(POLYVALで使用されるもの)、および再帰的簡約(Towerなど)が含まれます。論文『Exploring the Design Space of Prime Field vs. Binary Field ECC-Hardware Implementations』では、バイナリフィールドは加算および乗算の演算においてキャリーを導入する必要がなく、バイナリフィールドの平方演算は非常に効率的であると指摘されています。なぜなら、それは(X + Y )2 = X2 + Y 2の簡略化されたルールに従うからです。
図1に示すように、128ビットの文字列:この文字列は、バイナリ領域の文脈においてさまざまな方法で解釈できます。128ビットのバイナリ領域のユニークな要素と見なすことができるほか、2つの64ビットタワー領域の要素、4つの32ビットタワー領域の要素、16の8ビットタワー領域の要素、または128のF2領域の要素として解析することもできます。この表現の柔軟性は、計算コストを必要とせず、単にビット文字列の型変換(typecast)であり、非常に興味深く有用な特性です。同時に、小さな領域の要素は、追加の計算コストなしにより大きな領域の要素にパッケージ化できます。Biniusプロトコルは、この特性を利用して計算効率を向上させています。さらに、論文「On Efficient Inversion in Tower Fields of Characteristic Two」では、nビットのタワー型バイナリ領域(mビットのサブ領域に分解可能)における乗算、平方、逆演算の計算複雑度について探求しています。
! Bitlayer研究:Binius STARKsの原理分析と最適化思考
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:任意の点がブール超立方体上の多変数多項式でゼロであるかどうかを検証します∏x∈Hµ f(x) = 0,∀x ∈ Bµ, 多項式のゼロ点分布を確保するために。
SumCheck:多変数多項式の合計が宣言された値∑x∈Hµ f(x) = sであるかどうかを検出します。多変数多項式の評価問題を単変数多項式の評価に変換することで、検証者の計算の複雑さを低減します。さらに、SumCheckはランダム数を導入することで、複数の合計検証インスタンスのバッチ処理を実現する線形結合を構築することを可能にします。
BatchCheck:SumCheckに基づいて、複数の多変量多項式評価の正確性を検証し、プロトコールの効率を向上させます。
BiniusはHyperPlonkとプロトコル設計において多くの類似点がありますが、Biniusは以下の3つの点で改善を行っています:
ProductCheckの最適化:HyperPlonkでは、ProductCheckは分母Uが超立方体上で常に非零であることを要求し、積が特定の値に等しくなければなりません;Biniusはこの値を1に特化することで、このチェックプロセスを簡素化し、計算の複雑さを低減しました。
ゼロ除算の問題の処理:HyperPlonkはゼロの場合を十分に処理できず、超立方体上のUの非ゼロ問題を断言できませんでした;Biniusはこの問題を正しく処理し、分母がゼロの場合でもBiniusのProductCheckは処理を続け、任意の積の値に対して一般化を許可します。
列間PermutationCheck:HyperPlonkにはこの機能はありません;Biniusは複数の列間でPermutationCheckをサポートしており、これによりBiniusはより複雑な多項式の並べ替え状況を処理できるようになります。
そのため、Biniusは既存のPIOPSumCheckメカニズムを改善することにより、プロトコルの柔軟性と効率を向上させ、特により複雑な多変量多項式の検証を処理する際に、より強力な機能サポートを提供しました。これらの改善は、HyperPlonkの限界を解決するだけでなく、将来の二進法ドメインに基づく証明システムの基礎を築くことにもなります。
2.3 PIOP:新しいマルチラインシフト引数------ブールハイパーキューブに適用
Biniusプロトコルにおいて、仮想多項式の構築と処理は重要な技術の一つであり、入力ハンドルや他の仮想多項式から派生した多項式を効果的に生成し操作することができます。以下は二つの重要な方法です: