Verifer验证某个证明是否创立，计较公式如下：
Setup包罗两步：1）Lag（拉格朗日插值），R1CS到QAP的转化进程 2）fixMSM – 定点的多倍点加法。Prover也包罗两步：1）FFT（计较H多项式）2）varMSM – 不定点的多倍点加法。
DIZK设计中，R1CS的电路回收RDD数据暗示，因为R1CS电路跟着电路门的个数变大而变大。Pk（pubilc key）页是跟着门和R1CS的contraint的个数变大而变大，也回收RDD暗示。输入信息包罗两部门：果真的输入信息和隐私的输入信息。一般来说，果真的输入信息较量小，DIZK直接回收一般向量暗示。隐私信息回收RDD数据暗示。
3. Apache Spark
DIZK论文是Howard Wu等在2018年颁发。论文的下载地点如下：
假如a矩阵是个麋集型矩阵的话，只要匀称的切分计较劲即可。可是，在现实应用中，a矩阵是个稀疏矩阵。DIZK提出的要领也较量简朴明白：预先处理惩罚矩阵，统计每列的非零个数。非零个数，代表了计较劲。然后再按照这些非零个数，确定计较劲的分别。
1. DIZK逻辑框架
https://eprint.iacr.org/2018/691.pdf
5. DIZK计较机能
物理上，Spark框架包罗三个脚色：Driver Program就是Spark框架上编写的措施，Cluster Manager就是集群打点节点，Worker Node就是集群节点。从软件角度看，SparkContext维护了整个措施的执行情况。所有的计较会解析成一个个的Task，所有的Task都由Executor执行。
DIZK，是在Spark大数据计较框架下的漫衍式零常识证明系统。DIZK具体阐明白Groth16的计较，并针对几个计较模块提出了漫衍式计较算法。从DIZK的测试数据看，DIZK的Setup和Prover计较机能跟着计较节点的个数增长成线性增长。
总结：
4. DIZK计较框架
Lag的计较的公式如下：
左边代表的是传统的零常识证明（zk-SNARK）系统，主要由三部门计较构成：Setup/Prover/Verifier。右边代表是DIZK的逻辑框架。DIZK将Setup/Prover的计较用漫衍式实现，计较之间的依赖也用漫衍式数据暗示。Verifier相对来说简朴（毫秒级的计较），不需要漫衍式实现。
2. R1CS/QAP和Groth16
DIZK论文给出了漫衍式计较的测试功效：Apache Spark是大数据漫衍式处理惩罚框架。可以查察Spark官方先容领略Spark的一些逻辑：
在Spark的框架上，DIZK设计了Setup和Prover的计较框架：
常常有人在提及超大电路证明的时候，谈到DIZK。最近有空，我就看了看DIZK的论文以及源代码。总的来说，从技能人的角度来说，照旧有点惊喜，DIZK操作漫衍式数据处理惩罚Apache Spark平台，实现了zk-SNARK证明系统。
RDD（Resilient Distributed Datasets）是Spark框架下大数据的暗示。你可以领略，RDD是漫衍式的数据暗示。
简朴的说，DIZK的Setup和Prover计较机能跟着计较节点的个数增长成线性增长。
漫衍式计较的焦点，是让多个executor执行的计较劲只管匀称。在Lag的计较步调中，因为R1CS的(1+N)xM的矩阵是稀疏矩阵，DIZK提出了让多个executor匀称计较的要领。
DIZK在第4章具体描写了FFT/Lag/fixMSM/varMSM四个计较都能回收漫衍式算法。简朴的说，FFT的漫衍式算法相对巨大一些，，其他三个计较天生可以漫衍式计较。
Prover生成证明，计较公式如下：
固然DIZK是漫衍式零常识证明系统，零常识证明的协议和计较和传统的证明系统很是像。论文通过两张图给出了两者的区别和接洽：
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
