自去年夏天的主題論文和 Lasso 部署開始，到上個(gè)月的完全開源的 Jolt 實(shí)現(xiàn)的發(fā)布，我們一直都在致力于 Lasso+Jolt（我們的全新簡(jiǎn)便的高性能 lookup argument 和 zkVM）技術(shù)的研究并取得穩(wěn)步進(jìn)展。

與現(xiàn)有技術(shù)相比，這一實(shí)現(xiàn)顯示了 Jolt 的光明前景，并對(duì) SNARK 設(shè)計(jì)中的許多傳統(tǒng)智慧發(fā)起挑戰(zhàn)。自發(fā)布以來，我們陸續(xù)進(jìn)行更新，增加了對(duì) Rust 標(biāo)準(zhǔn)庫(kù)的支持，整合了來自 10 多名貢獻(xiàn)者的改進(jìn)，合并了近 50 個(gè) pull 請(qǐng)求，并且改進(jìn)了代碼庫(kù)的模塊化性能和可擴(kuò)展性。

在我們繼續(xù)增強(qiáng) Jolt 的同時(shí)，我想回應(yīng)外界的質(zhì)疑和困惑，澄清誤解，分享我對(duì)一些關(guān)鍵問題的看法。我在本文要探討的四部分內(nèi)容是：（1）sum-check 協(xié)議與 Binius 承諾方案之間的關(guān)系，（2）sum-check 和 lookups 在 Jolt 中的作用，（3）橢圓曲線與哈希，（4）與 zkVM 相關(guān)的預(yù)編譯。

1、Sum-check 協(xié)議與 Binius 承諾方案

Commitment schemes 通常被視為 SNARK 的關(guān)鍵組成部分。但還需注意另一個(gè)組件的作用也很重要，那就是多項(xiàng)式 IOP。例如，多線性多項(xiàng)式的 Binius 承諾方案是一個(gè)重大進(jìn)步，但它必須與多項(xiàng)式交互式 oracle 證明（polynomial interactive oracle proof，PIOP）配對(duì)，才能證明所提交的數(shù)據(jù)實(shí)際上驗(yàn)證了證明者的聲明。

Binius 的承諾與使用 sum-check 協(xié)議的 PIOP 高度兼容。原因很清楚（sum-check 依賴于多線性多項(xiàng)式，而不是單變量多項(xiàng)式；FRI-Binius 甚至在內(nèi)部使用 sum-check），也很微妙（sum-check PIOP 天然地跨任何特征字段運(yùn)行，這對(duì)于充分利用 Binius 的新性能至關(guān)重要）。Binius 的承諾與目前最常見的 PIOP 不兼容，很遺憾，這些 PIOP 不使用 sum-check。

設(shè)計(jì)一個(gè)快速的 PIOP 需要更多的洞察力，而不僅僅是「應(yīng)用 sum-check」這一句話而已。Binius 使用 sum-check 協(xié)議來實(shí)現(xiàn)高效的多項(xiàng)式 IOP。Binius 論文的第 4 和第 5 部分致力于設(shè)計(jì)新的高效的基于 sum-check 的 PIOP，以與承諾方案相結(jié)合。

Binius 承諾和 Jolt 的搭配就像花生醬和果醬一樣，因?yàn)?Jolt 是目前唯一一個(gè)完全基于 sum-check 協(xié)議的 zkVM。如今，Jolt 使用基于橢圓曲線加密的承諾方案，但將 Binius 承諾納入 Jolt 是我們工作的重中之重。

2、Sum-check、lookups、性能和簡(jiǎn)潔性

是什么讓 Jolt 與眾不同？是因?yàn)?Jolt 是第一個(gè)（也是目前唯一一個(gè)）專門使用基于 sum-check 的多項(xiàng)式 IOP 的 zkVM，還是因?yàn)?Jolt 實(shí)現(xiàn)了 lookup 奇點(diǎn)（幾乎所有的事情都是通過 lookups 而非約束（constraint）系統(tǒng)或電路來完成的）？答案是，兩者兼有。與之前的 zkVM 相比，Jolt 的大部分的簡(jiǎn)潔性優(yōu)勢(shì)都來自于 lookups，而它的性能優(yōu)勢(shì)來自于 lookups 和 sum-check 的使用。

單純的 lookup 方法對(duì)于某些指令（沒有非常小的電路的指令）更好些，但是對(duì)于具有非常小的電路的其他指令可能要更差。但總的來說，單純的 lookup 方法對(duì)性能來說只有好處沒有壞處，至少在處理 256 位字段時(shí)如此。如今，Jolt prover 投入 20% 的時(shí)間在「指令執(zhí)行」lookup 上，40% 的時(shí)間用于驗(yàn)證約束信息。添加更多約束來減少 lookups 是沒有任何幫助的。

