Binius：基于binary fields的SNARKs（Part 2）

1. 引言

前序博客有：

• Binius：基于binary fields的SNARKs（Part 1）
• Binius：助力ZK行业发展

本文重点关注：

• 1）concatenated codes：可扩展对small fields的多项式承诺方案
• 2）用于，check 基于多变量多项式的statements，的不同协议

2. Concatenated Codes

之前的 Binius：基于binary fields的SNARKs（Part 1） 博客中，已覆盖了对small fields的多项式承诺方案。
为开发通用承诺方案，首先需引入：

• 1）packing机制
• 2）concatenated codes

回顾下，small fields的多项式承诺方案中，基于的是a tower of fields：

• ${\tau }_0\subset {\tau }_1\subset \cdots \subset {\tau }_t$

对应为：

• linear inner code $[n_i,k_i,d_i]$：对应为${\tau }_i$域
• linear outer code $[n_{i+k},k_{i+k},d_{i+k}]$：对应为${\tau }_{i+k}$域

整个构建依赖于，将源自某field的多个元素进行packing，并将其解析为某扩域内元素：

• 可将${\tau }_i$中的$2^k$个元素，看成是${\tau }_{i+k}$中的某单个元素。
• 即，将${\tau }_i$看成是向量空间，类似与将复数，看成是基于实数的二维向量空间。

concatenated codes的编码流程为：

• 1）将基于${\tau }_i$的初始消息，pack进${\tau }_{i+k}$元素。如，有源自${\tau }_0$的4个bit变量$0,1,1,1$，可将其组合为${\tau }_2$的$0111$元素。
• 2）使用outer code来对packed message进行编码。如，可使用Reed-Solomon编码。
• 3）将codeword中的每个symbol，unpack为${\tau }_i$的某message。
• 4）使用inner code进行编码，并将编码元素进行concatenate。该编码可能是trivial的，即用于identity code。

所面临的问题之一是：

• 不得不使用extension code。

从而：

• 需在不同的fields之间来回切换：
  • 用于表示多项式系数的field
  • 用于表示code字母表的field
  • intermediate field
  • 用于密码学安全性的extension field：此处为${\tau }_t$。

为使用extension code，定义在（$2^{t-i}\times 2^k$个元素的）矩形数组内包含源自${\tau }_i$元素的结构：

• 每行有$2^k$个元素，可解析为一个${\tau }_{i+k}$元素。
• 每列有$2^{t-i}$个元素，可解析为一个${\tau }_t$元素。

可从2个维度来看该结构：

• 从列角度来看：将其看成是基于${\tau }_t$，维度为$2^k$的向量空间。
• 从行角度来看：将其看成是基于${\tau }_{i+k}$，维度为$2^{t-i}$的向量空间。

该数组，与某${\tau }_i$元素，的乘法运算，可解析为：

• 每个元素的乘法运算：
  • 可取每列（为单个${\tau }_t$元素），然后将每列与该元素相乘。
  • 可取每行（为单个${\tau }_{i+k}$元素），然后将每行与该元素相乘。

encoding-based多项式承诺方案的基本流程为：

• 1）$Commit(p)$：将多项式系数分配进某$m_0\times m_1$矩阵内，均为${\tau }_i$元素。以$2^k$为chunk size进行分组，并将其解析为${\tau }_{i+k}$元素。对每行应用extended encoding，获得size为$m_0\times n$的矩阵，其均为${\tau }_t$元素。基于列构建一棵Merkle tree，并将其root用作承诺值。
• 2）$Prove(p,s)$：Prover将多项式系数分配进某$m_0\times m_1$矩阵$(t_i{)}_{i=0}^{m_0-1}$内，均为${\tau }_i$元素。Prover计算并发送$t^{\prime }={\otimes }_{i=l_1}^{\ell }(1-r_i,r_i)\cdot (t_i{)}_{i=0}^{m_0-1}$ 给Verifier。
  • Verifier采样$\rho$个索引值 J : = { j 0 , j 1 , ⋯   , j ρ − 1 } \mathcal{J}:=\{j_0,j_1,\cdots,j_{\rho-1}\} J:={ j0​,j1​,⋯,jρ−1​}。
  • 对于所有的$j\in \mathcal{J}$，Prover将列$(u_{i,j}{)}_{i=0}^{m_0-1}$组成矩阵$U$，给Verifier发送编码后的矩阵$U$及其相应Merkle paths。
• 3）$Verify(\pi ,r,s)$：Verifier检查$t^{\prime }{\otimes }_{i=0}^{l_1}(1-r_i,r_i)=s$，然后：
  • Verifier将$t^{\prime }$按chunk size $2^k$分组，并应用extended code，unpacking所有元素来获得$u^{\prime }$。
  • Verifier检查所提供的所有列都包含在Merkle tree内，并检查${\otimes }_{i=l_1}^{\ell -1}(1-r_i,r_i)\cdot (u_{i,j}{)}_{i=0}^{m_0-1}\stackrel{?}{=}{u}_j^{\prime }$。

