入門指南：zkEVM、EVM 兼容性和 Rollup 最全解讀_ROLL:roll幣怎么用

ZK Rollups 長期以來一直被認為是以太坊擴容的終極目標。然而，盡管它們對以太坊擴展路線圖很重要，但幾個關鍵點仍然存在廣泛的不確定性：

ZK Rollup 到底是什么？

特定于應用程序的 Rollup 和通用 Rollup 之間有什么區別？

什么是 zk-EVM Rollup？像 EVM 等效和 EVM 兼容這樣的術語實際上是什么意思，它們如何應用于 Rollup？

ZK Rollup 生態系統的現狀如何，這對生態項目意味著什么？

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

ZK Rollups 可以通過一個簡單的觀察來實現：像 STARK 或 SNARK 這樣的證明系統允許使用亞線性處理來驗證線性數量的語句（例如，1000 條語句 → 10 次驗證者檢查，10,000 條語句 → 11 次驗證者檢查）。我們可以使用此屬性來創建可大規模擴展的區塊鏈交易處理，如下所示：

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

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

這個狀態更新和證明被提交到我們的 L1 ZK Rollup 智能合約并被驗證，并用于更新我們的 L1 狀態

用戶可以使用這種 L1 狀態（取決于不同的數據可用性機制）來檢索他們的資產，從而實現完全的自我托管和“以太坊安全”

簡化的 ZK Rollup 架構

驗證證明的 gas 成本與被證明的交易數量呈次線性關系，與直接使用 L1 相比，可以實現更大的規模。為了更詳細地了解這個過程，我推薦 Vitalik 的《不完全 Rollup 指南》或 Delphi 新發布的《完整 Rollup 指南》。

到目前為止，所有生產級 ZK Rollup 都是我們所說的“特定于應用程序的 Rollup”。在特定于應用程序的 Rollup 中，Rollup 支持由 Rollup 運營方定義的固定數量的“狀態轉換”（例如交易）。這對于超優化常見用例非常有用，例如：

Loopring—支付和 Swap

Immutable—NFT 鑄幣和交易、游戲

dydx—永續交易

特定于應用程序的 Rollup 非常適合擴展特定的、易于理解的問題。如果您作為項目的需求可以通過特定于應用程序的 Rollup 來滿足，那么您可能會為您的用例獲得更好的性能、更好的用戶體驗和更好的定價，因為它們缺乏泛化性是一個巨大的優勢。例如，在 Immutable，我們能夠通過補貼免費的 NFT 鑄造和通過 NFT 交易收費的轉賬來消除 gas 費用——這種權衡只有在 rollup 狀態轉換的可預測性質下才有可能。

但是，許多項目希望能夠創建自己的自定義邏輯和智能合約，獨立于 rollup 運營方，這在特定于應用程序的 rollup 中是不可能的。此外，許多 DeFi 項目需要“可組合性”，或與其他項目進行原子交互的能力（例如，許多 DeFi 項目使用 Uniswap 作為價格預言機）。只有當您的 rollup 不僅支持自定義代碼，而且支持任何用戶可以部署的本機智能合約時，組合性才是可能的。為了實現這一點，我們需要修改 ZK Rollup 的架構以概括我們的每個組件。

韓國議員發起提案，將處罰虛擬貨幣不公平交易及降低加密交易所準入門檻:5月16日，韓國國會議員Ping-wook Kim提出處罰虛擬貨幣不公平交易行為的提案。提案規定，禁止加密行業未經注冊的商業活動和未露重要信息的行為。如果違反規定，將處以3年以下有期徒刑或1億韓元以下罰款。操縱市場價格或用虛假手段吸引加密貨幣投資等行為也將受到處罰。該提案還為加密貨幣市場的自我監管奠定了基礎。虛擬資本行業協會被要求調解業務運營商和用戶之間的糾紛，制定發行、公告和虛擬貨幣上市的標準，并檢查合規性。此外，提案還要求該協會報告交易所的市場監測結果，如果懷疑該交易所是非法的，則應立即向金融委員會報告。金融委員會應對此進行調查并采取適當的措施。另外，要求加密交易所必須在金融委員會進行注冊。文章認為，比起另一個議員的提案要求交易所必須得到金融委員會批準，Ping-wook Kim的提案降低了加密交易所的準入門檻。（韓聯社）[2021/5/16 22:08:13]

