指南：清晰理解zkEVM、EVM 兼容性和Rollup

ZK-Rollup一直被認為是以太坊擴展的終極目標。然而，儘管它對以太坊的擴展路線圖來說是很重要，但在幾個關鍵點上仍然存在不確定性：

• ZK-Rollup到底是什麼?

• 特定於應用程序的Rollup和通用Rollup之間有什麼不同?

• 什麼是zkEVM Rollup?像EVM等效和EVM兼容這樣的術語實際上是什麼意思，它們如何應用於Rollup?

• ZK-Rollup生態系統的當前狀態是怎樣的，這對項目意味著什麼?

如果你是一名希望了解以太坊擴展下一階段的開發人員，本文將(希望)對你有所幫助。

ZK-Rollup

ZK -Rollup是這樣實現的：像STARK或SNARK這樣的證明系統允許用亞線性處理來驗證線性數量的語句(例如，1000個語句→10個驗證者檢查，10,000個語句→11個驗證者檢查)。我們可以使用這個屬性來創建可大規模擴展的區塊鏈交易處理上，如下所示：

• 用戶將他們的資產鎖定在L1上的ZK-Rollup智能合約中；

• 用戶將涉及這些資產的交易提交給L2的sequencer，L2的sequencer將它們收集成有序的批次，並為每個批次生成有效性證明（例如STARK/SNARK）和聚合狀態更新；

• 這個狀態更新和證明會提交給我們的L1的ZK-Rollup智能合約並進行驗證，它會用於更新我們的L1狀態；

• 用戶可以使用這種L1狀態(根據不同的數據可用性機制)來檢索他們的資產，從而實現完全的自我託管和“以太坊安全”。

驗證證明的gas成本與被驗證交易的數量呈次線性關係，與直接使用L1相比，它可以呈現更大的規模。

特定於應用程序的Rollup

到目前為止，所有生產級ZK-Rollup都是我們所說的“特定於應用程序的Rollup”。在特定於應用程序的Rollup中，Rollup支持由Rollup運算符定義的固定數量的“狀態轉換”(例如交易)。例如：

• Loopring—支付和交易

• Immutable —NFT鑄造，交易，遊戲

• dydx—永續合約交易

如果你需要解決的是一個項目的需求，那麼就可以通過特定於應用程序的Rollup來滿足，你的用例可能會獲得更好的性能、更好的用戶體驗和更好的價格，因為它們缺乏通用性是一個巨大的優勢。例如，在Immutable，我們可以通過補貼免費的NFT鑄造，在NFT交易中收取一定的費用來取消gas費用——這種權衡之所以可能是因為Rollup狀態轉換的可預測性。

然而，許多項目希望能夠創建自己的自定義邏輯和智能合約，獨立於Rollup的運營商，這在特定於應用程序的Rollup中是不可能的。此外，許多DeFi項目需要“可組合性”，或需要有與其他項目交互的能力(例如，許多DeFi項目使用Uniswap作為價格預言機)。只有當你的Rollup不僅支持自定義代碼，而且支持任何用戶都可以部署的原生智能合約時，可組合性才有可能實現。為了實現這一點，我們需要修改ZK-Rollup的體系結構，以囊括每個組件。

為了提高靈活性，需要做一些考慮和權衡：性能大幅下降、Rollup參數的可自定義性降低和費用增加。然而，其最大的缺點是沒有實現通用ZK-Rollup。但這種情況已經開始改變：

• StarkNet目前在主網上（儘管處於Alpha 階段）。

• 3個獨立的項目（zkSync, Polygon Hermez/zkEVM和Scroll）都在ETH CC 2022上宣布，它們將成為第一個到達主網的“zkEVM”。

這些公告是值得深入研究的，因為這些團隊不僅宣布了通用Rollup，他們還宣布了“zkEVM”。隨之而來的是Twitter上關於“EVM兼容性”、“EVM等效性”、“真正的zkEVM”以及哪種方法更好的爭論。對於應用程序開發人員來說，這些爭論常常是噪音——所以本文的目的是分析這些術語、設計決策和理念，並解釋它們對開發人員的實際影響。

什麼是EVM?