大概說來，Jolt 使用 lookups 來實(shí)現(xiàn) CPU 獲取 – 解碼 – 執(zhí)行循環(huán)的「獲取」和「執(zhí)行」部分。這些 lookups 速度足夠快，以至于 prover 的大部分時(shí)間都用于證明它運(yùn)行了「解碼」，這是通過傳統(tǒng)的約束來處理的。

單純的 lookup 方法還會(huì)促進(jìn)更簡(jiǎn)潔、更可審計(jì)的實(shí)現(xiàn)。這些好處很難被量化，需要時(shí)間才能被看見和認(rèn)可。但在代碼行數(shù)（Jolt 代碼庫(kù)約為 2.5 萬(wàn)行代碼，比之前的 RISC-V zkVM 少 2 到 4 倍）和開發(fā)時(shí)間等方面，Jolt 表現(xiàn)出色。這樣的改進(jìn)要比性能上的改進(jìn)難得多：雖然我預(yù)計(jì) zkVM prover 在未來幾個(gè)月的速度將比 2023 年 8 月差不多快百倍，但很難想象 zkVM 的代碼行數(shù)什么時(shí)候能減少 10 倍。

3、橢圓曲線

公共話語(yǔ)低估了擁有針對(duì)橢圓曲線的快速 zkVM 的好處，部分原因是大家普遍對(duì)基于哈希的承諾方案（如 Binius）熱情滿滿。

在證明關(guān)于橢圓曲線加密的聲明時(shí)，基于曲線的 zkVM 可以避開非原生字段算法，而非原生字段算法會(huì)增加成百上千倍的證明時(shí)間開銷。這些應(yīng)用包括很多數(shù)字簽名（與區(qū)塊鏈輕客戶端和基于 SNARK 的橋接相關(guān)的主要工作）的證明，Plonk/Groth16/Nova/Honk 證明的聚合，以及 Verkle 樹認(rèn)證路徑的證明。

我樂觀地認(rèn)為，社區(qū)將關(guān)注基于 sum-check 的 PIOP 與 FRI-Binius 承諾方案的結(jié)合，將其作為在許多應(yīng)用程序中執(zhí)行 SNARK 的正確方法。即使發(fā)生這種情況，基于曲線的快速 SNARK 仍然有用，除非這個(gè)世界完全棄用橢圓曲線加密（例如，在社會(huì)完成從非量子安全的加密系統(tǒng)轉(zhuǎn)移之后）。

小結(jié)：

基于曲線的承諾與目前的所有其他 zkVM 相競(jìng)爭(zhēng)（所有現(xiàn)存其他 zkVM 都已經(jīng)使用哈希承諾方案處理小字段）。

在證明關(guān)于橢圓曲線的聲明時(shí)（至少在證明非原生字段算法沒有重大進(jìn)展的情況下），人們會(huì)想要使用結(jié)合曲線的 Jolt。

作為一個(gè)純 zkVM，Jolt 和 Binius 相結(jié)合的承諾將比其他替代方案快很多，除非是證明關(guān)于曲線的聲明或小字段證明（在這種情況下，人們將使用結(jié)合曲線的 Jolt），否則人們將使用 Jolt 和 Binius 相結(jié)合的承諾方案。

在將證明發(fā)布到鏈上之前，基于橢圓曲線的 SNARK 將繼續(xù)用于壓縮證明大小和驗(yàn)證者成本。在這種情況下，處理大字段的 zkVM 將發(fā)揮作用。即使在今天，人們認(rèn)為基于哈希的 zkVM 項(xiàng)目實(shí)際上是使用在 BN254 曲線上定義的 zkVM 作為遞歸過程的一部分。

4、?預(yù)編譯和 zkVM 基準(zhǔn)

關(guān)于預(yù)編譯及其在 zkVM 和基準(zhǔn)測(cè)試中的作用已存在一些討論。在我進(jìn)行解釋之前，先來解釋一下什么是預(yù)編譯應(yīng)該會(huì)有所幫助，因?yàn)轭A(yù)編譯這個(gè)詞的含義在不同的上下文中有所不同。

（1）以太坊中的「預(yù)編譯」

在以太坊虛擬機(jī)（EVM）中，預(yù)編譯是一個(gè)經(jīng)常執(zhí)行的操作，并且受原生支持以提高效率。這就避免了通過冗長(zhǎng)的 EVM 操作碼序列執(zhí)行這些操作所帶來的大量開銷和過高的 gas 成本。

