雖然DIZK是分散式零知識證明系統，零知識證明的協議和計算和傳統的證明系統非常像。論文透過兩張圖給出了兩者的區別和聯絡：
左邊代表的是傳統的零知識證明（zk-SNARK）系統，主要由三部分計算組成：Setup/Prover/Verifier。右邊代表是DIZK的邏輯框架。DIZK將Setup/Prover的計算用分散式實現，計算之間的依賴也用分散式資料表示。Verifier相對來說簡單（毫秒級的計算），不需要分散式實現。
2. R1CS/QAP和Groth26
Prover生成證明，計算公式如下：
Verifer驗證某個證明是否成立，計算公式如下：
3. Apache Spark
Apache Spark是大資料分散式處理框架。可以檢視Spark官方介紹理解Spark的一些邏輯：
http://spark.apache.org/docs/latest/cluster-overview.html
物理上，Spark框架包括三個角色：Driver Program就是Spark框架上編寫的程式，Cluster Manager就是叢集管理節點，Worker Node就是叢集節點。從軟體角度看，SparkContext維護了整個程式的執行環境。所有的計算會分解成一個個的Task，所有的Task都由Executor執行。
RDD（Resilient Distributed Datasets）是Spark框架下大資料的表示。你可以理解，RDD是分散式的資料表示。
DIZK設計中，R1CS的電路採用RDD資料表示，因為R1CS電路隨著電路門的個數變大而變大。Pk（pubilc key）頁是隨著門和R1CS的contraint的個數變大而變大，也採用RDD表示。輸入資訊包括兩部分：公開的輸入資訊和隱私的輸入資訊。一般來說，公開的輸入資訊比較小，DIZK直接採用一般向量表示。隱私資訊採用RDD資料表示。
4. DIZK計算框架
在Spark的框架上，DIZK設計了Setup和Prover的計算框架：
Setup包括兩步：1）Lag（拉格朗日插值），R1CS到QAP的轉化過程 2）fixMSM - 定點的多倍點加法。Prover也包括兩步：1）FFT（計算H多項式）2）varMSM - 不定點的多倍點加法。
DIZK在第4章詳細描述了FFT/Lag/fixMSM/varMSM四個計算都能採用分散式演算法。簡單的說，FFT的分散式演算法相對複雜一些，其他三個計算天生可以分散式計算。
分散式計算的核心，是讓多個executor執行的計算量儘量均勻。在Lag的計算步驟中，因為R1CS的(1+N)xM的矩陣是稀疏矩陣，DIZK提出了讓多個executor均勻計算的方法。
Lag的計算的公式如下：
如果a矩陣是個密集型矩陣的話，只要均勻的切分計算量即可。但是，在現實應用中，a矩陣是個稀疏矩陣。DIZK提出的方法也比較簡單明瞭：預先處理矩陣，統計每列的非零個數。非零個數，代表了計算量。然後再根據這些非零個數，確定計算量的劃分。
5. DIZK計算效能
DIZK論文給出了分散式計算的測試結果：
簡單的說，DIZK的Setup和Prover計算效能隨著計算節點的個數增長成線性增長。
總結：
DIZK，是在Spark大資料計算框架下的分散式零知識證明系統。DIZK詳細分析了Groth26的計算，並針對幾個計算模組提出了分散式計算演算法。從DIZK的測試資料看，DIZK的Setup和Prover計算效能隨著計算節點的個數增長成線性增長。
