這篇「粉碎指南」你一定不可錯過...
譯文：基礎指南：zkEVM、EVM 兼容性和匯總（不可變 X）
編譯： Hakeen
修訂： Evelyn
ZK-rollup 長期以來被視為以太坊拓展性的終局。然而，儘管他們對以太坊拓展路線很重要，但在幾個關鍵點上仍有幾點不確定性：
- 到底什麼是 zk-rollup？
- 針對應用優化的 rollups 和通用 rollups 的區別是什麼？
- 什麼是 zk-EVM rollup？像 EVM 等效性和 EVM 兼容性等術語究竟是何意義，並且其如何適用於 rollups 的？
- Zk-rollup 生態系統的現狀如何，這對我的項目又意味著什麼？
如果你是一個希望了解以太坊擴展的下一階段的開發者，那希望這篇文章能對你有所幫助。
什麼是 zk-rollup？
Zk-rollup 的主要實現是：證明系統如 STARKs/sSNARKs，使用亞線性的處理流程來驗證線性的語句數量（例如，1000 個語句→ 10 個驗證人確認，而 10000 個語句只需要 11 個驗證人去確認），這個特性就能讓我們處理大量的區塊鏈交易流程：
- 用戶抵押其資產在 L1 的 zk-rollup 智能合約上
- 用戶提交包括這些資產的交易給 L2 的 sequencer，sequencer 把交易集合到有序的批次中，並且生成有效性證明，例如 stark/snark，最後更新狀態。
- 這個狀態更新和證明被提交給我們的 L1 zk-rollup 智能合約，並由其驗證，用於更新我們的 L1 狀態
- 用戶可以使用這個 L1 狀態（取決於不同的數據可用性機制）來檢索他們的資產，從而實現完全的自我託管和"以太坊安全性"
（簡化的 ZK-Rollup 架構）
在這裡，只要我們核實驗證的 gas 成本與交易規模呈現亞線性的關係，那麼就可以驗證更大規模的交易。要想更詳細地了解這個過程，我推薦 Vitalik 的 Incomplete Guide to Rollups 或 Delphi 新發布的 Complete Guide to Rollups。
針對應用優化的 rollups 和通用 rollups 的區別是什麼？
在特定於應用的 rollups 中，rollup 支持由 rollup 運算符定義的固定數量的狀態更改。這可以優化某些應用，如：
特定於應用程序的匯總非常適合擴展特定的、易於理解的問題。如果您作為項目的需求可以通過特定於應用程序的匯總來滿足，那麼您可能會為您的用例獲得更好的性能、更好的用戶體驗和更好的定價，因為它們缺乏泛化性是一個巨大的優勢。例如，在 Immutable，我們能夠通過補貼免費的 NFT 鑄幣廠和對 NFT 交易收取費用的轉賬來消除 gas 費用——這種權衡只有在 rollup 狀態轉換的可預測性質下才有可能。
但是，許多項目希望能夠創建自己的自定義邏輯和智能合約，獨立於匯總運算符，這在特定於應用程序的匯總中是不可能的。此外，許多 DeFi 項目需要 “可組合性”，或與其他項目進行原子交互的能力（例如，許多 DeFi 項目使用 Uniswap 作為價格預言機）。只有當您的匯總不僅支持自定義代碼，而且支持任何用戶可以部署的本機智能合約時，組合性才是可能的。為了實現這一點，我們需要修改 zk-rollup 的架構以概括我們的每個組件。
這種增加的靈活性有幾個權衡：性能大大降低，匯總參數的可定制性降低以及費用更高。然而，最大的權衡是根本沒有通用 zk-rollups 的實現，當然也沒有能夠生產量的實現。但這開始改變：
- StarkNet 目前在主網上運行（儘管處於有限的 Alpha 階段）
- 3 個獨立的項目 ( zkSync , Polygon Hermez/zkEVM 和 Scroll ) 都在 ETH CC 2022 上宣布它們將成為第一個進入主網的 “zkEVM”
這些最後的公告值得深入研究，因為這些團隊不僅宣布了通用匯總，他們還宣布了 “zkEVM”。隨之而來的是許多圍繞 “EVM 兼容性”、“EVM 等效性”、“真正的 zkEVM” 以及哪種方法更好而展開的大量推特爭論。
什麼是 zk-EVM？EVM 等效性和 EVM 兼容性術語的意義，並且其如何與 rollup 相結合？
理解虛擬機
以太坊虛擬機是執行以太坊交易的運行時環境，最初在以太坊黃皮書中定義，後來被一系列以太坊改進提案（EIP）修改。它由以下部分組成：
（圖來自 https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf）
我們的虛擬機的一些示例操作碼：
- 堆棧操作—— PUSH1（向堆棧添加一些內容）
- 算術運算—— ADD（加數字），SUBTRACT
- 狀態操作—— SSTORE（存儲數據），SLOAD（加載數據）
- 事務操作—— CALLDATA、BLOCKNUMBER（返回有關當前執行事務的信息）
EVM 程序只是一系列這些操作碼和參數。當這些程序被表示為一個連續的代碼塊時，我們將結果稱為 “字節碼”（通常表示為一個長的十六進製字符串）。
通過將大量這些操作碼組合成一個執行序列，我們可以創建任意程序。以太坊使用自定義虛擬機，而不是調整現有的 VM，因為它有獨特的需求：
- 每一個操作都必須有 “成本” 來防止濫用（因為所有節點都運行所有的交易）
- 每一個操作必須確定（因為所有節點都將同意更改後的狀態）
- 我們需要專門針對區塊鏈的概念（如智能合約，交易）
- 一些複雜操作需要成為原語（如密碼學）
- 交易必須是沙盒的，沒有 I/O 或者外部狀態訪問
EVM 是第一個圖靈完備的（也有準圖靈完備的說法）區塊鏈虛擬機，於 2015 年發布。它有一些設計限制，但其巨大的先發優勢和隨後的廣泛採用為以太坊創造了巨大的差異化優勢——它是迄今為止整個空間中最經得起考驗的智能合約基礎設施。
由於以太坊的主導地位，很多後來的區塊鏈都直接採用了這種運行時環境。例如，Polygon 和 BNBChain 是以太坊的直接分支，因此使用 EVM 作為它們的運行時間。值得注意的是，EVM 並非一成不變，並且在 EIP1559 等升級中經常被修改。由於其他區塊鏈需要時間進行更新，或者在多個地方與以太坊有所不同，它們通常運行著稍微過時的 EVM 版本，並且難以跟上變化的步伐——這一事實可能會讓以太坊的核心開發人員感到沮喪。
以太坊的兼容性
然而，人們所說的 “EVM 鏈” 通常不僅僅只是鏡像這個運行時環境。有幾個主要規範始於以太坊並已成為事實上的全球標準：
- Solidity（一種編譯成 EVM 字節碼的高級語言）
- 以太坊的 JSON-RPC 客戶端 API（與以太坊節點交互的規範）
- ERC20/ERC721（以太坊代幣標準）
- ethers.js（一個與以太坊接口的網絡庫）
- 以太坊的密碼學（例如 keccak256 作為散列函數，ECDSA 簽名在 secp256k1 上）
從技術上講，您的鏈可能有一個 EVM 運行時而不支持上述部分或全部。然而，遵守這些標準使得在你的新鏈上使用以太坊工具變得更加容易。一個很好的例子是 Polygon，它除了使用上述所有工具外，還能夠運行 Etherscan ( Polygonscan ) 的分叉版本，使用 Hardhat 等以太坊開發工具，並在 Metamask 等錢包中被支持為不同的以太坊 “網絡”。像 Nansen 和 Dune 等工具最初都針對以太坊，因此添加對新 EVM 區塊鏈的支持很簡單。新錢包，新 NFT 市場——如果以太坊界面和你的鏈界面之間的唯一區別是鏈 ID，那麼你可能是第一個也是最容易添加的。話雖如此，這些工具是為以太坊構建的——一旦你開始修改你的區塊鏈（例如更大的塊，更快的塊時間），你就有破壞它們的風險。沒有完美的兼容性。
儘管如此，針對以太坊規範的工具和應用程序的數量為新的區塊鏈創造了巨大的動力，使其僅僅反映以太坊標準。任何不支持上述規範的區塊鏈在涉及開發者工具時都會自動落後，並有可能隨著 EVM 生態系統的發展而進一步落後。
我的認知是，“EVM 兼容” 一詞實際上不足以描述這裡描述的網絡效應——我們實際描述的是 “以太坊兼容性”，並且遠遠超出了智能合約執行環境，延伸到了整個以太坊生態系統和工具集。
為了解決這個問題，像 Solana 這樣的非 EVM 區塊鏈必須創建完全平行的生態系統，這會降低它們的速度，並且更難吸引現有的開發人員。但是，不需要遵守這些標準確實使非 EVM 區塊鏈能夠對以太坊工具集進行更根本的更改，從而更積極地與以太坊區分開來。創建 EVM 區塊鏈非常簡單——但為什麼有人會使用你的區塊鏈而不是其他數百個 "快速 EVM 區塊鏈"中的一個。如果能克服建立一個成功的平行鍊和圍繞其生態系統的困難，Solana 已經證明：a）你可以吸引出色的原生應用程序（例如 MagicEden、Phantom）和 b）如果商業激勵就足夠了（例如 Opensea 添加 Solana 支持）。
（為什麼 Medium 不支持表格？）
ZK-EVM
通用 rollups 都有一個共同目標：讓開發人員和用戶盡快生成網絡效應。這需要結合創造最高性能的 rollup 技術、擁有最好的 BD 團隊以及進行最早或最有效的營銷。但是，所有 rullup 團隊（出於上述原因）都非常關注：
- 將現有的以太坊合約（和開發人員）遷移到他們的 rollup 中
- 受到現有 EVM 工具（例如庫、錢包、市場等）的支持
實現這兩個目標的最簡單方法是創建一個 “zkEVM”：一個通用匯總，將 EVM 作為其智能合約引擎運行，並保持與以太坊生態系統通用接口的兼容性，如上所述。
然而，這並不像分叉 Geth 那樣容易，就像我們從頭開始創建新的 L1 區塊鏈時那樣容易。我們的目標是運行 EVM 字節碼——但 ZK 證明需要將它們證明的所有計算語句轉換為一種非常特定的格式——一種 “代數電路”，然後可以將其編譯成 STARK 或 SNARK。為了快速了解 “電路”，這裡有一個例子（使用更直觀的布爾電路作為算術電路的特例）。在基於這個簡單電路的 zkSNARK 系統中，我們的證明者希望讓驗證者相信他們知道輸入（𝑥1 = 1，𝑥2 = 1，𝑥3= 0），這些輸入會產生真實的輸出。這是一個非常簡單的電路，具有有限數量的邏輯門——我相信你可以想像需要多少門來編碼一個證明復雜智能合約交互的電路，尤其是那些涉及密碼學的！
為了理解這個編譯過程的每一步，我推薦 Vitalik 的 SNARKs 從零到英雄指南，以及 Eli Ben-Sasson 對不同證明系統的討論。然而，對於我們的目的來說，這種更深入的理解並不是必需的——請記住，為了支持 EVM 計算，我們必須將所有 EVM 程序轉換為這些電路，以便以後可以證明它們。
從廣義上講，有幾種方法可以做到這一點（歸根結底是底層電路和 evm 本身的兼容性問題如何解決）：
- 通過將其轉換為可驗證的電路來直接證明 EVM 執行軌跡
- 創建一個自定義 VM，將 EVM 操作碼映射到該 VM 的操作碼，然後證明該自定義環境中跟踪的正確性
- 創建自定義 VM，將 Solidity 轉換為自定義 VM 的字節碼（直接或通過自定義高級語言），並在自定義環境中進行驗證
對以太坊的兼容性是從上至下的。
選擇一： 證明 EVM 執行軌跡
滾動
讓我們從最直觀的開始：證明 EVM 執行軌跡本身，這種方法目前正在由 Scroll 團隊（與以太坊基金會的隱私擴展小組一起）研究。為了使其發揮作用，我們需要：
- 為一些加密累積器設計一個電路（允許我們驗證我們正在準確地讀取存儲和加載正確的字節碼）。
- 設計一個電路來以正確的執行路線連接字節碼
- 為每一個 opcode 設計一個電路（允許我們證明讀寫計算都是正確的）
以電路的方式直接實現每一個 evm opcode 是具有挑戰性的，但是因為這個方式是對 EVM 的直接鏡像，這對於維護行，穩定性和工具支持具有潛在益處。下圖顯示，Scroll 和 Ethereum 之間唯一的理論區別是實際運行環境。然而，值得注意的是，Scroll 目前並沒有通過這種機制支持所有的 EVM 操作碼，儘管他們打算隨著時間的推移達到平價。
Optimism 團隊對此進行了精彩的討論，儘管是在 optimistic rollups 的背景下進行的。Optimism 最初創建了一個自定義的 Optimistic 虛擬機 (OVM) 作為其 rollup 的執行環境。OVM 是 “與以太坊兼容的”，這意味著它可以運行修改後的 Solidity 代碼，但幾個低級不匹配的領域意味著經常需要重寫以太坊工具和復雜代碼。因此，Optimism 轉而使用 “EVM 等效”，直接使用確切的 EVM 規範，並正在開發第一個等效於 EVM 的欺詐證明系統。然而，optimistic rollup 不需要擔心電路或證明者的效率——Optimism 的正確選擇可能不是我們 rollup 的正確選擇。
不幸的是，EVM 的核心基礎設施並適合於 zk-rollups。衡量 rollup 性能的一個核心指標是我們需要將某個計算編碼到電路中的"約束"的數量。在許多案列中，直接鏡像 EVM 會導致許多的過載。例如，EVM 使用 256bit 的整數，然而 zk 證明很自然的在素數有限域下工作。引入範圍檢查來對抗不匹配的域的算術，每個 EVM 步驟增加了約 100 個約束。以太坊的存儲佈局嚴重依賴 keccak256，它的電路形式比 STARK 友好的哈希函數（如 Poseidon，Pedersen）大 1000 倍—— 但替換 keccak 將對現有的以太坊基礎設施造成巨大的兼容性問題。另外，與 SNARK/STARK 友好的橢圓曲線相比，標準以太坊橢圓曲線上的簽名的證明和驗證非常昂貴。（這些難以編碼電路主要在於以太坊標準加密算法對於 zk 難以實現）簡單來說，直接證明 EVM 會導致承載大量的計算負荷。然而這裡有許多好處，（eg 多項式承諾，遞歸證明，驗證加速）證明 EVM 執行路徑總是比在定制設計的 VM 中證明效率低得多，至少在 EVM 本身做出更改以變得對 SNARK 更友好之前（可能需要幾年時間）。
選擇二： 自定義的 VM + Opcode Support
這種認識促使團隊採用上述 “與 EVM 兼容” 的方法：創建具有優化性能的自定義 VM，然後將 EVM 字節碼直接轉換為 VM 的字節碼。
多邊形
一個專注於這種方法的團隊是 Polygon Hermez（最近更名為 Polygon zkEVM）。Polygon 構建 zkEVM 的方法是"操作碼級等效"，這聽起來與 Scroll 採取的方法最初相似。然而，與 Scroll 不同的是，Polygon 的備用運行時（“zkExecutor”）運行定制的 “zkASM” 操作碼，而不是 EVM 操作碼來優化 EVM 解釋（即減少約束的數量與直接證明 EVM）。Hermez 團隊將此描述為 “基於操作碼的方法”，因為核心挑戰是在他們的自定義 VM 中重新創建每個 EVM 操作碼（您可以在此處查看代碼），以便他們可以快速從 EVM 字節碼轉換為可驗證的格式。
這些中間步驟為維護和潛在的錯誤創造了更大的表面積，但對於實現高性能的證明是必要的。最終，重要的是要清楚，你的程序不是在反映電路中的 EVM 的 zkEVM 中運行，而是在替代的"zkExecutor "運行時中運行，它與 EVM 本身相似但不同。令人困惑的是，該團隊將其稱為"zkEVM "和"EVM 等效"——然而，由於這個自定義的 zkASM 解釋器，根據上述 Optimism 定義，這個 rollup 程序實際上是"EVM 兼容"。
因此，儘管大多數 Solidity 代碼可能能夠按原樣運行，但可能與在該系統上運行的現有 L1 應用程序和工具存在一些不兼容。Polygon 已聲明 “與~ 100% 的現有以太坊工具” 兼容，並致力於 JSON-RPC 合規性，他們在文檔中引用並在此處提供了實現。在實踐中，這種說法可能是有抱負的，並且依賴於以太坊本身的東西變得對 SNARK 更加友好。
Polygon 的方法產生了比 Scroll 更高性能的匯總（肯定是在短期內），但具有：
- 大量自定義代碼，因為我們需要創建 zkASM
- 開發人員可能需要修改其 L1 代碼或工具框架
- 隨著時間的推移，以太坊的漂移可能會增加
選項 3: 自定義 VM+轉譯器
上述解決方案在 “使 EVM 為 zk-rollups 工作” 方面投入了大量的開發時間，將兼容性優先於長期性能和可擴展性。還有另一種選擇：創建一個全新的、專門構建的 VM，然後添加對以太坊工具的支持作為頂部的附加層。
星網
這是 StarkWare 對 StarkNet 採用的方法，這是目前最先進的通用 rollup。StarkNet 使用自己的低級語言 (Cairo) 運行自定義智能合約 VM (Cairo VM)，兩者都是為智能合約 rollups 而構建的。這意味著 StarkNet 沒有開箱即用的以太坊兼容性——正如我們之前看到的，即使是操作碼級別的 VM 級別兼容性也是 rollup 性能的潛在手剎。
然而，Nethermind 團隊（與 StarkWare 合作）創建了 Warp 轉換器，它能夠將任意 Solidity 代碼轉換為 Cairo VM 字節碼。Warp 的目標是使常見的 Solidity 合約可移植到 StarkNet——實現許多以太坊開發人員在 “EVM 兼容性” 方面的主要目標。在實踐中，有一些 Solidity 的功能不被 Warp 所支持，包括低級別的調用（完整的列表可以在這裡找到）。
這種構建智能合約 rollup 的方法是保持 “Solidity-compatibility”：你不是在 EVM 內執行程序，也不是保持與任何其他以太坊接口的兼容性，但 Solidity 開發人員將能夠編寫可用於你的 rollup。因此，您可以保持與以太坊類似的開發人員體驗，而不必損害 rollup 的基本層——擁有蛋糕並吃掉它。
然而，這種方法還有幾個額外的權衡。首先是構建自己的 VM 具有挑戰性——以太坊團隊已經有超過五年的時間來解決 EVM 的問題，並且仍然經常進行升級和修復。更加自定義的 rollup 將帶來更好的性能，但您將失去所有其他鍊和 rollup 對 EVM 所做的集體改進的好處。
接下來，通過轉譯器支持 Solidity 可能會導致可組合性的損失——如果開發人員同時在 CAIRO 和 Solidity 中編寫合約，那麼支持兩者之間接口的工具很可能會很變得脆弱。到目前為止，絕大多數 StarkNet 項目都直接使用了 CAIRO，它們可能不容易與未來的 Solidity 項目組合。最後，可能也是最重要的一點，StarkNet 團隊目前的目標不是與其他以太坊組件兼容——他們正在推出自己的客戶端 API、javascript 庫和錢包系統，這將迫使與以太坊兼容的工具手動添加對 StarkNet 的支持。這是極具挑戰性的，但並非不可能——如上所述，Solana 已經足夠成功，其自定義標準得到了一些以太坊工具的尊重。
但是，如果他們能夠成功地做到這一點，StarkWare 團隊將尋求復制 EVM 的先發優勢，並使用第一個針對 zk-rollups 優化的智能合約 VM。
同步
另一個採用這種策略的團隊是 zkSync。zkSync 創建了他們自己的 VM (SyncVM)，它是基於寄存器的，並定義了自己的代數中間表示 (AIR)。然後他們構建了一個專門的編譯器來將 Yul（一種中間語言，可以編譯為不同 EVM 版本的字節碼，認為是較低級別的 Solidity）編譯成 LLVM-IR，然後他們將其編譯成自定義 VM 的指令。這類似於 StarkWare 採用的方法，但理論上提供了圍繞基礎語言的更大靈活性（儘管目前僅支持 Solidity 0.8.x）。zkSync 團隊最初創建了自己的類 CAIRO 語言（Zinc )，但他們將大部分精力集中在 Solidity 編譯器上，以便為 L1 開發人員提供更簡單的遷移。一般來說，他們的策略是重用以太坊工具集而不是 StarkNet ——我希望他們的客戶端 API 等也更加 “與以太坊兼容”。
zkSync 利用這個自定義 VM 來提供非 EVM 兼容的功能，例如 Account Abstraction，這一直是核心以太坊協議的目標。這是自定義 VM 提供的好處的一個很好的例子——你不必等待以太坊構建新功能！
將所有內容放在一起，您可以清楚地看到每個團隊遵循的不同策略：
Vitalik 的 zkEVM 類型
Vitalik Buterin 關於 zkEVM 的博客強調了 Rollup 團隊當前面臨的基本困境：EVM 不是為 “可驗證” 程序構建的。事實上，正如我們通過上面的分析所表明的那樣，你尋求與以太坊的兼容性越強，你的 “可驗證格式” 程序的性能就會越差。Vitalik 根據與現有 EVM 基礎設施的兼容性程度確定了通用 rollup 的幾大類：
我要對他的論文做的唯一擴展是指出，即使在每個 “類型” 中也存在很大程度的可變性——我們正在處理一個範圍，而不是完全細分的類別。從開發人員體驗的角度來看，對應用程序層進行單一、小的更改的 Type 2.5 rollup 比 Type 3 rollup 更常見，後者對應用程序層進行了大規模更改，但在技術上沒有引入新的 VM 並成為 Type 4。
智能合約 rollup 的現狀
鑑於理解上述內容所需的細節，難怪我們圍繞以太坊兼容性發明了一堆令人困惑的語言。事實上，沒有 zk-rollup 在所有情況下都完美地反映了 EVM 的行為——這只是程度問題，每個團隊做出的詳細選擇最終將最重要的是可維護性和性能，而不是僅兼容性。我的觀點是以下定義是最清晰和最一致的：
重要的是要理解，上述方法都不是天生優越的——它是一種分類，而不是等級。它們都做出了不同的權衡：更容易構建、維護和升級，更高效，更容易與現有工具兼容。最終，領先的 rollup 也將取決於更好的分銷和營銷，而不是純粹的技術能力。話雖如此，做出正確的基本技術決策無疑具有重大優勢。Scroll 對 EVM 規範的熱心承諾是否會使他們能夠輕鬆響應任何 EVM 升級？另一個團隊更務實的方法會幫助他們更快地進入市場嗎？StarkWare 的定制 VM + 轉譯器方法會為長期規模提供更堅實的基礎嗎？另一支球隊最終會從這個領域的先行者無疑會犯的錯誤中吸取教訓並擊敗他們嗎？最終，以太坊開發當前時刻的美妙之處在於，我們有不同的團隊以截然不同的方法朝著一個共同的目標前進。
但在我們得意忘形之前，對當前智能合約 rollup 的準備情況保持清醒也是適當的。每個團隊都有強烈的動機將自己推銷為 “即將接管世界” 的團隊—— 但最早要到 2022 年底，以太坊上才會有 “生產級” 智能合約 rollup，其中許多團隊將直到 2023 年才准備好。根據 StarkNet 的發展歷程，我們應該預計從 rollup 到達 testnet 開始至少需要一年的迭代，然後才能在該 rollup 準備好支持主網上一致的生產級數量之前。
由於這種不成熟的狀態，對於需要在不影響以太坊安全性的情況下進行擴展的開發人員來說，特定於應用程序的 rollups 仍然是最強大的選擇。事實上，即使通用 rollups 可用並且得到更廣泛的集成，我預計在可預見的未來，特定應用 rollups 的性能、定制和可靠性對於某些用例（例如交易所、NFT 鑄造/交易）仍將保持優勢。
其他匯總因素
儘管本文的主要關注點，但這並不是關於以太坊生態系統兼容性與性能的全部內容！還有許多其他因素會影響您是否應該在特定的通用 rollup 上進行構建。我將建議幾個主要的附加標準：
- 費用：這些 rollups 是否會以原生代幣、ETH 或兩者的某種複雜組合收取費用？費用結構對用戶和開發人員體驗有巨大影響，因為 rollups 通常需要擁有費用代幣來支付計算費用。
- 證明和排序：所有 rollups 都需要一個實體，該實體負責對交易進行排序和生成證明。今天大多數特定於應用程序的 rollups 都是 “單序列器”，它以彈性為代價產生更高的吞吐量。大多數通用 rollups 最初是作為單個排序器 rollups 開始的，但他們通常計劃隨著時間的推移分散這個排序器。
- 自託管： zk-rollups 的核心承諾是能夠在保持以太坊安全的同時解鎖性能。但是，許多通用 rollups 目前沒有明確的機制來在保證發生惡意或不可用的排序器時恢復用戶資產。
- 數據可用性：如介紹中所述，自託管保證取決於故障情況下狀態數據的可用性。然而，完整的數據可用性為用戶帶來了額外的成本，從而導致了一系列數據可用性模式。這已經在特定於應用程序的 rollup 世界（例如 Validiums、Volitions）中廣泛使用，但是每個通用 rollup 都需要單獨添加此功能。
（Medium 把我縮小到截取滿是鏈接的表格……）
總結
智能合約 rollups 是以太坊擴展路線圖中令人難以置信的部分。這些 rollups 在與現有以太坊工具集的關係中做出的不同權衡是對以太坊開發者生態系統多樣性的驚人證明。
然而，目前關於 EVM 兼容性的討論通常沒有抓住重點。從開發人員的角度來看，所有這些 rollups 都將支持 Solidity 代碼。真正的以太坊兼容性是一個更大的挑戰，但實際上需要權衡取捨，開發人員在進行 rollup 之前應該意識到這一點。目前，大多數 rollup 項目都是大規模的 “遠期銷售”——銷售其能力的 3 年以上願景，而不是今天（甚至 12 個月內）可能實現的目標，這可能會使情況變得非常混亂。
為了透明起見，我希望每個主要的 rollup 團隊都能對以下問題提供更清晰的答案：
- L1 和 L2 在運行時的確切差異是什麼？L2 將修改哪些操作碼？與 L1 相比，其他任何 VM 特徵（例如費用結構）是否會有所不同？
- 您的自定義 VM 的正式規範在哪裡，它在哪裡比其他選項性能更高/性能更低？
- 此 rollup 將對其他以太坊接口（例如客戶端 API、庫）進行多少更改，這將破壞以太坊工具？
- 此 rollup 何時在測試網上上線？在主網上？能夠支持 1000+ 定制合同 tps 的持續生產吞吐量嗎？
- 您預計何時支持對用戶資產的完全自我託管，在通用 rollup 的背景下會是什麼樣子？
一旦這些 roolups 在測試網上發布，這些問題應該更容易回答。在那之前，我希望看到團隊繼續發布更多關於他們的解決方案將做出的確切權衡的技術細節，以及這將如何影響智能合約和工具開發人員等。
隨著合併指日可待，經過實戰考驗的特定應用程序 rollups 在生產中，以及通用 rollups 在明年進入主網，以太坊擴展的未來就是現在。
免責聲明：作為區塊鏈信息平台，本站所發布文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。本文內容僅用於信息分享，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
