最近，Paradigm 下重注領投了 Monad 一輪 2.25 億美元的巨額融資，引發市場對 “並行 EVM” 的強烈關注。
作者：Haotian
封面：Artela
最近，Paradigm 下重注領投了 Monad 一輪 2.25 億美元的巨額融資，引發市場對 “並行 EVM” 的強烈關注。 那麼，“並行 EVM” 到底解決了什麼問題？發展並行 EVM 的瓶頸和關鍵是什麼？ 在我看來，“並行 EVM” 是 EVM 鏈迎擊高性能 layer1 鏈的最後一博，事關乙太坊 EVM 生態的存續之戰。 Why？接下來，來談談我的理解：
由於乙太坊 EVM 虛擬機只能「串行」交易，這使得 EVM- Compatible layer1 鏈以及 EVM 相容的 layer2 鏈，也都受到了相應的性能制約，因為大家本質上都基於同一套框架處理狀態和交易 Finality。
然而，像 Solana、Sui、Aptos 等主打高性能的 layer1 先天就具有可並行的優勢。 在此背景下，EVM 基因的鏈要想正面 Battle 高性能 layer1 公鏈的衝擊，就勢必得補足「並行」能力先天不足的問題。 如何做呢？涉及技術原理和細節，我將以並行 EVM 新銳鏈 @Artela_Network 為例展開說明：
1）以 Monad、Artela、SEI 等為代表的強化型 EVM layer1 鏈，它們會在高度相容 EVM 的基礎上大幅提升 TPS 並能賦予交易在擬 EVM 環境下的並行能力，這類獨立並行 EVM layer1 鏈，有獨立的共識機制和技術特性，但依然會以相容並拓展 EVM 生態為目標，相當於，以 “換血統” 的方式重構 EVM 鏈，又服務於 EVM 生態;
2）以 Eclipse、MegaETH 等為代表的擴容型 layer2 EVM 兼容鏈，它們利用 layer2 鏈獨立的共識和交易「預處理」能力，可以在大批量交易被 Batch 到主網前，對交易狀態進行篩選和處理，並可同時選擇其他任意鏈的執行層來最終確定交易狀態。 等同於把 EVM 抽象成一個可插拔的執行模組，可根據需要選擇最佳 “執行層”，進而實現了並行能力; 但，這類方案可服務於 EVM，但又超出 EVM 框架範疇;
3）以 Polygon、BSC 等為代表的等效型 Alt-layer1 鏈，它們一定程度上實現了 EVM 的並行處理能力，但只是進行了演算法層的優化，並沒有進行深層次的共識層和存儲層的優化，因此這類並行能力更多可視為一個特定的 Feature，而並沒有徹底解決 EVM 的並行問題。
4）以 Aptos、Sui、Fuel 等為代表的差異型 Non-EVM 並行鏈，它們某種程度上並非實現的並非 EVM 鏈，而是在其先天具有高併發執行能力接觸上，然後通過某種中間件或編碼解析方式，實現了和 EVM 環境的相容。 我們看身為乙太坊 layer2 的 Starknet 就是如此，由於 Starknet 具備 Cario 語言和帳戶抽象使其也具備並行能力，但其相容 EVM 卻需要一個特殊的管道。 這些 Non-EVM 鏈的並行能力接軌 EVM 鏈基本都存在這個問題。
以上四個方案，各有側重點，比如：有並行能力的 layer2 側重模組化組合 “執行層” 鏈的靈活性; 而 EVM- Compatible 鏈則突出了特定功能的定製特性; 至於其他非 EVM 鏈的 EVM 兼容特性更多所圖抽乙太坊的流動性; 真正目標徹底鞏固 EVM 生態，並從底層改變並行能力的只剩一個強化型 EVM layer1 賽道了。
那麼，做強化型並行 EVM layer1 公鏈的關鍵是什麼？如何才能重構 EVM 鏈，又能服務於 EVM 生態？有兩個關鍵點：
1、訪問 state I/O 磁碟讀取和輸出資訊的能力，由於數據的讀取和寫入要消耗時間，只是簡單進行交易排序和調度，並不能根本上提高並行處理能力，還需要引入緩存、數據切片甚至分散式存儲技術等等，從根本狀態存儲和讀取流程上平衡讀取速度和狀態衝突的可能性;
2）擁有高效的網路通信，數據同步，演算法優化、虛擬機強化、以及將計算和 IO 任務分離等共識機制層的各類元件優化等等，需要牽一髮而動全身從底層元件架構、協作流程等方方面面綜合優化和提升，最終促成回應速度快、計算消耗可控、準確率高的並行交易的能力;
具體到並行 EVM layer1 鏈專案本身，要做哪些技術創新和框架優化來實現 “並行 EVM” 呢？
為了從底層架構層徹底實現資源協調和優化的「並行 EVM」能力，Artela 引入了彈性計算（Elastic Computing）和彈性區塊空間（Elastic Block Space），如何理解呢？ 彈性計算，網路可根據需求和負載動態地分配和調整計算資源; 彈性區塊空間，可根據網路中交易數量和數據大小進行動態調整區塊大小; 整個彈性設計工作原理，恰如商場自動感應人流量進行工作的扶梯一樣，很 Make Sense;
前文說了，State I/O 磁碟讀取性能對並行 EVM 很關鍵，Polygon、BSC 等 EVM-Compatible 鏈通過演算法實現的 “並行” 能力，也能實現 2-4 倍的效率提升，但其只是演算法層的優化，其共識層、存儲層並沒有進行深層優化，真正的深層優化會是怎樣呢？
針對此，Artela 借鑒了資料庫技術方案，在狀態讀取和寫入方面都做了提升，其中寫入狀態方面才去了寫入前日誌（WAL）技術，當狀態改變要寫入時先把改變記錄寫入日誌並提交到記憶體，就可以認為完成了 “寫入” 操作，這樣做其實實現了操作異步化，避免了在狀態改變時寫入時立即進行磁碟寫入操作，故而降低了對磁碟的 I/O 操作。 狀態讀取方面，本質上也是異步化操作，通過預載入策略來提升讀取效率，根據合約歷史執行記錄來預測下一次特定的合約調用會用到哪些狀態，並預先載入到記憶體中，進而提升了磁碟 I/O 請求效率。
總之，這是一種通過記憶體空間換執行時間的一種演算法，以此從根本上提升 EVM 虛擬機的並行處理能力，算是從根本上優化了狀態衝突問題。
除此之外，Artela 通過引入 Aspect 模組化程式設計能力，以更好管理複雜性並提高開發效率：通過引入 WASM 編碼解析以增強程式設計的靈活性; 同時，它還具有底層 API 訪問許可權，實現了執行層的安全隔離。 這使得開發者可以在 Artela 的環境下高效地開發，調試和部署智慧合約，以此啟動開發者群體的定製擴展能力。 特別是，開發者也會被激勵在智慧合約代碼層就往可並行的方向進行代碼優化，畢竟要減少狀態衝突概率，每一個智慧合約的調用邏輯和演算法都尤為關鍵。
以上
大家不難看出，「並行 EVM」這一概念本質上就是在優化交易狀態的執行過程， @monad_xyz 號稱可達到每秒 10,000 筆交易，其技術內核也無非在專用資料庫、開發者友好度、延遲執行共識、超標量流水線技術等等方面來達成大規模交易的並行處理，這和 Artela 的彈性計算和 I/O 異步性操作本質邏輯並無太大差異。
但我其實更想表達的是，這類高性能並行 EVM 鏈其實是融入 web2 產品和技術力之後的結果，確實採用了 web2 成熟應用市場上，時不時流量高負載下的「技術處理」精髓。
如果放眼一個 Mass Adoption 的遙遠未來，“並行 EVM” 的確是 EVM 生態下一步面向 web2 更廣泛市場的基礎 infra，能受資本市場如此 Bullish 也在情理之中。
免責聲明：作為區塊鏈資訊平臺，本站所發佈文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。 文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
