PG电子_ConSNARK：平衡安全与效率的零知识证明方案

为什么注目ZK-ConSNARKSuterusu项目注目的是需要trusted setup，且证明空间复杂度为常数的，计算出来高效的零科学知识证明方案，全称ZK-ConSNARK。我们告诉，一般情况下区块链系统必须将交易通过p2p网络传输给系统中每个检验节点展开检验。

因此，网络单位时间能处置的交易数目，又称出块亲率，相当大程度上各不相同区块大小，以及单位交易所占到空间大小【CDEGJKMSSSS16】。交易就越小，则出有块率越高。在隐私维护区块链方案中，交易大小又相当大程度上各不相同其所包括的零科学知识证明大小。事实上，必须trusted setup的ZK-ConSANRK文献里有数不少，Zcash所用于的方案就归属于这个类别。

但需要trusted setup的ZK-ConSNARK毕竟珍贵品种，目前本人所能寻找这方面的结果只有两篇：Crypto 2019年新鲜出炉的结果【LM19, BBF19】。这篇文章将非常简单讲解这两个方案的基本思路以及Suterusu项目在ZK-ConSANRK上的关注点。上述两篇论文【LM19, BBF19】都融合了概率性可验证证明（Probabilistically Checkable Proof，PCP）和子向量允诺（Subvector Commitment）方案。

PCP是复杂性理论和密码学里一个十分经典的结果，涉及定理的明确提出者因此得奖无数。PCP作为一个基础方案可用作结构零科学知识证明。上述两篇论文主要贡献不在于PCP，而在于这个子向量允诺方案。

其原因在于PCP方案如果想要在非交互式零科学知识证明这个领域施展身手必不可少高效的子向量允诺方案这个助手。什么是概率性可验证证明首先，我们非常简单讲解下什么是概率性可验证证明。我们在前文【林19-1】中讲解过零科学知识证明的概念。

零科学知识证明中有这么个检验者的概念，在PCP中也有个检验者。但PCP的检验者尤其哑，所以我们必须考虑到检验者如何能在做到非常少工作的情况下，还能精确辨别PCP证明者针对一个定理获取的证明否准确。尽管PCP本身的证明是十分宽，但PCP有个神秘的性质就是在证明者分解证明后，检验者只需随机在证明上查找若干点（实际中大约是安全系数×3bits才可，所以如果是256-bit security，查找长度只需256*3 bits），然后做到一些十分高效的运算就可以检验证明的正确性。

我们在前文【林19-1】中提到，区块链中用于的零科学知识证明必须是十分结尾的且最差计算出来也是高效的，尽管PCP的检验计算出来极为高效，但证明过长仍是个弊病。我们注意到在检验时检验者确实必须采访的只是整个证明中大于一部分内容。那么问题来了，是不是有可能让证明者在分解PCP证明后自己在证明上随机挑选检验者必须的查找点，然后只传输这些信息给检验者，从而大大减少通信量呢？这个思路是对的，但一个蓄意的证明者，或者一个不掌控证明秘密的人可以针对这个非常简单思路发动如下几个反击：比如有可能这个用作随机挑选查找点的随机数本身不随机，或者攻击者先生成随机数，然后再行针对这些随机方位分解对应证明，换句话说他有可能没能力分解全部准确PCP证明，但他却有办法针对提早分解的随机方位分解合法的部分证明，进而适当地更换伪造他所分解的非法证明的对应方位内容，从而通过检验。

什么是子向量允诺如何避免这类反击呢？这就必须引进我们的子向量允诺方案了。首先，我们再行说道下2019年前的工作中如何解决问题这个问题。

允诺这个概念我在前面讲解Mimblewimble的文章【林19-3】中曾提及，事实某种程度有Pedersen允诺方案，我前面关于Zcash的文章【林19-2】中提及的Merkle tree也可以被看做是一种允诺方案。那么明确Merkle tree可以怎么和PCP融合呢？证明者首先分解PCP证明，这些证明每个bit将作为Merkle tree的一个叶节点来计算出来哈希树根节点数值，这个数值就是一个对上述PCP证明的允诺了。

我们之前提过允诺方案有个soundness性质可以确保一旦允诺公开发表，用户是不了在关上允诺时转变允诺的内容的，在Merkle tree中这个性质主要是由所用于哈希函数的抗撞击性来确保的。那么好，证明内容一旦分解无法伪造了，接下来的问题就是随机性如何解决问题的问题了？如果Merkle tree现在的六根节点值是r的话，那么用作要求证明查找方位的随机数将被定义成H(r)，这里H是个安全性哈希函数，比如SHA256。

为什么这能确保H(r)是随机的呢？这个是和哈希函数的理论建模有关的。密码学理论里一般把H(.)建模成随机应验机，这意味著即使哈希函数的输出是公开发表的，其输入也是几乎随机的。哈希函数的这个随机应验机模型和允诺方案的soundness性质合力确保检验者可以坚信这个随机数是在证明者把PCP证明关在允诺这个箱子之后才分解的，且这个用作定义证明查找方位的随机数显然是随机的。

因此如果他确认后面允诺关上过程中表明的消息显然是这些随机数对应的位点信息后，那么上述反击就可以被指出是违宪的。好，网卓新闻网，那么现在问题就规约到如何确保证明者在允诺关上阶段输入的信息显然是对应由这些随机数定义的方位的。在Merkle tree这种允诺中，每个关上的消息同时还不会有一些附属的证明信息来证明这个关上的消息显然是某个叶节点方位的信息。但留意这个允诺方案的附属证明空间复杂度不是常数，而是PCP空间复杂度的对数。

另外，由于Merkle tree每次不能关上一个证明位点，上述证明过程必须反复和安全性参数涉及的次数（比如256*3次），这就造成证明所占到空间无法防止地收缩。【LM19】文章提及如果一个PCP所占到空间为1GB，用于Merkle tree这种允诺方案，对应的最后零科学知识证明所占到空间为88KB，且绝大部分都是由Merkle tree的这种附属证明造成的额外支出。现在，我们再一可以讲解什么是子向量允诺了，事实上，Merkle tree可以看做一种十分破旧的子向量允诺方案。

和Merkle tree一样，Crypto 19明确提出的子允诺方案可以重复使用把整个向量放进允诺这个黑箱里，但和Merkle tree有所不同的是，在关上允诺阶段，用户可以同时关上和向量若干个方位初始化的内容，而且对应的证明空间复杂性为常数。这个方案的结构必须中用一个类似的代数结构，叫group of unknown order。事实上，这个概念可以看做RSA group的一种抽象化。

但RSA group对应方案必须trusted setup，所以不过于限于于隐私维护区块链系统。目前也不存在需要trusted setup的RSA group方案，但效率极低。所以上述两文都提及了另外一种基于class groups of quadratic imaginary order的代数结构来确保需要trusted setup的高效子向量允诺方案。Suterusu的关注点尽管上述两文的方案已能构建可高效检验的ZK-ConSNARK，但底层基于的PCP方案由于分解证明的支出过于大无法实际应用于，但他们起码从理论上证明了需要trusted setup的ZK-ConSNARK的可行性。

Suterusu将针对去中心化隐私缴纳这种类似的应用于场景优化构建一些类似的ZK-ConSNARK，来前进隐私维护区块链的效率和去中心化程度。

本文来源：PG电子-www.nysawchina.com