为何需关注各ZKP方案的benchmarks？

news2024/9/22 3:43:48

1. 引言

近期，研究人员和工程人员有大量关于谁是最好的证明系统的争论：

2023年8月29日，StarkWare团队对比了FRI和KZG
2023年8月30日，JustinThaler和Srinath Setty讨论FRI和KZG谁的性能更佳？

在这里插入图片描述

不过，在深入benchmark细节之前，需有一些更明确的标准来说明是什么使某些东西在工程方面更具性能或更有用。此外，性能和适用性有时取决于应用场景，Zac Williamson指出：

SNARK在客户端证明中可能更有利。

当前，在性能方面有3大公开广泛讨论的策略：

1）Folding schemes
2）Lookup singularity
3）STARKs with small fields

随着时间的推移，这些思想可能会融合。与此同时，需要有一种方法来分析它们的实际潜力：

可以使用envelop calculations来分析这些不同的策略和证明系统。但：
- envelop calculations分析法只是对运算总数的估计，因此应始终持谨慎态度。
- envelop calculations分析法可能有助于评估某个系统或算法是否优于另一个，但不能作为性能的最终衡量标准。
与asymptotic complexity类似：从复杂性的角度来看，可认为某些算法可能是最优的，但这些算法没有实际用例（如著名的Galactic算法）。
此外，在工程上，问题是多维的，不同部分之间有很多相互作用：
- 内存、数据通信、硬件加速、代码可维护性、经济性等方面都存在限制。
- 如，若不适合缓存算法、数据预取和其他内存优化，内存访问模式可能会导致指令较少的程序运行速度较慢。
- 若必须额外考虑算法和GPU的并行度，复杂性就会增加，当在多台机器之间分配计算时，复杂性甚至会增加。
- 某些情况下，只能在一台机器中运行的高效算法，可能比，效率较低且可分布在多个设备中的其他算法，更差。
- 这又一次与Zac提到的内容非常相似。根据实际应用场景，可能有不同的算法选择标准。
- 在软件中，大多数情况下，一个问题的多个解决方案会根据场景来选择使用，甚至在需要时混合使用。
- 若认为存在一个解决所有问题的宏伟方案，在所有情况下都是最优的，这就可能高估了应用世界的复杂性。
- 有关于运算次数的说法没有考虑硬件施加的限制，或者使用特殊的域族来计算运算次数，但该域不适用于所选的椭圆曲线类型。例如，常用的pairing-friendly椭圆曲线是在不具有相同类型的有效运算的素数上定义的，例如Mersenne素数或“MiniGoldilocks”素数。

类似地，Justin Thaler也指出了真实工程系统中的复杂性。ustin Thaler问为什么Starkware继续使用一个相当大的有限域，尽管它与较小的域相比没有任何优势。原因很简单：

SHARP是在许多改进之前开发的，并且已经投入生产使用了很多年。
更重要的是，对于生产就绪的软件，我们需要的不仅仅是一个prover。
- 我们需要语言、编译器、虚拟机、开发人员工具和区块链sequencers。
- 有很多工作要做，在一个价值巨大的生产系统上，急于通过每一次可能的升级来改进prover可能是鲁莽的。
- 从论文中的一个绝妙想法到实际可投产使用的系统，有很多工程工作，在这一过程中，我们总是发现更多的困难，这些困难最初没有被考虑，或者很难预见。

关键是，通过评估和对潜在解决方案的良好理解，进行批判性分析。当前已看到像某些claims，如STARK使用了超过100 GB的RAM用于小程序。目前尚不清楚比较的标准是什么，以及替代品将使用多少GB。重要的是要利用开源软件，利用他人开发的工具，检查它们是否按规定工作，并证实数字。

Nova和Lasso带来了有趣的想法，可为其他证明系统带来新的解决方案。诸如Nova之类的折叠方案可以帮助解决许多与基于Plonkish或R1CS算术的SNARK相关的问题。
在Cairo Prover的案例中，有一种策略可压缩约束。Cairo AIR包含了对图灵完备虚拟机的所有指令的约束：

约束的数量不随计算大小而变化
而execution trace则随程序大小线性增长
然后对execution trace进行插值，并通过quotients来强化约束。

因此，Cairo Prover的相关度量是：

程序的步骤数，而不是约束的数量。应对一些常用的计算或交易（如ERC-20合约）进行公允计量。
同时还应谨慎对待将单个任务的速度视为唯一重要的事情的情况。
干净的代码库、易于维护和更新、健壮性、安全性、内存使用和可审计性也是需要考虑的因素。

Celer Network在基准测试中所做的工作为：

试图在不同的证明系统之间进行公平的比较，使用SHA-256作为示例电路。

也就是说，须始终记住，对于一个项目或特定团队来说，为特定的基准过度优化其代码库可能会变得很诱人。Celer指出：

很难对Nova进行比较，因为，“重要的是要认识到，Nova在时间和计算方面无法与其他框架直接比较。这种独特性源于Nova所提供的增量计算能力。简单地说，将整个计算分解为更详细的步骤自然会减少内存消耗，尽管这可能会导致计算时间的增加。”

同时，一些证明系统没有充分优化，这可能会改变趋势。内存与速度的权衡可能对某些用例很方便，但对其他用例则不方便。

另一点值得注意的是，有些人倾向于添加实践中不存在的约束，或者倾向于将一家公司使用的策略推广到所有其他可能的实现中。如，若A使用Poseidon作为哈希函数，则假设B、C和D也应该使用Poseion，即使这可能不适合B、C、D的特定应用。
在递归（recursive）环境中，可以用SNARK证明"验证了STARK证明"，这有很多用例。
当然，若有a tree of recursive proofs of verifications，那么对叶子节点使用更快的哈希函数（如Blake2），然后在第二层中proving that we verified proofs that used Blake2, with Poseidon or other hash，就不会有任何不便。

对于生产中所使用的代码，应该有明确的基准。当然，有些新技术或想法可能很有前景，我们应该探索，但永远不应该过于草率地跳上下一条船，尤其是当用户的资产或隐私受到威胁时。Lambda Class团队将在Lambdaworks库中实施不同的证明系统，这样任何人都可以轻松地运行bench，并检查哪一个最适合自己。此外，若对任何系统进行了优化，任何人都可以提交PR来改进。Lambda Class团队不是任何证明体系的最高主义者；Lambda Class团队想要的是这项技术取得成功，并在此基础上开发应用程序。如果某个特定的系统工作得更好，Lambda Class团队就会学习并使用它。

Lambda Class团队认为：