英文版文章见附件：麻烦润色修改

漫谈漫谈ZKVM的方案及未来

TL；DR

1. ZK的技术具有隐私和扩容两个最主要的使用场景，当我们讨论隐私的时候，我们利用ZK技术保护链下数据，不被获取；而当我们讨论扩容的时候，我们则是利用ZK节省链上计算空间。举个例子，如果我要确认某个账户有100块钱，传统区块链的方式是让每个节点都确认一遍，而现在我只需要一个节点，在保证数据完整性的前提下，找到最近净流入100块的凭证，即可证明账户有100元，区别就是前者需要大量计算和证明，后者只需要链下证明。
2. ZKVM发展的核心权衡在于是发挥ZK潜力重要，还是发挥目前开发者资源重要。围绕着发挥ZK潜力，意味着CPU寄存器的硬件加速，IR语言和assembly语言的再组织；而围绕着利用开发者资源，则意味着Solidity转化bytecode后，如何将Bytecode所映射的opcode，进行ZK证明的问题。
3. 以assembly 语言独立设计ZK证明的专用型的ZKapp，由于具有较低的可组合性和解耦能力，将在未来的发展过程中面临很大的阻碍。这些方案由于和其他ZK方案不兼容VM，不兼容语言，不兼容，存在较大的调用难度。
4. 按照模块化区块链的观点，L1解决共识问题，L2解决计算和执行问题，DA层解决数据可得性和完整性的问题。由于Zk类的L2其证明。
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相关的竞争格局，并为未来发展的方向做一些畅想。本文着重讨论：

1. 当我们在讨论ZK技术的时候我们在讨论什么？(知识铺垫，机构投资者可以从第二部分开始读。)
2. 从技术发展角度看待gzkvm（generalized zk vm）的发展规律和结构?