Aztec的客户端证明

1. 引言

隐私保护 zk-rollup 的证明生成与通用 zk-rollup 的证明生成有很大不同。原因是给定交易中存在特定数据（由私有函数处理），我们希望保持完全私有。在本文中，我们探讨了用于证明私有函数正确执行的客户端证明生成，并解释了它与通用汇总中的证明生成有何不同。

本文主要结构为：

1）何为proofs？及其在通用zkRollups中的工作原理
2）Aztec proofs工作原理
3）证明函数的正确执行
- 对于公共函数：rollup端生成证明
- 对于私有函数：客户端生成证明
4）proof示例
5）客户端证明生成如何降低内存需求
6）附录：客户端证明生成的其他细节。
7）总结

2. 何为proofs？及其在通用zkRollups中的工作原理

在深入研究 Aztec 的证明，特别是 Aztec 的 zkRollup 的隐私优先性质之前，先回顾一下通用zkRollups上的proofs的工作原理。
当有状态区块链执行交易时，它会进行状态转换。若网络最初的状态是A，那么在网络上执行一组交易（一个区块），现在网络的状态是B。

Rollups 也是有状态的区块链。他们使用证明来确保状态转换正确执行。为每个块生成并验证证明。所有证明都发布在 L1 上，任何人都可以重新验证它们，以确保状态转换正确完成。

对于通用 zkRollups，证明生成非常简单，因为所有数据都是公开的。sequencer和prover都可以看到所有交易数据，公共状态是公开的，并且重建每个状态转换所需的数据都发布在 L1 上。

3. Aztec proofs工作原理

Aztec 的 zkRollup 是一个不同的故事。在 Aztec 网络中，有两种类型的状态：公共状态和私有状态。
在这里插入图片描述
Aztec 智能合约（用Noir编写）由两种类型的函数组成：

私有函数：用户拥有的状态、客户端证明生成
公共函数：全局/公共状态、汇总端证明生成

对二者均需要正确执行的证明。然而，由于私有函数和公共函数的结构有很大不同，它们的证明生成也有很大不同。

简单概述一下Aztec智能合约的执行方式：首先执行所有私有函数，然后执行所有公共函数。
在这里插入图片描述
然而，深入剖析 Aztec 智能合约超出了本文的范围。要了解更多信息，可查看2024年2月22日博客WTF is Aztec?。

本文将重点关注私有函数正确执行的证明生成以及为什么它是隐私优先 zkRollup 的关键要素。

4. 证明函数的正确执行

区块链中私有状态和私有函数的概念可能看起来有点不寻常。

4.1 证明公共函数正确执行——rollup端生成证明

对于公共函数：

rollup端生成证明

首先看公共函数的执行，因为它与其他通用 zkRollups 更相似。

公共状态是每个人都可以使用的全局状态。sequencer执行公共函数，而prover生成正确的执行证明。特别是，最后一步意味着函数（用Noir编写）被编译为特定类型的程序表示形式，然后由虚拟机 (VM) 电路进行evaluate评估。已评估意味着它将一条一条地执行一组指令，从而得出正确执行或失败的证明。rollup端prover可以处理繁重的计算，因为它在强大的硬件上运行（即不是客户端情况下的智能手机或计算机浏览器）。

4.2 证明私有函数正确执行：客户端生成证明

对于私有函数：

客户端生成证明

另一方面，私有状态由用户拥有。当生成私人交易正确执行的证明时，希望所有数据保持私密。这意味着不能（像公共状态那样）拥有第三方prover，因为数据随后会暴露给prover，从而不再是私有的。

在私人交易的情况下，交易所有者（唯一知道交易数据的人）应自行生成证明。也就是说，私人交易正确执行的证明必须在客户端生成。

这意味着每个 Aztec 网络用户都应该能够在其智能手机或笔记本电脑浏览器上生成证明。此外，由于 Aztec 智能合约可能由许多私有函数组成，因此每个 Aztec 网络用户应该能够生成许多证明（每个私有函数一个证明）。

在 rollup 方面，区块证明是使用 ZK-VM（ZK 虚拟机）生成的。
在私有方面，没有VM。相反，每个私有函数都被编译成自己的静态电路。