可根据：

• $t^{\prime }$（源自${\tau }_t$的$m_1$个元素），
• 列（包含源自${\tau }_{i+k}$的$\rho m_0$个元素）
• 对$\rho$个列的authentication paths

来计算 proof size。若单个digest size为$256$ bits，则proof size为：

• $2^t{m}_1+2^{i+k}\rho m_0+2^8\rho {\log }_{2}n$ 个bits。

3. 用于，check 基于多变量多项式的statements，的不同协议

Binius中包含了一系列由HyperPlonk提出的关键多项式协议：

• 1）Query
• 2）SumCheck
• 3）ZeroCheck
• 4）ProductCheck
• 5）Multiset Check
• 6）Permutation
• 7）LookUp

几乎所有协议底层都是sumcheck协议。关于sumcheck协议基础知识，可参看Justin Thaler的Proofs, Arguments, and Zero-Knowledge书籍。

ZeroCheck协议，可用于证明HyperPlonk中所强化的gate constraints。在ZeroCheck协议中，有：

• multilinear多项式$M$（用于强化trace），
• 和selector multilinear多项式$S_1,S_2,S_3$

使得对$0,1^n$内的每个点，有：
$0=S_1(M_0+m_1)+S_2{M}_0{M}_1+S_{3}G(M_0,M_1)-M_2+I$
其中：

• $M_0(x)=M(0,0,x)$
• $M_1(x)=M(0,1,x)$
• $M_2(x)=M(1,0,x)$

如何证明多变量多项式$P=S_1(M_0+m_1)+S_2{M}_0{M}_1+S_{3}G(M_0,M_1)-M_2+I$，对于$0,1^n$内的每个点，其值均为0呢？

• 由Verifier提供${\mathbb{F}}^n$内随机点$r_{zc}$
• Prover 构建多变量多项式：$P^{\prime }(x)=eq(r_{zc},x)P(x)$，其中$eq(x,y)=\prod (x_i{y}_i+(1-x_i)(1-y_i))$
• Prover 对$P^{\prime }(x)$运行sumcheck协议，其sum值为0。
• Verifier仅需对$P^{\prime }(x)$在$x=r_s$点处做一次evaluation即可。

对$P^{\prime }(x)$时候用sumcheck时，包含了非multilinear多变量多项式，即意味着，Prover在每轮，不得不发送degree最多为$d$的多项式。HyperPlonk对此进行了优化：

• Prover发送某degree最多为$d$的单变量多项式 的承诺值，并提供在单个点（而不是至少3个点）的evaluation值。

由于大多数协议最终都对应为sumcheck协议，可使用随机线性组合来batch多项式，将所有check reduce为单个sumcheck。
https://gitlab.com/UlvetannaOSS/binius 代码库中已实现了ZeroCheck、SumCheck和evaluation check。

Binius推荐使用Plonkish算术化：

• 其与HyperPlonk的主要区别在于：trace内包含的元素属于不同的subfields。
• 因此gate constraints需基于不同的subfields来表示relations。

当：

• 1）所有gate constraints成立。【对任意Plonk变种都成立】
• 2）所有全局copy constraints满足。【对任意Plonk变种都成立】
• 3）每个witness变量位于所规定的subfield。【因使用的是extension towers】

则该execution是有效的。前2个条件对任意Plonk变种都成立，最后一个条件引入的原因在于：使用的是extension towers。

4. 结论

本文介绍了如何将 Binius：基于binary fields的SNARKs（Part 1） 的承诺方案扩展为适于packed fields。可以以双重方式来看待域元素数组：

• 按列或按行排列元素。

随后，本文提出了一些用于check多变量多项式的关键协议，如：

• evaluation check、sumcheck、productcheck

这些都可归结为进行几次（可被batch的）sumcheck协议。

small-field多项式承诺方案 ＋ 关键协议，再加上一些算术化方案（如Plonkish），可用来生成SNARK方案。

HyperPlonk和Binius的主要区别在于Binius中的trace元素可能属于不同的子域。但是，这不会添加新的检查。相反，这可以取代HyperPlonk中的额外检查。这些子域检查由small-field多项式承诺方案的安全性来保证。

参考资料

[1] LambdaClass团队2024年博客 SNARKs on binary fields: Binius - Part 2

Binius系列博客

• 以更快的承诺方案助力Lasso/Jolt
• 关于Lasso、Jolt和SNARK设计最新进展的技术常见问题解答
• 基于Towers of Binary Fields的succinct arguments
• multilinear多项式承诺方案benchmark对比
• Binius：基于binary fields的SNARKs（Part 1）
• Binius：助力ZK行业发展