原文：A 開發工程師’s指南to the zkGalaxy
去年夏天，Vitalik 寫了一篇博文，概述了不同類型的zkEVM（零知識以太坊虛擬機）。 Vitalik 根據性能和兼容性來定義與權衡。
這是一個非常有用的啟發式方法，以區分支持 zkEVM 的方法。然而，zkEVM 是構建零知識應用程序的所有可能方法的一個子集。對於想要利用 zk 計算的獨特屬性，即簡潔性、零知識和正確性的程序員來說，zkEVM 可能不是最好的選擇。通過闡述整個開發工具集，本文希望提供一個指南，幫助開發者在決策過程中選擇合適的 zk 堆棧。
抽象複雜度的力量
在過去的一兩年中，zk 工具有了巨大的進步。使得普通軟件的開發人員可以利用 zk 的強大屬性，而不需要深入了解令人生畏的基礎數學和工程。另一方面，為高級用戶提供的工具大幅上漲，使zk 專家能夠極其精細地控制zk 堆棧。
現代軟件是建立在無數的抽象層上的，以最大限度地提高專家的生產力。工程中的抽像有許多優勢，這些優勢在某種程度上是直觀的–網絡開發者不需要深入了解操作系統的工作原理。
建立良好的、可重複使用的抽象層的關鍵是封裝一個層的複雜性，然後為堆棧中更高的層提供簡單但有表現力的接口。正確的做法是，這使得具有不同專業領域和知識的開發人員能夠在整個堆棧中建立有用的工具。
毫不奇怪，這些原則也適用於 zk 系統，而且這些抽象層正變得足夠成熟，一個 zk 新手今天就可以開始使用它們並構建應用程序。
zk 堆棧與各層的一些工具/技術實例
低級別的 zk 開發
Arkworks-rs
Arkworks-rs 是一個 Rust 庫的生態系統，它為 zkSNARK 應用程序的子組件提供高效和安全的實現。 Arkworks 為開發者提供了必要的接口，以定制 zk 應用程序的軟件棧，而不必重新實現與其他現有庫的共性。
在 Arkworks 之前，創建一個新的 zk 應用程序的唯一方法是從頭開始構建一切。與定制的垂直整合工具相比，Arkworks-rs 的主要優勢在於其靈活性水平，減少重複工程，以及減少審計工作。 Arkworks 組件之間合理的接口線允許升級的速度，可以使堆棧在 zk 技術快速創新的過程中保持相關性，而不會迫使團隊從頭開始重建一切。
優點
通過模塊化實現靈活性
減少重複代碼
降低工程成本
減少審計/bug 的表面積
無需重大重構即可升級任何組件
易於在快速發展的zk 環境中試驗新原語
缺點
需要深入了解完整的軟件堆棧
如果沒有正確理解，太多的控制會導致腳槍
精細控制需要堆棧所有級別的專業知識。
Arkworks 確實提供了一些合理的默認設置。
zk 領域專用語言(DSL)
為了創建一個關於某些計算的證明，首先這個計算必須以一個 zkSNARK 系統可以理解的形式來表達。一些特定領域的語言已經創建了編程語言，允許應用開發者以這種方式表達他們的計算。這些語言包括 Aztec Noir、Starknet 的 Cairo、Circom、ZoKrates 和 Aleo 的 Leo 等等。底層的證明系統和數學細節一般不會暴露給應用開發者。
開發者的經驗
zkApp 的開發者必須熟練地用特定領域的語言編寫程序。其中一些語言看起來很像我們熟悉的編程語言，而其他語言可能相當難學。讓我們來分析一下其中的幾個。
Cairo – Starkware DSL 對於在 Starknet 上構建應用程序是必要的。編譯成 Cairo 特有的彙編語言，可由 Cairo zkVM 解釋。
ZoKrates – ZoKrates 是一個滿足 SNARK 常見需求的工具包，包括一種編寫電路的高級語言。 ZoKrates 在曲線、證明方案和後端方面也有一些靈活性，允許開發者通過簡單的 CLI 參數進行熱交易所。
Circom — Circom 是一種用於構建電路的專用語言。目前，它是生產電路的實際語言。該語言不是特別符合人體工程學，使開發者敏銳地意識到正在編寫電路。
Leo——Leo 被開發為Aleo區塊鏈的語言。 Leo 有一些類似Rust 的語法，專門用於區塊鏈內部的狀態轉換。
Noir – 受Rust 啟發的語法。圍繞IR 而不是語言本身構建，這意味著它可以有一個任意的前端。
適用於誰
任何想要在其應用程序中利用 zk 的獨特屬性的應用程序開發人員。
其中一些語言已經過數十億美元的實戰測試，如在ZCash 和Starknet 等鏈的流動。雖然我們將討論的一些項目還沒有完全準備好用於生產，但使用其中一種語言編寫電路是目前最好的策略，除非需要像Arkworks 這樣的工具包提供的更精細的控制。
優點
用戶不需要了解底層的 zk 細節
有一定的生產經驗，今天就可以使用
可在鏈上驗證
生態系統不可知
缺點
用戶需要學習一個新的 DSL
圍繞這些語言的工具和支持都是孤立的
對底層證明堆棧幾乎沒有控制權（目前）。
zkEVMs
zkEVM 的主要目標是採取 Ethereum 狀態轉換，並使用簡潔的零知識正確性證明來證明其有效性。正如 Vitalik 的帖子中提到的，有許多方法可以做到這一點，並有微妙的差異和相應的權衡。
所有這些方法之間的主要技術區別在於，在語言棧中，計算究竟在哪裡被轉換為可以在證明系統中使用的形式（算術化）。在一些 zkEVM 中，這發生在高級語言中（Solidity、Vyper、Yul），而其他方法則試圖將 EVM 一直證明到操作碼級別。這些方法之間的權衡在 Vitalik 的帖子裡有深刻的論述，但我將用一句話來概括它。在堆棧中發生的轉換/算術化越低，性能損失就越大。
高操作成本
為虛擬機創建證明的主要挑戰是，電路的大小與每條執行指令的所有可能指令的大小成比例地增長。這是因為電路不知道在每個程序中會執行哪些指令，所以它需要支持所有的指令。
在通用電路中，每條執行的指令的成本與所有支持的指令之和成正比。
這在實踐中意味著，你要為最昂貴的指令支付（性能成本），即使你只是在執行最簡單的指令。這導致了通用性和性能之間的直接權衡–當你為通用性增加更多的指令時，你要為你證明的每一條指令付出代價這就是通用電路的根本問題。
但隨著 IVC（增量可驗證計算）等技術的新發展，這種限制可以通過將計算分成更小的塊來改善，每個塊都有專門的、更小的子電路。
今天的zkEVM 實現使用不同的策略來減輕這個問題的影響……例如，zkSync 去掉了更昂貴的操作（主要是加密的預編譯，如哈希值，以及其他一些操作）
zkEVM 的理想客戶是那些需要比L1以太坊上的交易便宜幾個數量級的智能合約應用。這些開發人員不一定有專業知識或帶寬來從頭開始編寫 zk 應用程序。因此，更喜歡用熟悉的更高級的語言來寫應用程序，如 Solidity。
眾多開發團隊
擴展 Ethereum 是目前 zk 技術最需要的應用。
zkEVM 是一個以太坊擴展解決方案，可以無摩擦地緩解限制L1 dApp 開發者的擁堵問題。
開發者體驗
zkEVM 的目標是支持一個盡可能接近當前以太坊開發的開發者體驗。完全支持 Solidity 意味著團隊不必建立和維護多個代碼庫。這在某種程度上是不切實際的，因為 zkEVM 需要交易所一些兼容性，以便能夠在合理的時間內生成合理規模的證明。
zkSync 與Scroll
zkSync 和Scroll 之間的主要區別在於它們在堆棧中的何處/何時執行算術運算——也就是說，它們從普通EVM 構造轉換為SNARK 友好表示的位置。對於zkSync，當他們將YUL 字節碼轉換為他們自己的自定義zk 指令集時，就會發生這種情況。對於 Scroll 來說，這發生在最後，當實際的執行跟踪用實際的 EVM 操作碼生成時。
因此，對於zkSync，在生成zk 字節碼之前，一切都與與EVM 交互相同。對於Scroll，在執行實際的字節碼之前，一切都是一樣的。這是一個微妙的差異，它以性能換取支持。例如，zkSync 不會像開箱即用的調試器那樣支持EVM 字節碼工具，因為它是完全不同的字節碼。雖然Scroll 很難從指令中心化獲得良好的性能，但這並不是為zk 設計的。這兩種策略各有利弊，最終有很多外生因素會影響它們的相對成功。
zkLLVM 電路編譯器
正如詳細討論的那樣，開發zk 應用程序有無數不同的選擇，所有這些都有自己獨特的權衡。此K線走勢圖將幫助總結此決策矩陣，以便根據你的zk 專業知識水平和性能需求，選擇最適合該工作的工具。這不是一個完整的列表，會隨著 zk 的發展更新。
zkLLVM 被設計為現有LLVM 基礎設施的擴展，LLVM 基礎設施是一個行業標準工具鏈，支持許多高級語言，如Rust、C、C++ 等。
怎麼運行
想要證明某些計算的用戶只需用C++ 實現該計算即可。 zkLLVM 採用其修改後的clang 編譯器（當前為C++）支持的高級源代碼，並生成電路的一些中間表示。此時，電路已準備好進行驗證，但用戶可能希望根據一些動態輸入來驗證電路。為了處理動態輸入，zkLLVM 有一個稱為分配器的附加組件，它生成一個分配表，其中包含所有輸入和見證，這些輸入和見證已完全預處理並準備好與電路一起進行證明。
這兩個組件是生成證明所必需的。理論上，用戶可以自己生成證明，但由於這是一項有點專業化的計算任務，可能需要花錢請擁有硬件的其他人做這件事。對於這種交易對手發現機制，=nil；Foundation 還建立了一個“證明市場”，證明者競相為支付給他們的用戶證明計算。這種自由市場動態將導致證明者優化最有價值的證明任務。
權衡利弊
由於每個要證明的計算任務都是獨一無二的，並且會生成不同的電路，因此證明者需要能夠處理的電路數量是無限的。這種強制的通用性使得單個電路的優化變得困難。證明市場的引入允許對市場認為有價值的電路進行專業化。如果沒有這個市場，由於這種自然的冷啟動問題，說服驗證者優化該電路將是一項挑戰。
另一個權衡是經典的抽象與控制。願意採用這種易於使用的界面的用戶正在放棄對底層加密貨幣原語的控制。對於許多用戶來說，這是一個非常有效的權衡，因為讓密碼學專家為你做出這些決定通常更好。
優點
用戶可以用熟悉的高級語言編寫代碼
所有的 zk 內部結構都被抽像出來，不受用戶影響
不依賴增加額外開銷的特定“虛擬機“電路。
缺點
每個程序都有一個不同的電路。難以優化。 (證明市場部分解決了這個問題)
交易所/升級內部 zk 庫並非易事（需要分叉）
zkVM
zkVM 描述了所有zk 虛擬機的超集，而zkEVM 是一種特定類型的zkVM，由於其在當今的流行，值得作為一個單獨的主題進行討論。除了定制的加密貨幣VM 之外，還有一些其他項目正在致力於構建基於ISA 的更通用的zkVM。
系統可以證明不同的指令集架構(ISA)，例如新VM 中的RISC-V 或WASM，而不是證明EVM。致力於這些通用zkVM 的兩個項目是RISC Zero 和zkWASM。
讓我們在這裡深入了解一下 RISC Zero，以證明這種策略是如何工作的，以及它的一些優勢/劣勢。
Risc Zero
Risc Zero 證明生成的高級架構
RISC Zero 能夠證明任何在 RISC-V 架構上執行的計算。 RISC-V 是一個開源的指令集架構（ISA）標準，已經越來越受歡迎。 RISC（精簡指令集計算機）的理念是以最小的複雜性建立一個極其簡單的指令集。這意味著堆棧中較高層次的開發者在使用這種架構實現指令時最終會承擔更大的負荷，同時使硬件實現更加簡單。
這種理念也適用於一般的計算，ARM 芯片一直在利用 RISC 風格的指令集，並開始主導移動芯片的市場。事實證明，更簡單的指令集也具有更大的能量和芯片面積效率。
這個類比對於生成 zk 證明的效率來說相當適用。正如前面所討論的，在證明 zk 的執行軌跡時，你要為軌跡中每一項的所有指令的成本之和買單，所以更簡單、更少的總指令是更好的。
如何工作
從開發者的角度來看，使用 RISC Zero 來處理 zk 證明，很像使用 AWS Lambda函數來處理後端服務器架構。開發人員通過簡單地編寫代碼與 RISC Zero 或 AWS Lambda 互動，服務處理所有後端複雜性。
對於 RISC Zero，開發者編寫 Rust 或 C++（最終是任何針對 RISC-V 的東西）。然後，系統接受編譯過程中產生的 ELF 文件，並將其作為虛擬機電路的輸入代碼。開發者只需調用證明，返回一個收據（包含執行跟踪的 zk 證明）對象，任何人都可以從任何地方調用`驗證’。從開發者的角度來看，沒有必要了解 zk 是如何工作的，底層系統處理所有這些複雜的問題。
為了支持這樣一個通用接口，需要大量的開銷（在證明大小和生成速度方面）。
需要對證明生成技術進行重大改進，以實現對現有庫的廣泛支持
預建的可重複使用電路
對於一些對區塊鏈應用或其他地方特別有用的基本和可重複使用的電路，團隊可能已經為你構建和優化了這些電路。你只需為你的特定用例提供輸入即可。例如，Merkle 包容證明是加密貨幣應用中普遍需要的東西（空投清單、龍成交量風現金等）。作為一個應用程序的開發者，你總是可以重新使用這些經過實戰檢驗的合約，只是在上面修改一些層，以創建一個獨特的應用程序。
例如，Tornado Cash 的電路可以重新用於私人空投應用程序或私人投票應用程序。 Manta 和Semaphore 正在構建一個完整的工具包，包括像這樣的通用電路小工具，可以在Solidity 合約中使用，而無需了解或不了解底層的zk moon 數學。
正如詳細討論的那樣，開發zk 應用程序有無數不同的選擇，所有這些都有自己獨特的權衡。
此K線走勢圖將幫助總結此決策矩陣，以便根據你的zk 專業知識水平和性能需求，選擇最適合該工作的工具。這不是一個完整的列表，會隨著 zk 的發展更新。
zkGalaxy 應用開發者指南
1. 低級Snark 庫
適用場景
需要對整個證明堆棧進行精細控制
避免重建公共組件
嘗試證明方案、曲線和其他低級原語的不同組合
不適用場景
尋找高級證明接口的新手
可選用工具
Arkworks-rs
2. zk DSLs
適用場景
想使用一些久經考驗的語言
需要最小的電路尺寸，願意放棄抽象
不適用場景
需要對證明的後端進行精細控制（目前，可以為一些 DSL 交易所後端）
可選用工具
Circom
Aztec Noir
Cairo
ZoKrates
Leo
3. zk 編譯器
適用場景
不願意承擔通用電路的開銷
想用熟悉的語言編寫電路
需要高度定制的電路
不適用場景
想要控制底層加密貨幣原語
需要一個已經高度優化的電路
可選用工具
nil zkLLVM
4.zkEVM
適用場景
有一個已經在EVM 上運行的dApp
需要為用戶提供更便宜的交易
希望將部署到新鏈的工作量降到最低
只關心 zk（壓縮）的簡潔性
不適用場景
需要完美的EVM 等效性
需要zk 的隱私屬性
有一個非區塊鏈用例
可選用工具
zksync 2.0
Polygon zkEVM
Scroll
Starknet
5.zkVM
適用場景
想用高級語言編寫代碼
需要證明該執行的正確性
需要向驗證者隱藏該執行的一些輸入信息
幾乎沒有 zk 方面的專業知識
不適用場景
在延遲極低的環境中（它仍然很慢）。
有一個巨大的程序（目前）。
可選用工具
RISC Zero
zkWASM
6. 預建的可重複使用的電路
適用場景
有一個依賴常見的 zk 構建模塊的智能合約應用，比如 Merkle 包容。
對 zk 底層的東西幾乎沒有專業知識
不適用場景
有高度專業化的需求
用例不被預建電路所支持
可選用工具
Manta Network
Semaphore
結論
zk 處於多項技術的前沿，構建它需要對數學、密碼學、計算機科學和硬件工程有深刻的理解。然而，隨著每天都有越來越多的抽象層可用，應用程序開發人員無需博士學位即可利用zk 的強大功能。隨著時間的推移，通過對堆棧的所有級別進行優化，證明時間的限制會逐漸解除，我們可能會看到針對普通開發人員的更簡單的工具。
致謝
本文編譯工作獲得 DAOrayaki 社區的支持與反饋。
資訊來源：由0x資訊編譯自8BTC。版權歸作者所有，未經許可，不得轉載