本文带你共探零知识证明，发现 ZK 的新潜能。

整理： LXDAO

零知识证明（Zero-Knowledge Proofs）技术以卓越性的隐私保护能力，成为了数据安全领域的一颗璀璨明星，也一度登顶加密行业首榜热词行列。然而，ZK 技术的深度和复杂性却让许多渴望探索这一领域的学习者望而却步。而在本期 LX 分享会中，特邀安比实验室创始人郭宇，分享他的真知灼见与前瞻思考，让我们一同回顾本期精彩内容，解锁 ZK 的无限可能🚀

理论与实践的脱节，ZK 的应用场景在哪里

郭宇指出在比较众多的密码学分支中，ZK 的实践俨然已经十分充分了。但相比偏理论的研究，ZK 的理论由于其工程化以及产品的快速迭代，导致部分产品会使用相较不成熟且未经过严格验证的协议。而就目前而言 ZK 的学习材料偏理论居多，主要有以下两个原因：

1. 目前活跃的 ZK 研究者，大部分偏理论研究居多，做工程实践的偏少。就其成果产出， ZK 理论研究显然比工程实践的产出周期要短的多。比如许多的工程师，在打磨产品时，由于各自背景不同，就需要相对比较长的时间，去学习底层的算法 / 数学并积极实践，这就容易给人一种错觉，就好像我们看到东西都是偏理论的。

2. 本身行业的迅速发展、产品的高速更新迭代，部分工程内容在特定的应用场景上容易被其他协议替代甚至会逐渐退出人们的视野，因此即便目前 ZK 的技术门槛已经下降许多，但相比较实践，理论的发展总是会远先于实践的。

而如果想要进行 ZK 的实践，可以收集一些比较好的参照物，比如优质的工程代码，去进行模仿、使用甚至简单修改，先理清它的用途及其作用原理；其次如果有额外的需求，想尝试改动它的代码，增加新的性能，那就需要对这个代码有较深度的理解才能去修改它；再接下来，假设你有一个新的想法，想做一个产品，需要从头写代码，这就需要付出非常多的投入与潜心学习。但不管是理论还是实践，以模仿为主会相较更加切实。当我们随着自己水平的提高，也就会发现自己能做的事越来越多，当我们了解并掌握底层原理之后，我们也将会有更多勇气去做更多的事。

近十年来，ZK 工程实践已取得了长足的发展并依旧保持着快速发展的势头， ZK 的理论也进入了一个百花齐放的状态，然而这也给我们带来了部分学习的阻碍，比如从哪个开始学、应该怎么学，特别是密码学，有很多深不见底的数据但你却不知道它的用途是什么、算法来源是什么。而对于 ZK 的应用场景或者说有什么较好的应用，其实屈指可数，大量的应用级产品还处于概念验证阶段。但整体上而言，不断涌现新事物的同时也会给我们带来更多的希望，对于整个行业来说也需要有新事物的产生，需要有更多的人去做实验，去探索正确的道路。

ZK 链下应用与变现路径

郭宇对此回复说 ZK 具备未来发展的巨大的潜力，但倘若涉及到变现，其实更多依靠的是产品本身需真实解决核心问题，切实符合市场的需求 / 痛点，以此才能带来收益。

就目前来看的话，对于 ZK 链下应用，更加看好聚焦明确需求的应用，比如说：钱包、桥、Layer 2 以及智能合约的链下计算等。从其多年的学习经验来看，其实区块链在其发展过程中就已提出的不少明确的需求，比如说扩容、存储等，以及区块链自身的协议问题比如说节点数量太少、怎么有效压缩传输量等。当然，还有一类与区块链无关的，比如说隐私保护，但隐私保护也并不是一个纯技术问题，可能更多的是一个社会问题，隐私的定义究竟是什么、大家对于隐私的接受度又是如何的，这是属于大家的博弈。

而更加聚焦点的，比方说：以太坊状态爆炸、节点数量的数据可用性（Data Availbility）、增加更多的 Validator、解决 MEV 问题，包括链上合约的安全性，复杂性以及跨链桥的安全性问题等，满足这类需求 / 解决这类问题的应用大抵都具备较好的发展前景。

CRS 是什么，ZK 为什么需要它

郭宇指出所谓的 CRS（Common Reference String）就是 Prover & Verifier 不是凭空信任对方，一定是基于哪怕是一个 Bit 的共识的基础上相信对方，即在共识的基础上信任对方。

就比如，ZK 的基本概念中有一个概念叫电路，而电路就是把 Prover & Verifier 双方要共识的计算过程公开给所有人。在 Verifier 已知的前提下，由 Prover 计算隐私的参数并证明计算过程的完整性，其中电路必须公开，只有输入参数可以对 Verifier 进行隐藏。而这个电路本身也就是共识的一部分，因此在 Prover 前，双方就必须要达成一致的意见即电路，而按照定义，它就应该在 CRS 里。就当前而言，我们都在用零知识证明协议：ZK-SNARK（Zero Knowledge Succint Non-interactive ARguments of Knowledge）来说也基本上都含盖 CRS。

