原文：《 IOSG Weekly Brief | 為什麼我們看好零知識證明硬件加速#150 》
作者：Bryan, IOSG Ventures
本文將主要討論ZKP作為擴容方案的發展現狀，從理論層面描述產生證明過程中主要需要優化的幾個維度，並引深到不同擴容方案對於加速的需求。然後再圍繞硬件方案著重展開，展望zk硬件加速領域的摩爾定律。最後，關於硬件zk加速領域的一些機會和現狀，會在文末闡述。首先，影響證明速度的主要有三個維度：證明系統，待證明電路規模，和算法軟硬件優化。 （推薦閱讀：《 算力硬件的下一個藍海：ZK證明計算》）
對於證明系統來說，凡是使用橢圓曲線（EC）的算法，也就是市面上主流的Groth 16（Zcash), Galo2(Scroll), Plonk(Aztec, Zksync)這些zk-snark算法，產生多項式承諾的過程中涉及的大數點乘（MSM），目前都有時間長（算力要求高）的瓶頸。對於FRI-based算法，如ZK-Stark，其多項式承諾產生方式是Hash Function，不牽扯EC，所以並不涉及MSM運算。
證明系統是基礎，待證明電路的規模也是核心的硬件優化的需求之一。近期討論很火的ZKEVM據對以太坊的兼容程度不同，導致了電路的複雜程度的不同，比如Zksync/Starkware構建了與原生以太坊不同的虛擬機，從而繞開了一些以太坊原生的不適合利用zk處理的底層代碼，縮小了電路的複雜長度，而Scroll/Hermez這樣目標從最底端兼容的zkevm的電路自然也會更複雜。 （一個方便理解的比方是，電路的複雜性可以理解為一輛巴士上的座位，比如普通日子下需要搭載的乘客數在30人以下，有些巴士選擇了30人的座位，這些巴士就是Zksync/ StarkWare，而一年中也有一些日子有特別多的乘客，一般的巴士坐不下，所以有一些巴士設計的座位更多（Scroll）。但是這些日子可能比較少，會導致平時會有很多空餘的座位。）硬件加速對於這些電路設計更複雜的電路更迫切，不過這更多是一個Specturm的事情，對於ZKEVM也同樣有利無弊。
不同證明系統優化的需求/側重點:
基本：
當一個待證明事物經過電路（如R1CS/QAP）處理之後，會得到一組標量和向量，之後被用來產生多項式或者其他形式的代數形式如inner product argument (groth16)。這個多項式依然很冗長，如果直接生成證明那麼無論是證明大小或是驗證時常都很大。所以我們需要將這個多項式進一步簡化。這裡的優化方式叫做多項式承諾，可以理解為多項式的一種特殊的哈希值。以代數為基礎的多項式承諾有KZG, IPA，DARK，這些都是利用橢圓曲線產生承諾。
FRI是以Hash Function為產生承諾的主要途徑。多項式承諾的選擇主要是圍繞幾點- 安全性，Performance。安全性在這裡主要是考慮到在set up階段。如果產生secret所使用的randomness是公開的，比如FRI，那麼我們就說這個set up是透明的。如果產生secret所利用的randomness是私密的，需要Prover在使用之後就銷毀，那麼這個set up是需要被信任的。 MPC是一種解決這裡需要信任的手段，但是實際應用中發現這個是需要用戶來承擔一定的成本。
而上述提到的在安全性方面相對卓越的FRI在Performance並不理想，同時，雖然Pairing-friendly橢圓曲線的Performance比較卓越，但是當考慮將recursion加入時，因適合的曲線並不多，所以也是相當大的存在相當大的overhead。
圖片來源：https://hackernoon.com
Justin Drake on Polynomial commitment, Part 1
行業現狀：
當前不管是的基於Plonk(matterlabs) 或者基於Ultra-Plonk(Scroll, PSE)，他們最後的多項式commitment都是基於KZG，故而Prover的大部分工作都會涉及到大量的FFT計算(產生多項式）和ECC 點乘MSM運算（產生多項式承諾）。在純plonk模式下，由於需要commit的point數量不大，MSM運算所佔的Prove時間比重不高，所以優化FFT性能能夠短期帶來更大的性能提升。但是在UltraPlonk（halo2）框架下，由於引入了customer gate，prover階段設計的commit的point數量變多，使得MSM運算的性能優化也變得非常重要。 （目前MSM運算進行pippenger優化之後，依然需要log(P(logB)) (B 是exp的上界，p是參與MSM的point的數量)。
目前新一代Plonky2證明系統由於所採用的多項式commitment不再是KZG而是STARK系統中常見的FRI，使得Plonky2的prover不需要再考慮MSM，從而理論上該系統的性能提升不再依賴MSM相關的算法優化。 plonky2的作者Mir(目前的Polygon Zero)正在大力推廣該系統。不過由於plonky2採用的數域Goldilocks Field對於編寫elliptic 相關的hash算法相關的電路（例如ECDSA）不是特別友好，所以儘管Goldilocks Field在機器word運算方面優勢明顯，但是依然難以判斷Mir 和PSE/Scroll方案誰是更好的方案。
基於對Plonk,Ultraplonk, Plonky2的Prove算法的綜合考量，需要硬件加速的模塊大概率還是會集中在FFT，MSM，HASH 三個方向。
Prover的另一個瓶頸是witness的生成，通常普通非zk計算會略去大量的中間變量，但是在ZK prove的過程中，所有witness都需要被記錄，並且會參與之後的FFT計算，所以如何高效的並行witness計算也會是prover礦機需要潛在考慮的方向。
加速ZKP方面的嘗試: recursive proof - StarkNet的fractal L3概念基於recursive proof的概念，Zksync的fractal hyperscaling，Scroll也有類似的優化。
> Recursive zkSNARK 概念是對一個Proof A 的驗證過程進行證明，從而產生另一個Proof B。只要Verifier 能接受B，那麼相當於也接受了A。遞歸SNARK 可以也可以把多個證明聚合在一起，比如把A1 A2 A3 A4 的驗證過程聚合為B；遞歸SNARK也可以把一段很長的計算過程拆解為若干步，每一步的計算證明S1 都要在下一步的計算證明中得到驗證，即計算一步，驗證一步，再計算下一步，這樣會讓Verifier 只需要驗證最後一步即可，並避免構造一個不定長的大電路的難度。
理論上zkSNARK 都支持遞歸，有些zkSNARK 方案可以直接將Verifier 用電路實現，另一些zkSNARK 需要把Verifier 算法拆分成易於電路化的部分和不易電路化的部分，後者採用滯後聚合驗證的策略，把驗證過程放到最後一步的驗證過程中。
在L2的未來應用上，遞歸的優勢可以通過對於帶證明事物的歸納而進一步將成本與性能等要求進一步降低。
第一種情況(application-agnostic)是針對不同的待證明的事物，比如一個是state update另一個是Merkle Tree，這兩個待證明事物的proof可以合併成一個proof但是依舊存在兩個輸出結果（用來分別驗證的public key)
第二種情況(applicative recursion) 是針對同類的待證明的事物，比如兩個都是state update, 那麼這兩個事物可以在生成proof前進行聚合，且僅有一個輸出結果，該結果就是經歷了兩次update的state difference。 （Zksync的方法也類似，user cost僅對state difference負責）
除了recursive proof以及下文主要討論的硬件加速之外，還有其他的加速ZKP的方式，比如custom gates, 移除FFT（OlaVM的理論基礎）等，但本文因篇幅原因不予討論。
硬件加速
硬件加速在密碼學中一直是一種普遍的加速密碼學證明的方式，無論是對於RSA（RSA的底層數學邏輯與橢圓曲線有類似之處，同樣涉及了很多複雜的大數運算），還是早期對於zcash/filecoin的zk-snark的GPU-based的優化方式。
硬件選擇
在以太坊The Merge發生之後，不可避免將會有大量的GPU算力冗餘（部分受到以太坊共識改變的影響，GPU巨頭英偉達股價距年初已經跌去50%，同時庫存冗餘也在不斷增加），下圖是英偉達GPU旗艦產品RTX 3090的成交價格，也顯示買方勢力較為薄弱。
在GPU價格處於低點，同時大量GPU算力閒置，一個自然的問題就是，是否GPU是合適的加速zk的硬件呢？硬件端主要有三個選擇，GPU/FPGA/ASIC.
FPGA vs GPU:
先看總結：以下是trapdoor-tech關於GPU（以Nvidia 3090為例）以及FPGA（Xilinx VU9P為例）在幾個維度的總結，非常重要的一點是：GPU在性能（生成證明的速度）方面要高於FPGA, 而FPGA在能源消耗則更具有優勢。
一個更直觀的來自於Ingoyama的具體的運行結果：
尤其是對於比特寬度更高（2^20）的運算，GPU是FPGA運算速度的五倍，而消耗的電量同時也高很多。
對於普通礦工來說，性價比也是一個衡量到底使用哪一個硬件的重要的因素。無論是U55C ($4795) 還是VU9P ($8394) 來說，相比於GPU (RTX 3090：$1860)，價格都要高出很多。
理論層面，GPU適合併行運算，FPGA追求可編程性，而在零知識證明生成的環境下，這些優勢並不能完美適用。比如，GPU適用的並行計算是針對大規模圖形處理，雖然邏輯上和MSM的處理方式類似，但是適用的範圍（floating number）與zkp針對的特定的有限域並不一致。對於FPGA來說，可編程性在多個L2的存在的應用場景並不明朗，因為考慮到L2的礦工獎勵與單個L2承接的需求掛鉤（與pow不一樣），有可能在細分賽道出現winner takes all的局面，導致礦工需要頻繁更換算法的情景出現的可能性不高。
ASIC是在性能與成本方面上權衡表現較優的方案（包括吞吐量、延遲等），但是否是最好的方案仍然沒有定論，其存在的問題是：
開發時間長- 需經歷完整的芯片設計到芯片生產的過程，即使目前已經設計好了芯片，芯片生產也是一個冗長、燒錢並且良片率不一的過程。代工資源方面，台積電和三星是最好的芯片代工工廠，目前台積電的訂單已經排到了兩年後，與ZK芯片競爭代工資源的是AI芯片、電動車芯片這類web2早早做好芯片設計的已經被需求證明的產品，相比之下ZK芯片的需求並不明朗。
其次，整顆芯片的性能和單個芯片的大小，也就是人們常說的20nm,18nm是成負相關的，也就是說單個芯片越小，晶片可以容納的芯片的數量越多，即整顆的性能越高，而目前的製造高端芯片的的技術是被壟斷的（比如芯片製造中最複雜的一環，光刻技術，是被荷蘭的ASML公司壟斷），對於一些中小型的代工廠（如國內的中芯國際）這類技術方面落後頂尖一到兩代，也就意味著從良品率以及芯片大小方面是落後於最好的代工廠的。這會導致對於ZK芯片來說，只能尋求一些次優的解決方案，當然也是在需求端不那麼明朗的情況下基於成本的考慮，選擇28nm左右的非高端芯片。
目前的ASIC解決方案主要處理的是FFT以及MSM兩個常見的ZK電路中算力需求比較高的算子，並不是針對具體的一個項目設計的，所以具體運行的效率並不是理論上最高的。比如，目前Scroll的prover的邏輯電路還沒百分百實現，自然也不存在與之一一匹配的硬件電路。並且，ASIC是application-specific，並不支持後續的調整，當邏輯電路發生了變化，比如節點的客戶端需要升級，是否存在一個方案也可以兼容，也是目前不確定的。
同時，人才缺失也是ZK芯片的一個行業現狀，理解密碼學和硬件的人才並不好找，合適的人選是有同時具備較深的數學造詣以及多年的硬件產品設計以及維護經驗。
Closing thoughts - prover發展趨勢EigenDA
以上都是行業對於加速ZKP的思考與嘗試，最終意義就是運行prover的門檻會越來越低。週期性來講prover需要經歷大致的如下三個階段：
Phase I: Cloud-based prover
基於雲的prover可以大大提高第三方prover（非用戶/項目方）的准入門門檻，類似於web2的aws/google cloud。商業模式上來講，項目方會流失一部分獎勵，但是從去中心化的敘事講這是一種經濟以及執行層面吸引更多參與者的方式。而云計算/雲服務是web2現有的技術棧，已有成熟的開發環境可供開發者使用，並且可以發揮雲所特有的低門檻/高集群效應，對於短期內的proof outsource是一種選擇。目前，Ingoyama也有在這一方面的實現（最新的F1版甚至達到了pipeMSM的基準速度的兩倍）。但是，這依然是一個單個prover運行整個proof的方式，而在phase II中proof可以是一種可拆分的形式存在，參與者數量會更多。
Phase II: Prover marketplace
proof生成的過程中包含不同的運算，有的運算對於效率有偏好，有的運算則對成本/能源消耗有要求。比如MSM計算涉及pre-computation，這需要一定的memory支持不同的pre-computation上的標量顆粒，而如果所有的標量都存在一個計算機上的話對於該計算機的memory要求較高，而如果將不同的標量存儲在多個服務器上，那麼不僅該類的計算的速度會提高，並且參與者的數量也會增加。
Marketplace是一種針對上述外包計算的一種商業模式上的大膽的思考。但其實在Crypto圈子裡也有先例- Chainlink的預言機服務，不同鏈上的不同交易對的價格餵送也是以一種marketplace的形式存在。同時，Aleo的創始人Howard Wu曾經合作撰寫過一篇DIZK，是一個分佈式賬本的零知識證明生成方法論，理論上是可行的。
話說回來，商業模式上講這是一種非常有意思的思考，但是可能在實際落地時一些執行上的困難也是巨大的，比如這類運算之間如何協調生成完整的proof，至少需要在時間以及成本上不落後於Phase I。
Phase III: Everyone runs prover
未來Prover會運行在用戶本地（網頁端或者移動端），如Zprize有基於webassembly/andriod執行環境的ZKP加速相關的競賽和獎勵，意味著一定層面上用戶的隱私會得到確保（目前的中心化prover只是為了擴容，並不保證用戶隱私），最重要的上- 這裡的隱私不僅局限於鏈上行為，也包括鏈下行為。
一個必須要考慮的問題是關於網頁端的安全性，網頁端的執行環境相比硬件來說對於安全性的先決條件更高（一個industry witness是metmask這樣的網頁端錢包相比於硬件錢包，安全性更低）。
除了鏈上數據鏈下證明外，以ZKP的形式將鏈下數據上傳到鏈上，同時百分百保護用戶隱私，也只有在這個Phase可能成立。目前的解決方案都難免面臨兩個問題- 1. 中心化，也就是說用戶的信息依然有被審查的風險2. 可驗證的數據形式單一。因為鏈下數據形式多樣且不規範化，可驗證的數據形式需要經過大量的清洗/篩查，同時依舊形式單一。這裡的挑戰甚至不只是證明生成的環境，對於算法層面是否有能夠兼容（首先必須使用transparent的算法），以及成本/時間/效率都是需要思考的。但是同樣需求也是無與倫比的，想像可以以去中心化的方式抵押現實生活的信用在鏈上進行借貸，並且不會有被審查的風險。
