ここで「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ビットのサブフィールドに分解可能)での乗算、平方、逆演算の計算の複雑さについて検討しています。
Binius STARKsの原理解析:バイナリーフィールドによる効率的な証明システムの構築
Binius STARKsの原理とその最適化思考の解析
1 はじめに
STARKsの効率が低下する主な理由は、実際のプログラム内の大多数の数値が小さいことです。例えば、forループ内のインデックス、真偽値、カウンターなどです。しかし、Merkleツリー証明の安全性を確保するために、Reed-Solomon符号を使用してデータを拡張する際には、多くの追加の冗長値が全体の領域を占めることになります。原始的な値自体が非常に小さい場合でもです。この問題を解決するために、領域のサイズを縮小することが重要な戦略となりました。
第1世代STARKsのエンコードビット幅は252ビットであり、第2世代STARKsのエンコードビット幅は64ビット、第3世代STARKsのエンコードビット幅は32ビットですが、32ビットのエンコードビット幅には依然として大量の無駄なスペースが存在します。それに対して、バイナリフィールドはビットに対して直接操作を行うことを許可し、エンコードはコンパクトで効率的であり、無駄なスペースがありません。つまり、第4世代STARKsです。
Goldilocks、BabyBear、Mersenne31など、近年の新しい研究で発見された有限体と比較して、2進数体の研究は1980年代にさかのぼります。現在、2進数体は暗号学に広く使用されており、典型的な例には次のものが含まれます:
高度な暗号標準(AES)、F28フィールドに基づいて;
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システムの構築には通常、以下の二つの部分が含まれています:
情報理論的多項式インタラクティブオラクル証明(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 + Brakedown PCS + 二進制域。具体而言,Binius包括五项关键技术,以实现其高效性和安全性。首先,基于タワー型二進数域(towers of binary fields)の算術的構成がその計算の基礎を成し、二進数域内で簡略化された演算を実現します。次に、Biniusはそのインタラクティブオラクル証明プロトコル(PIOP)において、HyperPlonkの積と置換チェックを改編し、変数およびその置換間の安全で効率的な一貫性チェックを保証しています。第三に、プロトコルは新しい多項式シフト証明を導入し、小さな域上で多項式関係を検証する効率を最適化しています。第四に、Biniusは改良版のLasso探索証明を採用し、探索メカニズムに柔軟性と強力な安全性を提供しています。最後に、プロトコルは小域多項式コミットメントスキーム(Small-Field PCS)を使用し、二進数域上で効率的な証明システムを実現し、通常大域に関連するオーバーヘッドを削減しています。
2.1 有限体:二値体の塔に基づく算術
タワー型二進数体は、高速で検証可能な計算を実現するための鍵であり、主に二つの側面によるものです:効率的な計算と効率的な算術化です。二進数体は、本質的に高度に効率的な算術操作をサポートしており、性能要件に敏感な暗号学的アプリケーションに理想的な選択肢となります。さらに、二進数体の構造は、簡略化された算術化プロセスをサポートしており、二進数体上で実行される演算は、コンパクトで検証しやすい代数形式で表現できます。これらの特性に加え、タワー構造を通じてその階層的特性を十分に活用できることから、二進数体は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:二つの多変数集合が等しいかどうかをチェックします。つまり、{(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とプロトコル設計において多くの類似点があるにもかかわらず、以下の3つの点で改善を行いました:
ProductCheckの最適化:HyperPlonkでは、ProductCheckは分母Uが超立方体上で常に非零であることを要求し、積は特定の値に等しくなければなりません;Biniusはこの値を1に特化することで、このチェックプロセスを簡素化し、計算の複雑さを低減しました。
ゼロ除算の問題処理:HyperPlonkはゼロの場合を十分に処理できず、超立方体上のUの非ゼロ性を主張することができませんでした;Biniusはこの問題を正しく処理し、分母がゼロの場合でもBiniusのProductCheckは処理を続行でき、任意の積値に拡張を許可します。
列間PermutationCheck:HyperPlonkにはこの機能がありません;Biniusは複数の列間でPermutationCheckをサポートしており、これによりBiniusはより複雑な多項式の排列状況を処理することができます。
したがって、Biniusは既存のPIOPSumCheckメカニズムを改善することにより、プロトコルの柔軟性と効率を向上させ、特により複雑な多変数多項式検証を処理する際に、より強力な機能サポートを提供しました。これらの改善は、HyperPlonkの限界を解決するだけでなく、将来の二進法領域に基づく証明システムの基盤を築くものです。
2.3 PIOP:新しいマルチリンシフト引数------ブールハイパーキューブに適用
Biniusプロトコルでは、仮想多項式の構築と処理が重要な技術の一つであり、入力ハンドルや他の仮想多項式から派生した多項式を効果的に生成および操作することができます。以下は二つの重要な方法です: