*注：首先，這是一個用一個小時寫的草稿。 主要是為了快速收集信息，所以可能存在非常多的潛在錯誤和不完整的信息。

對 ZK 的主要批評包括兩個：

• 一是證明時間長 (因此有各種 benchmark、各種新的 ZK 協議和各種硬件優化）；

• 一是系統和應用程序安全性仍然需要測試。

 證明生成性能​

零知識證明是區塊鏈領域非常流行的技術。 由於鏈上計算資源稀缺且昂貴，零知識證明允許這些計算在鏈下進行，雖然鏈下證明生成的總時間消耗非常高，但它仍然壓縮了最終證明和相關的計算驗證，從而允許計算“在鏈上”。

ZK 證明生成時間過長的問題往往被研究者和開發者所忽視，因為這本質上是 ZK 需要做出的權衡。

雖然他們沒有直接批評 ZK 的這個缺點，但是他們有很多從對面解決這個缺點的方法和討論。

也就是說，他們通過提出各種解決方案並進行大量基準測試來隱含地談論 ZK 的極長證明時間。

a) Benchmark​

在衡量 ZK 應用之前，我們首先要測試 ZK 協議底層 commitment 的性能。

因為比如，FRI 導致 STARK，KZG 導致常規 SNARK，IPA 導致 Bulletproof 。 底層承諾的性能測試對於 ZK 應用的性能並不直觀，但對於理解 ZK 證明時間長的問題很有幫助。

從上面的鏈接我們可以看出，這些底層承諾協議不僅計算複雜 (可能導致證明時間長)，而且還存在內存消耗非常大的問題。

當然，內存消耗其實更多的是跟硬件配置要求有關，這跟我們今天要討論的話題是不一樣的。

對於具體的 SNARK 性能測試，a16z crypto 將它們分為前端和後端：

• 前端通常是 ZK 應用開發者接觸到的 Cairo 語言/ zkVM 高級語言等；

• 而後端是更接近 SNARK 證明生成時間的承諾等底層密碼學操作。

其中，作者提到 SNARK 證明生成具有大約 100 倍的計算開銷，並且每個 ZK 協議都有額外的開銷，例如：

“In Groth16, P must work over a pairing-friendly group, whose operations are typically at least 2x slower than groups In Groth16, P must work over a pairing-friendly group, whose operations are typically at least 2x slower than groups that aren't pairing friendly. , this results in at least an additional factor-6 slow down relative to the 100-|C| estimate above.”

總體而言，可以說 zk-SNARK 的額外性能開銷在 200 - 1000 倍的範圍內。

此外，文章還提到了 zk-SNARK 的其他限制，例如可信設置和內存使用。

Modulus Labs 的文章測量了一些 ZK 協議的實際性能。有些基準是針對參數數量的，這對我們來說不是很直觀。然而，在應用中，文章提到在 Worldcoin 用例中，即使使用 “最快” 的 Plonky2，仍然需要幾分鐘的證明生成時間和數十 GB 的內存消耗，無法在個人電腦上運行。

b) 遞歸和批處理​

為了減少證明生成時間，我們可以並行證明多個證明。

通常，有兩種方法可以做到這一點：一種是批處理，另一種是遞歸。

簡單來說，批處理是同時證明一批證明，最後將它們聚合在一起，而遞歸是在一個證明中驗證其他證明。 一般而言，遞歸方法具有更小證明大小 的額外優勢。

一些更常見的聚合方法包括 Halo2、Plonky2。他們每個人都以不同的方式執行批處理和遞歸，從而減少了證明時間。

除了ZK的協議層，ZK的應用層也可以有針對性的優化。例如，可以同時使用多個 ZK 協議 (STARK + SNARK ），或者針對宏觀採取遞歸策略進行特定於應用程序的調優。

一般來說，這實際上減少了協議和證明分配方面的證明生成時間。 在探索新的 ZK 協議時，減少證明時間是最重要的考慮因素。

c) 硬件加速​

此外，從硬件角度進一步減少 ZK 應用在物理和節點層面的證明時間也做了很多努力。

首先，與前面提到的新協議一樣，ZK 協議被設計為儘可能對硬件友好，例如 HyperPlonk。

Paradigm 提到，ZK 的證明生成速度慢主要是由於涉及大量的 MSM 和 FFT，它們對硬件不友好，導致由於隨機內存訪問等問題導致最終證明生成速度慢。 對於這些底層加密計算，ZK 協議需要在它們的組成和規模上進行一些權衡，以使其對硬件更加友好。

幾家 ZK 硬件加速廠商表示，GPU 實際上是目前最經濟和可配置的硬件選擇，我們最終將有 FPGA 過渡到 ASIC 階段。 根據 zk 硬件公司的說法，他們的第一版 ASIC 可以直接減少至少 30% 的 ZK 證明生成時間。

此外，由於不同的服務器配置，將不同的雲服務器作為節點運行可能涉及不同的硬件特定優化。

Security​

ZK 現在的另一個批評是電路代碼仍然需要正確 (沒有 bug)。

如果 ZK 協議從健全性、完整性、零知識的角度受到攻擊，我們將不再擁有有效的 ZK 系統。 我們可以在這個鏈接中看到各種角度的攻擊示例。

雖然 ZK 應用可以被稱為 trustless，但我們仍然需要確保項目的 ZK 協議和應用的代碼和架構是正確的。 區塊鏈領域中存在多種 ZK 錯誤。例如，由於 zkEVM 的 ZK 電路代碼庫龐大的問題，Vitalik 談到了 ZK 應用程序的多證明者的需求。

因此，ZK 系統可能需要與形式驗證等安全工具或 Ecne 等其他安全相關工具搭配使用。應用程序級別，它需要更多的審計，特別是對於像 zkEVM 這樣的大項目。