如果是基于椭圆曲线类的，它有两种，一种是像 Groth16，会有一个可信设置（Trusted setup） 的过程，这个过程是一个安全多方计算的协议，完成后把这部分共识的电路烧进去。另一种不烧电路的像 Marlin、Plonk 等，虽然不需要烧电路，但也事先需要烧一些共识内容进去。

另一类虽然基于椭圆曲线，但其安全假设取决于离散对数也就是椭圆曲线离散对数问题（ECDLP） 的这一类协议。对这类协议则需要进行透明设置（Transparent setup），同样也需要达成内容的共识，比方说：选择哪根椭圆曲线、密钥生成算法（Generator）以及 P、Q 这些素数等。还有一类基于 Hash-based，比如像 Stark、Risk Zero 等这一类 Hash-based zkSNARK，也需要有 CRS，你选用的哈希函数、RS code（Reed-solomon codes）等，严格意义上这些都在 CRS 里面。

所以，总的来说 CRS 基本上是必须的，只是说 CRS 的内容可能非常不同，一般而言其目的之一也是为了减少通信开销、减少证明的 Size 等，但不同的协议也存在一定的差别。

现实需求要如何转化为 ZK 的多项式表达

郭宇指出从理论层面来讲，要想实现 ZK 的多项式表达，就得需要计算，无论是扩容还是隐私，都需要用适合的电路进行表达，并且这个计算得是固定的计算，这不仅指算法固定，也包括计算的规模也得固定。而当算法本身在一个比较确定性的阶段，其计算量易被拆解时，也更加便于去操作，这也叫做写电路。

随着对 ZKEVM 的深入研究，ZKVM 技术栈的快速发展，也已经出现了免费使用的开源零知识计算平台比如 Risc Zero、SP1、zkWASM 等不同的实现，能够无需构建电路，仅通过 Rust 构建或自定义代码即可编写 ZK 应用程序。因此，把业务逻辑 ZK 化变得越来越简单。

而除了写电路之外，另一种计算则是基于 RAM（Random Access Machine）模型。我们可以把它想像为一台虚拟机在运行，在这个过程在不再是写电路而是写状态转移，而怎么把业务逻辑更好的写成状态转移甚至实现轻量级或直接将业务逻辑转变为多项式，这则更多依赖自身的能力以及需要经验的积累。

但总的来说，它是有门槛的，即便是写电路也有门槛。

精彩答疑集锦

为什么需要 ZK？

郭宇认为就目前其实缺少比较大的应用可以证明其可用 / 好用性，而 ZK 的出现可以更好的构建这种信任，况且 ZK 技术在密码学当中都是比较少有的针对信任问题的基础性工具。其次，在区块链发展的过程中，本身就遇到了诸多的问题，比如：节点数的急剧下滑、以太坊状态的爆炸等，这些都有望于 ZK 去改善以及解决，因此对于现在包括未来，ZK 对于区块链都是至关重要的。

当然，ZK 本身也需要区块链，它的前提基础需要有相信的存在其次才是信任甚至协议交互的问题，而区块链就是 ZK 信任冷启动环节中不可或缺的一环。两者相辅相成，缺一不可。

ZK 入门及其学习心得与经验分享

郭宇对此回复首先从动机出发，是因为我本身对理论层面非常感兴趣，我想要清楚明白它是什么，又为什么它可以。就入门来说，更多的是多去看一些专业的论文以及基础的资料，掌握必备的基础知识与深入学习，在这个过程中，慢慢积累，厚积薄发。而对于论文，其实有很多没有写清楚的上下文或者鱼龙混杂，所以需要多看甚至重复看，才可能做到看的非常顺畅与理解到位。当然，如果是找工作的话，写电路是比较切实可行的途径。多实践，多学习优质项目的代码，也许就在一些不起眼的角落你会找到令你拍案叫绝的东西，以及多模仿写电路，甚至尝试总结经验，转化为自己的知识沉淀与个人经验总结。

同时，也可以多关注行业内的一些非专业爱好者。他们通常会普及一些通俗易懂的教程或自己的学习心得亦或者个人经验。但由于行业的迅速发展，在学习的同时需要注意这些内容是否过时，留意内容编写的时间以及辩证的态度看待与学习。

如果是对理论感兴趣的小伙伴可以更聚焦在局部，从点到面，先把局部学清楚，而后带着局部的学习经验再去看其他的学习内容，即深度优先遍历（DFS：Depth First Search）要优于广度优先遍历（BFS：Breadth First Search），对此，像是相对深度的学习资料或者论文，如何找寻以及确保是有益的，其实共学就是一种很好的形式，一个人如果闭门造车闷头学习是非常困难的，通过共学与志同道友一同探索学习并深度讨论，可以很大程度上帮助我们可持续并且有效的进行学习与探索。

ZK 学到什么程度才可以去找工作呢？