這種增加的靈活性有幾個妥協：性能大大降低，rollup 參數的可定制性降低以及費用更高。然而，最大的妥協是根本沒有通用 ZK Rollups 的實現，當然也沒有能夠生產級的實現。但這種情況開始改變：

StarkNet 目前已經在主網上運行（盡管處于有限的 Alpha 階段）

3 個獨立的項目（zkSync、Polygon Hermez/zkEVM 和 Scroll）都在 ETH CC 2022 上宣布它們將成為第一個進入主網的“zkEVM”

這些最新的公告值得深入研究，因為這些團隊不僅宣布了通用 Rollup，他們還宣布了“zkEVM”。隨之而來的是推特上許多圍繞“EVM 兼容性”、“EVM 等效性”、“真正的 zkEVM”以及哪種方法更好的爭論。對于應用開發人員來說，這些對話通常是噪音——因此本博客的目的是分解這些術語、設計決策和理念，并解釋它們對開發人員的實際影響。

讓我們從頭開始：什么是 EVM？

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

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

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

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

堆棧操作 - PUSH1（向堆棧添加一些內容）

算術運算 - ADD（加數字），SUBTRACT

狀態操作——SSTORE（存儲數據），SLOAD（加載數據）

交易操作——CALLDATA、BLOCKNUMBER（返回有關當前執行事務的信息）

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

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

每個操作都必須有“成本”以防止濫用（因為所有節點都運行所有交易）

中國銀行原行長：Libra要達到西方國家市場準入門檻需解決三大問題:5月5日晚，對于Libra的顛覆性潛力，中國銀行前行長、中國互聯網金融協會區塊鏈研究組組長李禮輝在人民網直播中表示，一是行業巨霸聯合創始，覆蓋巨大客戶群體。二是應用數字技術，構建獨立的金融基礎設施。三是以硬資產做支撐，維護獨立數字貨幣的價值。他表示，Libra要真正達到西方國家的市場準入的門檻，必須解決一些重大問題，包括：一是必須驗證技術平臺的效率和可靠性；二是商業運行模式的可行性和透明度；三是金融合規管控的實現的路徑和可信度。查看演講完整內容請點擊原文鏈接。[2020/5/6]

每個操作都必須是確定性的（因為所有節點必須在交易執行后就狀態達成一致）

我們需要特定于區塊鏈的概念（例如智能合約、交易）

一些復雜的操作必須是原語（例如密碼學）

交易必須是在沙盒里的，沒有 I/O 或外部狀態訪問

EVM 是第一個圖靈完備的區塊鏈 VM，于 2015 年發布。它有一些設計限制，但其巨大的先發優勢和隨后的廣泛采用為以太坊創造了巨大的差異化——它是迄今為止最久經考驗的區塊鏈虛擬機。它是整個領域的智能合約基礎設施。

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

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

Solidity（一種編譯成 EVM 字節碼的高級語言）

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

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

ethers.JS（一個與以太坊接口的網絡庫）

以太坊的密碼學（例如 keccak256 作為哈希函數，對 secp256 k1 的 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 支持）。

動態 | Coinbase為入門級加密用戶推出新信號工具:據coindesk報道，Coinbase為入門級加密用戶推出新信號工具，頂級持有人的活動將匯總在整個交易所的所有個人Coinbase賬戶中 （不包括機構賬戶）。[2019/7/18]

公共通用 rollup 都有一個共同目標：讓開發人員和用戶盡快生成網絡效應。這需要結合創造最高性能的 rollup 技術、擁有最好的 BD 團隊以及進行最早或最有效的營銷。但是，所有 rollup 團隊（出于上述原因）都非常關注：

將現有的以太坊合約（和開發人員）遷移到他們的 rollup 中

受到現有 EVM 工具（例如庫、錢包、市場等）的支持

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

然而，這并不像分叉 Geth 那樣容易，就像我們從頭開始創建新的 L1 區塊鏈時那樣容易。我們的目標是運行 EVM 字節碼——但 ZK 證明要求將它們證明的所有計算語句轉換為一種非常特定的格式——一種“代數電路”，然后可以將其編譯成 STARK 或 SNARK。為了快速了解“電路（circuit）”，這里有一個例子（使用更直觀的布爾電路作為算術電路的特例）。在基于這個簡單電路的 zkSNARK 系統中，我們的證明者希望讓驗證者相信他們知道輸入（?1 = 1，?2 = 1，?3= 0），這些輸入會產生真實的輸出。這是一個非常簡單的電路，具有有限數量的邏輯門——我相信你可以想象需要多少門來編碼一個證明復雜智能合約交互的電路，尤其是那些涉及密碼學的！

