零知识证明开发指南：从入门到高阶

去年夏天，Vitalik 写了一篇博文，概述了不同类型的 zkEVM（零知识以太坊虚拟机）。Vitalik 根据性能和兼容性来定义与权衡。

这是一个非常有用的启发式方法，以区分支持zkEVM的方法。然而，zkEVM是构建零知识应用程序的所有可能方法的一个子集。对于想要利用zk计算的独特属性，即简洁性、零知识和正确性的程序员来说，zkEVM可能不是最好的选择。通过阐述整个开发工具集，本文希望提供一个指南，帮助开发者在决策过程中选择合适的zk堆栈。

抽象复杂度的力量

在过去的一两年中，zk工具有了巨大的进步。使得普通软件的开发人员可以利用zk的强大属性，而不需要深入了解令人生畏的基础数学和工程。另一方面，为高级用户提供的工具激增，使 zk 专家能够极其精细地控制 zk 堆栈。

现代软件是建立在无数的抽象层上的，以最大限度地提高专家的生产力。工程中的抽象有许多优势，这些优势在某种程度上是直观的–网络开发者不需要深入了解操作系统的工作原理。

建立良好的、可重复使用的抽象层的关键是封装一个层的复杂性，然后为堆栈中更高的层提供简单但有表现力的接口。正确的做法是，这使得具有不同专业领域和知识的开发人员能够在整个堆栈中建立有用的工具。

毫不奇怪，这些原则也适用于zk系统，而且这些抽象层正变得足够成熟，一个zk新手今天就可以开始使用它们并构建应用程序。

zk堆栈与各层的一些工具/技术实例

低级别的zk开发

Arkworks-rs

Arkworks-rs是一个Rust库的生态系统，它为zkSNARK应用程序的子组件提供高效和安全的实现。Arkworks为开发者提供了必要的接口，以定制zk应用程序的软件栈，而不必重新实现与其他现有库的共性。

在Arkworks之前，创建一个新的zk应用程序的唯一方法是从头开始构建一切。与定制的垂直整合工具相比，Arkworks-rs的主要优势在于其灵活性水平，减少重复工程，以及减少审计工作。Arkworks组件之间合理的接口线允许升级的速度，可以使堆栈在zk技术快速创新的过程中保持相关性，而不会迫使团队从头开始重建一切。

优点

• 通过模块化实现灵活性
• 减少重复代码
• 降低工程成本
• 减少审计/bug的表面积
• 无需重大重构即可升级任何组件
• 易于在快速发展的 zk 环境中试验新原语

缺点

• 需要深入了解完整的软件堆栈
• 如果没有正确理解，太多的控制会导致脚枪
• 精细控制需要堆栈所有级别的专业知识。
• Arkworks 确实提供了一些合理的默认设置。

zk领域专用语言(DSL)

为了创建一个关于某些计算的证明，首先这个计算必须以一个zkSNARK系统可以理解的形式来表达。一些特定领域的语言已经创建了编程语言，允许应用开发者以这种方式表达他们的计算。这些语言包括Aztec Noir、Starknet的Cairo、Circom、ZoKrates和Aleo的Leo等等。底层的证明系统和数学细节一般不会暴露给应用开发者。

开发者的经验

zkApp的开发者必须熟练地用特定领域的语言编写程序。其中一些语言看起来很像我们熟悉的编程语言，而其他语言可能相当难学。让我们来分析一下其中的几个。

Cairo – Starkware DSL对于在Starknet上构建应用程序是必要的。编译成Cairo特有的汇编语言，可由Cairo zkVM解释。

ZoKrates – ZoKrates是一个满足SNARK常见需求的工具包，包括一种编写电路的高级语言。ZoKrates在曲线、证明方案和后端方面也有一些灵活性，允许开发者通过简单的CLI参数进行热交换。

Circom — Circom 是一种用于构建电路的专用语言。目前，它是生产电路的实际语言。该语言不是特别符合人体工程学，使开发者敏锐地意识到正在编写电路。

Leo——Leo 被开发为 Aleo 区块链的语言。Leo 有一些类似 Rust 的语法，专门用于区块链内部的状态转换。

Noir – 受 Rust 启发的语法。围绕 IR 而不是语言本身构建，这意味着它可以有一个任意的前端。

