零知识证明zk-snark的8种实现的对比

简介:

zk-SNARK是一个快速发展的领域,仅在过去的两个月里,就宣布了数个突破性的zk-SNARK构建。曾经必须的可信设置现在已经是冗余的了,这意味着可以使用任何计算。然而关于这些新的zk-SNARK构建的资料很难找到。在这片文章中,我将比较这些新出现的zk-SNARK构建,并在以后不定期更新。

像zk-SNARK这样的零知识证明有很多应用:Zcash利用零知识证明来保护隐私,Coda和Mir利用零知识证明将整个区块链压缩到只有几K字节,0x和Matter则利用零知识证明将许多交易封装为以太坊
上的单一证明。如果你还不了解零知识证明,可以看一下这里的解释

相关链接:以太坊 | 比特币 | EOS | Tendermint Core | Hyperledger Fabric | Omni/USDT | Ripple

1、可信设置

传统的zk-SNARK,例如Groth16有一个主要的缺点:依赖于一个公共的参考字符串,该字符串使用一次性可信设置创建。该设置创建一个供证明方和验证方同时使用的参考字符串。这里面有三个主要的问题:

  • 可信设置生成的“有毒废料”,如果泄露的话,可以被用于生成无法 检测的伪造证明。多方计算通常会忽略这个问题,但是仪式的协调 异常复杂。
  • 可信设置创建的参考字符串通常绑定到一个电路(基本上就是程序)。 不可能为任何计算创建一个单独的可信设置,这使得很多应用都不可行, 例如智能合约。
  • 可信设置是一次性的,生成的参考字符串不可升级,这意味着如果 Zcash需要修复其zk-SNARK电路中的哪怕一个很小的bug,也需要一个 新的仪式来部署修复。

2、通用zk-SNARK

新的zk-SNARK构建解决了对可信设置的要求,这意味着像智能合约等任意代码可以作为zk-SNARK运行。目前有两个不同的方法:

  • 透明设置

设置创建一个共用的参考字符串,公开并且不会创建有毒废料。这和zk-STARK的机制类似。Fractal、Halo和SuperSonic-CG使用的就是透明设置。这种方法的缺点在于证明数据量会很大。Fractal和zk-STARK证明能达到250KB,这对于区块链应用是不现实的。Fractal团队告诉我,他们正在解决证明数据量过大的问题。Halo和SuperSonic的证明要小一些,
不到10KB。

  • 通用设置

这种设置创建一个结构化参考字符串,也会产生有毒废料,不过设置不再局限于单一电路,一个参考字符串可以用于无限的任意电路中。例如Marlin、SuperSonic-RSA和Plonk。这三种构建生成的参考字符串可以升级,以便提高安全性。如果当前的有毒废料泄露,那么只需要升级设置就可以再次保障系统的安全。

3、zk-SNARK分类

如何比较新出现的zk-SNARK?在证明人侧,为每种zk-SNARK构建生成一个证明需要O(n log n)时间。区别主要在于证明的数据量大小、验证时间以及参考字符串的大小。

下面的分类基于Alessandro Chiesa在旧金山ZKSummit上的演讲

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OFmjyJkG-1581898965870)(compare-gp-zksnarks/classify.png)]

所有这些zk-SNARKS使用的编译器可以分为三类:预处理、DARK和传统的SNARK(非通用):

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0KQDwOxX-1581898965871)(compare-gp-zksnarks/three-types.png)]

4、已有的zk-SNARK构建

作为参考,我将介绍三种已有的构建。Groth16是非通用的,它依赖于一次性不可升级的设置,Sonic是一个通用的zk-SNARK。

Groth16:Groth16是目前最快、数据量最小的zk-SNARK,被用于Zcash等。Groth16不是通用的,其设置需要绑定到一个特定的电路。由于其速度和证明的小数据量,因此常常被新的zk-SNARK拿来比较性能。Groth16论文链接:https://eprint.iacr.org/2016/260

Sonic:Sonic是一个早期的通用zk-SNARK协议。论文发表于2019年1月。Sonic支持通用、可升级的参考字符串。Sonic的证明大小固定,但是验证成本高。理论上可以将多个证明分批验证以获得更好的性能。下面列举的许多新的zk-SNARK都是基于Sonic。Sonic论文链接:https://eprint.iacr.org/2019/099