郭宇认为现在就是最好的时机，先去找，能力不够就再补。大部分的工作其具体信息都是公开的，所以可以尝试着联系，帮忙改改代码或找 Bug 等。况且好的工程师需求缺口是很大的， ZK 技术也发展非常迅速，所以即便可能经验欠缺，这也不是什么问题。相反，随着技术的快速更迭，新手并不会有太多劣势。

如果我们是在 ZKVM 上，比如说像 Starknet (STRK) 类似的链上是不是就不需要写电路吗？

郭宇指出，就目前来看，这些虚拟机（VM） 需要提供给到系统调用的特殊指令，或者叫特殊接口，即你如果反复做一个计算，如果你都直接把它编译成 VM 指令，它就会膨胀的厉害。因此，常用的一些指令，我们通常都会把它电路化，在电路化之后，VM 证明所指定的分布式链路追踪（Trace）就会短很多。同时，当成电路也可以帮助预处理的部分事项并且其本身也会比 Trace 更加高效。

而在极个别的证明系统中，计算里有一些电路，同一个算法，只是参数不同，循环了十次哈希时，就正常情况来说，如果不进行干预，它就会产生十倍的哈希电路。但现在有一类的证明技术，可以把这十个电路并行起来，并且在并行起来之后能够产生额外的优化，且优化相当可观。对此，其实现在的 VM 设计原则也可以考虑把用户需要执行的特定函数让用户自己写下电路，并整合在一起，但就目前来看还是主要依靠 VM 提供。

此外，还有一类的技术，如 Folding scheme，它可以把反复串联的电路压缩成一份，这样证明过程会特别省内存但同时对于写电路有着更高的要求。总结来说，要不要学或者要不要写，其实与你的收益有很强的关联，但是理论上是可以无脑编译，通过 ZKVM 直接调用。

ZK 除了和区块链结合外，还有其他可能的方向吗？

郭宇认为隐私保护可能是一个方向，但对于它的需求存疑，因为即便是在 Web3 中，大家的隐私也都没有非常关注，更不用说传统行业。在学术圈，其实有很多 ZK 与非 Crypto 结合的方向，比方说零知识机器学习（ZKML）、ZK 数据库以及也有使用 ZK 做匿名投票等，但这些是否真的能解决实际问题以及到底是不是一个痛点，这有待确认。而当由紧迫 / 切实的需求进行推进时，其成果会更易显见，比方说 ZKEVM 的发展其实就来源于 EVM，整个以太坊需要在 Layer 2 上去兼容 EVM，尽管 EVM 做的不是很顺利，但当整个相关的技术移植到 ZKEVM 上时就取得了相对比较好的成果。

在当下区块链所处的阶段，技术与业务场景分别提供了什么价值？

郭宇回复道，如果我们讨论的是在 Crypto 世界的需求，它的用处就比较多了。比方说身份认证中的去中心化身份（DID：Decentralized Identity）以及社交网络上的隐私保护等，只不过关键点在于需要找到一个场景，切实用户需求 / 特点让它可以爆起来。所以如果是做业务的话可以多去看一看 ZK 的近况。因为就目前而言，其实现在的技术条件已经达到了或者说已经接近达到一些简单的场景。

现场观众石头对此回复说，所以由于信任或者共识的建立在当前的运转模式下，它整个消耗的资源带宽，或者说存储非常高，而通过 ZK 的话，就可以把整个的效率提升至指数级，这也就是说至少在技术层面它的价值是非常之高的，而只要它的技术价值体现了，场景价值也就一定会有相应的体现。

郭宇对此补充道但现在 ZK 发展其实有一个问题即它没有明确的方向，无法进行推测或预见。因为 ZK 的发展分叉格外的多，你无法知道哪个叉口会往上走，或在是否会有一个分叉，这也导致了做应用的人跟做理论的人之间的巨大的鸿沟。比方说做理论的人难以知道应用层面哪些问题痛点，只能靠自己拍一拍脑袋，凭空想像构建应用场景去写论文。但与此同时 ZK 的门槛又在不断的变高，以至于做产品、做业务可能更搞不清楚它可以干什么、能干什么。对此，其实做应用的可以多去了解一些基础概念与常用工具，比如说像一些常见的 ZK 的工具和文档，它到底能证明多大的业务逻辑，计算量又是如何。这并不需要有多么了解 ZK，只需要知道 ZK 的基本概念、大概能做什么事，以及什么事不善于解决等就可以了。总而言之，两者之间也是相辅相成，以共同推进区块链的繁荣与发展。

结语

通过本期 LX 分享会，相信大家对于零知识证明（ZK）的发展及其应用实践与入门学习等已有了更全面与深入的了解。而随着行业的持续发展，ZK 技术的不断创新与突破，我们也相信，ZK 将展示出巨大的发展潜力与广阔的应用前景。与此同时，这也将为加密行业乃至整个 Web3 的发展注入新的活力。未来，期待与各位继续携手并进，共探 ZK，共筑一个更安全、高效与透明的数字世界！