主要zkEVM項目2023年進展大盤點

訪客 1年前 (2023-12-26) 閱讀數(shù) 286 #區(qū)塊鏈

文章標簽前沿文章

作者：Alex Connolly，Immutable聯(lián)創(chuàng)兼CTO；翻譯：喜來順財經xiaozou

2022年8月，我曾寫過一篇關于zkEVM當前發(fā)展狀態(tài)的博文，標題為《zkEVM、EVM兼容性及Rollup基礎指南》（Ground Up Guide to zkEVM, EVM Compatibility and Rollups）。在同一周，V神發(fā)布了一篇文章，介紹了不同類型的zkEVM，確立了Type 1、Type 2分類法，現(xiàn)在通常用使用不同的Type分型來稱呼不同的zkEVM——競爭很是激烈！

在那篇博文中，我做出了如下預測：

……還應該對智能合約rollup的當前狀態(tài)有清醒認知。每個團隊都有強烈的動機將自己推銷為是那個“即將接管世界”的角色——但最早要到2022年底，以太坊上才會出現(xiàn)“生產級”的智能合約，而其中許多團隊要到2023年后期才能做好準備。

我們現(xiàn)在已經到了“2023年結尾”了——zkEVM的開發(fā)和采用情況如何了？從zkEVM的很多方面來說，今年都是重要的一年：

·?Polygon zkEVM、Linea和Scroll發(fā)布！

·?Immutable宣布下一個rollup——Immutable zkEVM

·?Polygon宣布計劃將Polygon PoS升級至zkEVM Validium

·?Optimism表明計劃支持OP Stack鏈作為zkEVM運行

無論怎樣，數(shù)據是不言自明的：

簡而言之，zkEVM的開發(fā)工作正在進行中，但與現(xiàn)有的區(qū)塊鏈相比，目前還沒有哪個zkEVM獲得了巨大采用。這篇文章的目的是回答一個顯而易見的問題——各zkEVM項目進展情況如何，怎樣才能產生可喜的關注度？

首先，讓我們快速回顧一下V神的“zkEVM類型”，有助于理解zkEVM項目：

這看起來很復雜，但實際上很容易理解。每個人最初都在心里認為zkEVM只是采用現(xiàn)有的以太坊執(zhí)行客戶端（例如Geth、Nethermind、Erigon），生成其執(zhí)行跟蹤的zk（零知識）證明，并使用這些證明來確保L1-L2消息橋接。然而，EVM最初的設計考量并不包括zk證明，而且這種方法效率非常低（例如，以太坊的keccak哈希函數(shù)成本高昂）。所以，我們有幾個選擇：

·?Type 1?– 只管處理，我的用戶/我將付費。這里有兩個主要優(yōu)勢：你可以使用現(xiàn)有區(qū)塊鏈的Type 1 Prover（證明程序），并且你不需要維護自己的以太坊客戶端（開發(fā)成本可能與證明成本一樣高），但是你必須保持執(zhí)行客戶端更新。

·?Type 2?-- 不觸及“應用層”（例如，不改變操作碼成本/實現(xiàn)），但要更改鏈上節(jié)點，使其具有對prover更友好的內部結構（例如，使用Sparse默克爾樹來表示狀態(tài)）。這種方法的一大缺點是，你需要維護一個永久分叉的以太坊客戶端。考慮到以太坊已經在費力維護多個生產級客戶端，這是一項非常重要的任務，需要有一個專業(yè)的區(qū)塊鏈工程師團隊。

·?Type 3?– 完成Type 2中的所有工作，同時修改EVM，去掉最難證明的部分（例如，一些很少使用的預編譯），這可能會增加prover密集型操作的操作碼成本。這是將你的prover推向市場的最快方式，但你需要進行上述所有客戶端更新，并經歷與現(xiàn)有以太坊應用和工具不兼容的情況（例如，使用這些預編譯的任何合約都會中斷）。

