收藏本站 网站导航 开放平台 Monday, November 28, 2022 星期一
  • 微信

Cipholio 深度分析:漫谈ZKVM的方案及未来

来源 中金网 05-27 17:11
摘要: 本文将着重从生态发展角度,来分析ZK技术和其应用场景,描述目前ZK相关的竞争格局,并为未来发展的方向做一些畅想。来源于火星财经专栏作家Cipholio

  根据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节省链上计算空间。

  •   ZKVM发展的核心权衡技术与devs。围绕着发挥ZK潜力,意味着CPU寄存器的硬件加速,IR语言和assembly语言的再组织;而围绕着利用开发者资源,则意味着Solidity转化bytecode后,如何将Bytecode所映射的opcode,进行ZK证明的问题。

  •   以assembly 语言独立设计ZK证明的专用型的ZKapp,由于具有较低的可组合性和解耦能力,将在未来的发展过程中面临很大的阻碍。这些方案由于和其他ZK方案不兼容VM,不兼容语言,不兼容证明,存在较大的调用难度。

  •   按照模块化区块链的观点,L1解决共识问题,L2解决计算和执行问题,DA层解决数据可得性和完整性的问题。由于Zk类,数据安全性和证明的完整性决定了其执行的可靠性。这里有一对矛盾,如果我们不信任链下节点,希望将数据交由DA独立存储,那么对DA链就提出安全的要求,;如果存在本地,保证数据不被篡改,就需要证明节点本身不去作恶。这些都提升了对MPC/FHE解决方案的需求。

  •   在目前ZK方案大部分闭源的状态下,目前大量的共识还是建立在链下节点的自律上,缺乏一系列必要的工具(测试,证明,等等),来保障链下环境的安全性。未来contraint设计和代数证明将成为两个最主要的审计环节。

  •   ZK生态主要的风险。典型问题包括:约束系统(constraint system)不充分。当证明一些复杂交叉的命题时,约束面临不够充分的问题;私有数据泄露。私有数据当做公开数据处理;针对链下数据的攻击,合约层的“metadata-attack”;ZK证明节点的作恶等等。

  •   随着不同Circuit的不断成熟,Sequencer/Roller/Miner 也会迎来提效和分工,我们期待ZK证明的硬件加速机会。

免责声明:中金网发布此信息目的在于传播更多信息,与本网站立场无关。中金网不保证该信息的准确性、真实性、完整性、有效性等。相关信息并未经过本网站证实,不构成任何投资建议,据此操作,风险自担。