以太坊虛擬機是執行以太坊交易的運行環境，最初在以太坊黃皮書中定義，後來被一系列以太坊改進提案(eip)修改。它由以下部分組成：

• 用於執行程序的標準“機器”，每個交易都有易失的“內存”，交易可以寫入的持久“存儲”和一個可操作的“堆棧”。

• 在這個機器中執行狀態轉換的140個定價“操作碼”。

虛擬機的一些操作碼示例：

• 堆棧操作：PUSH1(向堆棧中添加內容)

• 算術操作：ADD（加數字），SUBTRACT

• 狀態操作：SSTORE(存儲數據)，SLOAD(加載數據)

• 交易操作：CALLDATA， BLOCKNUMBER(返回當前執行交易的信息)

一個EVM程序就是一系列操作碼和參數。當這些程序被表示為一個連續的代碼塊時，我們稱其結果為“字節碼”(通常表示為十六進製字符串)。

通過將大量這樣的操作碼組合成一個執行序列，我們可以創建任意的程序。以太坊使用自定義虛擬機，而不是去適應調整現有的虛擬機，因為它有獨特的需求：

• 每個操作都必須有防止濫用的“成本”(因為所有節點都運行所有交易)。

• 每個操作都必須是確定性的(因為所有節點必須對交易執行後的狀態達成一致)。

• 我們需要區塊鏈特定的概念(例如智能合約、交易)。

• 一些複雜的操作必須是原語(例如密碼學)。

• 交易必須沙箱化，沒有I/O或外部狀態訪問。

EVM是2015年發布的第一個圖靈完備區塊鏈VM。它有一些設計上的限制，但其巨大的先發優勢和隨後的廣泛採用為以太坊提供了差異化——它是目前為止在整個領域中最久經考驗的智能合約基礎設施。

由於以太坊的主導地位，許多後來的區塊鏈都直接採用了這種運行環境。例如，Polygon和BNBChain是以太坊的直接分叉。值得注意的是，EVM並不是一成不變的，並且經常在EIP-1559等升級中進行修改。由於其他區塊鏈需要時間更新，或在多個地方與以太坊不同，所以它們通常運行的是略微過時的EVM版本，可能難以跟上變化的步伐——這一事實可能會讓以太坊核心開發人員感到沮喪。

以太坊兼容性

然而，人們所說的“EVM鏈”通常不僅僅是對這個運行環境的鏡像。有幾個主要的規範開始於以太坊，並已成為事實上的全球標準：

• Solidity（可編譯為EVM字節碼的高級語言）

• 以太坊的JSON-RPC客戶端API（與以太坊節點交互的規範）

• ERC20/ERC721（以太坊代幣標準）

• ethers . js（以太坊接口的web庫）

• 以太坊的密碼學（例如keccak256作為哈希函數，secp256k1上的ECDSA簽名）

從技術上講，你的鏈可能有一個EVM 運行環境，卻不支持上述部分或全部。然而，遵守這些標準會使你在新鏈上使用以太坊工具變得更加容易。一個很好的例子就是Polygon，它除了使用上述所有工具之外，還能夠運行一個分叉版本的Etherscan (Polygonscan)，使用像Hardhat這樣的以太坊開發工具，並在像Metamask這樣的錢包中作為不同的以太坊“網絡”被支持。像Nansen和Dune這樣的工具最初都是針對以太坊的，因此添加對新的EVM區塊鏈的支持很簡單。新的錢包，新的NFT市場——如果以太坊的接口和你的鏈的接口之間的唯一區別是鏈ID，那麼你有可能是第一個，並且是以最輕鬆的方式進行添加的人。也就是說，這些工具是為以太坊構建的。一旦你開始修改自己的區塊鏈(例如，更大的區塊，更快的區塊時間)，你就需要冒著破壞它們的風險。這裡沒有所謂的完美匹配。

當涉及到開發人員工具時，任何不支持上述規範的區塊鏈都會被自動落下，並且隨著EVM生態系統的發展有進一步落後的風險。

我認為，“EVM兼容”這個術語實際上不足以描述這裡所說的網絡效應，我們實際上描述的是“以太坊兼容”，它遠遠超出了智能合約執行環境，已經擴展到了整個以太坊生態系統和工具集。

