作者：Justin Thaler，a16z研究合夥人；翻譯：金色財經xiaozou
自從去年夏天的主題論文和Lasso部署開始，到上個月的完全開源的Jolt實現的發布，我們一直都在致力於Lasso+Jolt（我們的全新簡便的高性能lookup argument和zkVM）技術的研究並取得穩步進展。
與現有技術相比，這項實現顯示了Jolt的光明前景，並對SNARK設計中的許多傳統智慧發起挑戰。自發布以來，我們陸續進行更新，增加了對Rust標準庫的支持，整合了來自10多名貢獻者的改進，合併了近50個pull請求，並且改進了代碼庫的模組化性能和可擴展性。
在我們繼續增強Jolt的同時，我想回應外界的質疑和困惑，澄清誤解，分享我對一些關鍵問題的看法。我在本文要探討的四部分內容是：（1）sum-check協議與Binius承諾方案之間的關係，（2）sum-check和lookups在Jolt中的作用，（3）橢圓曲線與哈希， （4）與zkVM相關的預編譯。
1、Sum-check協議與Binius承諾方案
Commitment schemes通常被視為SNARK的關鍵組成部分。但還要注意另一個組件的作用也很重要，那就是多項式IOP。例如，多線性多項式的Binius承諾方案是一個重大進步，但它必須與多項式互動式oracle證明（polynomial interactive oracle proof，PIOP）配對，才能證明所提交的數據實際上驗證了證明者的聲明。
Binius的承諾與使用sum-check協議的PIOP高度相容。原因很清楚（sum-check依賴多線性多項式，而不是單變量多項式；FRI-Binius甚至在內部使用sum-check），也很微妙（sum-check PIOP天然地跨任何特徵字段運行，這對於充分利用Binius的新性能至關重要）。 Binius的承諾與目前最常見的PIOP不相容，很遺憾，這些PIOP不使用sum-check。
設計一個快速的PIOP需要更多的洞察力，而不僅僅是「應用sum-check」這句話而已。 Binius使用sum-check協定來實現高效率的多項式IOP。 Binius論文的第4和第5部分致力於設計新的高效的基於sum-check的PIOP，以與承諾方案相結合。
Binius承諾和Jolt的搭配就像花生醬和果醬一樣，因為Jolt是目前唯一一個完全基於sum-check協議的zkVM。如今，Jolt使用基於橢圓曲線加密的承諾方案，但將Binius承諾納入Jolt是我們工作的首要任務。
2、Sum-check、lookups、效能和簡潔性
是什麼讓Jolt與眾不同？是因為Jolt是第一個（也是目前唯一一個）專門使用基於sum-check的多項式IOP的zkVM，還是因為Jolt實現了lookup奇點（幾乎所有的事情都是透過lookups而非約束（constraint）系統或電路來完成的）？答案是，兩者兼具。與先前的zkVM相比，Jolt的大部分的簡潔性優勢都來自於lookups，而它的效能優勢來自於lookups和sum-check的使用。
單純的lookup方法對於某些指令（沒有非常小的電路的指令）更好些，但是對於具有非常小的電路的其他指令可能要更差。但總的來說，單純的lookup方法對效能來說只有好處沒有壞處，至少在處理256位元欄位時是如此。如今，Jolt prover投入20%的時間在「指令執行」lookup上，40%的時間用於驗證約束資訊。增加更多約束來減少lookups是沒有任何幫助的。
大概說來，Jolt使用lookups來實現CPU獲取-解碼-執行循環的「獲取」和「執行」部分。這些lookups速度足夠快，以至於prover的大部分時間都用於證明它運行了“解碼”，這是透過傳統的約束來處理的。
單純的lookup方法也會促進更簡潔、更可審計的實現。這些好處很難被量化，需要時間才能被看見和認可。但在程式碼行數（Jolt程式碼庫約2.5萬行程式碼，比之前的RISC-V zkVM少2到4倍）和開發時間等方面，Jolt表現出色。這樣的改進比效能上的改進難得多：雖然我預期zkVM prover在未來幾個月的速度將比2023年8月差不多快百倍，但很難想像zkVM的程式碼行數什麼時候能減少10倍。
3.橢圓曲線
公共話語低估了擁有針對橢圓曲線的快速zkVM的好處，部分原因是大家普遍對基於哈希的承諾方案（如Binius）熱情滿滿。
在證明關於橢圓曲線加密的聲明時，基於曲線的zkVM可以避開非原生字段演算法，而非原生字段演算法會增加數百上千倍的證明時間開銷。這些應用包括許多數位簽章（與區塊鏈輕客戶端和基於SNARK的橋接相關的主要工作）的證明，Plonk/Groth16/Nova/Honk證明的聚合，以及Verkle樹認證路徑的證明。
我樂觀地認為，社區將關注基於sum-check的PIOP與FRI-Binius承諾方案的結合，將其作為在許多應用程式中執行SNARK的正確方法。即使發生這種情況，基於曲線的快速SNARK仍然有用，除非這個世界完全棄用橢圓曲線加密（例如，在社會完成從非量子安全的加密系統轉移之後）。
小結：
-
基於曲線的承諾與目前的所有其他zkVM相競爭（所有現存其他zkVM都已經使用哈希承諾方案處理小字段）。
-
在證明關於橢圓曲線的聲明時（至少在證明非原生字段演算法沒有重大進展的情況下），人們會想要使用結合曲線的Jolt。
-
作為一個純zkVM，Jolt和Binius結合的承諾將比其他替代方案快很多，除非是證明關於曲線的聲明或小字段證明（在這種情況下，人們將使用結合曲線的Jolt），否則人們將使用Jolt和Binius結合的承諾方案。
-
在將證明發佈到鏈上之前，基於橢圓曲線的SNARK將繼續用於壓縮證明大小和驗證者成本。在這種情況下，處理大字段的zkVM將發揮作用。即使在今天，人們認為基於哈希的zkVM專案實際上是使用在BN254曲線上定義的zkVM作為遞歸過程的一部分。
4、 預編譯和zkVM基準
關於預編譯及其在zkVM和基準測試中的作用已存在一些討論。在我進行解釋之前，先來解釋一下什麼是預編譯應該會有所幫助，因為預編譯這個字的意思在不同的上下文中有所不同。
（1）以太坊中的“預編譯”
在以太坊虛擬機器（EVM）中，預編譯是一個經常執行的操作，並且受原生支援以提高效率。這就避免了透過冗長的EVM操作碼序列執行這些操作所帶來的大量開銷和過高的gas成本。
「EVM預編譯」和「初始指令」（操作碼）之間的區別主要是語義上的區別。例如，Keccak雜湊函數是EVM操作碼，而SHA-2則是EVM預編譯。預編譯和操作碼都是經常執行的操作，以太坊出於相同的目的對它們提供原生支援：優化效率和gas成本。不可否認，預編譯是EVM的一部分，EVM通常用於廣泛地描述以太坊執行環境，包含的不僅僅是操作碼。
如果EVM的功能與操作碼基本上相同，為什麼還要有預編譯呢？主要在於慣例問題。另一個可能的原因是，預編譯由相對複雜的操作組成，例如將來可能需要更改的加密原語，如果它們沒有分配操作碼，則將來更改起來會更容易一些。
（2）zkVM設計中的“預編譯”
在zkVM設計中，預編譯是指針對特定函數（如Keccak或SHA雜湊）或特定一組橢圓曲線操作的具有特殊用途的SNARK。如今的SNARK預編譯通常是透過手動優化的約束系統來實現的（儘管隨著社區轉向基於sum-check的SNARK，這些約束系統的性質以及它們被證明的方式將會改變）。
EVM預編譯器zkVM預編譯之間具有深度相似性。在Jolt發布之前，zkVM透過手動最佳化的約束系統實作初始指令，每個指令一個，就像它們實作預編譯一樣。所謂的zkVM預編譯和所謂的初始指令之間的區別純粹是語義上的。他們之間沒有實際的區別。
在Jolt中，我們使用lookups來實作初始指令，而不使用傳統的約束。但是選擇透過約束來實現一些初始指令並沒有什麼大問題。 （事實上，lookups甚至可以被視為一種約束。）實際上，正如我之前所說的，一旦我們轉向Binius承諾方案，我們可能不得不使用傳統的約束來實現RISC-V的加法和乘法。
5.zkVM基準測試
有了這些背景了解，下面我來談談我對預編譯的看法，因為它們與zkVM和基準測試有關。
首先，在沒有預先編譯的情況下對各種RISC-V zkVM進行基準測試正是對RISC-V zkVM進行基準測試的意義。 「zkVM」一詞是一個非正式的叫法，因此必然產生分歧，但在我看來，具有一個或多個預編譯的RISC-V zkVM不再是RISC-V的zkVM：它是基於RISC- V的新指令集的zkVM，將每個預編譯加入為初始指令。至少，加入zkVM的每個預編譯都會削弱zkVM範式的價值主張－每增加一個電路都會增加潛在的bug表面積，而現有程式將無法開箱即用地利用這些新的預編譯。
有些人也將zkEVM的EVM預編譯概念與zkVM的預編概念混為一談。但這是兩個截然不同的東西。雖然zkEVM的一些關鍵操作——例如Merkle雜湊和數位簽章驗證——確實比初始的RISC-V指令更複雜，但這並不能改變EVM預編譯和初始EVM指令之間沒有功能差異這樣一個事實。 zkEVM必須支援EVM預編譯，以聲明與EVM對等。換句話說，不支援EVM預編譯的zkEVM不同於像Jolt這樣的RISC-V zkVM，後者將使用預編譯擴展RISC-V以外的指令集。
另一個問題是如何選擇一組「公平」的函數來對zkVM進行基準測試。但是對於RISC-V zkVM來說，任何函數集都是公平的。 Prover時間幾乎完全取決於RISC-V CPU運行的週期數，原因有兩點。首先，prover在「獲取-解碼-執行」循環的「執行」部分花費了一小部分時間。其次，不同的RISC-V指令，以及記憶體訪問，證明時間都高度相似。 （在Jolt中，它們都是透過離線記憶體檢測技術來處理的。）
最後，如果使用預編譯，Jolt的表現可能不會比其他替代方案差。事實上，我預計它會表現得更好，因為基於sum-check的預編譯將是最快的，並且可以整合到Jolt中而沒有開銷，因為它專門使用了基於sum-check的PIOP。在這一點上，有些人擔心使用橢圓曲線承諾方案的預編譯將比使用基於哈希方案的預編譯差很多。如今，Jolt使用曲線，但這並不是必須的，我們一直對轉向Binius的計劃持開放態度。
6.關於基準的廣泛思考
我們進行基準測試的主要目標是確定不同證明系統的內在效能情況，在某種程度上，它們可以與它們的實現分開。這種方法使社區能夠理解並聚焦於設計高性能且安全的SNARK的正確技術。但是，當試圖比較兩個不同的SNARK時，數不盡的混淆因素往往導致不可能進行嚴絲合縫的對比。
工程方面的努力是這些混淆因素之中的一個，儘管社區中的許多人似乎持對立觀點。想法似乎是這樣的：如果一個項目添加了“特性”，例如針對特定硬體的預編譯或進行了優化，那麼它應該在任何基準測試中都擁有“榮譽”表現。
兩種觀點都有其可取之處。但長遠來看，後一種觀點顯然站不住腳。新方法在任何基準測試中都將永遠處於劣勢，因為那些新方法沒有與舊專案可比的時間。這樣的觀點是對進步的阻礙。
隨著時間的推移，我預期基準測試相關的混淆因素將會減少。隨著SNARK的開發工具的成熟，SNARK獲得良好的性能所需的工程方面的工作量將變少。 zkVM的成本主要取決於週期數，而不是任何特定應用程式的特性，這是一個小小的奇蹟（至少對於RISC-V）。如果人們關注約束系統的選擇（而不是今天的R1CS、AIR、Plonkish等碎片化狀態），針對約束系統的SNARK可能也會出現類似的情況，使用約束系統大小的簡單度量方法來代替週期數。
在此之前，很難在混雜因素控制不足和過度控制之間取得適當的平衡。分歧是不可避免的，而建造者將必須提供任何一個基準背後的全部背景、細節資訊和基本原理，以便社區能夠理解和探討。