·?Type 4?-- 創(chuàng)建專為高效zk證明而設計的自定義VM，并創(chuàng)建運行該VM的自定義客戶機。這將大大降低驗證成本，但需要構建一個龐大的工具和基礎設施生態(tài)系統(tǒng)來支持你的自定義VM/客戶機。你或許能夠提供某種形式的Solidity代碼轉換，但是開發(fā)人員可能必須對他們現(xiàn)有的合約和工具進行實質性的更改才能在你的鏈上部署。在我看來，大多數(shù)Type 4 rollup都不是真正的zkEVM——用“智能合約zk-rollup”來描述可能更準確。

用表格的形式可能更容易理解：

到2023年底，幾乎每個活躍項目都是Type 3或Type 4 rollup，原因很簡單：它們的構建速度要快得多（以兼容性和不斷增加的維護開銷為代價）！有趣的是，幾乎所有目前屬于Type 3的項目都計劃最終成為Type 2或Type 1 rollup，以提高其與以太坊的兼容性，并有可能不再需要開發(fā)自己的客戶端。

在去年的博文中，我主要關注了各zkEVM團隊如何設計他們的prover。今年，我想涵蓋各項目做法的其他重要方面，包括那些沒有被經常討論的事項（如各zkEVM執(zhí)行客戶端計劃）。例如，許多人認為L2是“排序器”（sequencer）和prover，而標準的zkEVM設計實際上看起來更像是這樣！

還有其他的排序器設計（我們將在后面討論），但大多數(shù)zkEVM目前都計劃運行一個單獨的區(qū)塊鏈作為L2排序器，具有自己的執(zhí)行客戶端（接收和執(zhí)行交易）和共識客戶端（就所有L2節(jié)點的交易順序達成共識）。

重要的是，修改標準以太坊客戶端來創(chuàng)建你自己的自定義鏈是有成本的。每次的以太坊客戶端更改（特別是每次硬分叉）都將是所有zKEVM團隊的治理決策項。自定義的部分越多，進行上游變更就越困難。隨著時間的推移，很容易產生zkEVM異步——在某個點上與以太坊匹配的zkEVM將迅速失去同步。

1、zkEVM項目狀態(tài)

那么，我們去年探討的那些項目怎么樣了？

（1）Polygon zkEVM（以及Polygon CDK鏈）

Polygon zkEVM于2023年3月在主網上線，迄今已處理了近1000萬筆交易。它目前屬于Type 3類型，目標是在2024年的某個時候成為Type 2。

當然，作為Type 2/3，Polygon zkEVM需要有屬于自己的自定義客戶端實現(xiàn)。Polygon選擇從頭開始構建自己的客戶端（zkevm-node）以獲取兼容性，但這個新客戶端發(fā)生過停機事故，并且缺少許多標準以太坊客戶端所具有的功能。

為了彌補這一點，Polygon與gateway.fm合作修改Erigon（以前的turbo-geth）以支持Type 2/3 prover所需的更改。這將為Polygon zkEVM提供一個更穩(wěn)定的基礎層和更優(yōu)化的性能，盡管保持與上游Erigon的兼容性仍然是一個持續(xù)挑戰(zhàn)。

許多團隊也宣布將使用Polygon鏈開發(fā)工具包（CDK）構建zkEVM，包括Astar、OKX和Palm Network。Polygon CDK的愿景是支持開發(fā)人員按照自己的需求，通過結合使用不同的客戶端、prover和數(shù)據可用性解決方案來構建自己的自定義鏈（即構建自己的zkEVM工具包）。如今，CDK支持一個客戶端實現(xiàn)（zkevm-node）和一個prover（Polygon zkEVM）。未來，Polygon團隊計劃向CDK添加更多的客戶端實現(xiàn)（例如Type-2-Erigon）和prover（例如Polygon Zero）。

這意味著你今天就可以部署你自己版本的Polygon zkEVM！但是，任何使用zkevm-node進行部署的團隊將來都可能需要遷移到其他客戶端，所以可能希望在準備好后再遷移。

我們還應該注意到，Polygon正計劃將Polygon PoS（世界上最大、最成功的區(qū)塊鏈之一）升級為一個具有鏈下數(shù)據的zkEVM，但具體升級時間表還未確定。

（2）Scroll

