EVM：以太坊的核心

EVM（Ethereum Virtual Machine, 以太坊虛擬機）是以太坊的核心，負責運行智能合約和處理交易。

虛擬機通常用於真實計算機的虛擬化，通常由「虛擬機管理程序」（如 VirtualBox）或整個操作系統實例（如 Linux 的 KVM）進行虛擬化。它們必須分別提供實際硬體、系統調用和其他內核功能的軟體抽象。

EVM 在一個更有限的領域中運行：它只是一個計算引擎，因此提供了計算和儲存的抽象，例如類似於 Java 虛擬機（JVM）規範。從高層次的角度來看，JVM 旨在提供與底層主機操作系統或硬體無關的運行時環境，從而實現跨各種系統的兼容性。同樣，EVM 執行自己的字節碼指令集，這些指令集通常由 Solidity 編譯而成。

EVM 是一個准圖靈完備的狀態機，"准 "是因為所有執行步驟都會消耗有限的資源 Gas，因此任何給定的智能合約執行都會限制在有限的計算步數內，避免了執行過程可能的死循環，從而導致整個以太坊平台停止的情況。

EVM 沒有調度功能，以太坊的執行模塊從區塊中取出一個個交易，EVM 負責依次去執行。執行的過程中會修改最新的世界狀態，一筆交易執行完成後進行狀態累加，到達區塊完成後的最新的世界狀態。下一區塊的的執行時又嚴格依賴上一個區塊執行後的世界狀態，所以以太坊的交易線性執行過程無法很好的進行並行執行優化。

從這個意義上說，以太坊協議約定交易按照順序執行。雖然順序執行確保了交易和智能合約能夠以確定性順序執行，保障了安全性，但在面臨高負載的情況下，可能會導致網路擁堵和延遲，這也是為什麼以太坊有極大的性能瓶頸，需要 Layer2 Rollup 擴容的原因。

高性能 Layer1 的並行之道

大多數高性能 Layer1 都是基於以太坊不能並行處理的缺陷去設計自己的優化方案，這裡只聊執行層的優化，也就是虛擬機和並行執行。

虛擬機

EVM 設計成一台 256 位的虛擬機，目的是為了更易於處理以太坊的哈希算法，它會明確產生 256 位的輸出。然而，實際運行 EVM 的計算機則需要把 256 位的字節映射到本地架構來執行智能合約，從而使得整個系統變得非常低效和不實用。因此從虛擬機的選擇上，高性能 Layer1 更多採用的是基於 WASM，eBPF 字節碼或 Move 字節碼的虛擬機，而非 EVM。

WASM 是一種體積小、加載快、可移植且基於沙盒安全機制的字節碼格式，開發人員可以使用多種編程語言（C/C++、Rust、Go、AssemblyScript、JavaScript 等）編寫智能合約，然後編譯成 WASM 字節碼並執行。WASM 已經被許多區塊鏈項目接納為標準，包括 EOS，Dfinity，Polkadot（Gear），Cosmos（CosmWasm），Near 等，以太坊未來也會集成 WASM，從而保證以太坊的執行層更加高效、簡單，適合作為完全的去中心化計算平台。

eBPF 前身是 BPF（Berkeley Packet Filter，伯克利包過濾器），原本是用於網路數據包的高效過濾，後經過演化形成了 eBPF，提供更豐富的指令集，允許在不改動源碼的情況下對操作系統內核進行動態干預和修改其行為。後來這項技術從內核中走出來，發展出了用戶態 eBPF 運行時，其具有高性能、安全和可移植性。Solana 上執行的智能合約都會編譯成 SBF（基於 eBPF）字節碼並在其區塊鏈網路上運行。

Move 是 Diem 設計的一種新的智能合約編程語言，注重靈活性、安全和可驗證性。Move 語言旨在解決資產和交易中的安全性問題，使得資產和交易能夠被嚴格定義和控制。Move 的字節碼驗證器是一個靜態分析工具，分析 Move 字節碼並確定是否遵守所需的類型、內存和資源安全規則，不需要在智能合約級別實現並在運行時檢查。Aptos 繼承了 Diem Move，Sui 則通過自身定製版本的 Sui Move 來編寫其智能合約。

