TL; DR

1、ZK当我们讨论隐私时，我们使用隐私和扩容技术ZK不获得技术保护链下的数据；当我们讨论扩展时，我们使用它ZK节省链上的计算空间。例如，如果我想确认一个账户有100元，传统的区块链方式是让每个节点再次确认，现在我只需要一个节点，在确保数据完整性的前提下，找到最近净流入100元，可以证明账户有100元，区别是前者需要大量的计算和证明，后者只需要链证明。

2、ZKVM发展的核心权衡在于发挥ZK发挥当前开发者资源的潜力很重要。围绕着它ZK潜力，意味着CPU加速寄存器的硬件，IR语言和assembly语言再组织；围绕开发者资源的利用，意味着Solidity转化bytecode后，如何将Bytecode所映射的opcode，进行ZK证明问题。

3.根据模块化区块链的观点，L1解决共识问题，L解决计算和执行问题，DA层解决数据可用性和完整性的问题Zk类的L2其证明。

4、以assembly 语言独立设计ZK专用型证明ZKapp，由于可组合性和解耦能力较低，在未来的发展过程中将面临巨大的障碍。这些计划是由于其他原因ZK方案不兼容VM，语言不兼容，调用难度大。

5、依赖、时间序列交易Log，数据安全性和证明的完整性决定了其执行的可靠性ZK在大多数闭源状态下，ZK安全审计有很大的发展前景。

6、由于ZKP依靠链下数据，交由DA链条会失去数据的隐私。想要与数据隐私兼容ZK要证明节点不作恶，需要新的解决方案。我们看好未来，比如MPC/FHE等待安全计算方案。

7、随着不同Circuit不断成熟，Zk证明也可能迎来提高效率和分工，ZK硬件加速方案和专业证书ZK矿工也可能应运而生。

8、ZKP经验局限性。典型的问题包括：约束系统（constraint system）不能有效限制数据，当证明一些复杂的交叉命题时，约束面临不足的问题；私人数据泄露，私人数据作为公共数据处理；对链下数据的攻击，合同层metadata-attack”；ZK证明节点作恶等。

9.短期来看，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 等操作系统。再比如，X需要86芯片的硬件x86版本的windows匹配。这主要是因为操作系统底部的汇编语言需要与芯片匹配。

App的成功运行需要与CPU还需要匹配操作系统。例如：1，为了确保 Office 2017 的正常运行需要 x86C 的 CPU；2，有些APP只能在window XP上运行，2000上运行。

CPU 只能解释自己固有的机器语言。不同的 CPU 可以解释的机器语言类型也不同。也就是说，它是用不同的高级语言编写的APP，若不能通过操作系统编译CPU语言可以运算，CPU也不能执行。

二、Zk VM是什么？

通常我们在讨论ZK通常在三种语境中：

使用ZK作为Scaling方案RollupL2。使用zkp申请证明，dydx，Zklink等等。zkproof作为密码算法。

用什么语言，在什么环境下，用什么硬件？这是广义的VM要解决的问题。

我们刚刚介绍了传统的操作系统(也是一种)VM），再来看ZKVM我们可以发现，ZKVM硬件层(原生链 )也完成了类似的功能ZK证明系统)和高级语言（solidity或者原生ZK语言)沟通。当系统接收到两种类型时，其核心是数据证明和状态更新input，输出指令(更新状态)和原始数据(状态和指令)和证明(状态和指令的相关证明)ZKP(证明)，提交L共识广播。

具体来看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比较，从而决定状态是否正确。

ZK语言的公约数

根据MidenVM 总结，目前市场主要Zkapp使用的工具都是以WASM和RISC V主要汇编语言，一些工具包可以让应用程序快速ZK概念或标签。但是稍微拆解一下结构，就会发现传统的智能合同是由的L为了保证安全，全网广播形成共识的安全性已经被历史考验，并在链下使用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节省链上计算空间。

ZKVM核心权衡技术与发展devs。围绕着发挥ZK潜力，意味着CPU加速寄存器的硬件，IR语言和assembly语言再组织；围绕开发者资源的利用，意味着Solidity转化bytecode后，如何将Bytecode所映射的opcode，进行ZK证明问题assembly 语言独立设计ZK专用型证明ZKapp，由于可组合性和解耦能力较低，在未来的发展过程中将面临巨大的障碍。这些计划是由于其他原因ZK方案不兼容VM，语言不兼容，证明不兼容，调用难度大。根据模块化区块链的观点，L解决共识问题，L解决计算和执行问题，DA层解决数据可用性和完整性的问题Zk类，数据安全性和证明的完整性决定了其执行的可靠性。这里有一对矛盾，如果我们不信任链下节点，希望将数据交由DA独立存储，是的DA链条提出安全要求，；如果存在本地，确保数据不被篡改，则需要证明节点本身不作恶。所有这些都得到了改进MPC/FHE需要解决方案ZK在大多数闭源状态下，目前，大量的共识仍然是基于链下节点的自律，缺乏一系列必要的工具（测试、证书等），以确保链下环境的安全contraint设计和代数证明将成为两个主要审计环节。ZK主要的生态风险。典型的问题包括：约束系统（constraint system）不够。当证明一些复杂的交叉命题时，约束是不够的；私人数据泄露。私人数据作为公共数据处理；对链下数据的攻击，合同层metadata-attack”；ZK证明节点作恶等Circuit不断成熟，Sequencer/Roller/Miner 我们期待着提高效率和分工ZK硬件加速机会的证明。