2023年Scroll上線了兩個測試網和一個主網（10月）——這是大型建設之年！Scroll目前是一個Type 3 zkEVM，之前他們曾表示打算在未來轉為Type 1/2，具體時間尚不明確。他們有一個與以太坊的差異列表，表里包含了一些未實現(xiàn)的預編譯和一些微小的狀態(tài)修改。Scroll的客戶端是Geth v1.10.13的一個分叉，目前在單排序器模式下運行。值得注意的是，Scroll的執(zhí)行客戶端的某些部分已經落后于上游以太坊兩年（盡管他們已經選擇了上海執(zhí)行客戶端的EIPs來減少應用層偏差）。這不會對鏈造成任何直接的破壞，但卻表明了許多項目將面臨治理挑戰(zhàn)，需要確定與上游以太坊長期保持多近的距離，以及需要多少工程努力才能不斷縮小這一差距。

（3）Immutable zkEVM

7月份以來，Immutable zkEVM已經有了一個公共測試網，并計劃在1月上線主網。Immutable zkEVM使用標準go-ethereum客戶端版本，該版本已針對我們的核心領域（游戲）進行了定制。有趣的是，Immutable zkEVM是目前本文探討的唯一一個特定域（domain specific）zkEVM，盡管L2能夠根據特定領域的要求進行定制同時保持以太坊的安全性是它們的一個主要吸引力。例如，Immutable zkEVM滿足于使用validium數(shù)據可用性來降低成本，并選擇了單塊最終性PoSBFT設計來提供近乎即時的確認，這些決策可能并不適合通用鏈。此外，如果大量的游戲和游戲用戶涌向這條鏈，可能會產生網絡效應——我們預計未來會出現(xiàn)更多的特定域L2。

然而，該鏈的發(fā)布不會提供prover支持。這是因為Immutable zkEVM計劃在Type 1 Polygon Zero證明程序可用且具成本效益時再采用。Immutable發(fā)布Type 3的唯一方法是對客戶端進行實質性更改，考慮到客戶端偏離以太坊的影響，我們不愿意這樣做。如今，Polygon Zero由Plonky-2提供支持，Plonky-3正在積極開發(fā)中，預計在2024年中后期達到生產級，屆時性能將提高約一個數(shù)量級。這將為Polygon提供兩個獨立的prover（Polygon Zero和Polygon zkEVM），開發(fā)人員將能夠在他們基于CDK的鏈中選擇使用哪個prover。

（4）Linea

Linea在8月份發(fā)布了他們的主網，并采用了與Polygon/Scroll類似的方式：從Type 3 rollup開始，逐漸轉為Type 1或Type 2型。Linea目前與以太坊London只有若干不同之處，如表中所示。

Linea正在使用他們自己更新的Geth版本，他們將其命名為“zkGeth”。值得注意的是，這個客戶端的源代碼不是開源的，prover也不是開源的——用戶無法驗證它們是否按預期運行。他們計劃將所有這些組件開源，作為他們文檔完備的去中心化路線圖的一部分。Linea的文檔表明，他們計劃從“zkGeth”轉為linea-besu，這是對Consensys開發(fā)的Besu客戶端的更新版本。從中期來看，Linea團隊計劃合并linea-besu和常規(guī)besu，并依靠Besu的插件系統(tǒng)來進行必要的狀態(tài)修改，以成為一個Type 2 zkEVM。

（5）Taiko

Taiko正在打磨他們的第五個測試網，計劃明年上線主網。Taiko正在開發(fā)他們自己的基于PSE實現(xiàn)的zk prover（與Scroll類似）。有趣的是，Taiko是本文中唯一一個目前不考慮將單個排序器逐步去中心化為一個L2區(qū)塊鏈這種設計模式的團隊。Taiko的設計基于Justin Drake所描述的Based Rollup概念——而不是擁有一個經許可的validator（驗證者/器）集，任何人都可以向以太坊L1提交交易包和證明。這種實現(xiàn)意味著rollup將排序完全委托給了以太坊L1，允許它自動繼承以太坊L1的活躍度和去中心化特性。然而，它存在一個重要的缺點：L2排序器不會提供“快速最終性”確認，也就是說用戶等待交易確認的時間更長。Justin Drake提出了“Based preconfirmations（預確認）”機制，以提供延遲僅為100ms的概率確認，但是還沒有接近生產水平，并且引入一個單獨的“preconf（預確認）承諾”和“preconf tips”系統(tǒng)可能會對現(xiàn)有的以太坊工具產生影響。這是一個活躍的研究領域！

