在快速发展的区块链和密码学领域,经常听说,旨在扩展以太坊或解决大规模计算问题 的 速度超快的零知识虚拟机 (zkVM,zero-knowledge Virtual Machine)。
然而,若要实现真正的隐私,ZKP应在本地运行。
基本原则简单但至关重要:
本文将深入探讨内存高效的ZKP世界,将探索:
读完本文,即能很好地理解:
Icme团队:
在深入研究内存效率型零知识证明的最新进展之前,了解客户端 ZK 实现的历史和演变非常重要。这段历史为内存效率为何成为该领域如此重要的关注点提供了重要背景。
2016 年,Jens Groth 推出了 Groth16 协议,这是零知识简洁非交互式知识论证 (zero-knowledge Succinct Non-interactive Arguments of Knowledge,zk-SNARK) 的重大进步。Groth16 提供了几个引人注目的功能:
这些特性使得 Groth16 对于区块链应用极具吸引力,因为最小化链上成本至关重要。然而,Groth16 要求每个电路都进行可信设置仪式,这对许多应用来说是一个严重的限制。
随着客户端 ZK 的潜力逐渐显现,需要一些工具来使实现更容易。Circom 应运而生,它是一种领域特定语言(domain-specific language,DSL)和编译器,可构建用于零知识证明的算术电路。Circom 允许开发人员用高级语言描述电路,然后可将其编译成适用于 Groth16 等 ZK 证明系统的约束。Circom 的工具包包括用于生成和验证 JavaScript 和 WASM 中proofs的工具。这使其成为基于浏览器的 ZK 任务的理想选择。
使用 Circom,开发人员完全可在网络浏览器中生成 ZK 证明。
许多项目使用 Circom-Groth16 栈来保护隐私。如最近的隐私 DeFi 项目Penumbra或 ZK 移动手机框架Mopro。但在这些之前,有一些著名的例子——如Tornado Cash。
客户端 ZK 最突出的早期应用之一是 Tornado Cash,这是以太坊的去中心化、非托管隐私解决方案。Tornado Cash 于 2019 年推出,它使用客户端 ZK 允许用户打破源地址和目标地址之间的链上链接,即实现更私密的交易。
以下是一个示例流程:
Tornado 展示了客户端 ZK 在增强区块链交易隐私方面的强大功能。然而,它也凸显了一些挑战:
这些挑战促使近期许多研究转向内存效率更高的 ZK 证明系统。其目标是让隐私保护 ZK 在更广泛的设备和用例中更易于访问和实用,为隐私保护技术的更广泛采用铺平道路。
Holographic或预处理 SNARK(以 Spartan 等系统为例)提供了一种有趣的方法来减少证明者开销。在这些系统中,证明者的工作可分为:
根据Srinath Setty 2024年7月28日twitter,Srinath Setty 指出,Spartan有一个简单的技巧,可以让证明者减轻负担:证明者的工作分为三个部分:
其中Spartan 证明者工作量最重的部分在“3)证明sparse multilinear多项式evaluations”。事实上,证明者90%以上的工作都在步骤3)中。幸运的是,步骤3)可以被任何无法访问witness多项式的人证明,因此可在不侵犯隐私的情况下将其卸载给任何不受信任的一方。这应该为证明者提供一个数量级的加速。步骤3)也可以一次被一堆客户端proofs证明,进一步分散不受信任实体的工作。
这里的关键见解是,第三步(占证明者工作量的 90% 以上)可以转移给不受信任的一方,而不会损害隐私。这种转移可以显著加快证明者的速度。此外,此步骤可以批量处理多个客户端证明,从而进一步分摊不受信任实体的工作。
但是,需要牢记一些重要事项。
值得注意的是,预处理技术可以应用于基本上任何预处理(或Holographic)SNARK。这些技术提供了通过允许提前完成一些工作或将工作转移到更强大的机器上来减轻证明者计算负担的方法。
零知识证明系统的最新进展带来了创新的空间节省技术,尤其是在sumcheck协议中。这些发展对于在资源受限的设备或网络浏览器中部署 ZKP 系统至关重要,为隐私保护应用程序开辟了新的可能性。
该领域的一项显著贡献是multilinear sumcheck协议的一系列新prover算法,其提供了灵活的时间-空间权衡。【详情见Alessandro Chiesa等人2024年8月论文《A Time-Space Tradeoff for the Sumcheck Prover》】
如,当 k=2 时,该算法的prover运行时间为 O(N)(其中 N 是sum中addends加数的数量),同时仅使用 O(√N) 空间。这比以前需要线性空间或超线性时间的方法有了显著的改进。不幸的是,目前尚不清楚这项工作是否可以用作 zkSNARKs 中的sumcheck,因为它只处理简单的多项式。
Ligetron是另一种新型零知识证明系统,其基于 Ligero 协议构建,实现了令人印象深刻的空间效率。Ligetron 的与众不同之处在于其处理待证明的底层计算的创新方法。Ligetron 不使用可能占用大量内存的扁平电路表示,而是使用 WebAssembly (WASM) 作为计算的中间表示。这使它能够利用原始高级代码的语义结构,从而节省大量内存。(详情见博客Ligero 和 Ligetron 中的 MPC 和 ZK)
Ligetron 的一个关键特性是其垃圾回收机制。
Ligetron 的空间效率在结构化计算中尤为明显。如,在他们对涉及 SHA256 哈希和编辑距离计算的组合电路的基准测试中,Ligetron 的内存使用量随着电路规模的增加而增长非常缓慢,这使得它仅使用几百MB的内存就可以处理数十亿门的电路。详情见Ligero团队2024年论文《Ligetron: Lightweight Scalable End-to-End Zero-Knowledge Proofs. Post-Quantum ZK-SNARKs on a Browser》。
此外,Ligetron 实现了这种空间效率,同时又不会牺牲太多的速度。其prover在单实例证明中每门运行时间约为 500(纳秒),在批量设置中每门运行时间则高达 65(纳秒)。
这些节省空间的协议和证明算法的进步代表着向着使零知识证明更加实用和广泛应用迈出的重要一步,特别是在内存限制是关键因素的场景中。
Nova和其他类似的folding方案使用不同的技术来提高空间效率。
IVC 类型递归的另一个好处是prover可选择步长。这意味着,若有一台功能强大的大型机器,可选择更大的步长并更快地进行证明,或者若有一台较小的机器,可选择最小的步长以匹配内存。
经测试,zkEngine 能够将证明步骤降低到每步约 50MB,这使得其适用于许多 DePIN 和客户端设备。
递归也存在于 STARKish 类型的系统中,Plonky2就是一个很好的例子。其使用 PLONK 和 FRI 的混合来达到速度和证明大小之间的平衡。通常,基于 FRI 的系统可以运行得非常快,但如果这样做,则证明大小会更大。Plonky2 希望消除这种权衡。ICME Lab团队预计Plonky2的递归开销会比 Nova 等系统大一点,使得可实现的最小内存开销大于递归系统中的开销;这本身并不坏,因为 Plonky2 的设计目标是实现最大速度,而不是最大空间效率。
递归是 ZKP 系统中用于控制prover在任何步骤所需的内存的核心工具。但是,当将上述所有空间效率技术结合起来时会发生什么?
最节省内存和性能的系统源自现有最佳技术的结合,并添加了一些新技术;这是内存高效 ZK 的前沿技术!
如,使用合作博弈论优化,如Shapley value跟踪,这些优化用于名为NovaNet的更全面的证明系统。该系统使用 NIVC(详情见2023年3月17日博客ZKWasm: Expanding the Horizons of Privacy-Preserving Technologies with SuperNova (Proving Universal Machine Executions Without Universal Circuits)),允许单点选择并只支付特定计算中使用的电路。在该系统中,可让 Ligetron prover在设备上运行,并在后期由更强大的prover完成聚合层,而 Ligetron 电路本身作为verifier电路运行。对于 JOLT(尚未启用隐私)prover、zkML 特定prover或可制成递归verifier电路的任何其他东西也是如此。
在预处理 SNARK 的情况下,点菜式选择也非常有吸引力,因为许多小型prover可在其设备上完成 10% 的工作,而更大的 NovaNet 网络中可能更大、更专业的机器可以完成 90% 的工作。NoveNet,Orchestrator 节点正在确定最有效的联盟来完成手头的任务,NULL 参与者不会得到任何东西,而相同的贡献会获得相同的价值。研究人员或开发人员可以添加他们优化的证明方案(专业化或更通用),并通过 NovaNet 获得激励。
“需要prover合作的地方,需要prover竞争的地方。”
多种技术的组合还可以产生具有预处理的 Ligetron,从而实现双倍内存效率的 ZK。或者具有递归的 JOLT。Icme团队对能够实现更好的设备 ZK 的组合感到非常兴奋——因为这是实现隐私和大规模本地可验证计算的唯一方法。在受限设备上获得更好的性能是全球采用 ZK 的关键一步,可以说是全球采用 web3 的关键一步。
[1] Icme团队 Wyatt Benno 2024年8月20日博客 Minimal Space, Maximum Pace: How memory efficient zero-knowledge proofs work