基于Plookup实现Sha256和Keccak

1. 引言

在AztecProtocol的 Barretenberg 中，基于plookup table实现了Sha256 constraint system，该plookup table针对的为：

• majority function：$maj(x,y,z)=(x\wedge y)\oplus (x\wedge z)\oplus (y\wedge z)$
• choose function：$ch(x,y,z)=(x\wedge y)\oplus (\neg x\wedge z)$

2. majority plookup table

x	y	z	maj(x,y,z)	x+y+z
0	0	0	0	0
0	0	1	0	1
0	1	0	0	1
0	1	1	1	2
1	0	0	0	1
1	0	1	1	2
1	1	0	1	2
1	1	1	0	3

3. choose plookup table

x	y	z	choose(x,y,z)	x+2y+3z
0	0	0	0	0
0	0	1	1	3
0	1	0	0	2
0	1	1	1	5
1	0	0	0	1
1	0	1	0	4
1	1	0	1	3
1	1	1	1	6

4. 抽象

将2和3中的plookup table中的第4列中的majority和choose函数 统一抽象为logical 函数$log(x,y,z)$，将最后一列的运算抽象为algebraic encoding函数$alg(x,y,z)$。
目标为，寻找transformation $f$ 实现 $alg\to log$。

详细的抽象思路为：

• 1）对于所有的arguments $c$ in $(x,y,z)$，由二进制$c=\sum c_i{2}^i$表示 转为 由sparse $c_{sparse}=\sum c_i{b}^i$表示，其中$b$用于防止algebraic encoding函数中的值溢出即可，如对于majority函数，可令$b=4$；而对于choose函数，可令$b=7$。
  实际实现时，可将$c$ split为合适size的chunks，来mapping each chunk to sparse representation separately (通过查表实现)，然后take linear combination of transformed chunks。
• 2）不再直接对$(x,y,z)$进行逻辑运算，而是对其sparse encodings $(x_{sparse},y_{sparse},z_{sparse})$进行algebraic操作。对于majority和choose，其algebraic operations仅为简单的linear combinations，仅需一个single PLONK gate即可实现。
• 3）normalization：将结果有sparse form转换为binary form，即将each chunk $[0;b-1]$ map为 { 0 , 1 } \{0,1\} {0,1}，通过上面定义的one-to-one $f$ 函数即可实现。

以上抽象，可在两个维度实现更紧凑的constraint systems：

• 1）减少所使用的table数量：由为每个基础逻辑操作（如$\wedge ,\neg ,\oplus$等）定义不同tables，改为，仅需定义2个table——一个用于将number转换为sparse form，另一个用于将sparse from转换为number。
• 2）可减少所需用到的gate总数。

不过，以上抽象对事情进行了简化。实际Sha256 hash运算中包含了复杂的逻辑运算和circular rotations。以上抽象适于表达复杂的逻辑运算，但是不适于表达circular rotations。

AztecProtocol的 Barretenberg 中，为了解决circular rotations运算，引入了几种不同的tables来做rotation and convertion to sparse form in one fell swoop。该策略适于（尽管仍然不太理想）当Sha256中the number of different rotation moduli is rather small，但是当用于Keccak时有严重的障碍，因为在Keccak中要求each of 25 lanes is shifted by unique modulus。

sparse algebraic encoding for $x$ in base $b$ 表示为：
$x={\sum }_i^n{x}_i{b}^i$
其中每个$x_i\in [0,c-1]$。
事实上，对$b$的选择仅限制要求：
all separate chunks $x_i$ should be uniquely decodable and retrieved from $x$，即：
map $([0,c-1]\times n)\to \mathbb{F}:(x_0,\cdots ,x_n)\to {\sum }_i^n{x}_i{b}^i$ 为injective。

最简单的方式是选择$b=c$，但实际上，可令$b=c+1$或$b=2c$等等，只要$x={\sum }_i^n{x}_i{b}^i$ 不会wrap around modulus $p$ of field $\mathbb{F}$。
但是，若令$b=g$，$g$为root of unity of order $n$，尽管其会force $x$ wrap around $p$（从而不满足injective条件），但是却对rotations超级友好：
$g^n=1,g^i\ne 1,\forall i<n$

若是能让$b=g$时，仍满足injective条件，则两个目标都达成了：

• 1）logical operations are encoded as algebraic relations and are done on chunk-to-chunk basis
• 2）numbers are rotated by multiplication by corresponding powers of $g$。

若以上两个目标都可达成，则可使用相同的Plonk gates来表示rotations和arithmetic。

事实上，appliedzkp在zkevm实现中，重点关注的是以下2种特殊情况下的injectivity问题：

• 1）$c=8,n=32$：用于高效实现Sha256 gadget。
• 2）$c=8$或至少$c=4$，$n=64$：用于Keccak

注意，当$c=8,n=32$时，Sha266的所有linear combinations ${\sum }_i{x}_i{g}^i$组合总数为$8^{32}=2^{96}$，因此，无法通过brute-force的方式来检查injectivity。
若针对injectivity problem的存在更强健的正向解决方案，则可进一步减少Sha256和Keccak Plookup实现中所需的gate和table数量。

参考资料

[1] Thoughts on Plookup implementation of Sha256 and Keccak