Taiko從一開始就表示他們計劃成為Type 1 zkEVM。他們認為，其他zkEVM帶來的兼容性差異將比更高昂的證明生成成本還要糟，無論如何，隨著技術的進步，成本終將會下降。Taiko的客戶端實現(xiàn)很有趣——核心的“執(zhí)行客戶端”是經過修改的Geth v1.13 (taiko-geth)。然而，他們也在維護自己的“共識客戶端”(taiko-client)，它處理與L1的通信并監(jiān)控based排序過程。

（6）zkSync Era

zkSync Era于2023年3月發(fā)布，到目前為止可謂是成功的，即將進行空投的傳言將其TVL推高至5億美元以上。zkSync是Type 4 zkEVM，他們正在證明自己的自定義VM (eraVM)，而不是試圖直接修改EVM。他們的目標是與以太坊進行“語言級兼容”，并提供了一個從Solidity代碼到他們的自定義VM的直接編譯器。他們對許多關鍵EVM操作碼的實現(xiàn)進行了實質性的更改，對編譯過程也進行了一些更改，所以開發(fā)人員常常需要修改他們的合約或部署腳本才能在zkSync Era上進行部署。

zkSync Era有自己的自定義客戶端，允許他們實現(xiàn)非EVM功能，如原生帳戶抽象。2023年7月，他們將prover升級為“Boojum”，這是一個STARK證明系統(tǒng)，然后用SNARK包裝進行鏈上驗證，類似于Polygon zkEVM。zkSync Era需要完全鏈上數(shù)據，但他們計劃在未來引入“zkPorter”，這將允許用戶在不同價位的不同數(shù)據可用性模式之間進行選擇，與StarkWare提出的Volition模型類似。

（7）StarkNet

StarkNet是以太坊生態(tài)系統(tǒng)中最雄心勃勃的項目之一：他們正在從頭開始構建一個Type 4 rollup和生態(tài)系統(tǒng)，其中包括一個新的VM (CairoVM)、一個新的編程語言(Cairo)、一個新的prover (Stone)和新的客戶端（Pathfinder、Papyrus、Juno）。StarkNet在2021年和2022年逐步開放，現(xiàn)在擁有超1.5億美元的TVL，月處理交易量超1000萬筆。

從頭開始構建新生態(tài)系統(tǒng)是極具挑戰(zhàn)性的，但也為EVM一直在努力的領域（例如原生賬戶抽象）提供了根本性創(chuàng)新的機會，并大幅提高了性能。該工具鏈的大部分已經通過基于StarkEx的項目（如Immutable X、dydx v3和Sorare）完成了廣泛測試，這些項目自2020年以來一直在運行，并已被廣泛采用。

最初，StarkNet生態(tài)系統(tǒng)通過我去年提到的Warp Solidity→Cairo轉譯器等項目探索了語言級別的兼容性。然而，Warp現(xiàn)在已經過時了，而StarkNet生態(tài)系統(tǒng)已經決定完全致力于新的CAIRO工具集，而不再支持任何類型的Solidity向后兼容性?，F(xiàn)在，他們面臨著與Solana或Sui等非EVM生態(tài)系統(tǒng)相同的挑戰(zhàn)——你能讓大量開發(fā)人員采用你的新工具嗎？還是普遍存在EVM會勝出？

Kakarot團隊正在做的工作是唯一的一個例外，他們正在使用CAIRO語言開發(fā)一個Type 2.5 EVM，將作為運行在StarkNet上的一組合約。通過Kakarot，用戶將能夠部署在StarkNet上擁有代碼/狀態(tài)的EVM合約并與之交互，允許用戶從StarkNet的性能中受益，同時保留EVM兼容性。由于底層執(zhí)行環(huán)境仍將是StarkNet，這將犧牲以太坊工具的兼容性——但對于某些項目來說，這可能是一個可以接受的權衡。Kakarot還沒有達到生產級別，這種分層方法的性能和工具兼容性的影響還不清楚，但這是一個令人興奮的嘗試，可以彌合各種zkEVM類型之間的差距，也表明我們在探索設計空間方面行動很早。