為了理解這個編譯過程的每一步，我推薦你閱讀 Vitalik 的《從入門到精通 SNARKs》，以及 Eli Ben-Sasson 對不同證明系統的討論。然而，對于我們的目的來說，這種更深入的理解并不是必需的——請記住，為了支持 EVM 計算，我們必須將所有 EVM 程序轉換為這些電路，以便以后可以證明它們。

從廣義上講，有幾種方法可以做到這一點：

通過將其轉換為可驗證的電路來直接證明 EVM 執行痕跡

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

創建自定義 VM，將 Solidity 轉換為自定義 VM 的字節碼（直接或通過自定義高級語言），并在自定義環境中進行驗證

讓我們從最直觀的開始：證明 EVM 執行痕跡本身，這是 Scroll 團隊（與以太坊基金會的隱私擴展團隊一起）目前正在研究的一種方法。為了完成這項工作，我們需要：

為一些密碼積累器設計一個電路（允許我們驗證我們正在準確地讀取存儲并加載正確的字節碼）

設計一個電路來鏈接字節碼和真實的執行痕跡

為每個操作碼設計一個電路（允許我們證明每個操作碼的讀取、寫入和計算的正確性）

直接在電路中實現每個 EVM 操作碼具有挑戰性，但由于這種方法準確地反映了 EVM，因此它在可維護性和工具支持方面具有顯著優勢。下圖顯示了 Scroll 和以太坊之間唯一的理論區別是實際的運行環境。然而，值得注意的是，Scroll 目前并不通過這種機制支持所有 EVM 操作碼，盡管他們打算隨著時間的推移達到對等。

動態 | 《幼兒區塊鏈入門》在亞馬遜兒童新書榜中排名第一:CNN編輯Alex Koppelman在推特上曬出一本名為《幼兒區塊鏈入門》（《Blockchain for Babies》）的圖書。據悉，此書在兒童實用書類新書榜中排名第一。[2019/1/8]

Optimism 團隊對此進行了精彩的討論，盡管是在 Optimistic Rollup 的背景下進行的。Optimism 最初創建了一個自定義的 Optimistic Virtual Machine (OVM) 作為其 Rollup 的執行環境。OVM 是“與以太坊兼容的”，這意味著它可以運行修改后的 Solidity 代碼，但幾個低級不匹配的領域意味著以太坊工具和復雜的代碼經常需要重寫。因此，Optimism 切換到“EVM 等效”，直接使用確切的 EVM 規范，并正在開發第一個等效于 EVM 的欺詐證明系統。然而，Optimistic Rollup 不需要擔心電路或證明者的效率——Optimism 的正確選擇可能不是我們 Rollup 的正確選擇。

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

這種認識促使團隊采用上述“與 EVM 兼容”的方法：創建具有優化性能的自定義 VM，然后將 EVM 字節碼直接轉換為 VM 的字節碼。

一個專注于這種方法的團隊是 Polygon Hermez（最近更名為 Polygon zkEVM）。Polygon 的方法是構建一個 zkEVM 是“操作碼級別的等效性”，這聽起來最初類似于 Scroll 采用的方法。然而，與 Scroll 不同的是，Polygon 的替代 runtime（“zkExecutor”）運行定制的“zkASM”操作碼而不是 EVM 操作碼來優化 EVM 解釋（即減少約束的數量與直接證明 EVM）。Hermez 團隊將此描述為“基于操作碼的方法”，因為核心挑戰是在他們的自定義 VM 中重新創建每個 EVM 操作碼（您可以在此處查看代碼），以便他們可以快速從 EVM 字節碼轉換為可驗證的格式。

這些中間步驟增加了用于維護和潛在錯誤的表面積，但對于啟用性能證明是必要的。最終，重要的是要清楚，您的程序不是在反映電路中 EVM 的 zkEVM 中運行，而是在替代的“zkExecutor”運行時中運行，這與 EVM 本身相似但不同。令人困惑的是，該團隊將其作為“zkEVM”和“EVM 等效”進行營銷——然而，由于這個自定義的 zkASM 解釋器，根據上面的 Optimism 定義，這個 Rollup 實際上是“EVM 兼容”。

