文章讨论了零知识证明系统中FRI和KZG等不同方案的优劣，以及Folding schemes、Lookup singularity和STARKs等新兴策略。强调工程实践中，除了理论计算，还需要考虑内存、硬件加速、代码维护等多种因素。同时，提倡通过基准测试和开源代码来促进零知识证明技术的发展，并鼓励社区对不同方案进行优化和比较。
最近，研究人员和工程师之间就最佳证明系统展开了相当多的辩论。例如，Justin Thaler 和 Srinath Setty 一直在讨论在计算方面，基于 FRI 还是基于 KZG 的 SNARK 更好，这是根据 Eli Ben-Sasson 在 SBC 期间的一些计算 得出的。在深入研究细节和我们对基准测试的看法之前，我们想说我们非常喜欢作者开发的所有工作，这些工作带来了新的想法和辩论，可以帮助扩展和改进零知识方案及其应用。我们从他们所有人那里学到了东西，但认为我们应该对什么在工程方面更有效或更有用有一些更清晰的标准。此外，正如 Zac Williamson 在 X 上的一次交流中指出的那样，性能和适用性有时取决于应用程序，他指出 SNARK 在客户端证明中可能更有优势。
如今，公开讨论的性能方面有三大策略：
随着时间的推移，一些想法可能会结合起来。与此同时，我们需要有一种方法来分析它们的实际潜力。我们可以使用粗略的计算来分析这些不同的策略和证明系统。但它们只是对操作总数的估计，因此应始终持保留态度。它们可能有助于评估某个系统或算法是否可以胜过另一个系统或算法，但不能作为性能的最终衡量标准。渐近复杂性也有类似的情况；我们知道有些算法从复杂性的角度来看可能是最佳的，但没有实际应用（著名的银河算法）。此外，在工程中，问题是多维的，并且不同部分之间存在大量交互。
在内存、数据通信、拥有硬件加速、代码可维护性、经济性等方面存在限制。例如，如果内存访问模式不适合缓存算法、数据预取和其他内存优化，则指令较少的程序可能会运行较慢。如果我们必须额外考虑算法和 GPU 的并行化程度，复杂性就会增加，而当我们可以将计算分配到多台机器之间时，复杂性会更大。与效率较低且可以分布在多个设备中的算法相比，只能在一台机器上运行的高效算法在某些情况下可能会更糟。这再次与 Zac 提到的非常相似。根据用例，选择算法的标准可能不同。在大多数情况下，软件中针对一个问题使用了多种解决方案，具体取决于场景，甚至在需要时将它们混合在一起。认为我们已经为所有问题找到了一个大解决方案，在所有场景中都是最佳的，这可能高估了应用世界的复杂性。有些关于操作数量的说法没有考虑到硬件施加的约束，或者使用特殊的域族来计算操作数量，这不适用于所选的椭圆曲线类型。例如，常用的 pairing-friendly 椭圆曲线是在素数上定义的，这些素数不具有与 Mersenne 素数或“MiniGoldilocks”素数相同类型的高效算术。
从我们的角度来看，Thaler 的这条 推文 中也看到了真实工程系统的复杂性的另一个例子。他问为什么 Starkware 继续使用相当大的有限域，尽管它没有提供优于较小有限域的任何优势。原因很简单：SHARP 是在许多改进之前开发的，并且已经投入生产多年。此外，对于可以投入生产的软件，我们需要的不只是一个证明器。我们需要语言、编译器、虚拟机、开发人员工具和区块链排序器。有很多工作要做，并且在已经投入生产且具有很大价值的系统上，急于通过每次可能的升级来改进证明器，可能是不负责任的。从纸上一个 brilliant 的想法到可以投入生产的系统，有很多工程工作要做，而且我们总是在前进的道路上发现更多最初没有考虑或难以预见的困难。
严格的分析，通过测量和对可能解决方案的良好理解，是关键。我们已经看到诸如 STARKs 对小型程序使用超过 100 GB RAM 的说法。尚不清楚比较的标准是什么，以及替代方案将使用多少 GB。重要的是利用开源软件并使用他人开发的工具，以检查它们是否按所述工作并证实数字。
我们认为 Nova 和 Lasso 带来了有趣的想法，这些想法可以激发其他证明系统的新解决方案。我们写了一篇关于 Nova 的文章，并且我们计划写一篇关于 Jolt 和 Lasso 的文章。我们甚至讨论过是否可以将其中一些想法改编为 STARKs 证明器。诸如 Nova 之类的折叠方案可以帮助解决许多与基于 Plonkish 或 R1CS 算术化的 SNARK 相关的问题。对于 Cairo 证明器，有一种压缩约束的策略。Cairo AIR 包含图灵完备虚拟机的所有指令的约束。约束的数量不会随计算大小而变化，这与执行跟踪相反，后者随程序的大小线性增长。然后，对跟踪进行插值，并通过商强制执行约束。因此，这里相关的度量是程序的步数，而不是约束的数量。应针对一些常用的计算或交易进行公平的测量，例如 ERC-20 合约。我们还应该注意不要将单项任务的速度视为唯一重要的因素。干净的代码库、易于维护和更新、鲁棒性、安全性、内存使用情况和可审计性也是需要考虑的因素。
我们喜欢 Celer Network 的基准测试 所做的工作，他们试图在使用 SHA-256 作为示例电路的不同证明系统之间进行公平的比较。也就是说，我们必须始终记住，一个项目或一个特定的团队可能会为了特定的基准测试而过度优化其代码库。很高兴看到 Celer 基准测试指出，要建立 Nova 的比较是相当困难的，正如他们所提到的“重要的是要认识到，就时间和计算而言，Nova 无法与其他框架直接比较。这种独特性源于 Nova 启用的增量计算能力。简而言之，将整个计算分解为更详细的步骤自然会导致内存消耗减少，即使它可能会导致计算时间增加。”我们指出，某些证明系统尚未完全优化，这可能会改变趋势。内存与速度之间的权衡可能对某些用例有利，但对其他用例则不然。
另一个值得注意的点是，有些人倾向于添加实际上不存在的约束，或者倾向于将一家公司使用的策略推广到所有其他可能的实现。例如，如果 A 使用 Poseidon 作为哈希函数，他们会假设 B、C 和 D 也应该使用 Poseidon，即使这可能不适合他们的特定应用。在递归环境中，我们可以使用 SNARK 证明我们验证了一个 STARK 证明，这有很多用例。当然，如果我们有一个递归验证证明树，那么在叶子中使用更快的哈希函数（例如 Blake2）没有问题，然后在第二层中证明我们使用 Poseidon 或其他哈希验证了使用 Blake2 的证明。
我们认为我们应该有明确的基准，使用在生产中使用的代码。当然，有一些新的技术或想法可能很有前景，我们应该去探索，但不应该急于跳上下一艘船，尤其是在用户资产或隐私受到威胁时。我们将把不同的证明系统实现到 Lambdaworks 库中，以便任何人都可以轻松地运行基准并检查哪个最适合他。此外，如果任何系统有优化，任何人都可以提交他们的 PR 来改进它们。我们不是任何证明系统的 maximalist；我们想要的是这项技术能够成功并在其之上开发应用程序。如果某个特定系统效果更好，我们将学习它并使用它。
我们认为辩论和拥有不同的观点对于将新的想法和改进带到桌面上非常重要，我们可以从中受益。拥有开源代码，而不仅仅是论文，可用于调整、分析和使用证明系统对于进行比较至关重要。Starkware 刚刚开源了其经过实战考验的 Stone 证明器，这将有助于改进和比较策略。我们也很喜欢 ZPrize 之类的倡议，团队在其中提出针对零知识证明中常见问题的开源优化。这可以让我们有机会探索不同的策略并得出在实践中效果最佳的算法。
