文章開頭講了講 NIZK/zk-SNARK的基本概念，給出了zk-SNARK的工作流程圖：
在這個流程圖上，清晰的給出了“電路”，“R1CS”以及“QAP”的關係。一個NP問題，先拍平（Flatten）構成電路（若干個乘法門/加法門構成）。在電路的基礎上，構造約束，也就是R1CS。有了一個個的約束，就可以把NP問題，抽象成QAP問題。有了QAP問題的描述，Groth26的演算法就可以初始化，生成以及驗證證明了。
整個流程從工程的角度，又可以“切分”成幾個大塊：
設計階段(Design) - NP問題，也就是業務的設計。
翻譯QAP(Translation) - 抽象並轉化成QAP問題。
初始引數生成（Setup) - 生成可信引數，也就是傳說中的CRS(Common Reference String)。
構造證明 - 提供私有/公開資訊，生成證明。
驗證 - 採用公開資訊，驗證證明。
2. zk-SNARK的工具鏈
文章中也比較細心地給出了目前zk-SNARK開發的各種高階語言以及相互的依賴關係。
大家可以看出，目前，R1CS->QAP的這條鏈上，相對其他來說是最健壯的。如果開始入門的小夥伴，可以從Zokrates/libsnark/Bellman入手：
零知識證明 - libsnark原始碼分析
零知識證明 - bellman原始碼分析
零知識證明 - 深入理解ZoKrates
3. 應用風險總結
開發實現的風險
零知識證明的開發（所有的軟體開發）常見的安全風險：記憶體汙染，邏輯上的漏洞。加密的東西，沒有時間的挑戰都感覺有隱患。新的加密的實現存在新的風險。
文章舉例，Zcash中的Faerie Gold攻擊。在Zcash生成commitment的時候，傳送方有意採用同樣的隨機數(rho)傳送多筆交易。接受者只能消費其中的一筆交易。
去年7月份，暴露出來另外一個雙花的Bug：
零知識證明 - zkSNARK應用的Nullifier Hash攻擊
初始設定的風險
zk-SNARK一直被詬病，就是因為需要Trusted Setup。這個初始設定涉及到人為因素，雖然可以採用MPC多方計算加強安全性，但是始終不是絕對安全。
資訊洩露
雖然ZCash提供了隱私交易，但事實上截止2019年9月份，整個Zcash的交易中只有5%的交易是隱私交易：
並且，從進行隱私交易的交易地址，金額，交易時間以及使用者習慣，也可以推斷出一些有用資訊。
密碼學本身安全問題
Groth26發表在2016年，2017年就大規模應用。沒有得到充分的時間驗證。Zcash之前有些零知識證明相關的漏洞，都是很晚才公佈。文章列舉了一些之前公佈的漏洞，感興趣的小夥伴可以看看。
其他問題
文章給出了自己的一些安全思考，並列舉了一些其他問題。
文章最後給出瞭如何使用ZKP構造協議來進行資料的交易。對這部分感興趣的小夥伴，可以自己檢視原文。
感謝360安全的Zhiniang Peng，分享零知識證明和相關安全問題。大會發言用的完整版PPT，也分享給我了。需要原始完整PPT的小夥伴，可以留言。