動態 | Filament為企業提供Blocklet Kit區塊鏈入門套件:據coincryptorama消息，為物聯網(IoT)企業提供區塊鏈解決方案的Filament公司，宣布為企業提供Blocklet Kit區塊鏈入門套件。這是一個端到端的區塊鏈解決方案，旨在幫助移動、可再生能源和其他行業采用像區塊鏈這樣的分布式賬本技術(DLT)。[2018/10/10]

因此，盡管大多數 Solidity 代碼可能能夠按原樣運行，但可能與在該系統上運行的現有 L1 應用程序和工具存在一些不兼容。Polygon 已聲明“與 100% 的現有以太坊工具”兼容，并致力于 JSON-RPC 合規性，他們在文檔中引用并在此處提供了實現。在實踐中，這種說法可能是有抱負的，并且依賴于以太坊本身的東西變得對 SNARK 更加友好。

Polygon 的方法產生了比 Scroll 更高性能的 Rollup（肯定是在短期內），但具有：

大量自定義代碼，因為我們需要創建 zkASM

開發人員可能需要修改其 L1 代碼或工具框架

隨著時間的推移，與以太坊的偏離可能會增加

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

這是 StarkWare 對 StarkNet 采用的方法，這是目前最先進的通用 rollup。StarkNet 使用自己的低級語言 (Cairo) 運行自定義智能合約 VM (Cairo VM)，兩者都是為智能合約 rollup 而構建的。這意味著 StarkNet 沒有開箱即用以太坊兼容性——正如我們之前看到的，即使是操作碼級別的 VM 級別的兼容性也是對 Rollup 性能的潛在限制。

然而，Nethermind 團隊（與 StarkWare 合作）創建了 Warp 轉譯器，它能夠將任意 Solidity 代碼轉換為 Cairo VM 字節碼。Warp 的目標是使常見的 Solidity 合約可移植到 StarkNet——實現許多以太坊開發人員在“EVM 兼容性”方面的主要目標。然而，在實踐中，Warp 不支持一些 Solidity 功能，包括低級調用（可以在此處找到完整列表）。

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

然而，這種方法還有一些額外的妥協。首先是構建自己的 VM 具有挑戰性——以太坊團隊已經花了超過五年的時間來解決 EVM 的問題，并且仍然經常進行升級和修復。更自定義的 Rollup 將帶來更好的性能，但您將失去所有其他鏈和 Rollup 對 EVM 所做的集體改進的好處。

接下來，通過轉譯器支持 Solidity 可能會導致可組合性的損失——如果開發人員同時在 CAIRO 和 Solidity 中編寫合約，那么支持兩者之間接口的工具很可能會很脆弱。到目前為止，絕大多數 StarkNet 項目都直接使用了 CAIRO，它們可能不容易與未來的 Solidity 項目組合。最后，可能也是最重要的一點，StarkNet 團隊目前的目標不是與其他以太坊組件兼容——他們正在推出自己的客戶端 API、JavaScript 庫和錢包系統，這將迫使與以太坊兼容的工具手動添加對 StarkNet 的支持。這是極具挑戰性的，但并非不可能——如上所述，Solana 已經足夠成功，其自定義標準得到了一些以太坊工具的尊重，但將依賴 StarkWare 團隊吸引不介意重建的開發人員的能力。

然而，如果他們能夠成功地做到這一點，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 兼容的功能，例如賬戶抽象，這一直是核心以太坊協議的目標。這是自定義 VM 提供的好處的一個很好的例子——你不必等待以太坊構建新功能！

將所有內容放在一起，您可以清楚地看到每個團隊遵循的不同策略：

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

我對他的論文的唯一擴展是指出，即使在每個“類型”中也存在很大程度的可變性——我們正在處理一個范圍，而不是完全細分的類別。從開發人員體驗的角度來看，對應用程序層進行單一、小的更改的 Type 3 rollup 比 Type 3 rollup 更常見，后者對應用程序層進行了大規模更改，但在技術上沒有引入新的 VM 并成為 Type 4。

鑒于理解上述內容所需的細節，難怪我們圍繞以太坊兼容性發明了一堆令人困惑的語言。事實上，沒有 zk-rollup 在所有情況下都完美地反映了 EVM 的行為——這只是程度問題，每個團隊做出的詳細選擇最終將最重要的是可維護性和性能，而不是僅兼容性。我的觀點是以下定義是最清晰和最一致的：

