Crypto行业被广泛关注的零知识证明技术，并非是这几年刚冒出来的新技术，而是在1980年就被数学家S.Goldwasser、S.Micali及C.Rackoff提出。
零知识证明涉及一系列步骤，可以实现密码学中的「可用而不可知」。
而区块链有着公开透明、不可篡改等特征，意味着加密投资者的链上资产及交易记录是没有隐私可言的，于是零知识证明技术被引入了区块链，当中以zk-SNARK和zk-STARK最为关注。
zk-SNARK被项目方采用得最多，zk-STARK则被密码学专家认为优于ZK-SNARK。那么综合技术与实际应用，二者谁更优？
zk-SNARK：简洁+非交互性
AlessandroChiesa等人在2012年开发了zk-SNARK协议，这是一种简洁化、非交互式的零知识证明技术，全称是zero-knowledgesuccinctnon-interactiveargumentsofknowledge，可以拆解成三部分来理解：
zero-knowledge：
零知识证明，在不暴露隐私情况下向对方证明一件事情，让数据「可用而不可知」。
succinct：
简洁性，要证明的东西占用的空间很小，而且可以快速验证。
non-interactive：
非交互性，意味着证明者和验证者之间不需要有交集即可快速地得到验证结果。
zk-SNARK的简洁性和非交互性，是相对于传统的零知识证明方案而言的。
简单来说，传统方案是交互式证明，即示证者和验证者之间反复确认，你可以理解为示证者不断向验证者询问“是或不是？”，然后验证者不断给出回答，直到最后碰出一个正确答案来，所以效率很低。
zk-SNARK的解决方案则不需要双方反复确认“是或不是”，而是提前先搞一个「可信初始化」，从而生成公共参考字符串，然后所有的示证者都可以直接访问它。
打一个通俗的比方。交互式证明相当于老师要批改每一个考生的每一道考题，效率很低，但正确答案只掌握在老师这边，基本不存在有人偷答案的情况。
但zk-SNARK直接上传了正确答案，然后让考生自己对答案，非常高效，代价是答案有可能被泄露，虽然这个答案系统是经过加密的。
因此针对zk-SNARK容易被泄露的问题，有很多围绕着提高「答案系统」安全性的解决方案，不同采用zk-SNARK的项目方的方案各有不同。如zCloak钱包是直接把算法以纯文本的形式发给用户，用户下载到本地去做计算。
zk-STARK：概率证明+缓冲时间
zk-STARK是成立于2017年12月的StarkWare团队开发的，它是针对zk-SNARK的替代解决方案。研发历时一年多，经过无数次迭代才彻底搞定，已经到2019年了。
zk-SNARK是提前生成公共参考字符串，用非交互式证明的方式提高了证明效率，但也留下了隐患。zk-STARK虽然是交互式证明，但它是一种巧妙的交互式证明——通过哈希函数碰撞来保证安全性，因此也实现了高效证明。
这个思路直接借鉴自2015年推出的交互式预言机证明技术，简单来说是先把问题用密码学的方式打碎，然后验证者随机向示证者提出几个的问题，如果几轮下来，示证者都给出准确的回答，那么验证就通过了。
所以zk-STARK同样也只需要极少的计算资源就可以完成证明，但是它更安全，不存在答案泄露的风险。并且为了进一步确保安全性，还设置了争议时间延迟来作为缓冲。
zk-SNARK和zk-STARK的区别
1.透明度
zk-SNARK的公共参考字符串通常由一个小团体来保管，因此有泄露的可能性，从而被恶意利用，如创建虚假证明。
zk-STARK则直接利用生成随机性的参数来验证，不需要任何第三方的「答案系统」，因此透明度大幅提高。
2.抗量子计算机攻击
zk-SNARK未来会轻易被量子计算机暴力破解。当然，量子计算何时到来还是个问题。
zk-STARK采用的是哈希函数碰撞的方法来证明，理论上量子计算机的暴力破解是无效的。
3.可扩展性
zk-SNARK的证明在链上更具可扩展性，zk-STARK在纯链上似乎没有优势。
StarkWare官网宣称是最快的，可能是因为zk-STARK允许链下进行大规模计算和存储，然后在链上完成验证，因此可扩展性显著提升，而成本显著降低。
总结
zk-SNARK技术被采用得最多，尤其是在以太坊扩容场景中。zk-SNARK主要是围绕「隐私保护」去做身份、支付、DeFi、资产证明等各种应用。
zk-STARK虽然也在发展之中，但技术尚不成熟，至少在通用性上受限，所以我们看到大多是围绕着「可扩展性」去做各种应用。
不过据StarkWare团队在2022年的说法，已经解决了可扩展性，该把目标瞄准「隐私保护」了，而方式是通过StarkNet的Layer3以及Layer4中以分形分层的方式解决，这似乎与zk-STARK证明系统本身没有直接关系。
至少就目前而言，大多数以太坊Layer2项目(zkSync、Aztec、Loopring、Scroll等)都采用的是zk-SNARK技术路线，除了通用性上受限，还有一个原因是普遍反馈说zk-STARK的开发难度过大……
当然长远来看，zk-STARK可承载的运算量更大，可能更有前景。
总的来说，zk-SNARK和zk-STARK的关系，有些像Optimisticrollups和ZKrollups的关系，前者短期利好，后者长期利好。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。