5、新的zk-SNARK构建

Fractal:Fractal 是一种允许递归的zk-SNARK。通过对电路的预处理实现了透明设置。证明最大250KB,这笔其他构建生成的证明都要大的多。Fractal论文链接: https://eprint.iacr.org/2019/1076

Halo:Halo支持递归证据组织,无需可信设置。与其他新的zk-SNARK构建不同,Halo的验证时间是线性的。Halo论文链接: https://eprint.iacr.org/2019/1021

SuperSonic:SuperSonic 是Sonic的改进版,是第一个在验证时间和证明数据量方面实用化的透明zk-SNARK。SuperSonic论文链接: https://eprint.iacr.org/2019/1229

Marlin:Marlin 是Sonic的改进版,证明时间缩短10倍,验证时间缩短4倍。Marlin论文链接: https://eprint.iacr.org/2019/1047

Plonk:Plonk也是Sonic的改进,证明时间缩短5倍。Plonk论文链接: https://eprint.iacr.org/2019/953

6、zk-SNARK构建的性能比较

一个大问题是:如何比较这些不同zk-SNARK构建的性能?不幸的是,我不知道zk-SNARK有任何基准测试,不过即使有的话,也不是所有的新构建都有一个参考实现。因此下面表格中的数字请不要过于较真,它们是基于论文中的基准指标,或者基于发明者提供的估算。

通过查看证明的大小、证明运行时间、验证运行时间,有一些方面是值得注意的:

  • 使用透明设置的构建通常由较大的证明数据量
  • Halo的验证时间不恒定,这和其他新的zk-SNARK构建不同
  • 在证明数据量尺寸和运行速度方面,Groth16仍然是无敌的

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XNlpemhR-1581898965872)(compare-gp-zksnarks/performance.png)]


原文链接:8种zk-SNARK构建的比较 — 汇智网

目录
相关文章
|
3月前
|
监控
分布式-Zookeeper-Zab协议
分布式-Zookeeper-Zab协议
|
5月前
|
算法
共识协议的技术变迁问题之Raft的选举算法进行如何解决
共识协议的技术变迁问题之Raft的选举算法进行如何解决
103 7
|
Java 开发工具 Maven
分布式系列教程(12) -分布式协调工具Zookeeper(选举与哨兵机制)
分布式系列教程(12) -分布式协调工具Zookeeper(选举与哨兵机制)
87 0
|
7月前
|
存储 分布式计算 Hadoop
ZooKeeper初探:分布式世界的守护者
ZooKeeper初探:分布式世界的守护者
87 0
|
7月前
Zookeeper的选举机制原理(图文深度讲解)——过半选举
Zookeeper的选举机制原理(图文深度讲解)——过半选举
508 0
|
存储 算法 安全
Raft 共识算法1-Raft基础
Raft 是一种用于管理第 2 节中描述的形式的复制日志的算法。@fig2 以压缩形式总结了该算法以供参考,@fig3 列出了该算法的关键属性; 这些图片中的元素将在本节的其余部分进行分段讨论。
122 1
|
存储 算法 安全
Raft 共识算法4-选举限制
本节通过添加对哪些服务器可以被选为领导者的限制来完成 Raft 算法。 该限制可确保任何给定任期的领导者都包含之前任期已提交的所有条目(@fig3 中的领导者完整性(Leader Completeness)属性)。 考虑到选举限制,然后我们使提交规则更加精确。 最后,我们展示了领导者完整性的证明草图,并展示了它如何保证复制状态机的正确行为。
141 0
|
存储 算法 索引
深入剖析共识性算法 Raft-2
深入剖析共识性算法 Raft
160 0
|
存储 消息中间件 算法
深入剖析共识性算法 Raft
深入剖析共识性算法 Raft
249 0
|
存储 消息中间件 算法
zookeeper知识结构2-zab协议
通过《zookeeper知识结构1》了解了zookeeper是什么?为什么使用zookeeper? 以及zookeeper内部数据结构,选举机制
125 0
zookeeper知识结构2-zab协议