並行執行

區塊鏈中的並行執行意味著同時處理不相關的交易。把不相關的交易看作互不影響的事件。例如，如果兩個人在不同的交易平台上交易代幣，他們的交易可以同時處理。但是，如果它們在同一平台上交易，則可能需要按照特定的順序執行交易。

實現並行執行的主要挑戰是確定哪些交易是不相關的，哪些是獨立的，大多數高性能 Layer1 依賴於兩種方法：狀態訪問方法和樂觀並行模型。

狀態訪問方法需要預先知道每個交易可以訪問區塊鏈狀態的哪一部分，從而分析出哪些交易是獨立的。代表方案是 Solana 和 Sui。

在 Solana 中，程序（智能合約）是無狀態的，因為它們不能自行訪問（讀取或寫入）在整個交易過程中持續存在的任何狀態，要訪問或保持狀態，程序需要使用帳戶。Solana 的每個交易必須指定在交易執行期間將訪問哪些帳戶，這樣交易處理運行時可以調度非重疊交易並行執行，同時保證數據一致性。

在 Sui Move 中，每個智能合約都是一個模塊，由函數和結構定義組成。結構在函數中實例化，可以通過函數調用傳遞給其他模塊。運行時儲存的結構實例作為對象，Sui 中存在三種不同類型的對象，分別是擁有者對象，共享對象和不可更改對象。Sui 的並行化策略與 Solana 相似，交易也需要指定操作哪些對象。

樂觀並行模型在所有交易都是獨立的假設下運行，只是回顧性地驗證這一假設並在必要時進行調整。代表方案是 Aptos。

Aptos 使用 Block-STM（區塊軟體事務內存，Block Software Transactional Memory）的方法來應用樂觀並行執行。在 Block-STM 中，交易首先在區塊內按照一定的順序進行設置，然後在不同的處理線程之間進行拆分，以便同時執行。在處理這些交易時，系統會跟蹤每個交易更改的內存位置。在每一輪處理之後，系統檢查所有的交易結果。如果它發現某個交易觸及了由早期交易更改的內存位置，則擦除其結果並再次運行。這一過程一直持續到區塊中的每個交易都被處理完畢。

並行 EVM

並行 EVM（Parallel EVM）早在 2021 年就被提起，那時候指的還是支持同時處理多個交易的 EVM，旨在改進現有 EVM 性能和效率，代表方案有 Polygon 基於 Block-STM 實現的並行 EVM，BSC 和 NodeReal 合作開發的並行 EVM。

但在 2023 年底，Paradigm 的 CTO Georgios Konstantopoulos 和 Dragonfly 的 Haseeb Qureshi 不約而同在展望 2024 年趨勢時又提到了並行 EVM，帶火了一波採用了並行執行技術的 EVM 兼容 Layer1，包括 Monand 和 Sei V2。

現如今，Solana 上的 EVM 兼容方案 Neon，以太坊 SVM（Solana 虛擬機）的 Layer2 Rollup Eclipse，以太坊 Move 虛擬機的 Layer2 Rollup Lumio，模塊化執行層 Layer1 Fuel 都紛紛貼上了並行 EVM 的標籤，令人眼花繚亂。

我認為合理的能定義成並行 EVM 的只有以下三類：

1.沒有採用並行執行技術的 EVM 兼容的 Layer1 的並行執行升級，例如 BSC，Polygon；

2.採用了並行執行技術的 EVM 兼容的 Layer1，例如 Monand，Sei V2 以及 Artela；

3.採用了並行執行技術的非 EVM 兼容的 Layer1 的 EVM 兼容方案，例如 Solana Neon。

BSC 和 Polygon 作為最主流的兼容 EVM 的 Layer1 自不必多說，這裡簡單介紹下 Monand，Sei V2，Artela 和 Solana Neon。