（8）Optimism

由于顯而易見的原因，Optimism通常被認為是一個專注于optimistic rollup的團隊。然而，他們一再表示計劃支持zk零知識證明作為未來的一種選擇，并且已經與幾個積極貢獻的團隊進行了熱烈討論。像zeth這樣令人興奮的zk生態(tài)項目現(xiàn)在提供Optimism區(qū)塊支持。然而，我們還沒有看到任何正式的時間表或設計——也許在明年的zkEVM回顧中會有令人興奮的變化！

正如你所見，各個kEVM團隊之間的做法有很大的差異。即使是同一種類型的rollup也經常采用與其prover、客戶端和排序機制截然不同的設計。

還有另一種非常重要的方法來比較這些新的zkEVM——它們的實際配置！一般來說，分析各鏈的客戶端和prover的體系結構要更加有趣，因為涉及到根本的設計決策，而不是可以輕松更改的應用級配置。然而，如果你是一個應用程序開發(fā)人員，具體配置無疑是很重要的，所以一定要確保你研究了每個zkEVM的區(qū)塊時間、區(qū)塊gas限制、證明發(fā)布頻率、排序器共識機制以及任何可能影響應用程序用戶體驗的因素！

綜上所述：2023年，各種各樣的團隊進行了大量的開發(fā)工作。所以，如果一切正在進展中，我們是否只需要靜靜等待？我們還需要解決什么問題，才能看到zkEVM獲得實質性的關注度？

2、zkEVM開發(fā)中還有哪些懸而未決的問題？

首先，客戶端和prover之間缺少標準化接口。目前，每個prover僅與最初構建它們時所用的客戶端兼容。你無法在任何其他Type 2/3客戶端上使用Polygon zkEVM的prover。理想情況下，任何新的prover或客戶端都應該與盡可能多的現(xiàn)有prover/客戶端兼容。鼓勵各種zkEVM團隊遵循單一接口的EIP是未來發(fā)展的關鍵一步。

可以理解的是，大多數(shù)團隊目前都在優(yōu)先改進自己的部署，而不是尋求與他人的兼容性。目前這種做法可能是可以接受的，但最終我們尤其希望L2排序的zkEVM可以使用多客戶端/prover設置，以減少重大bug風險。此外，標準化“經典”type 2功能的實現(xiàn)（例如Sparse默克爾樹、Poseidon哈希函數(shù)而非keccak）可能有助于多個prover使用相同或相似的客戶端。減少“geth”類客戶端的數(shù)量將是該生態(tài)系統(tǒng)的巨大勝利！一項名為“RollCall”的標準化倡議已被提出，同時還提出了一系列Rollup優(yōu)化建議（RIPs），雖然目前尚不清楚這一倡議的關注度有多高。

其次，這些zkEVM幾乎全都是單一排序器，是對這些rollup的去中心化和安全性的挑戰(zhàn)。尤其要注意，prover的行為只是為了確保L1-L2橋接是安全的。任何依賴于L2預確認的外部系統(tǒng)(如CEX)都將大量資金置于風險之中，因為它們完全依賴于單一排序器——對于今天的許多L2來說，極具破壞性的黑客攻擊只需要盜用一個排序器密鑰就可實現(xiàn)。然而，一旦你將排序器去中心化，就會出現(xiàn)不同的挑戰(zhàn)（正如你在上述Taiko內容中所見！）。你是否需要向L1提供一個zk證明，證明已經達成了L2共識？活躍度問題呢？MEV呢？大多數(shù)單一排序器rollup出于品牌/聲譽/鏈信任的原因目前都沒有利用MEV，但這種情況可能會在未來有所改變。

第三，沒有衡量zkEVM性能和成本的標準框架。本文的大部分內容都在比較各種zkEVM設計的潛在性能影響，但是目前很少有zkEVM團隊發(fā)布任何真正的性能規(guī)范或測試。“zkEVM成本”由以下幾部分構成：

·?生成證明的云計算成本（受電路效率影響）