适用于谁

任何想要在其应用程序中利用zk的独特属性的应用程序开发人员。

其中一些语言已经过数十亿美元的实战测试，如在 ZCash 和 Starknet 等链的流动。虽然我们将讨论的一些项目还没有完全准备好用于生产，但使用其中一种语言编写电路是目前最好的策略，除非需要像 Arkworks 这样的工具包提供的更精细的控制。

优点

• 用户不需要了解底层的zk细节
• 有一定的生产经验，今天就可以使用
• 可在链上验证
• 生态系统不可知

缺点

• 用户需要学习一个新的DSL
• 围绕这些语言的工具和支持都是孤立的
• 对底层证明堆栈几乎没有控制权（目前）。

zkEVMs

zkEVM的主要目标是采取Ethereum状态转换，并使用简洁的零知识正确性证明来证明其有效性。正如Vitalik的帖子中提到的，有许多方法可以做到这一点，并有微妙的差异和相应的权衡。

所有这些方法之间的主要技术区别在于，在语言栈中，计算究竟在哪里被转换为可以在证明系统中使用的形式（算术化）。在一些zkEVM中，这发生在高级语言中（Solidity、Vyper、Yul），而其他方法则试图将EVM一直证明到操作码级别。这些方法之间的权衡在Vitalik的帖子里有深刻的论述，但我将用一句话来概括它。在堆栈中发生的转换/算术化越低，性能损失就越大。

高操作成本

为虚拟机创建证明的主要挑战是，电路的大小与每条执行指令的所有可能指令的大小成比例地增长。这是因为电路不知道在每个程序中会执行哪些指令，所以它需要支持所有的指令。

在通用电路中，每条执行的指令的成本与所有支持的指令之和成正比。

这在实践中意味着，你要为最昂贵的指令支付（性能成本），即使你只是在执行最简单的指令。这导致了通用性和性能之间的直接权衡–当你为通用性增加更多的指令时，你要为你证明的每一条指令付出代价！这就是通用电路的根本问题。

但随着IVC（增量可验证计算）等技术的新发展，这种限制可以通过将计算分成更小的块来改善，每个块都有专门的、更小的子电路。

今天的 zkEVM 实现使用不同的策略来减轻这个问题的影响……例如，zkSync 去掉了更昂贵的操作（主要是加密的预编译，如哈希值，以及其他一些操作）

zkEVM的理想客户是那些需要比L1以太坊上的交易便宜几个数量级的智能合约应用。这些开发人员不一定有专业知识或带宽来从头开始编写zk应用程序。因此，更喜欢用熟悉的更高级的语言来写应用程序，如Solidity。

众多开发团队

扩展Ethereum是目前zk技术最需要的应用。

zkEVM是一个以太坊扩展解决方案，可以无摩擦地缓解限制L1 dApp开发者的拥堵问题。

开发者体验

zkEVM的目标是支持一个尽可能接近当前以太坊开发的开发者体验。完全支持Solidity意味着团队不必建立和维护多个代码库。这在某种程度上是不切实际的，因为zkEVM需要交换一些兼容性，以便能够在合理的时间内生成合理规模的证明。

zkSync 与 Scroll

zkSync 和 Scroll 之间的主要区别在于它们在堆栈中的何处/何时执行算术运算——也就是说，它们从普通 EVM 构造转换为 SNARK 友好表示的位置。对于 zkSync，当他们将 YUL 字节码转换为他们自己的自定义 zk 指令集时，就会发生这种情况。对于Scroll来说，这发生在最后，当实际的执行跟踪用实际的EVM操作码生成时。

因此，对于 zkSync，在生成 zk 字节码之前，一切都与与 EVM 交互相同。对于 Scroll，在执行实际的字节码之前，一切都是一样的。这是一个微妙的差异，它以性能换取支持。例如，zkSync 不会像开箱即用的调试器那样支持 EVM 字节码工具，因为它是完全不同的字节码。虽然 Scroll 很难从指令集中获得良好的性能，但这并不是为 zk 设计的。这两种策略各有利弊，最终有很多外生因素会影响它们的相对成功。

zkLLVM 电路编译器