Monad 是一個採用 PoS 機制的兼容 EVM 的高性能 Layer1，旨在通過並行執行顯着增強可擴展性和交易速度。Monad Labs 由 Jump Trading 前研究負責人 Keone Hon 創立。Monad 允許在區塊內並行執行交易以提高效率。它使用樂觀並行模型，在上一步的執行完成之前就開始執行新交易。為了應對不正確的結果，Monad 跟蹤輸入 / 輸出並重新執行不一致的交易。靜態代碼解析器可以預測依賴關係，避免無效的並行性，並在不確定時恢復到簡單模式。這種並行執行增加了吞吐量，同時減少了交易失敗的可能性。

Sei 是基於 Cosmos SDK 開發的 Layer1，專門為 DeFI 設計的公鏈。Sei 團隊成員兼具科技和傳統金融背景，曾就職於 Robinhood、Databricks、Airbnb 及高盛等公司。Sei V2 是對 Sei 網路的大範圍升級，旨在成為第一個完全並行的 EVM。與 Monad 一樣，Sei V2 將使用 樂觀並行化。這允許區塊鏈同時執行交易，而不需要開發人員定義任何依賴項。當發生衝突時，區塊鏈將跟蹤每個交易觸及的儲存部分並按順序重新運行這些交易。這個過程將遞歸地持續下去，直到所有未解決的衝突都得到解決。

Artela 是一個可擴展的區塊鏈網路，使開發人員能夠構建功能豐富的去中心化應用程序（dApps），核心成員來自於螞蟻鏈。Artela 推出的 EVM++ 代表着高擴展性 + 高性能的並行 EVM，分為兩個階段實現，第一階段將圍繞並行執行進行設計，在並行執行的基礎上，通過彈性計算保證網路節點算力可擴展，最終實現彈性區塊空間。其中並行執行會根據交易依賴衝突分析對交易進行分組以支持並行執行。

Solana Neon 是 Neon Labs 開發的解決方案，用於在 Solana 之上執行 EVM 交易。Neon EVM 實際上是 Solana 上的一個智能合約，該合約內實現了一個 EVM 解釋器，編譯為 SBF 字節碼。Neon EVM 內部實現了一套以太坊交易模型和帳戶模型，用戶只需要支付 EVM GAS 費用即可發送交易。Solana 網路的費用是由 Neon Proxy 支付的。Solana 強制要求交易提供帳戶列表，包裝交易也不例外，所以 Neon Proxy 的職責包括生成這個帳戶列表，同時也獲得了 Solana 的交易並行執行能力。

這裡補充一點，類似 Solana Neon 將 EVM 作為智能合約運行以實現 EVM 兼容的方案還有 Near Aurora 和 EOS EVM+，理論上 Aptos 和 Sui 上也可以採用此方案來實現無侵入性的 EVM 兼容，但我沒有找到相關資料（或許 Pontem 在做這個事情？），如果有正在進行中的項目可以聯繫我補充。EVM 兼容使得開發者可以輕鬆將他們的以太坊應用遷移到鏈上，而無需進行大規模修改，是一個很好建設 Aptos 和 Sui 生態的方向。

總結

區塊鏈的並行技術已經是個老生常談的話題了，敘事每隔一段時間就會抬一次頭，但是目前主要都是對以 Aptos 的 Block-STM 機制 為代表的樂觀執行模型的改造和模仿，沒有實質性的突破，所以熱度難以持續。

展望未來，還會有更多的新興的 Layer1 項目加入並行 EVM 的競爭，而對於一些舊的 Layer1 也會實現 EVM 並行升級 或 EVM 兼容的方案，兩個方向殊途同歸，還會誕生更多與性能提升有關的新敘事。

不過相比於高性能 EVM 的敘事，我還是更希望區塊鏈能百花齊放，出現類似 WASM，SVM 及 Move VM 的敘事。

原文連結