TL; DR
01
ZK 的技术具有隐私和扩容两个最主要的使用场景，当我们讨论隐私的时候，我们利用 ZK 技术保护链下数据，不被获取；而当我们讨论扩容的时候，我们则是利用 ZK 节省链上计算空间。举个例子，如果我要确认某个账户有 100 块钱，传统区块链的方式是让每个节点都确认一遍，而现在我只需要一个节点，在保证数据完整性的前提下，找到最近净流入 100 块的凭证，即可证明账户有 100 元，区别就是前者需要大量计算和证明，后者只需要链下证明。
02
ZKVM 发展的核心权衡在于是发挥 ZK 潜力重要，还是发挥目前开发者资源重要。围绕着发挥 ZK 潜力，意味着 CPU 寄存器的硬件加速，IR 语言和 assembly 语言的再组织；而围绕着利用开发者资源，则意味着 Solidity 转化 bytecode 后，如何将 Bytecode 所映射的 opcode，进行 ZK 证明的问题。
03
按照模块化区块链的观点，L1 解决共识问题，L2 解决计算和执行问题，DA 层解决数据可得性和完整性的问题。由于 Zk 类的 L2 其证明。
04
以 assembly 语言独立设计 ZK 证明的专用型的 ZKapp，由于具有较低的可组合性和解耦能力，将在未来的发展过程中面临很大的阻碍。这些方案由于和其他 ZK 方案不兼容 VM，不兼容语言，不兼容，存在较大的调用难度。
05
依赖，时间序列的交易 Log，数据安全性和证明的完整性决定了其执行的可靠性。在目前 ZK 方案大部分闭源的状态下，ZK 安全审计有很大的发展前景。
06
由于 ZKP 依赖链下数据，交由 DA 链则会失去数据的隐私性。想要兼容数据隐私性和 ZK 证明节点不作恶，就需要新的解决方案。我们看好未来诸如 MPC/FHE 等安全7
随着不同 Circuit 的不断成熟，Zk 证明可能也会迎来提效和分工，ZK 证明的硬件提速方案，以及专业的 ZK 矿工也可能应运而生。
08
ZKP 经验局限性问题。典型问题包括：约束系统（constraint system）无法有效约束数据，当证明一些复杂交叉的命题时，约束面临不够充分的问题；私有数据泄露，私有数据当做公开数据处理；针对链下数据的攻击，合约层的“metadata-attack”；ZK 证明节点的作恶等等。
09
短期来看，ZK 方案的安全性存在局限，目前大量的共识还是建立在链下节点的自律上，缺乏一系列必要的工具（测试，证明，等等），来保障链下环境的安全性。
概览
一直以来 ZK 技术由于其重峦叠嶂的专业术语，使得人们难以对这一主题充分讨论。本文将着重从生态发展角度，来分析 ZK 技术和其应用场景，描述目前 ZK 相关的竞争格局，并为未来发展的方向做一些畅想。本文着重讨论：
当我们在讨论 ZK 技术的时候我们在讨论什么？( 知识铺垫，机构投资者可以从第二部分开始读。)
从技术发展角度看待 gzkvm（generalized zk vm）的发展规律和结构?
目前主要 ZKvm 技术方案的比较？
分析和展望
一
虚拟机 ABC-- 从日常计算机说起
在介绍 ZKEVM 相关的知识以前，我想先从我们日常的计算机的结构讲起。我们都知道计算机分为软件和硬件两部分，为了让软件顺利的在硬件上运行，我们需要为软件匹配适宜的运行环境。从结构来看，运行环境由【硬件 + 操作系统】两部分组成。
其中黄色部分为硬件，绿色部分为操作系统。这里可能有同学会提出疑问：为什么运行环境不等价于操作系统，这主要是因为操作系统难以兼容所有的硬件，只有操作系统和硬件的匹配才能为软件提供服务。这个问题，我们再后面 ZKVM 的发展路线钟，还会提到。
有了运行环境，我们还需要具体的软件（程序 /app）才可以实现具体需求。那么程序是怎样跑起来的呢？
从图上我们可以看到，软件经操作系统交由硬件层来进行计算的整个流程，在过程中程序语言经过了三个阶段的变化，高级语言用来写程序完成实际需求，汇编语言用来和计算机沟通，底层本地代码（16 进制数）由计算机具体执行。具体来看，程序员完成 APP 的代码后，经由转译器翻译成 obj（目标语言），这些离散的目标语言，将会通过操作系统中的 Linker 得以链接，两者输出可执行的 exe 文件存储在硬盘中。
当运行的时候，exe 文件会将数据放入内存，经由 CPU 将 Obj 转化为本地代码（字节码）进行计算操作，实现 app 的 I/O。这一过程中存在非常多的选择，多样的语言，多样的操作系统，多样的硬件，从商业角度面临了非常多的 Tradeoff，而这些选择最后便体现在编译器内核 LLVM（low level virtual machine）的改进中。
下图我们可以看到，硬件（黄色）和操作系统之间有多种对应关系和限制条件：
同一类型的硬件可以安装多种操作系统，不同硬件需要匹配不同类型的操作系统。例如， 同样的 AT 兼容机 A 中， 既可以安装 Windows， 也可以安装 LinuxB 等操作系统。又如，X86 芯片的硬件，需要 x86 版本的 windows 来匹配。这主要是由于操作系统底层汇编语言需要与芯片匹配。
App 的成功运行需要与 CPU 匹配，也需要与操作系统匹配。例如：1，为了保证 Office 2017 的正常运行， 需要具备 x86C 的 CPU；2，有些 APP 只能在 window XP 上运行，在 2000 上则运行不了。
CPU 只能解释其自身固有的机器语言。不同的 CPU 能解释的机器语言的种类也是不同的。也就是说，用不同高级语言编写的 APP，如果不能通过【操作系统】编译成 CPU 可以运算的语言，CPU 也是无法执行的。
二
Zk VM 是什么？
通常我们在讨论 ZK 的时候，通常是在三个语境当中：
用什么语言，在什么环境下，用什么硬件执行？这是广义 VM 所要解决的问题。
前面我们刚刚介绍了传统操作系统（也是一种 VM），再来看 ZKVM 的时候，我们可以发现，ZKVM 也完成了类似的职能，完成了硬件层（原生链 +ZK 证明系统）和高级语言（solidity 或者原生 ZK 语言）的沟通。其核心是数据证明与状态更新，当系统接收到两类 input，原始数据（状态和指令）和证明（对于状态和指令的相关证明），比对计算后，输出指令（更新状态）和 ZKP（证明），提交 L1 进行共识广播。
具体来看 ZK 证明经过几个部分（by JP Aumasson, Taurus）:
1. 本地的计算；
2. Circuit 的定义。比如确认你钱包有没有钱，确认信息是不是完整，确认签名是否正确；
3. 算术化证明：运用数学方法证明计算是可执行的。
4. 将算数证明结果和实际结果比对
5. 将结果递交上链
以 Scroll 的方案为例，我们看到从 Geth 出发，系统完成了本地的计算，将交易 Trace（交易的历史 log）拆解转化成 Circuits 算子，然后使用算数方法（例如多项式拆解，密码学）得出 ZK 证明。然后比对数据和证明，如果无误即可广播上链。这当中涉及许多关键技术，比如如何设定 Circuits，有哪几类 Circuits？如何对 Circuits 进行拆解? 整个确认方法，可以想象一张巨大的表，每一个变量都有其参数，在已知历史数据的背景下，求特定结果的必然性。
举个例子，如果我要确认某个账户有 100 块钱，传统区块链的方式是让每个节点都确认一遍，而现在我只需要一个节点，在保证数据完整性的前提下，再加上最近净流入 100 块的证明，然后进行确认（案例中的情形比较简单，看一眼便知，实际情况中是需要数学运算的。）完成后，即可证明账户有 100 元，区别就是前者需要每一个节点的计算，后者只需要单一节点计算和 zk 证明。在这个例子中，确认的是“如何在链下证明账户有充足余额”，证明需要的约束是“当最近历史时间轴内账户净流入大于 100（实质基于 Merkle Root 的证明），然后将节点计算结果与 ZKP 比对，从而决定状态是否正确。
2.1
ZK 语言的公约数
根据 MidenVM 的总结，目前市场上主要的 Zkapp 所采用的的工具都是以 WASM 和 RISC V 为主的汇编语言，一些工具包能让应用很快打上“ZK”的概念或者标签。但稍微拆解一下结构，我们会发现传统智能合约由 L1 来保证安全性，全网广播形成共识的安全性已经经过历史检验了，而利用链下 ZKP 证明，则存在 ZKP 证明节点是否作恶的问题。
先不论 Devs 是否能够合理设立约束（Contraint）的能力问题，如何防范 ZKP 证明节点的作恶意愿问题，无疑是更为重要的。
举例来看，一些 ZK dex 更像是在 Cex 和 Dex 之间寻找一个平衡点，相较于 Cex 而言，用户可以将资金保管在自己的 L1 账户；而相对 Dex 而言，又能有更优的效率表现。但在实践中，大量的项目都存在链下证明的安全隐患。此外，由于从 APP 层到 IR 层，都是由 zkAPP 团队独立开发，家家户户有着自己的编程习惯和轮子库，这也导致团队与团队之间难以形成可组合性，也不利于加速市场分工和硬件设备的加速。
因此，市场破解寻找一个在密码学和高级语言之间找到一层公约数。来为各类应用提供一个通用的框架，而 ZK-VM 则是适配整套系统，承上启下的重要部分。
在执行模式方面，EVM 与 JVM 非常相似。两者都是执行字节码的堆栈机。EVM 增加了一个存储的概念，它的字节码指令更适合于合同开发。
图中我们以 ETH 举例，传统 ETH 由三部分构成，ETH 网络（节点 + 共识机制），EVM，Dapp 开发生态。这里我们可以很清晰的感受到 ZK 承上启下的作用：
1. 站在 ZK 电路硬件层的角度：
EVM 可能无法全部兼容。由于 EVM 有一些变长的指令，比如 CALL，DATACOPY，EXP，CREATE 等等，这些对 ZK 电路不友好。
2. 站在开发者角度：
能否不需要重新学习语言（Solidity 仍然兼容），保留 EVM 的 API 特性。在这种情况下，整个生态就可能失去对一些 ZK 算法的支持。
除此以外，ZKVM 还需要考量很多技术兼容，比如：
1. 寄存器的兼容。Machine Type. 传统 EVM 是一个 Stack-based 的 State machine，因此大量的计算式串联的，不可并行的，这确保了整个计算机的原子性。这一架构对于 ZK 是非常不利的，如果要发挥 ZK 算法的全部效率，则需要做一个 Register-Based，也就是以 CPU- 寄存器为核心架构来设计 VM。
2. 语言上的兼容。Function Calls. VM 系统将底层特性封装成 API，如何让 API 支持动态调用，支持像 Python 一样的高级语言。
3. 计算机底层的兼容。Native Field. 不同的 CPU 有不同的位数，在不同算法上的表现不同。需要为 ZK 专用计算机做谋划。
4. 传统公链结构的兼容: Sequencer/Roller/Miner.
三
ZKVM 的架构
主流技术方案
用什么语言，在什么环境下，用什么硬件执行？这是广义 VM 所要解决的问题。
VM 当中最为重要的内核便是 LLVM（low-level-virtual-machine），他可以看作是编译器最重要的内核。图中是原始 EVM 的运作方案，智能合约通过 LLVM IR 的中间代码进行转化，转化成 Bytecode。这些 Bytecode 会存储在区块链上，当智能合约被调用的时候，便会将 Bytecode 转化成对应的 Opcode，再由 EVM 和节点硬件来执行。
结合上 ZK，各个不同的解决方案是怎样实现的呢？
Starkware
Starkware 由于在整个 ZK 领域起步较早，技术积累较为充分，拥有一定的技术领先。他是代表性的 ZK 中心主义的技术架构，围绕 ZK 构建了 Cairo VM 和 Cairo 的语言。但由于他是闭源状态，一些技术细节并不清晰。其缺点在于，Cairo 的学习成本。虽然官方也开发了 Solidity 转换 Cairo 的一些框架，但由于其底层核心均建立于 CairoVM 上，意味着有相当多 Solidity-EVM 兼容的特征会损失。
Zksync
ZKsync 的框架兼容了 EVM 和 ZK 两方面的特点，将 Solidity 和其自主开发的电路语言 Zinc 做了一个融合，在编译器内部将两者在 IR 层面上做了统一。其优点在于编译器内核的 LLVM 可以兼容多种语言。Zksync 也是闭源框架。
Hermez by Polygon
Scroll
HermZ 和 Scroll 两个技术方案更侧重以太坊生态，他们在 Bytecode 上和 ETH 生态做了融合。由于 EVM 天然支持 bytecode 和其对应的 opcode，这两者和 ETH 生态有着更高的融合性。Solidity 在这两个 Zkvm 上能充分的调用 EVM 的 API，最大保留了 EVM 的架构优点。两个方案有所差异的是，Hermz 会将 opcode 在内部进行统一，然后再进行证明；而 Scroll 则会将 Opcode 拆解 circuit 进行证明，再进行整合。
为什么要选择兼容 EVM？因为 EVM 当中有一些架构经过检验，安全性比较好，兼容性也比较好。举例来说 Geth 模型和 RPC 架构，这些 API 已经被 EVM 较好的封装，也经过历史检验。
总结来看，
Starkware 最底层从 WASM 和机器码层面进行统一，ZKsync 最浅在 IR 层面进行统一，Hermz 和 Scroll 居中在 Bytecode 上进行统一；
Starkware 是技术转型最彻底的，但也是用户学习门槛最高的；而 Zksync 相对比较均衡，保留一部分 solidity 特性，发挥局部 ZK 性能；
Hermz 和 Scroll 相对最易应用和拆解，全面集成 Bytecode，整合 EVM，尤其是 Scroll，开放 ZK 证明，也给了硬件加速更大的空间。
相对来说，无论是技术驱动还是生态整合驱动，都在未来有各自的发展空间，“贸工技”还是“技工贸” 都有机会找到自己的场景，发挥更大价值。
如果我们对照回顾 Windows 历史，在强有力的操作系统出现以前，不同的开发者需要对不同的硬件，掌握不同的开发工具。不掌握汇编，不理解计算机底层的开发者在开发过程中会遇到非常多的挫折。而操作系统在硬件当中寻找最大的公约数，将 CPU 以外的 I/O 系统都封装成统一的接口，这些技术积累，使得软件开发的门槛大大降低了，也使得大部分程序员只需要理解高级语言即可，即使不具备汇编和底层代码知识仍然可以写出漂亮的 App。
对照看到 ZKVM 的发展，我们可以看到一些端倪，如果说现在的 ZKapp 需要传统程序员 + 汇编 + 密码学知识储备才能开发，未来随着 ZKVM 的成熟，越来越多的底层技术封装进高级语言当中，开发门槛渐次降低，生态繁荣是可以想见的。
对于 Founder 而言，有两个注意点：
1. ZK 技术将链上共识转为链下证明，目前证明技术相对成熟，但是拆解证明，数据存储的安全隐患仍然不少，相关审计机构，测试工具都存在空白缺位。
2. ZK 技术的使用场景尚待发掘。通用型 ZKVM 紧锣密鼓开发，ZK 对应高级语言也有待技术人员的学习，从技术成熟到解决问题还有一段时间。想要用 ZK 解决问题，founder 需要回答：如果是个细分场景，是否需要自己用 WASM 去搭建，一旦 ZKVM 成熟，自己的技术积累是否还有先发优势？是否支持其他 ZKapp 调用？
展望与结论
ZK 的技术具有隐私和扩容两个最主要的使用场景，当我们讨论隐私的时候，我们实际上是在保护链下数据，不被获取；而当我们讨论扩容的时候，我们是利用 ZK 节省链上计算空间。
1
ZKVM 发展的核心权衡技术与 devs。围绕着发挥 ZK 潜力，意味着 CPU 寄存器的硬件加速，IR 语言和 assembly 语言的再组织；而围绕着利用开发者资源，则意味着 Solidity 转化 bytecode 后，如何将 Bytecode 所映射的 opcode，进行 ZK 证明的问题。
2
以 assembly 语言独立设计 ZK 证明的专用型的 ZKapp，由于具有较低的可组合性和解耦能力，将在未来的发展过程中面临很大的阻碍。这些方案由于和其他 ZK 方案不兼容 VM，不兼容语言，不兼容证明，存在较大的调用难度。
3
按照模块化区块链的观点，L1 解决共识问题，L2 解决计算和执行问题，DA 层解决数据可得性和完整性的问题。由于 Zk 类，数据安全性和证明的完整性决定了其执行的可靠性。这里有一对矛盾，如果我们不信任链下节点，希望将数据交由 DA 独立存储，那么对 DA 链就提出安全的要求，；如果存在本地，保证数据不被篡改，就需要证明节点本身不去作恶。这些都提升了对 MPC/FHE 解决方案的需求。
4
在目前 ZK 方案大部分闭源的状态下，目前大量的共识还是建立在链下节点的自律上，缺乏一系列必要的工具（测试，证明，等等），来保障链下环境的安全性。未来 contraint 设计和代数证明将成为两个最主要的审计环节。
5
ZK 生态主要的风险。典型问题包括：约束系统（constraint system）不充分。当证明一些复杂交叉的命题时，约束面临不够充分的问题；私有数据泄露。私有数据当做公开数据处理；针对链下数据的攻击，合约层的“metadata-attack”；ZK 证明节点的作恶等等。
6
随着不同 Circuit 的不断成熟，Sequencer/Roller/Miner 也会迎来提效和分工，我们期待 ZK 证明的硬件加速机会。
◆ ◆ ◆
Readlist：
见【原文链接】
【免责声明】市场有风险，投资需谨慎。本文不构成投资建议，用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资，责任自负。