為了解決這個問題，像Solana這樣的非EVM區塊鏈不得不創建完全平行的生態系統，這就降低了它們的速度，使其更難吸引現有的開發者。然而，不需要遵守這些標準確實使非EVM 區塊鏈能夠對以太坊工具集進行更根本的更改，從而更積極地將自己與以太坊區分開來。創建一個EVM區塊鏈非常簡單，但為什麼有人會使用你的而不是數以百計的其他“快速EVM區塊鏈”呢? 如果能克服需要建立一個成功的平行鍊和生態系統的困難，那麼Solana的情況已經表明，a) 你可以吸引出色的應用程序（如MagicEden, Phantom）， b) 如果商業激勵充足，源於EVM的項目仍然會支持你（如Opensea增加對Solana的支持）。

zk-EVM

通用Rollup都有一個共同的目標：讓開發人員和用戶以盡可能快的速度產生網絡效果。這就需要創造性能最好的Rollup技術，擁有最好的BD團隊和最有效的營銷，三者缺一不可。然而，所有Rollup團隊(基於上述原因)都深切關注：

• 將現有的以太坊合約(和開發人員)遷移到他們的Rollup中。

• 支持現有的EVM工具(例如庫、錢包、市場等)。

實現這兩個目標的最簡單方法是創建一個“zkEVM”：一個通用的Rollup，它將EVM作為智能合約引擎運行，並保持與上述以太坊生態系統的通用接口的兼容性。

然而，這並不像分叉Geth，或創建一個新的L1區塊鏈那樣容易。我們的目標是運行EVM字節碼——但是ZK證明需要將它們要證明的所有計算語句轉換成一種非常特定的格式——一種“代數電路”，然後再將它們編譯成STARK或SNARK。

這種更深層次的理解對於我們的目的來說並不是必要的——只要記住，為了支持EVM計算，我們必須將所有的EVM程序轉換成這些電路，以便稍後驗證它們。

一般來說，有以下幾種方法：

• 通過將其轉換成可驗證的電路，直接證明EVM的執行跟踪。

• 創建一個自定義VM，將EVM操作碼映射到該VM的操作碼上，然後證明該自定義環境中跟踪的正確性。

• 創建一個自定義VM，將Solidity轉換為自定義VM的字節碼(直接，或者通過自定義高級語言)，並在自定義環境中進行驗證。

選項1：證明EVM執行跟踪

Scroll

讓我們從最直觀的開始：證明EVM執行跟踪本身，這是目前由Scroll團隊研究的一種方法。為了實現這一目標，我們需要:

• 為一些密碼累加器設計一個電路(允許驗證我們正在準確讀取存儲並加載正確的字節碼)。

• 設計一個電路來連接字節碼和實際的執行跟踪。

• 為每個操作碼設計一個電路(允許我們證明每個操作碼讀寫和計算的正確性)。

在電路中直接實現每個EVM操作碼是具有挑戰性的，但這種方法會準確地反映EVM，因此它在可維護性和工具支持方面有顯著優勢。下圖顯示了Scroll和Ethereum之間，唯一理論上的區別——實際的運行環境。值得注意的是，Scroll目前並沒有通過這種機制支持所有的EVM操作碼，儘管他們打算隨著時間的推移進行改善。

Optimism團隊曾對此進行了精彩的討論，雖然他們的討論是在Optimistic Rollup的背景下展開的。 Optimism最初創建了一個自定義的Optimistic虛擬機(OVM)作為它們Rollup的執行環境。 OVM是“兼容以太坊”的，這意味著它可以運行修改過的Solidity代碼，但一些不匹配的領域的存在，使得以太坊工具和復雜的代碼經常需要被重新編寫。因此，Optimism轉向了“EVM等效”，直接使用確切的EVM規範，並正在開發第一個與EVM等效的欺詐證明系統。然而，Optimistic Rollup不需要擔心電路或驗證者效率。