·?驗證證明的L1成本

·?數(shù)據可用性成本

·?從一層向另一層發(fā)送信息的成本

我應該能夠為這些領域創(chuàng)建標準化測試，并將結果制成表格，以幫助建設者做出更明智的決策——目前這是不可能的。細微差別在這里：在某些類型的交易中，一些prover實現(xiàn)將比其他prover更佳，部分成本將取決于使用情況，因為能夠在交易包中分攤交易成本。這些成本應該如何呈現(xiàn)給用戶也是一個很大的不確定性（例如，Immutable zkEVM計劃在大多數(shù)情況下為用戶支付發(fā)布成本，而Scroll則有一個復雜的L1 + L2收費設置，以確保每筆交易都是盈利的）。此外，許多zkEVM可能會遇到與狀態(tài)增長相關的性能問題——擴展以太坊區(qū)塊空間不是免費的！所有這些都需要比現(xiàn)在更高的可衡量性/可比性。

第四，對于大多數(shù)智能合約rollup而言，退出機制仍然沒有被很好地理解和定義。自我托管在特定應用rollup（如Immutable X）上被很好地定義——你存放到該L1橋中的任何資產都應該是可檢索的，即使排序器完全脫機或完全是惡意的。這通常被稱為“逃生艙口”。但這在智能合約rollup的情況下意味著什么呢？如果你的ETH質押在一個合約中，無論如何都不應可用呢？這一切都是關于抗審查性嗎（我們需要保證強制交易的能力嗎）？對于用于不同目的（例如游戲資產與DeFi）的zkEVM來說，什么程度的數(shù)據可用性是可接受的？我們需要一致的框架向用戶傳達實際的故障情況——L2 Beat在這方面開了個好頭！

第五，zkEVM與以太坊L1之間的關系尚不明晰。在撰寫本文期間，我再一次被V神發(fā)布的一篇反思“enshrined zkEVM”的博文所吸引。主要內容是以太坊客戶端層可以“enshrined” zk prove實現(xiàn)，可用于驗證其他來源（例如L2）提交的EVM區(qū)塊的執(zhí)行情況。這就避免了讓所有L2 zkEVM都必須保持他們的zkEVM prover是最新的（重大勝利！）——他們可以依靠其他團隊的工作成果，包括核心以太坊客戶端團隊，一個完全SNARK的以太坊已成為現(xiàn)實。那么，我是否應該將“enshrined zkEVM”的提議解讀為偏離以太坊以L2為中心的擴展路線圖，將L2捕獲的價值帶回？

不完全是這樣。L2仍然需要自己的排序器來提供快速確認（在游戲等領域至關重要），而V神提出的設計只支持具有完全鏈上數(shù)據的zkEVM。出于變現(xiàn)等原因，大多數(shù)L2幾乎都希望保持獨立性，這對以太坊生態(tài)系統(tǒng)來說是一個重要的權衡。L2對于以太坊區(qū)塊空間的擴展至關重要，但他們的動機（和BD團隊）可能并不總是與以太坊對齊。

最后，多個zkEVM將繼續(xù)分散用戶和流動性，致使用戶體驗很糟。如今，每多一個以太坊L2將繼續(xù)分散狀態(tài)和流動性——如果你在Arbitrum上有2枚ETH，那么在任何其他L2上訪問ETH都是有難度的。在我看來，這是迄今為止對單體鏈的最佳論證，在單體鏈中，可組合性得到了極大改善，用戶不必在多個鏈之間進行平衡。隨著當前“L2工具包”（例如Polygon CDK、Arbitrum Orbit、OP Stack）流行開來，啟動鏈從未如此輕松，但代價是更大程度的碎片化問題。

為了使這種多L2模型取得長期成功，在大多數(shù)情況下，我們需要將單個鏈和平衡從用戶中抽象出來。這是有效性證明優(yōu)于欺詐證明更有力的論據之一——快速鏈間橋接的即時性證明驗證。然而，即使有了強大的橋接/互操作性框架，仍然有大量的用戶體驗問題需要解決。在Immutable，我們的計劃是通過錢包層的Immutable Passport和垂直整合和來解決這個問題。