作者：Alex Connolly，Immutable聯創兼CTO；譯：金財經xiaozou
2022年8月，我曾寫過一篇關於zkEVM目前發展狀態的博文，標題為《zkEVM、EVM相容性及Rollup基礎指南》（Ground Up Guide to zkEVM, EVM Compatibility and Rollups）。在同一周，V神發布了一篇文章，介紹了不同類型的zkEVM，確立了Type 1、Type 2分類法，現在通常用使用不同的Type分型來稱呼不同的zkEVM——競爭很激烈！
在那篇文章中，我做出瞭如下預測：
……也應該對智能合約rollup的現況有清醒認知。每個團隊都有強烈的動機將自己推銷為是那個「即將接管世界」的角色——但最早要到2022年底，以太坊上才會出現「生產級」的智能合約，而其中許多團隊要到2023年後期才能做好準備。
我們現在已經到了「2023年結尾」了——zkEVM的開發和採用情況如何了？從zkEVM的許多方面來說，今年都是重要的一年：
· Polygon zkEVM、Linea和Scroll發表！
· Immutable宣布下一個rollup——Immutable zkEVM
· Polygon宣布計劃將Polygon PoS升級至zkEVM Validium
· Optimism表明計劃支持OP Stack鏈作為zkEVM運行
不管怎樣，數據是不言自明的：
簡而言之，zkEVM的開發工作正在進行中，但與現有的區塊鏈相比，目前還沒有哪個zkEVM獲得了巨大採用。這篇文章的目的是回答一個顯而易見的問題－各zkEVM專案進度如何，怎樣才能產生可喜的關注度？
首先，讓我們快速回顧一下V神的“zkEVM類型”，有助於理解zkEVM專案：
這看起來很複雜，但實際上很容易理解。每個人最初都在心裡認為zkEVM只是採用現有的以太坊執行客戶端（例如Geth、Nethermind、Erigon），生成其執行跟踪的zk（零知識）證明，並使用這些證明來確保L1-L2訊息橋接。然而，EVM最初的設計考量並不包括zk證明，而且這種方法效率非常低（例如，以太坊的keccak雜湊函數成本高昂）。所以，我們有幾個選擇：
· Type 1 – 只管處理，我的用戶/我將付費。這裡有兩個主要優點：你可以使用現有區塊鏈的Type 1 Prover（證明程式），而且你不需要維護自己的以太坊客戶端（開發成本可能與證明成本一樣高），但你必須保持執行客戶端更新。
· Type 2 — 不觸及「應用層」（例如，不要改變操作碼成本/實現），但要更改鏈上節點，使其具有對prover更友善的內部結構（例如，使用Sparse默克爾樹來表示狀態）。這種方法的一大缺點是，你需要維護一個永久分叉的以太坊客戶端。考慮到以太坊已經在費力維護多個生產級客戶端，這是一項非常重要的任務，需要有專業的區塊鏈工程師團隊。
· Type 3 – 完成Type 2中的所有工作，同時修改EVM，去除最難證明的部分（例如，一些很少使用的預編譯），這可能會增加prover密集型操作的操作碼成本。這是將你的prover推向市場的最快方式，但你需要進行上述所有客戶端更新，並經歷與現有以太坊應用和工具不相容的情況（例如，使用這些預編譯的任何合約都會中斷）。
· Type 4 — 建立專為高效率zk證明而設計的自訂VM，並建立執行該VM的自訂客戶機。這將大大降低驗證成本，但需要建立一個龐大的工具和基礎設施生態系統來支援你的自訂VM/客戶機。你或許能夠提供某種形式的Solidity程式碼轉換，但是開發人員可能必須對他們現有的合約和工具進行實質的更改才能在你的鏈上部署。在我看來，大多數Type 4 rollup都不是真正的zkEVM——用「智能合約zk-rollup」來描述可能更準確。
用表格的形式可能比較容易理解：
到2023年底，幾乎每個活躍專案都是Type 3或Type 4 rollup，原因很簡單：它們的建置速度要快得多（以相容性和不斷增加的維護開銷為代價）！有趣的是，幾乎所有目前屬於Type 3的專案都計劃最終成為Type 2或Type 1 rollup，以提高其與以太坊的兼容性，並有可能不再需要開發自己的客戶端。
在去年的部落格文章中，我主要關注了各zkEVM團隊如何設計他們的prover。今年，我想涵蓋各專案做法的其他重要方面，包括那些沒有被經常討論的事項（如各zkEVM執行客戶端計劃）。例如，許多人認為L2是「排序器」（sequencer）和prover，而標準的zkEVM設計實際上看起來更像是這樣！
還有其他的排序器設計（我們將在後面討論），但大多數zkEVM目前都計劃運行一個單獨的區塊鏈作為L2排序器，具有自己的執行客戶端（接收和執行交易）和共識客戶端（就所有L2節點的交易順序達成共識）。
重要的是，修改標準以太坊客戶端來創建自己的自訂鍊是有成本的。每次的以太坊客戶端變更（特別是每次硬分叉）都將是所有zKEVM團隊的治理決策項目。自訂的部分越多，進行上游變更就越困難。隨著時間的推移，很容易產生zkEVM非同步——在某個點上與以太坊匹配的zkEVM將迅速失去同步。
1、zkEVM專案狀態
那麼，我們去年探討的那些項目怎麼樣了呢？
（1）Polygon zkEVM（以及Polygon CDK鏈）
Polygon zkEVM於2023年3月在主線上線，迄今已處理了近1,000萬筆交易。它目前屬於Type 3類型，目標是在2024年的某個時候成為Type 2。
當然，作為Type 2/3，Polygon zkEVM需要有屬於自己的自訂客戶端實作。 Polygon選擇從頭開始建立自己的客戶端（zkevm-node）以取得相容性，但這個新客戶端發生過停機事故，並且缺少許多標準以太坊客戶端所具有的功能。
為了彌補這一點，Polygon與gateway.fm合作修改Erigon（先前的turbo-geth）以支援Type 2/3 prover所需的變更。這將為Polygon zkEVM提供一個更穩定的基礎層和更優化的性能，儘管保持與上游Erigon的兼容性仍然是一個持續挑戰。
許多團隊也宣布將使用Polygon鏈開發工具包（CDK）建構zkEVM，包括Astar、OKX和Palm Network。 Polygon CDK的願景是支援開發人員按照自己的需求，透過結合使用不同的用戶端、prover和資料可用性解決方案來建立自己的自訂鏈（即建立自己的zkEVM工具包）。如今，CDK支援一個客戶端實作（zkevm-node）和一個prover（Polygon zkEVM）。未來，Polygon團隊計劃在CDK中添加更多的客戶端實作（例如Type-2-Erigon）和prover（例如Polygon Zero）。
這意味著你今天就可以部署你自己版本的Polygon zkEVM！但是，任何使用zkevm-node進行部署的團隊將來都可能需要遷移到其他客戶端，所以可能希望在準備好後再遷移。
我們還應該注意到，Polygon正計劃將Polygon PoS（世界上最大、最成功的區塊鏈之一）升級為具有鏈下資料的zkEVM，但具體升級時間表尚未確定。
（2）Scroll
2023年Scroll上線了兩個測試網和一個主網（10月）－這是大型建設之年！ Scroll目前是一個Type 3 zkEVM，之前他們曾表示打算在未來轉為Type 1/2，具體時間尚不清楚。他們有一個與以太坊的差異列表，表裡包含了一些未實現的預編譯和一些微小的狀態修改。 Scroll的客戶端是Geth v1.10.13的一個分叉，目前在單一排序器模式下運作。值得注意的是，Scroll的執行客戶端的某些部分已經落後於上游以太坊兩年（儘管他們已經選擇了上海執行客戶端的EIPs來減少應用層偏差）。這不會對鏈造成任何直接的破壞，但卻表明了許多項目將面臨治理挑戰，需要確定與上游以太坊長期保持多近的距離，以及需要多少工程努力才能不斷縮小這一差距。
（3）Immutable zkEVM
自7月以來，Immutable zkEVM已經有了一個公共測試網，並計劃在1月上線主網。 Immutable zkEVM使用標準go-ethereum客戶端版本，該版本已針對我們的核心領域（遊戲）進行了自訂。有趣的是，Immutable zkEVM是目前本文探討的唯一一個特定領域（domain specific）zkEVM，儘管L2能夠根據特定領域的要求進行客製化同時保持以太坊的安全性是它們的一個主要吸引力。例如，Immutable zkEVM滿足於使用validium資料可用性來降低成本，並選擇了單塊最終性PoSBFT設計來提供近乎即時的確認，這些決策可能不適合通用鏈。此外，如果大量的遊戲和遊戲用戶湧向這條鏈，可能會產生網路效應——我們預計未來會出現更多的特定域L2。
然而，該鏈的發布不會提供prover支援。這是因為Immutable zkEVM計劃在Type 1 Polygon Zero證明程式可用且具有成本效益時再採用。 Immutable發布Type 3的唯一方法是對客戶端進行實質更改，考慮到客戶端偏離以太坊的影響，我們不願意這樣做。如今，Polygon Zero由Plonky-2提供支持，Plonky-3正在積極開發中，預計在2024年中後期達到生產級，屆時性能將提高約一個數量級。這將為Polygon提供兩個獨立的prover（Polygon Zero和Polygon zkEVM），開發人員將能夠在他們基於CDK的鏈中選擇使用哪個prover。
（4）Linea
Linea在8月發布了他們的主網，並採用了與Polygon/Scroll類似的方式：從Type 3 rollup開始，逐漸轉為Type 1或Type 2型。 Linea目前與以太幣London只有若干不同之處，如表中所示。
Linea正在使用他們自己更新的Geth版本，他們將其命名為「zkGeth」。值得注意的是，這個客戶端的原始碼不是開源的，prover也不是開源的——用戶無法驗證它們是否按預期運行。他們計劃將所有這些元件開源，作為他們文件完整的去中心化路線圖的一部分。 Linea的文檔表明，他們計劃從“zkGeth”轉為linea-besu，這是對Consensys開發的Besu客戶端的更新版本。從中期來看，Linea團隊計劃合併linea-besu和常規besu，並依靠Besu的插件系統來進行必要的狀態修改，以成為一個Type 2 zkEVM。
（5）Taiko
Taiko正在打磨他們的第五個測試網，計劃明年上網主網。 Taiko正在開發他們自己的基於PSE實現的zk prover（與Scroll類似）。有趣的是，Taiko是本文中唯一一個目前不考慮將單一排序器逐步去中心化為一個L2區塊鏈這種設計模式的團隊。 Taiko的設計是基於Justin Drake所描述的Based Rollup概念——而不是擁有一個經許可的validator（驗證者/器）集，任何人都可以向以太坊L1提交交易包和證明。這種實作意味著rollup將排序完全委託給了以太坊L1，讓它可以自動繼承以太坊L1的活躍度和去中心化特性。然而，它有一個重要的缺點：L2排序器不會提供「快速最終性」確認，也就是說使用者等待交易確認的時間更長。 Justin Drake提出了「Based preconfirmations（預先確認）」機制，以提供延遲僅為100ms的機率確認，但還沒有接近生產水平，並且引入一個單獨的「preconf（預確認）承諾」和「preconf tips」系統可能會對現有的以太坊工具產生影響。這是一個活躍的研究領域！
Taiko從一開始就表示他們計劃成為Type 1 zkEVM。他們認為，其他zkEVM帶來的相容性差異將比更高昂的證明產生成本還要糟，無論如何，隨著技術的進步，成本終將會下降。 Taiko的客戶實作很有趣－核心的「執行客戶端」是經過修改的Geth v1.13 (taiko-geth)。然而，他們也在維護自己的「共識客戶端」(taiko-client)，它處理與L1的通訊並監控based排序過程。
（6）zkSync Era
zkSync Era於2023年3月發布，到目前為止可謂是成功的，即將進行空投的傳言將其TVL推高至5億美元以上。 zkSync是Type 4 zkEVM，他們正在證明自己的自訂VM (eraVM)，而不是試圖直接修改EVM。他們的目標是與以太坊進行“語言級相容”，並提供了一個從Solidity程式碼到他們的自訂VM的直接編譯器。他們對許多關鍵EVM操作碼的實作進行了實質性的更改，對編譯過程也進行了一些更改，所以開發人員常常需要修改他們的合約或部署腳本才能在zkSync Era上進行部署。
zkSync Era有自己的自訂客戶端，讓他們實現非EVM功能，例如原生帳戶抽象化。 2023年7月，他們將prover升級為“Boojum”，這是一個STARK證明系統，然後用SNARK包裝進行鏈上驗證，類似於Polygon zkEVM。 zkSync Era需要完全鏈上數據，但他們計劃在未來引入“zkPorter”，這將允許用戶在不同價位的不同數據可用性模式之間進行選擇，與StarkWare提出的Volition模型類似。
（7）StarkNet
StarkNet是以太坊生態系統中最雄心勃勃的項目之一：他們正在從頭開始建立一個Type 4 rollup和生態系統，其中包括一個新的VM (CairoVM)、一個新的程式語言(Cairo)、一個新的prover (Stone)和新的客戶端（Pathfinder、Papyrus、Juno）。 StarkNet在2021年和2022年逐步開放，現在擁有超1.5億美元的TVL，每月處理交易量超1000萬筆。
從頭開始建立新生態系統是極具挑戰性的，但也為EVM一直在努力的領域（例如原生帳戶抽象化）提供了根本性創新的機會，並大幅提高了效能。該工具鏈的大部分已經通過基於StarkEx的項目（如Immutable X、dydx v3和Sorare）完成了廣泛測試，這些項目自2020年以來一直在運行，並已被廣泛採用。
最初，StarkNet生態系統透過我去年提到的Warp Solidity→Cairo轉譯器等計畫探索了語言層面的兼容性。然而，Warp現在已經過時了，而StarkNet生態系統已經決定完全致力於新的CAIRO工具集，而不再支援任何類型的Solidity向後相容性。現在，他們面臨著與Solana或Sui等非EVM生態系統相同的挑戰——你能讓大量開發人員採用你的新工具嗎？還是普遍存在EVM會勝出？
Kakarot團隊正在做的工作是唯一的例外，他們正在使用CAIRO語言開發一個Type 2.5 EVM，將作為運行在StarkNet上的組合約。透過Kakarot，用戶將能夠部署在StarkNet上擁有程式碼/狀態的EVM合約並與之交互，允許用戶從StarkNet的效能中受益，同時保留EVM相容性。由於底層執行環境仍將是StarkNet，這將犧牲以太坊工具的兼容性——但對於某些專案來說，這可能是可以接受的權衡。 Kakarot還沒有達到生產級別，這種分層方法的性能和工具兼容性的影響還不清楚，但這是一個令人興奮的嘗試，可以彌合各種zkEVM類型之間的差距，也表明我們在探索設計空間方面行動很早。
（8）Optimism
由於顯而易見的原因，Optimism通常被認為是一個專注於optimistic rollup的團隊。然而，他們一再表示計劃支持zk零知識證明作為未來的一種選擇，並且已經與幾個積極貢獻的團隊進行了熱烈討論。像zeth這樣令人興奮的zk生態項目現在提供Optimism區塊支援。然而，我們還沒有看到任何正式的時間表或設計——也許在明年的zkEVM回顧中會有令人興奮的變化！
如你所見，各個kEVM團隊之間的做法有很大的差異。即使是同一種類型的rollup也經常採用與其prover、客戶端和排序機制截然不同的設計。
還有另一種非常重要的方法來比較這些新的zkEVM——它們的實際配置！一般來說，分析各鏈的客戶端和prover的體系結構要更加有趣，因為涉及根本的設計決策，而不是可以輕鬆更改的應用級配置。然而，如果你是應用程式開發人員，具體配置無疑是很重要的，所以一定要確保你研究了每個zkEVM的區塊時間、區塊gas限制、證明發布頻率、排序器共識機制以及任何可能影響應用程式使用者體驗的因素！
綜上所述：2023年，各種各樣的團隊進行了大量的開發工作。所以，如果一切正在進展中，我們是否只需要靜靜等待？我們還需要解決什麼問題，才能看到zkEVM獲得實質的關注？
2、zkEVM開發中還有哪些懸而未決的問題？
首先，客戶端和prover之間缺少標準化介面。目前，每個prover僅與最初建造它們時所使用的客戶端相容。你無法在任何其他Type 2/3客戶端上使用Polygon zkEVM的prover。理想情況下，任何新的prover或客戶端都應該與盡可能多的現有prover/客戶端相容。鼓勵各種zkEVM團隊遵循單一介面的EIP是未來發展的關鍵一步。
可以理解的是，大多數團隊目前都在優先改善自己的部署，而不是尋求與他人的兼容性。目前這種做法可能是可以接受的，但最終我們尤其希望L2排序的zkEVM可以使用多客戶端/prover設置，以減少重大bug風險。此外，標準化「經典」type 2功能的實作（例如Sparse默克爾樹、Poseidon雜湊函數而非keccak）可能有助於多個prover使用相同或相似的客戶端。減少“geth”類客戶端的數量將是該生態系統的巨大勝利！一項名為「RollCall」的標準化倡議已被提出，同時也提出了一系列Rollup優化建議（RIPs），雖然目前尚不清楚這項倡議的關注度有多高。
其次，這些zkEVM幾乎全都是單一排序器，是對這些rollup的去中心化和安全性的挑戰。尤其要注意，prover的行為只是為了確保L1-L2橋接是安全的。任何依賴L2預確認的外部系統(如CEX)都將大量資金置於風險之中，因為它們完全依賴於單一排序器——對於今天的許多L2來說，極具破壞性的黑客攻擊只需要盜用一個排序器金鑰就可實現。然而，一旦你將排序器去中心化，就會出現不同的挑戰（正如你在上述Taiko內容中所見！）。你是否需要提供L1一個zk證明，證明已經達成了L2共識？活躍度問題呢？ MEV呢？大多數單一排序器rollup出於品牌/聲譽/鏈信任的原因目前都沒有利用MEV，但這種情況可能會在未來有所改變。
第三，沒有衡量zkEVM性能和成本的標準架構。本文的大部分內容都在比較各種zkEVM設計的潛在效能影響，但是目前很少有zkEVM團隊發布任何真正的效能規格或測試。 「zkEVM成本」由以下幾部分構成：
· 產生證明的雲端運算成本（受電路效率影響）
· 驗證證明的L1成本
· 數據可用性成本
· 從一層傳送訊息給另一層的成本
我應該能夠為這些領域創建標準化測試，並將結果製成表格，以幫助建造者做出更明智的決策——目前這是不可能的。細微差別在這裡：在某些類型的交易中，一些prover實作將比其他prover更佳，部分成本將取決於使用情況，因為能夠在交易包中分攤交易成本。這些成本應該如何呈現給用戶也是一個很大的不確定性（例如，Immutable zkEVM計劃在大多數情況下為用戶支付發布成本，而Scroll則有一個複雜的L1 + L2收費設置，以確保每筆交易都是盈利的）。此外，許多zkEVM可能會遇到與狀態成長相關的效能問題——擴展以太坊區塊空間不是免費的！所有這些都需要比現在更高的可衡量性/可比性。
第四，對於大多數智能合約rollup而言，退出機制仍然沒有被很好地理解和定義。自我託管在特定應用rollup（如Immutable X）上被很好地定義——你存放到該L1橋中的任何資產都應該是可檢索的，即使排序器完全脫機或完全是惡意的。這通常被稱為“逃生艙口”。但這在智能合約rollup的情況下意味著什麼呢？如果你的ETH質押在一個合約中，無論如何都不應可用呢？這一切都是關於抗審查性嗎（我們需要保證強制交易的能力嗎）？對於用於不同目的（例如遊戲資產與DeFi）的zkEVM來說，什麼程度的數據可用性是可接受的？我們需要一致的框架向用戶傳達實際的故障情況——L2 Beat在這方面開了個好頭！
第五，zkEVM與以太坊L1的關係尚不明晰。在撰寫本文期間，我再一次被V神發布的一篇反思「enshrined zkEVM」的部落格文章所吸引。主要內容是以太坊客戶端層可以「enshrined」 zk prove實現，可用於驗證其他來源（例如L2）提交的EVM區塊的執行情況。這避免了讓所有L2 zkEVM都必須保持他們的zkEVM prover是最新的（重大勝利！）——他們可以依靠其他團隊的工作成果，包括核心以太坊客戶端團隊，一個完全SNARK的以太坊已成為現實。那麼，我是否應該將「enshrined zkEVM」的提議解讀為偏離以太坊以L2為中心的擴展路線圖，將L2捕獲的價值帶回？
不完全是這樣。 L2仍然需要自己的排序器來提供快速確認（在遊戲等領域至關重要），而V神提出的設計只支援具有完全鏈上資料的zkEVM。出於變現等原因，大多數L2幾乎都希望保持獨立性，這對以太坊生態系統來說是一個重要的權衡。 L2對於以太坊區塊空間的擴展至關重要，但他們的動機（和BD團隊）可能不會總是與以太坊對齊。
最後，多個zkEVM將繼續分散用戶和流動性，致使用戶體驗很糟。如今，每多一個以太坊L2將繼續分散狀態和流動性——如果你在Arbitrum上有2枚ETH，那麼在任何其他L2上訪問ETH都是有難度的。在我看來，這是迄今為止對單體鏈的最佳論證，在單體鏈中，可組合性得到了極大改善，用戶不必在多個鏈之間進行平衡。隨著目前「L2工具包」（例如Polygon CDK、Arbitrum Orbit、OP Stack）流行開來，啟動鏈從未如此輕鬆，但代價是更大程度的碎片化問題。
為了使這種多L2模型長期成功，在大多數情況下，我們需要將單一鍊和平衡從使用者中抽像出來。這是有效性證明優於詐欺證明更有力的論點之一——快速鏈間橋接的即時性證明驗證。然而，即使有了強大的橋接/互通性框架，仍然有大量的使用者體驗問題需要解決。在Immutable，我們的計劃是透過錢包層的Immutable Passport和垂直整合和來解決這個問題。
3、結論
對zkEVM來說，2023年既是開發進度的重要一年，也是準備實際採用的一年。 2024年將是Type 1和Type 2 zkEVM真正準備好投入生產使用的第一年，但實際上我們最早也要到第三/四季才能使用——想要實現這一目標，我們還需要解決很多性能問題！
我想清楚地表明，zkEVM在2024年要解決的主要問題不是技術問題（雖然我們顯然還有一些技術問題需要解決），而是價值問題——我們能在下一代L2上為用戶創建令人興奮的應用程式嗎？我們需要出色的協議開發人員和出色的應用程式開發人員！