但是，EVM的核心基礎設施不太適合ZK-Rollup。 Rollup性能的一個核心衡量標準是我們需要將特定計算編碼到電路中所需的“約束”數量。在許多情況下，鏡像EVM會直接帶來巨大的開銷。例如，EVM使用256位整數，而ZK證明在素數字段上才會最自然地工作。引入範圍檢查以對抗不匹配的字段算術為每個EVM 步驟增加了約100 個約束。以太坊的存儲佈局嚴重依賴於keccak256，它的電路形式比對STARK友好的哈希函數(如Poseidon, Pedersen)大1000倍——但替換keccak將會對現有的以太坊基礎設施造成巨大的兼容性問題。此外，與SNARK/STARK友好限額橢圓曲線相比，標準以太坊橢圓曲線上的簽名在證明和驗證上都非常昂貴。簡單地說，直接證明EVM會帶來巨大的計算開銷。雖然最近在這方面有了一些進展(例如多項式承諾、遞歸證明、硬件加速)，但證明EVM跟踪的效率要遠遠低於在自定義設計的VM中進行的證明，至少在EVM本身做出改變變得對SNARK更友好之前(可能需要幾年時間)。

選項2：自定義VM+操作碼支持

這種實現促使團隊採用上面所述的“與EVM兼容”的方法：創建具有優化性能的自定義VM，然後將EVM字節碼直接轉換為用於VM的字節碼。

Polygon

Polygon Hermez(最近更名為Polygon zkEVM)便是一個專注於此方法的團隊。 Polygon的方法是構建一個zkEVM（操作碼級別的等效），這聽起來與Scroll所採取的方法很相似。然而，與Scroll不同的是，Polygon的備用運行環境(“ZKExecutor”)運行自定義的“zkASM”操作碼而不是EVM操作碼，以試圖優化EVM解析(即減少約束的數量和直接證明EVM)。 Hermez團隊將其描述為“基於操作碼的方法”，其核心挑戰是在他們的自定義VM中重新創建每個EVM操作碼，這樣他們就可以快速地從EVM字節碼轉換為可驗證的格式。

這些中間步驟增加了維護和潛在bug的“表面積”。最後，重要的是要清楚，你的程序不是運行在電路中鏡像EVM的zkEVM中，它們在備用的“ZKExecutor”運行，這與EVM本身類似但又不同。

因此，雖然大多數Solidity代碼可以正常運行，但會有一些不兼容運行在該系統上的現有L1應用程序和工具的情況。 Polygon宣稱“與現有的以太坊工具100%兼容”，並承諾遵守JSON-RPC。在實踐中，這種說法可能是比較理想化的，依賴於以太坊本身的東西將變得對SNARK 更加友好。

Polygon的方法比Scroll的Rollup性能更好(至少在短期內是這樣)，但有:

• 更多的自定義代碼，因為我們需要創建zkASM。

• 開發人員可能需要修改他們的L1代碼或工具框架。

• 隨著時間的推移，可能與以太坊偏離。

選項3：自定義VM + 轉譯器

上述解決方案在“使EVM為ZK-Rollup工作”上投入了大量的開發時間，將兼容性置於長期性能和可擴展性之上。還有另一種選擇：創建一個全新的、專門構建的VM，然後在上面添加對以太坊工具的支持以作為附加層。

StarkNet

這就是StarkWare在StarkNet上所採取的方法，StarkNet是目前進展最快的通用Rollup。 StarkNet運行一個自定義的智能合約VM (Cairo VM)，帶有自己的底層語言(Cairo)，兩者都是為智能合約Rollup而構建的。這意味著StarkNet沒有現成的以太坊兼容性——正如我們之前看到的，即使是操作碼級別的VM級別兼容性也是Rollup性能的潛在“手剎”。

然而，Nethermind團隊(與StarkWare合作)已經創建了Warp轉譯器，它能夠將任意的Solidity代碼轉換為Cairo VM字節碼。 Warp的目標是將普通的Solidity合約移植到StarkNet上——這會實現許多以太坊開發者在“EVM兼容性”方面的主要目標。然而，在實踐中，Warp 不支持一些Solidity 功能，包括低級調用。

這種構建智能合約Rollup的方法保持了“Solidity兼容性”：你不需要在EVM內部執行程序，也不需要保持與任何其他以太坊接口的兼容性，但Solidity開發人員將能夠編寫可用於你的Rollup的代碼。因此，你可以保持與以太坊類似的開發人員體驗，而不必犧牲自己的基礎層。