正如详细讨论的那样，开发 zk 应用程序有无数不同的选择，所有这些都有自己独特的权衡。此图表将帮助总结此决策矩阵，以便根据您的 zk 专业知识水平和性能需求，选择最适合该工作的工具。这不是一个完整的列表，会随着zk的发展更新。

zkLLVM 被设计为现有 LLVM 基础设施的扩展，LLVM 基础设施是一个行业标准工具链，支持许多高级语言，如 Rust、C、C++ 等。

怎么运行

想要证明某些计算的用户只需用 C++ 实现该计算即可。zkLLVM 采用其修改后的 clang 编译器（当前为 C++）支持的高级源代码，并生成电路的一些中间表示。此时，电路已准备好进行验证，但用户可能希望根据一些动态输入来验证电路。为了处理动态输入，zkLLVM 有一个称为分配器的附加组件，它生成一个分配表，其中包含所有输入和见证，这些输入和见证已完全预处理并准备好与电路一起进行证明。

这两个组件是生成证明所必需的。理论上，用户可以自己生成证明，但由于这是一项有点专业化的计算任务，可能需要花钱请拥有硬件的其他人做这件事。对于这种交易对手发现机制，=nil；Foundation 还建立了一个“证明市场”，证明者竞相为支付给他们的用户证明计算。这种自由市场动态将导致证明者优化最有价值的证明任务。

权衡利弊

由于每个要证明的计算任务都是独一无二的，并且会生成不同的电路，因此证明者需要能够处理的电路数量是无限的。这种强制的通用性使得单个电路的优化变得困难。证明市场的引入允许对市场认为有价值的电路进行专业化。如果没有这个市场，由于这种自然的冷启动问题，说服验证者优化该电路将是一项挑战。

另一个权衡是经典的抽象与控制。愿意采用这种易于使用的界面的用户正在放弃对底层加密原语的控制。对于许多用户来说，这是一个非常有效的权衡，因为让密码学专家为您做出这些决定通常更好。

优点

• 用户可以用熟悉的高级语言编写代码
• 所有的zk内部结构都被抽象出来，不受用户影响
• 不依赖增加额外开销的特定 "虚拟机 "电路。

缺点

• 每个程序都有一个不同的电路。难以优化。(证明市场部分解决了这个问题)
• 交换/升级内部zk库并非易事（需要分叉）

zkVM

zkVM 描述了所有 zk 虚拟机的超集，而 zkEVM 是一种特定类型的 zkVM，由于其在当今的流行，值得作为一个单独的主题进行讨论。除了定制的加密 VM 之外，还有一些其他项目正在致力于构建基于 ISA 的更通用的 zkVM。

系统可以证明不同的指令集架构 (ISA)，例如新 VM 中的 RISC-V 或 WASM，而不是证明 EVM。致力于这些通用 zkVM 的两个项目是 RISC Zero 和 zkWASM。

让我们在这里深入了解一下RISC Zero，以证明这种策略是如何工作的，以及它的一些优势/劣势。

Risc Zero

Risc Zero证明生成的高级架构

RISC Zero能够证明任何在RISC-V架构上执行的计算。RISC-V是一个开源的指令集架构（ISA）标准，已经越来越受欢迎。RISC（精简指令集计算机）的理念是以最小的复杂性建立一个极其简单的指令集。这意味着堆栈中较高层次的开发者在使用这种架构实现指令时最终会承担更大的负荷，同时使硬件实现更加简单。

这种理念也适用于一般的计算，ARM芯片一直在利用RISC风格的指令集，并开始主导移动芯片的市场。事实证明，更简单的指令集也具有更大的能量和芯片面积效率。

这个类比对于生成zk证明的效率来说相当适用。正如前面所讨论的，在证明zk的执行轨迹时，你要为轨迹中每一项的所有指令的成本之和买单，所以更简单、更少的总指令是更好的。

如何工作

从开发者的角度来看，使用RISC Zero来处理zk证明，很像使用AWS Lambda函数来处理后端服务器架构。开发人员通过简单地编写代码与RISC Zero或AWS Lambda互动，服务处理所有后端复杂性。

