去中心化存储：

Filecoin 使用 ZKP（在 GPU 上运行）来证明网络中的节点正确存储数据。

区块链压缩：

Mina 和 Celo 使用 ZKP 将同步到链上最新状态所需的区块链数据压缩成一个小证明。

鉴于上述情况，可以肯定地说，随着加密资产采用率的增加，我们将需要 ZKP，以适应用户对性能和隐私以及新型应用程序和协议日益增长的需求。

ZKP 从根本上允许可扩展的私人支付和智能合约平台蓬勃发展，但也带来了巨大的开销，这在历史上阻碍了它们的采用。

为什么 ZKP 很慢，我们如何让它们变快？

证明计算需要首先将其从经典程序转换为 ZK 友好格式。这可以通过手动重写代码以使用 Arkworks 之类的低级库来实现，也可以通过使用 Cairo 或 Circom 之类的域特定语言来编译成必要的原语来生成证明。

而更昂贵和更复杂的操作会导致更长的证明生成时间。一些操作对 ZK 不友好（例如 SHA 或 Keccak 中使用的逐位操作）也很常见，这导致在经典计算机上可能是廉价操作的证明生成时间很长。

一旦您的计算采用 ZK 友好的形式，你就可以选择一些输入并将其发送到证明系统。目前已经有很多证明系统，一些以论文作者的名字命名（例如 Groth16、GM17），另一些则以更具创造性的名字命名（PLONK、Spartan、STARK）。它们的共同点是，它们接受一个以 ZK 友好格式表示的计算，以及一些输入，并输出一个证明。

根据证明系统的不同，证明生成过程可能会有所不同，但瓶颈始终是：

对大型数字向量（字段或组元素）的乘法，特别是可变基数和固定基数多标量乘法（MSM）；或

快速傅里叶变换（FFT）和逆快速傅里叶变换（IFFT）（尽管有一些技术适用于无 FFT 证明系统）；

在同时存在 FFT 和 MSM 的系统中，大约 70% 的生成证明时间都花在 MSM 上，而其余时间则由 FFT 主导。

MSM 和 FFT 都很慢，但也都有提高性能的方法：

MSM 可以通过在多个线程上运行它们来进行加速。然而，即使在数百个内核上，如果每个元素向量的长度为 2^25（即 3300 万个元素，对于像 zkEVM‌ 这样的应用程序来说，这是一个保守的复杂度范围），那么乘法最终仍然会花费大量时间。这意味着经常重复相同的操作，并且会耗尽设备上的大部分可用内存。简而言之，MSM 需要大量内存，并且即使在高度并行化时仍然会很慢。

FFT 严重依赖算法运行时数据的频繁洗牌。这使得它们很难通过在计算集群中分配负载来实现加速，正如 DIZK ‌所示。此外，它们在硬件上运行时需要大量带宽。重组意味着你需要“随机”加载和卸载元素，例如，在内存等于或少于 16 GB 的硬件芯片上，从大于 100 GB 的数据集中加载和卸载元素。虽然硬件上的操作非常快，但通过网络加载和卸载数据的时间最终会显着减慢操作速度。 (责任编辑：admin)