然而，這種方法還有幾個需要考慮的方面。首先，構建自己的VM是具有挑戰性的——以太坊團隊已經有超過五年的時間來解決EVM的問題，並且仍然經常進行升級和修復。更自定義的Rollup可以獲得更好的性能，但同時也將失去其他所有鍊和Rollup對EVM所做的集體改進帶來的好處。

其次，通過轉譯器來支持Solidity會有潛在損失可組合性的風險——如果開發人員同時使用CAIRO和Solidity編寫合約，那麼支持兩者之間接口的工具很可能會非常容易受攻擊。到目前為止，絕大多數的StarkNet項目都直接使用了CAIRO，它們可能不容易與未來的Solidity項目組合在一起。最後，可能也是最重要的一點是，StarkNet團隊目前的目標並不是與其他以太坊組件兼容——他們正在開發自己的客戶端API、javascript庫和錢包系統，這將迫使兼容以太坊的工具手動添加對StarkNet的支持。這非常具有挑戰性，但並非不可能——正如上文所述，Solana已經足夠成功，其自定義標準受到一些以太坊工具的尊重。

然而，如果他們能成功做到這一點，StarkWare團隊將著眼於復制EVM的先發優勢，並使用首個針對ZK-Rollup進行優化的智能合約VM。

zkSync

另一個採用這種策略的團隊是zkSync。 zkSync創建了自己的VM (SyncVM)，它是基於寄存器的，並定義了自己的代數中間表示(AIR)。然後，他們構建了一個專門的編譯器，將Yul(一種中間語言，可以編譯成針對不同EVM版本的字節碼，比如較低級別的Solidity)編譯成LLVM-IR，然後再將LLVM-IR編譯成用於自定義VM的指令。這類似於StarkWare所採取的方法，但它們在基礎語言上提供了更多的靈活性（儘管目前僅支持Solidity 0.8.x）。 zkSync團隊最初創建了他們自己的類似於Cairo的語言(Zinc)，但是他們將主要精力集中在了Solidity編譯器上，以便L1開發人員能夠更簡單地進行遷移。

zkSync利用這個自定義VM來提供非EVM兼容的功能，比如帳戶抽象(Account Abstraction)，這一直是以太坊核心協議的一個目標。

綜上所述，你可以清楚地看到每個團隊遵循的不同策略:

Vitalik的zkEVM類型

Vitalik Buterin在關於zkEVM的博客上強調了Rollup團隊目前面臨的基本困境：EVM不是為“可驗證”程序構建的。事實上，正如我們通過上面的分析所展示的，越是尋求與以太坊的高兼容性，程序在“可驗證格式”中的性能就會越低。根據與現有EVM基礎設施的兼容性程度，Vitalik確定了通用Rollup的幾大類別：

我想對他的論點做的唯一擴展是，在每個“類型”中也存在著顯著程度的可變性——我們處理的是一個範圍，而不是完全細分的類別。從開發人員的經驗來看，對應用層進行單個小更改的Type 3 Rollup比對應用層進行大規模更改的Type 2 Rollup更常見，但在技術上沒有引入新的VM並成為Type 4。

智能合約Rollup的當前狀態

沒有ZK-Rollup能完美地反映EVM在所有情況下的行為——這完全是程度的問題，當涉及可維護性和性能(而不僅僅是兼容性)時，每個團隊所做的具體選擇將是最重要的。我認為以下定義是最清晰、最一致的：

重要的是要明白，以上這些方法都不是“天生王者”——它是一種分類，而不是一種等級。它們都做出了不同的權衡：更容易構建、維護和升級，性能更高，更容易與現有工具兼容。最終，領先地位也將由更好的分銷和營銷決定，而不是純粹的技術能力。話雖如此，做出正確的基本技術決策無疑具有很大的優勢。 Scroll對EVM規範的熱忱承諾是否能讓他們輕鬆應對EVM的任何升級?另一個團隊更務實的方法會幫助他們更快地進入市場嗎?StarkWare的自定義VM + 轉譯器方法會為長期發展奠定更堅實的基礎嗎?另一個團隊是否會從這個領域的先行者犯的錯誤中吸取教訓，並擊敗他們? 以太坊當前發展的美妙之處在於，我們有不同的團隊，用本質上不同的方法朝著一個共同的目標前進。