「EVM 預(yù)編譯」和「初始指令」（操作碼）之間的區(qū)別主要是語(yǔ)義上的區(qū)別。例如，Keccak 哈希函數(shù)是一個(gè) EVM 操作碼，而 SHA-2 則是 EVM 預(yù)編譯。預(yù)編譯和操作碼都是經(jīng)常執(zhí)行的操作，以太坊出于相同的目的對(duì)它們提供原生支持：優(yōu)化效率和 gas 成本。不可否認(rèn)，預(yù)編譯是 EVM 的一部分，EVM 通常用于廣泛地描述以太坊執(zhí)行環(huán)境，包含的不僅僅是操作碼。

如果 EVM 的功能與操作碼基本相同，為什么還要有預(yù)編譯呢？主要在于慣例問題。另一個(gè)可能的原因是，預(yù)編譯由相對(duì)復(fù)雜的操作組成，比如將來可能需要更改的加密原語(yǔ)，如果它們沒有分配操作碼，則將來更改起來會(huì)更容易一些。

（2）zkVM 設(shè)計(jì)中的「預(yù)編譯」

在 zkVM 設(shè)計(jì)中，預(yù)編譯是指針對(duì)特定函數(shù)（如 Keccak 或 SHA 哈希）或特定一組橢圓曲線操作的具有特殊用途的 SNARK。如今的 SNARK 預(yù)編譯通常是通過手動(dòng)優(yōu)化的約束系統(tǒng)來實(shí)現(xiàn)的（盡管隨著社區(qū)轉(zhuǎn)向基于 sum-check 的 SNARK，這些約束系統(tǒng)的性質(zhì)以及它們被證明的方式將會(huì)改變）。

EVM 預(yù)編譯器 zkVM 預(yù)編譯之間具有深度相似性。在 Jolt 發(fā)布之前，zkVM 通過手動(dòng)優(yōu)化的約束系統(tǒng)實(shí)現(xiàn)初始指令，每個(gè)指令一個(gè)，就像它們實(shí)現(xiàn)預(yù)編譯一樣。所謂的 zkVM 預(yù)編譯和所謂的初始指令之間的區(qū)別純粹是語(yǔ)義上的。他們之間沒有實(shí)際的區(qū)別。

在 Jolt 中，我們使用 lookups 來實(shí)現(xiàn)初始指令，而不使用傳統(tǒng)的約束。但是選擇通過約束來實(shí)現(xiàn)一些初始指令并沒有什么大問題。（事實(shí)上，lookups 甚至可以被視為一種約束。）實(shí)際上，正如我之前說過的，一旦我們轉(zhuǎn)向 Binius 承諾方案，我們可能不得不使用傳統(tǒng)的約束來實(shí)現(xiàn) RISC-V 的加法和乘法。

5、zkVM 基準(zhǔn)測(cè)試

有了這些背景了解，下面我來談?wù)勎覍?duì)預(yù)編譯的看法，因?yàn)樗鼈兣c zkVM 和基準(zhǔn)測(cè)試有關(guān)。

首先，在沒有預(yù)編譯的情況下對(duì)各種 RISC-V zkVM 進(jìn)行基準(zhǔn)測(cè)試正是對(duì) RISC-V zkVM 進(jìn)行基準(zhǔn)測(cè)試的意義。「zkVM」一詞是一個(gè)非正式的叫法，因此必然產(chǎn)生分歧，但在我看來，具有一個(gè)或多個(gè)預(yù)編譯的 RISC-V zkVM 不再是 RISC-V 的 zkVM：它是基于 RISC-V 的新指令集的 zkVM，將每個(gè)預(yù)編譯添加為初始指令。至少，添加到 zkVM 的每個(gè)預(yù)編譯都會(huì)削弱 zkVM 范式的價(jià)值主張——每添加一個(gè)電路都會(huì)增加潛在的 bug 表面積，并且現(xiàn)有程序?qū)o(wú)法開箱即用地利用這些新的預(yù)編譯。

有些人還將 zkEVM 的 EVM 預(yù)編譯概念與 zkVM 的預(yù)編概念混為一談。但這是兩個(gè)截然不同的東西。雖然 zkEVM 的一些關(guān)鍵操作——比如 Merkle 哈希和數(shù)字簽名驗(yàn)證——確實(shí)比初始的 RISC-V 指令更復(fù)雜，但這并不能改變 EVM 預(yù)編譯和初始 EVM 指令之間沒有功能差異這樣一個(gè)事實(shí)。zkEVM 必須支持 EVM 預(yù)編譯，以聲明與 EVM 對(duì)等。換句話說，不支持 EVM 預(yù)編譯的 zkEVM 不同于像 Jolt 這樣的 RISC-V zkVM，后者將使用預(yù)編譯擴(kuò)展 RISC-V 以外的指令集。