至關重要的是要理解，上述方法都不是天生優越的——它是一種分類，而不是等級。它們都做出了不同的妥協：更容易構建、維護和升級，更高效，更容易與現有工具兼容。最終，領先的 Rollup 也將取決于更好的分銷和營銷，而不是純粹的技術能力。話雖如此，做出正確的基本技術決策無疑具有重大優勢。Scroll 對 EVM 規范的熱心承諾是否能讓他們輕松響應任何 EVM 升級？另一個團隊更務實的方法會幫助他們更快地進入市場嗎？StarkWare 的定制 VM + 轉譯器方法是否會為長期擴展提供更堅實的基礎？另一支玩家最終會從這個領域的先行者無疑會犯的錯誤中吸取教訓并擊敗他們嗎？歸根結底，以太坊開發當前時刻的美妙之處在于，我們有不同的團隊以截然不同的方法朝著一個共同的目標前進。

但在我們得意忘形之前，對當前智能合約 Rollup 的準備情況保持清醒也是適當的。每個團隊都有強烈的動機將自己推銷為“即將接管世界”——但最早要到 2022 年底，以太坊上才會有“生產級”智能合約匯總，其中許多團隊將直到 2023 年才準備好。根據 StarkNet 的發展歷程，我們應該預計從 rollup 到達測試網開始至少需要一年的迭代，然后 rollup 才能準備好支持主網上一致的生產級數量。

由于這種不成熟的狀態，對于需要在不影響以太坊安全性的情況下進行擴展的開發人員來說，特定于應用程序的 Rollup 仍然是最強大的選擇。事實上，即使通用 Rollup 可用并得到更廣泛的集成，我預計在可預見的未來，應用特定 Rollup 的性能、定制和可靠性對于某些用例（例如交易所、NFT 鑄造/交易）仍將保持優勢。

盡管本文的主要關注點，但這并不是關于以太坊生態系統兼容性與性能的全部內容！還有許多其他因素會影響您是否應該在特定的通用 Rollup 上進行構建。我將建議幾個主要的附加標準：

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

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

自托管：ZK Rollup 的核心承諾是能夠在保持以太坊安全的同時解鎖擴展。然而，許多通用 Rollup 目前沒有明確的機制來在發生惡意或不可用的排序器時恢復用戶資產。

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

智能合約 Rollup 是以太坊擴展路線圖中令人難以置信的部分。這些 Rollup 在與現有以太坊工具集的關系中做出的不同妥協是對以太坊開發者生態系統多樣性的驚人證明。

然而，目前關于 EVM 兼容性的討論通常沒有抓住重點。從開發人員的角度來看，所有這些 Rollup 都將支持 Solidity 代碼。真正的以太坊兼容性是一個更大的挑戰，但實際上需要權衡取舍，開發人員在進行 Rollup 之前應該意識到這一點。目前，大多數 Rollup 項目都是大規模的“超前銷售”——銷售其能力的 3 年以上愿景，而不是今天（甚至 12 個月內）可能實現的目標，這可能會使情況變得非常混亂。

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

L1 和 L2 在 runtime 的確切差異是什么？L2 將修改哪些操作碼？與 L1 相比，其他任何 VM 特征（例如費用結構）是否會有所不同？

您的自定義 VM 的正式規范在哪里，它在哪里比其他選項性能更高/性能更低？

此 rollup 將對其他以太坊接口（例如客戶端 API、庫）進行多少更改，這是否將破壞以太坊工具？

此 rollup 何時在測試網上上線？在主網上？能夠支持 1000+ 定制合約 tps 的持續生產吞吐量嗎？

您預計何時支持對用戶資產的完全自我托管，在通用 rollup 的背景下會是什么樣子？

一旦這些 rollup 在測試網上發布，這些問題應該更容易回答。在那之前，我很樂意看到團隊繼續發布更多關于他們的解決方案將做出的確切權衡的技術細節，以及這將如何影響智能合約和工具開發人員等。

隨著合并即將到來，經過實戰考驗的特定應用程序 rollup 在生產中，以及通用 rollup 在明年進入主網，以太坊擴展的未來就是現在。

Tags：ROLLROL以太坊ARKThe Troller Coinroll幣怎么用以太坊交易所排名Sparkster

比特幣行情