对于RISC Zero，开发者编写Rust或C++（最终是任何针对RISC-V的东西）。然后，系统接受编译过程中产生的ELF文件，并将其作为虚拟机电路的输入代码。开发者只需调用证明，返回一个收据（包含执行跟踪的zk证明）对象，任何人都可以从任何地方调用`验证'。从开发者的角度来看，没有必要了解zk是如何工作的，底层系统处理所有这些复杂的问题。

为了支持这样一个通用接口，需要大量的开销（在证明大小和生成速度方面）。

需要对证明生成技术进行重大改进，以实现对现有库的广泛支持

预建的可重复使用电路

对于一些对区块链应用或其他地方特别有用的基本和可重复使用的电路，团队可能已经为你构建和优化了这些电路。你只需为你的特定用例提供输入即可。例如，Merkle包容证明是加密货币应用中普遍需要的东西（空投清单、龙卷风现金等）。作为一个应用程序的开发者，你总是可以重新使用这些经过实战检验的合约，只是在上面修改一些层，以创建一个独特的应用程序。

例如，Tornado Cash 的电路可以重新用于私人空投应用程序或私人投票应用程序。Manta 和 Semaphore 正在构建一个完整的工具包，包括像这样的通用电路小工具，可以在 Solidity 合约中使用，而无需了解或不了解底层的 zk moon 数学。

正如详细讨论的那样，开发 zk 应用程序有无数不同的选择，所有这些都有自己独特的权衡。

此图表将帮助总结此决策矩阵，以便根据您的 zk 专业知识水平和性能需求，选择最适合该工作的工具。这不是一个完整的列表，会随着zk的发展更新。

zkGalaxy 应用开发者指南

1. 低级 Snark 库

适用场景

• 需要对整个证明堆栈进行精细控制
• 避免重建公共组件
• 尝试证明方案、曲线和其他低级原语的不同组合

不适用场景

• 寻找高级证明接口的新手

可选用工具

• Arkworks-rs

2. zk DSLs

• 适用场景
• 想使用一些久经考验的语言
• 需要最小的电路尺寸，愿意放弃抽象

不适用场景

需要对证明的后端进行精细控制（目前，可以为一些DSL交换后端）

可选用工具

• Circom
• Aztec Noir
• Cairo
• ZoKrates
• Leo

3. zk 编译器

适用场景

• 不愿意承担通用电路的开销
• 想用熟悉的语言编写电路
• 需要高度定制的电路

不适用场景

• 想要控制底层加密原语
• 需要一个已经高度优化的电路
• 可选用工具
• nil zkLLVM

4.zkEVM

适用场景

• 有一个已经在 EVM 上运行的 dApp
• 需要为用户提供更便宜的交易
• 希望将部署到新链的工作量降到最低
• 只关心zk（压缩）的简洁性

不适用场景

• 需要完美的 EVM 等效性
• 需要 zk 的隐私属性
• 有一个非区块链用例

可选用工具

• zksync2.0
• Polygon zkEVM
• Scroll
• Starknet

5.zkVM

适用场景

• 想用高级语言编写代码
• 需要证明该执行的正确性
• 需要向验证者隐藏该执行的一些输入信息
• 几乎没有zk方面的专业知识

不适用场景

• 在延迟极低的环境中（它仍然很慢）。
• 有一个巨大的程序（目前）。

可选用工具

• RISC Zero
• zkWASM

6. 预建的可重复使用的电路

适用场景

• 有一个依赖常见的zk构建模块的智能合约应用，比如Merkle包容。
• 对zk底层的东西几乎没有专业知识

不适用场景

• 有高度专业化的需求
• 用例不被预建电路所支持
• 可选用工具
• Manta Network
• Semaphore

结论

zk 处于多项技术的前沿，构建它需要对数学、密码学、计算机科学和硬件工程有深刻的理解。然而，随着每天都有越来越多的抽象层可用，应用程序开发人员无需博士学位即可利用 zk 的强大功能。随着时间的推移，通过对堆栈的所有级别进行优化，证明时间的限制会逐渐解除，我们可能会看到针对普通开发人员的更简单的工具。

致谢

本文编译工作获得DAOrayaki社区的支持与反馈。

DAOrayaki DAO研究奖金池：

资助地址: DAOrayaki.eth

投票进展：DAO Committee 3/0

通过研究种类：DAO, Governance

贡献者：Shaun @DAOrayaki

审核者：Yofu @DAOrayaki

原文：A Developer’s Guide to the zkGalaxy