作者: Suning Yao @ Foresight Ventures
TL; DR
零知識證明技術, 可以保證計算的完整性、正確性和隱私, 在區塊鏈擴容和隱私中有應用.
zk-SNARK 和zk-STARK 各有優點, 而它們的合理結合更加有潛力.
zkVM 能賦予應用零知識證明能力, zkVM 分為使用主流、EVM 或全新指令集.
EVM 的適配包括EVM 兼容性、等同性和Specification 上的適配.
zkEVM 是兼容EVM 而又零知識證明友好的環境, 主要分為原生和編譯流派.
基於原生的zkEVM 是以太坊和區塊鏈的未來.
支持Solidity 生態的通用zkVM 是Web3 的未來.
0. 零知識證明
不嚴謹但簡單易懂地來介紹一下零知識證明:
你在上小學. 老師是驗證者, 你作為學生是證明者. 你如何證明你掌握了一元二次方程的求解公式呢? 那就需要數學考試.
老師會隨機出10 道相關的題目, 而你如果掌握了, 則可以把他們都做出來. 在這個過程中, 你沒有背誦或者默寫求解公式的具體內容, 但是老師卻可以很簡單地驗證你的知識掌握程度.
其實這就是Tartaglia 與Cardano (對的, 就是這個名字) 爭奪誰是一元三次方程發現者時所採用的方法. 他們都不想告訴對方自己公式的內容, 但是通過做題, 就可以很容易地驗證且過程中不透露知識地, 判斷他們是否掌握了這一知識.
零知識證明有什麼用呢? 用處就是, 整個過程可以節省計算算力和壓縮鏈上空間, 同時也可以對隱私有保護, 符合區塊鏈去信任的特點以及密碼學的基因.
1. SNARK 和STARK
區塊鏈領域中所用到或者提到的“zk” 通常不是真正的零知識證明, 而經常是Validity Proof. 由於相關詞彙的混亂, 所以本文中的某些地方會延續這些“誤用”.
在目前的區塊鏈版圖中, zk 可以說是區塊鏈擴容(不zk 的Validity Proof) 與隱私技術(真正的zk) 的最前沿與最優解決方案, 在Tornado.cash, ZCash, zkSync, zk.money, Filecoin, 和Mina 等項目中都有使用.
目前的技術方案主要分為SNARK 以及STARK 兩類.STARK 中的S 代表可擴展的, 意味著被證明的語句有重複的結構, 而SNARK 支持任意的電路, 這些電路被預處理以實現簡潔的證明.其中對SNARK 的技術實踐佔據了主導地位, STARK 主要有StarkWare 在已上線的產品中大規模採用. 以下是它們之間的對比.
從Meme 的角度而言, STARK 比SNARK 優秀(?, Star Wars, Star Trek).
如果SNARK 是以太坊2.0 的未來, 那麼STARK 就會是以太坊3.0 的未來. 正經的來說, STARK 的優勢在於
更低的gas (更能scale)
更大的batch size (更能scale * 2)
更快的證明(更能scale * 3)
沒有trusted setup (生成的參數僅對當前的應用有效, 若出現了修改需要重新setup)
後量子安全
但是STARK 生成的證明的體積更大, 並且還大不少, 由於比如WASM 的一些限制, 可能會在構建時需要額外的操作(這裡是SNARK). Mir 前段時間在Starky 給出了一個AIR-based STARK的實踐, 是Plonky2的一部分(Plonky2 和Starky 的關係比較複雜...). 我個人認為, 體積大可以通過各種手法來優化, 但是算法本身的時間複雜度是很難再進一步壓縮的.
這些零知識證明技術可以通過合理的結合來構建更強大的應用. 比如Polygon Hermez 就通過SNARK 來證實STARK 的正確性, 從而減少最終發布證明時的gas fee.
總結來說, SNARK 和STARK 都是優秀的零知識證明技術, 各有千秋, 而它們的合理結合更加有潛力.
2. zkVM
前面所說到的Tornado.cash和zk.money類似都是僅支持轉賬操作的零知識證明應用, 不支持通用的計算. 類比來說, 這些應用都只有比特幣的功能, 遠遠不及以太坊的圖靈完備, 更不要說建生態了(比特幣上的智能合約一直沒做出生態來).
zkVM 就是一個由零知識證明來保證安全可驗證可信特性的虛擬機, 簡單來說就是, 輸入舊狀態和程序, 返回新狀態. 它能讓所有的應用都被賦予零知識證明的超能力.
Miden 在ETH Amsterdam 的演講用一張圖很好概括了zkVM 到底是什麼.
zkVM 的優點:
易用: 開發者不用學密碼學或者零知識開發就可以使用zkVM 來運行程序保證計算安全(不代表完全無門檻)
通用: zkVM 可以給任何程序和計算生成證明.
簡潔: 相對比較少量constraints 就可以描述整個VM (不用重複生成整個VM 的電路).
遞歸: 免費的遞歸特性. 和通用性一樣, 對VM 的驗證可以通過VM 來進行. 這個就挺好玩, 比如你可以在zkVM 裡放一個zkVM, 就類似StarkWare 說的L3 的概念.
zkVM 的缺點:
計算架構特殊: 並非所有零知識證明系統可以被用來做zkVM.
性能問題: 電路需要優化, 可以為特定計算進行針對性優化.
現在主流的zkVM 有三大類, 括號中是它們的指令集: 主流(WASM, RISC-V)、EVM (EVM bytecode)、ZK-Optimized (全新指令集, 針對零知識證明所優化, 比如Cairo 和zkSync ). 以下是根據Miden 在ETH Amsterdam 的演講所整理的類型對比圖:
很多零知識證明開發生態所做的事情大多是讓開發者能用Circom 庫(以及snarkyjs 這種) 或者其他新創造的語言(Leo 或者Cairo 這種語言都有奇奇怪怪的限制) 來做通用zk DApp 的開發, 但是沒有像以太坊上用Solidity 那麼直接和易學.
除此之外, 還有很多項目, 比如zkSync, Scroll, 或者Polygon 旗下的好多家都在嘗試做zkEVM 或者其他的zkVM.
3. EVM
EVM 就是以太坊的虛擬機, 也可以理解為運行智能合約的一套執行環境.
數年來, 各個公鏈都在不停嘗試著去兼容EVM, 從而接入到以太坊的開發生態當中. 對於這個概念, 衍生出了EVM 兼容, 等同和其他一些定義.
EVM 兼容性: Solidity 等語言層面的適配.
EVM 等同性: EVM 字節碼層面的適配.
EVM Specification 適配: 也就是通常所說的真正的zkEVM, 大多情況下甚至是向後兼容的優化後的超集, 能提供賬戶抽象(就是每個賬戶都是一個智能合約) 等EVM 沒有提供的特性.
4. zkEVM
我們再來解讀一下zkEVM. 定義上來說, zkEVM 是一種兼容EVM 同時又對零知識證明友好的虛擬機, 能保證程序, 操作, 和輸入輸出等的完全正確性.
對於實現通用計算來說, 要做zkEVM 主要需要解決兩個難點:
a) 電路複雜
不同的合約需要生成不同的電路, 而且這些電路很“複雜”.
這方面主要就要靠各種優化了, 比如Aleo (不過它不是direct ZK 這一類... 只是為了舉例說明優化) 通過分佈式Cluster 來並發計算Proof, 或者通過各種硬件上的優化來加速.
b) 設計困難
zkEVM 不止要對EVM 進行重構, 對以太坊的整體狀態轉換都要用零知識證明技術進行重構.
EVM 設計的時候就沒想到後面要做zkEVM, 造成了非常大的困難. 導致了有兩個門派的路線, 都在圖裡了.
或者說按VM 的架構來分, 就長這樣(超級感謝Scroll Tech 的原圖總結!). Opcode 指的是EVM Opcode. 其中StarkWare 部分是用Warp 來將Solidity 轉成Cairo 合約, 或者直接用Cairo 寫合約, 一樣能獲得不錯的開發體驗和全套工具.
在開發者和用戶層面, 這幾個方案其實我認為是基本無差別的, 但是在基礎設施上, 越靠右的方案EVM 兼容性越好, 可以無縫接入Geth 等基礎設施, 但開發進度基本上也越慢.
5. zkEVM 和zkVM
zkEVM 的存在我認為是在以太坊生態上去翻新和打補丁, 能為以太坊及其生態的繁榮添磚加瓦, 而zkVM 的存在卻不一定是給以太坊做加強, 同時也具有更大的想像力.
StarkNet 的Cairo VM 儘管可能不是我想像中最完美的zkVM, 但它能比EVM 或者zkEVM 幹更多的事, 同時這些不止是停留在EIP 級別的功能拓展. Cairo VM 上可以跑機器學習模型, 甚至現在還有機器學習模型平台正在StarkNet 上建設.
相比zkEVM, 一個zkVM 會更加容易被構建(無需擔心EVM 的技術債), 更加靈活(無需擔心EVM 的更新), 更加容易優化(電路和證明器的軟硬件優化比構建zkEVM 簡單和便宜非常多).
當然zkVM 的一個最微小但很致命的缺點就是, 如果zkVM 無法支持EVM 兼容(Solidity 語言層面), 那麼zkVM 就很難像EVM 一樣有最完備和成熟的Web3 開發生態.
zkVM 或許是更大的趨勢, 能讓對EVM 的縱向優化, 變成EVM 生態的橫向拓展, 跳出了EVM 的限制.
6. zkVM 的未來
如果能有一種通用的zkVM 能夠讓所有編程語言的智能合約, 不止是Solidity, 不止是Cairo, 而是Rust, C++, Go,在零知識證明的加持下安全運行呢? (Stellar 嘗試過, 但失敗了.)
正如@kelvinfichter所說的:Why zkEVM if zkMIPS? 正如@KyleSamani所說的:EVM is a bug not a feature. Why zkEVM if zkVM?
Winterfall或者Distaff或者Miden VM等zkVM 都沒有做到非常好的開發友好度. Nervos 有RISC-V 的VM, 但是Nervos 沒有用零知識證明技術.
現狀下最優解的方案就是構建一個WASM 或者RISC-V 的zkVM, 最好能支持Rust, Go, C++, 甚至Solidity (zkSync 好像可以立大功) 等語言. 如果有這麼一個通用zkVM, 那麼對於zkEVM會是降維打擊.
Web3 開發者的數量大概佔所有開發者的0.07%, 也就可以推斷出, Solidity 開發者的數量實際上會比0.07% 更少, 會用Cairo 寫合約或者用Leo 寫電路就更少了. 這樣完美的zkVM 所針對的是幾乎100% 的開發者, 任何開發者用幾乎任何語言都可以得到一個完美的零知識運行環境.
如果Web3 和Crypto 有統治世界的一天, 我認為絕對不會是EVM 生態佔據100% 的所有開發者, 而是所有的開發者會慢慢轉化為Web3 和Crypto 開發者. 這就是通用的zkVM 的絕妙之處.
原生zkEVM 是區塊鏈的未來.
通用zkVM 是Web3 的未來.
相關文章
https://brewminate.com/a-mathematical-duel-in-16th-century-renaissance-venice/
https://twitter.com/_bfarmer/status/1520091937444925440
https://twitter.com/EliBenSasson/status/1514242653671546890
https://hackmd.io/V-7Aal05Tiy-ozmzTGBYPA?view=
https://twitter.com/_bfarmer/status/1511486435077017607
https://github.com/mir-protocol/plonky2/tree/main/starky
https://blog.polygon.technology/introducing-plonky2/
https://twitter.com/dlubarov/status/1520090852093091840
https://blog.polygon.technology/zkverse-deep-dive-into-polygon-hermez-2-0/
https://www.youtube.com/watch?v=81UAaiIgIYA
https://medium.com/starkware/fractal-scaling-from-l2-to-l3-7fe238ecfb4f
https://trapdoor-tech.github.io/zkstark-book/Cairo_example/frame.html
https://twitter.com/toghrulmaharram/status/1518270138876891138
https://twitter.com/gluk64/status/1518617582420611072
https://twitter.com/kelvinfichter/status/1522389737021001734
https://twitter.com/guiltygyoza/status/1458494941684850688
https://gizatech.xyz
https://www.reddit.com/r/Stellar/comments/q6ar3w/what_happened_to_zkvm_on_stellar/
https://twitter.com/kelvinfichter/status/1516509144068464644
https://twitter.com/KyleSamani/status/1511683267770163200
https://github.com/novifinancial/winterfell#Usage
https://github.com/GuildOfWeavers/distaff
https://github.com/maticnetwork/miden
https://docs.nervos.org/docs/basics/concepts/ckb-vm/
APP 