另一個(gè)問題是如何選擇一組「公平」的函數(shù)來對(duì) zkVM 進(jìn)行基準(zhǔn)測(cè)試。但是對(duì)于 RISC-V zkVM 來說，任何函數(shù)集都是公平的。Prover 時(shí)間幾乎完全取決于 RISC-V CPU 運(yùn)行的周期數(shù)，原因有兩點(diǎn)。首先，prover 在「獲取 – 解碼 – 執(zhí)行」循環(huán)的「執(zhí)行」部分花費(fèi)了一小部分時(shí)間。其次，不同的 RISC-V 指令，以及內(nèi)存訪問，證明時(shí)間都高度相似。（在 Jolt 中，它們都是通過離線內(nèi)存檢測(cè)技術(shù)來處理的。）

最后，如果使用預(yù)編譯，Jolt 的表現(xiàn)可能不會(huì)比其他替代方案差。事實(shí)上，我預(yù)計(jì)它會(huì)表現(xiàn)更好，因?yàn)榛?sum-check 的預(yù)編譯將是最快的，并且可以集成到 Jolt 中而沒有開銷，因?yàn)樗鼘ｉT使用了基于 sum-check 的 PIOP。在這一點(diǎn)上，有些人擔(dān)心使用橢圓曲線承諾方案的預(yù)編譯將比使用基于哈希方案的預(yù)編譯差很多。如今，Jolt 使用曲線，但這并不是必須的，我們一直對(duì)轉(zhuǎn)向 Binius 的計(jì)劃持開放態(tài)度。

6、關(guān)于基準(zhǔn)的廣泛思考

我們進(jìn)行基準(zhǔn)測(cè)試的主要目標(biāo)是確定不同證明系統(tǒng)的內(nèi)在性能情況，在某種程度上，它們可以與它們的實(shí)現(xiàn)拆分開。這種方法使社區(qū)能夠理解并聚焦于設(shè)計(jì)高性能且安全的 SNARK 的正確技術(shù)。但是，當(dāng)試圖比較兩個(gè)不同的 SNARK 時(shí)，數(shù)不盡的混淆因素往往導(dǎo)致不可能進(jìn)行嚴(yán)絲合縫的對(duì)比。

工程方面的努力是這些混淆因素之中的一個(gè)，盡管社區(qū)中的許多人似乎持對(duì)立觀點(diǎn)。想法似乎是這樣的：如果一個(gè)項(xiàng)目添加了「特性」，比如針對(duì)特定硬件的預(yù)編譯或進(jìn)行了優(yōu)化，那么它應(yīng)該在任何基準(zhǔn)測(cè)試中都擁有「榮譽(yù)」表現(xiàn)。

兩種觀點(diǎn)都有其可取之處。但長(zhǎng)遠(yuǎn)來看，后一種觀點(diǎn)顯然站不住腳。新方法在任何基準(zhǔn)測(cè)試中都將永遠(yuǎn)處于劣勢(shì)，因?yàn)槟切┬路椒]有與舊項(xiàng)目可比的時(shí)間。這樣的觀點(diǎn)是對(duì)進(jìn)步的阻礙。

隨著時(shí)間的推移，我預(yù)計(jì)基準(zhǔn)測(cè)試相關(guān)的混淆因素將減少。隨著 SNARK 的開發(fā)工具的成熟，SNARK 獲得良好的性能所需的工程方面的工作量將變少。zkVM 的成本主要取決于周期數(shù)，而不是任何特定應(yīng)用程序的特性，這是一個(gè)小小的奇跡（至少對(duì)于 RISC-V 如此）。如果人們關(guān)注約束系統(tǒng)的選擇（而不是今天的 R1CS、AIR、Plonkish 等碎片化狀態(tài)），針對(duì)約束系統(tǒng)的 SNARK 可能也會(huì)出現(xiàn)類似的情況，使用約束系統(tǒng)大小的簡(jiǎn)單度量方法來代替周期數(shù)。

在此之前，很難在混雜因素控制不足和過度控制之間取得適當(dāng)?shù)钠胶狻７制缡遣豢杀苊獾模ㄔO(shè)者們將必須提供任何一個(gè)基準(zhǔn)背后的全部背景、細(xì)節(jié)信息和基本原理，以便社區(qū)能夠理解和探討。