但在我們忘乎所以之前，我們也應該清醒地認識到智能合約Rollup的當前情況。每個團隊都有強烈的慾望將自己推銷為“即將接管世界”的項目——但最早要到2022年底，才會有“生產級”智能合約rollup在以太坊上，而其中許多團隊要到2023年才會準備好。

由於這種尚不成熟的狀態，特定於應用程序的Rollup仍然是開發人員在不影響以太坊安全性的前提下進行擴展的最佳選擇。我預計在可預見的未來，特定於應用程序Rollup的性能、自定義和可靠性仍將在某些用例(例如，交易所、NFT鑄造/交易)中保持卓越表現。

其他因素

儘管本文主要關注以太坊生態系統的兼容性與性能，但這些並不是關於他們的全部內容。還有許多其他因素會影響我們是否應該構建特定的通用Rollup。下面將提出幾個主要的附加標準：

• 費用：這些Rollup會以原生代幣，或ETH，或兩者的某種複雜組合收取費用嗎?費用結構對用戶和開發人員的體驗有巨大的影響，因為Rollup通常需要費用代幣來支付計算費用。

• 證明和排序：所有的Rollup都需要一個實體，該實體負責對交易進行排序和生成證明。今天，大多數特定於應用程序的Rollup都是“單sequencer”，它往往以彈性為代價產生更高的吞吐量。大多數通用的Rollup最初是作為單sequencer的Rollup，但他們通常有計劃隨著時間的推移將這個sequencer進行去中心化。

• 自我託管：ZK-Rollup的核心承諾是在保持以太坊安全性的同時擴大規模。然而，許多通用Rollup目前沒有明確的機制在發生惡意或出現不可用的sequencer時恢復用戶資產。

• 數據可用性：如介紹中所述，自我託管的保證取決於故障情況下狀態數據的可用性。然而，完全的數據可用性為用戶帶來了額外的成本，導致了一系列的數據可用模式。這已經廣泛應用於特定於應用程序的Rollup中（例如Validiums、Volitions），但每個通用Rollup都需要單獨添加此功能。

總結

智能合約Rollup是以太坊擴展路線圖中一個非常重要的部分。這些Rollup在與現有以太坊工具集的關係中做出了不同的權衡，這也證明了以太坊開發人員生態系統的多樣性。

然而，目前關於EVM兼容性的討論通常沒有抓住要點。從開發人員的角度來看，所有這些Rollup都將支持Solidity代碼。真正的以太坊兼容性是一個更大的挑戰，需要進行大量的考慮和權衡，開發人員在提交Rollup之前應該意識到這一點。目前，大多數Rollup項目都是大規模的“遠期銷售”，即銷售3年以上的願景，而不是今天(甚至是12個月)可能實現的目標，這可能會造成一定程度上的混亂。

為了提高透明度，我希望每個主要Rollup團隊都能對以下問題提供更清晰的答案：

• 在L1和L2運行時，它們的區別是什麼?哪些操作碼會在L2上被修改嗎?VM的其他特徵(例如費用結構)與L1有什麼不同嗎?

• 你的自定義VM的正式規範在哪裡?與其他選項相比，它的性能在哪裡更高/更低?

• 這次Rollup將對其他以太坊接口(例如客戶端API、庫)做出多少更改，這將破壞以太坊工具嗎?

• 這個Rollup什麼時候會在測試網上上線?在主網上嗎?能夠支持1000+客戶合約TPS的持續吞吐嗎?

• 你希望什麼時候支持用戶資產的完全自我託管?在通用Rollup的背景下，它將是什麼樣子的?

隨著合併即將到來，經過檢驗的特定於應用程序的Rollup在生產中，而通用Rollup將在明年沖擊主網，以太坊擴展的未來就在當下。

Source：https://immutablex.medium.com/ground-up-guide-zkevm-evm-compatibility-rollups-787b6e88108e