所谓“电路”，是指填充了一些预先计算值的表。该表描述了在特定代码运行期间要执行的指令序列（如 MUL 和 ADD）。

表的行和列之间有一堆预定义的关系，如，复制约束规定多条wires的值应相同。
在这里插入图片描述
在上图中，有两个门，门 1 (+) 和门 2 (x)。可看到，z既是门 1 的输出（表示为 w3，线路 3），又是门 2 的左侧输入（表示为 w4，线路 4）。因此，需保证门1的输出值与门2的左输入值相同。即w3 = w4。这即是“checking copy constraints检查复制约束”。

当verifier验证电路时，其会检查这些预定义关系是否适用于所有行和列。

5. proof示例

以下示例以简化的方式反映了一般逻辑。真正的功能要复杂得多：
假设有一个函数a² + b² = c² 。目标是证明特定输入和输出的等式成立。假设 a = 3、b = 4、c = 5。

作为一段代码，可将函数表示为：
在这里插入图片描述
当函数执行时，每一步的结果都会记录在表中。当该表填充了特定函数对特定值的执行结果时，被称为execution trace。

这只是表的一个片段，包含值和操作码名称。然而，要指示计算机应在哪个特定行中执行哪个操作，仅操作码名称是不够的，还需要selectors选择器。
选择器是指切换操作的门（如开/关开关）。在本例中将使用带有两个选择器的简化 Plonk 方程：

q_ ADD用于加法门，
q_ MUL用于乘法门。

简化的 Plonk 方程为：

q_ MUL (a * b) + q_ ADD (a + b) – c = 0 。

打开和关闭它们，即赋值1和0，方程将转化为不同的运算。例如，要执行 a 和 b 的加法，我们设置q_ ADD = 1，q_ MUL = 0 ，因此方程为a + b – c = 0 。

因此，对于每个执行的操作，还将其选择器存储在表中：
在这里插入图片描述

6. 客户端证明生成如何降低内存需求

对于私有函数，由于每个函数都被编译成静态电路，所以所有需要的选择器都被预先放入表中。特别是，当编译智能合约函数时，它会输出包含一组选择器的验证密钥。
在智能合约的情况下，电路要大几个数量级，因为它包含更多带有用于公共函数执行的选择器的列。此外，还有更多的关系检查要做。如，需要检查智能合约字节码是否确实执行了预期的操作（即，所打开的选择器是根据提供的字节码承诺来打开的）。
在这里插入图片描述
作为一种心理模型，可将智能合约电路视为一个表，其中 70 列中的 50 列保留用于选择器的查找表。存储整个表需要大量内存。
客户端和rollup端证明生成的电路大小之间的差异：

在客户端，电路要小得多，内存和计算要求较低。这是为什么能够在用户设备上生成私有函数正确执行的证明的关键原因之一。

7. 附录：客户端证明生成的其他细节

为了进一步降低prover的内存和计算需求，使用了特定的证明系统 Honk。HonK是由Aztec Labs开发的高度优化的 Plonk 。Honk 是 Plonk-ish算术化、sum-check协议（有一些很好的内存技巧）和multilinear多项式承诺方案的组合。
一些可以添加到 Honk 中以使其更加高效的小工具包括Goblin Plonk（由 Aztec Labs 开发的一种特定类型的递归）以及ProtoGalaxy（由 Liam Eagen 和 Ariel Gabizon 开发）。
- Goblin Plonk 允许资源受限的prover构建具有多层递归的 zk-snark。这完全适合客户端证明生成的情况，其中智能合约中每个私有函数的证明是递归的附加层。技巧在于每个递归层的昂贵操作（如椭圆曲线操作）被推迟到最后一步，而不是在每个递归层执行。递归以智能合约中所有私有函数的一个证明结束。
- 然后，该证明由rollup电路进行验证。该证明的递归验证非常耗费资源。然而，由于它是在rollup端执行的，因此它具有足够的计算和内存资源。
- ProtoGalaxy 是一种优化递归verifier工作的folding方案。它允许在一个步骤中折叠多个实例，将verifier在每个折叠步骤中的工作量减少到一个常数。