詳解Celer「萬神殿Pantheon」：零知識證明開發框架評測平台
一級標題
一級標題
一級標題
零知識證明開發框架評測平台「萬神殿Pantheon」
過去幾個月，我們投入了大量時間和精力，開發了利用zk-SNARK 簡潔證明構建的前沿基礎設施。這個次世代創新平台使開發者能夠構建前所未有的區塊鏈應用新範例。在開發工作中，我們測試並使用了多種零知識證明(ZKP) 開發框架。雖然這段旅程收穫頗豐，但我們也確實意識到，當新的開發者試圖找到最適合其特定用例和性能要求的框架時，多種多樣的ZKP 框架通常會給他們帶來挑戰。考慮到這一痛點，我們認為需要一個能夠提供全面性能測試結果的社區評估平台，這將極大地促進這些新應用的開發。為了滿足這一需求，我們推出了零知識證明開發框架評測平台「萬神殿Pantheon」這一公益社區倡議。倡議的第一步將鼓勵社區分享各種ZKP 框架的廣受認可的測試平台，一級標題
一級標題
在這篇文章中，我們邁出了構建ZKP Pantheon 的第一步，在一系列低級電路開發框架中使用SHA-256 提供一組可複現的性能測試結果。雖然我們承認其他性能測試粒度和原語或許也是可行的，但我們選擇SHA-256 是因為它適用於廣泛的ZKP 用例，包括區塊鏈系統、數字簽名、zkDID 等。另外值得一提的是，我們在自己的系統中也使用了SHA-256 ，所以這對我們來說也很方便！
二級標題
二級標題
二級標題
Circom + snarkjs / rapidsnark證明系統
gnark近年來，我們觀察到零知識證明系統激增。跟上該領域所有激動人心的進步是具有挑戰性的，我們根據成熟度和開發者採用情況精心挑選了以下證明系統作為測試對象。我們的目標是提供不同前端/後端組合的代表性樣本。
Arkworks: Circom 是一種流行的DSL，用於編寫電路和生成R 1 CS 約束，而snarkjs 能夠為Circom 生成Groth 16 或Plonk 證明。 Rapidsnark 也是Circom 的證明器，它生成Groth 16 證明，並且由於使用了ADX 擴展，它通常比snarkjs 快得多，並儘可能並行化證明生成。
Halo 2 (KZG): gnark 是來自Consensys 的綜合Golang 框架，支持Groth 16、Plonk 和許多更高級的功能。
Plonky 2 : Arkworks 是一個用於zk-SNARKs 的綜合Rust 框架。
Starky: Halo 2 是Zcash 與Plonk 的zk-SNARK 實現。它配備了高度靈活的Plonkish 算術，支持許多有用的原語，例如自定義網關和查找表。我們使用具有以太坊基金會和Scroll 支持的KZG 的Halo 2 分叉。
: Plonky 2 是基於來自Polygon Zero 的PLONK 和FRI 技術的SNARK 實現。 Plonky 2 使用小的Goldilocks 字段並支持高效的遞歸。在我們的性能測試中，我們以100 位推測的安全性為目標，並使用為性能測試工作產生最佳證明時間的參數。具體來說，我們使用了28 Merkle 查詢、 8 的放大係數和16 位工作量證明挑戰。此外，我們設置num_of_wires = 60 和num_routed_wires = 60 。
: Starky 是Polygon Zero 的高性能STARK 框架。在我們的性能測試中，我們以100 位推測的安全性為目標，並使用產生最佳證明時間的參數。具體來說，我們使用了90 Merkle 查詢、 2 倍放大係數和10 位工作量證明挑戰。
下表總結了上述框架以及我們性能測試中使用的相關配置。這個列表絕不是詳盡的，我們還將在未來研究許多最先進的框架/技術（例如，Nova、GKR、Hyperplonk）。
請注意，這些性能測試結果僅適用於電路開發框架。我們計劃在未來發布一篇單獨的文章，對不同的zkVM（例如，Scroll、Polygon zkEVM、Consensys zkEVM、zkSync、Risc Zero、zkWasm）和IR 編譯器框架（例如，Noir、zkLLVM）進行性能測試。性能評測方法論為了對這些不同的證明系統進行性能測試，我們計算了N 字節數據的SHA-256 哈希值，其中我們對N = 64、 128、...、 64 K 進行了實驗（Starky 是一個例外，其中電路重複SHA-256 固定64 字節輸入的計算，但保持相同的消息塊總數）。可以在
此存儲庫
中找到性能代碼和SHA-256 電路配置。
此外，我們使用以下性能指標對每個系統進行了性能測試：
證明生成期間的平均CPU 使用率百分比。 （該指標反映了證明生成過程中的並行化程度）
二級標題
二級標題
二級標題
機器
我們在兩台不同的機器上進行了性能測試：
二級標題
二級標題
正文
正文
正文
約束數量
在我們繼續討論詳細的性能測試結果之前，首先通過查看每個證明系統中的約束數量來了解SHA-256 的複雜性是很有用的。重要的是要注意不能直接比較不同算術方案中的約束數量。
Halo 2 和Plonky 2 都使用Plonkish 算術，其中行數範圍從2 ^ 22 到2 ^ 23 。由於使用查找表，Halo 2 的SHA-256 實現效率比Plonky 2 的高得多。
正文
正文
正文
證明生成時間
[圖1 ] 使用Linux 服務器測試了SHA-256 的每個框架在各種原圖像尺寸上的證明生成時間。我們可以得到以下發現：
對於SHA-256 ，Groth 16 框架（rapidsnark、gnark 和Arkworks）生成證明的速度比Plonk 框架（Halo 2 和Plonky 2 ）快。這是因為SHA-256 主要由位運算組成，其中線值為0 或1 。對於Groth 16 ，這減少了從橢圓曲線標量乘法到橢圓曲線點加法的大部分計算。但是，連線值並不直接用於Plonk 的計算，因此SHA-256 中的特殊連線結構不會減少Plonk 框架中所需的計算量。
在所有Groth 16 框架中，gnark 和rapidsnark 比Arkworks 和snarkjs 快5 到10 倍。這要歸功於它們利用多個內核並行化生成證明的卓越能力。 Gnark 比rapidsnark 快25% 。
對於Plonk 框架，當使用>= 4 KB 的較大原像尺寸時，Plonky 2 的SHA-256 比Halo 2 的慢50% 。這是因為Halo 2 的實現主要使用查找表來加速按位運算，導致行數比Plonky 2 少2 倍。但是，如果我們比較具有相同行數的Plonky 2 和Halo 2 （例如，Halo 2 中超過2 KB 的SHA-256 與Plonky 2 中超過4 KB 的SHA-256 ），Plonky 2 比Halo 2 快50% 。如果我們在Plonky 2 中使用查找表實現SHA-256 ，我們應該期望Plonky 2 比Halo 2 更快，儘管Plonky 2 的證明尺寸更大。
另一方面，當輸入原像尺寸較小（<= 512 字節）時，由於查找表的固定設置成本佔大部分約束，Halo 2 比Plonky 2 （和其他框架）慢。然而，隨著原像的增加，Halo 2 的性能變得更具競爭力，對於高達2 KB 的原像大小，其證明生成時間保持不變，如圖所示，其幾乎呈線性擴展。
正如預期的那樣，Starky 的證明生成時間比任何SNARK 框架都短得多( 5 倍-50 倍)，但這是以更大的證明大小為代價的。
另外需要注意的是，即使電路大小與原像大小成線性關係，由於O(nlogn) FFT，對於SNARKs 的證明生成也是呈超線性增長的（儘管由於對數刻度，這一現像在圖表上並不明顯）。
除了Starky 之外，所有SNARK 框架在原像尺寸變大時都會遇到內存不足(OOM) 錯誤或使用交換內存（導致證明時間變慢）現象。具體來說，Groth 16 框架（snarkjs、gnark、Arkworks）在原像尺寸>= 8 KB 時就開始使用交換內存，而gnark 在原像尺寸>= 64 KB 時出現內存不足。當原像尺寸>= 32 KB 時，Halo 2 遇到了內存限制。當原像尺寸>= 8 KB 時，Plonky 2 開始使用交換內存。
二級標題
二級標題
二級標題
內存使用峰值
二級標題
二級標題
CPU 利用率
二級標題
CPU 利用率
我們通過測量SHA-256 在4 KB 原像輸入的證明生成期間的平均CPU 利用率來評估每個證明系統的並行化程度。下表顯示了Linux Server（20 核）和Macbook M 1 Pro（10 核）上的平均CPU 利用率（括號中為每個內核的平均利用率) 。
大多數框架在Linux 服務器上的CPU 利用率是在Macbook Pro M 1 的2 倍，只有snarkjs 例外。
一級標題
一級標題
一級標題
結論及未來研究
這篇文章全面比較了SHA-256 在各種zk-SNARK 和zk-STARK 開發框架上的性能測試結果。通過比較，我們深入了解了每種框架的效率和實用性，以期可以幫助需要為SHA-256 操作生成簡潔證明的開發者。我們發現Groth 16 框架（例如rapidsnark、gnark）在生成證明方面比Plonk 框架（例如Halo 2、Plonky 2 ）更快。 Plonkish 算術化中的查找表在使用較大的原像尺寸時顯著減少了SHA-256 的約束和證明時間。此外，gnark 和rapidsnark 展示了利用多核以並行化運作的出色能力。另一方面，Starky 的證明生成時間要短得多，但代價是證明大小要大得多。在內存效率方面，rapidsnark 和Starky 優於其他框架。
