jakiro
作者：Zhixiong Pan，來源：作者博客
TL;DR
Parallel EVM 概念正在被幾家頭部 VC 押註：Paradigm、Jump、Dragonfly 等。
代表項目是 Monad，另外還有 Sei、MegaETH、Polygon、Neon EVM、BSC 等。有些是 L1，有些是 L2。各團隊的具體差異暫無完整的公開信息。
Parallel EVM 雖然字面意思僅代表了「並行化」，但其實也是對 EVM 各個組件性能的專項優化，所以它的努力很可能代表者著 EVM 標準下的性能極限。
難點：除了要對整個技術棧重構之外，還有如何提前預判並行的交易是否會衝突，以及遇到衝突後的重新執行效率。
挑戰：如何在開源生態構建差異性、如何在去中心化和性能之間找到平衡。
既共識算法、DA（數據層）、零知識證明技術被廣泛研究和迭代後，下一個被關注的硬核技術是 Parallel EVM，資本市場也已經為這個敘事投註上億美元，並誕生多個獨角獸級別的初創。
社區開始關注 Parallel EVM（EVM 並行化） 起源 於 Georgios Konstantopoulos （Paradigm 的 CTO ）和 Dragonfly 的 Haseeb Qureshi 不約而同在 2023 年底展望 2024 年趨勢時，提到的這同一個關鍵詞。但討論這個話題的細節並不多，而且也有很多人認為這並不是什麼新概念， EVM 和並行化計算分別都是相對成熟的概念了 ，為什麼把這兩個詞結合在一起就是個重要的趨勢呢？
但這仍然是個非常小眾的話題，以至於如果翻看很多研究機構的年度總結和趨勢預測時，都沒有提到 Parallel EVM。所以這仍然是個未形成大規模共識的新概念。而且這個概念和共識算法、DA 等話題類似，都是純技術相關的，所以關注的人群就更少了。
Paralle EVM 最直接的優勢是 讓現有的去中心化應用，實現網際網路級別的性能 。甚至可以這麼說，Parallel EVM 是唯一一個既能利用（大量成熟的）現有智能合約的同時，還能實現高性能、並行化公鏈吞吐量的新技術。
Paradigm 期待入局已久，Jump 系下重注
據「財富」 報導 ，Paradigm 正計劃領投 Monad 的最新一輪，以 30 億美元估值籌集 2 億美元。雖然這是 Paradigm 計劃投資的第一個 Parallel EVM 概念的團隊，但其實他們關注這個技術已多年，Georgios Konstantopoulos （Paradigm 的 CTO ）曾在 2021 年就 提及 了這個詞。
Monad 這個詞的來源也很有意思。在哲學家萊布尼茨的哲學體系中，Monad 是構成宇宙的基本元素，它們是不可分的、不受物理影響的實體，每個 Monad 都反映了整個宇宙，在中文曾被翻譯為「單子」。
而在計算機科學中，Monad 是函數式程式語言中的一種設計模式，它幫助程式設計師以近乎數學的純淨性來處理現實世界的複雜性，使得代碼更加模塊化、易於理解和維護。
另一個有意思的是， Monad 和 Nomad 互為「變位詞」（Anagram），nomad 是指遊牧者，而 digital nomad 是指數字遊民/數字牧民。
除了 Monad，Georgios 討論 這個話題時還提及過 Sei 和 Polygon。不過他這麼看好 Parallel EVM 還有一個重要原因，就是他們開發了一個以太坊客戶端 Reth。它的定位就是高性能的以太坊執行層客戶端，用 Rust 語言實現。Reth 在以很快的速度開發，剛進入 Beta 階段。或許他們會考慮直接在 Reth 上實現 Parallel EVM，但考慮到研發的工程量，通過投資其他團隊推動 Parallel EVM 可能是個更好的選擇。而據 Monad 的文檔，他們在工程上主要採用的是 C++ 和 Rust。
Reth 推出之初還被 Erigon 團隊成員指責抄襲其 Akula 的開原始碼，也導致了 Akula 項目缺少資金停止開發。Georgios 回應稱 Reth 並不是任何其他客戶端的分叉，代碼也不來自於任何其他客戶端，但的確是受到了Geth、Erigon 和 Akula 的影響和啟發。( https://thedefiant.io/paradigm-accused-copying-code )
另一個核心參與者就是 Jump Trading 和 Jump Capital，Monad 創始人來自 Jump Trading，有豐富的高頻交易的經驗；Sei 的投資人有 Jump Capital，而且 Jump 還一直深度參與 Solana 生態，包括基礎建設和項目。
而 Monad 的早期投資者 Dragonfly 也一直關注相關賽道，曾投資專注分片技術的 NEAR，以及 Aptos、Avalanche、Nervos 等公鏈。
升級共識算法還不夠，終於輪到執行層
在過去的幾次公鏈大戰中，執行層一直是被忽視的地方，他們幾乎只談論共識算法的創新，無論是 Solana、Avalanche 還是 EOS 等。雖然他們在執行層有很多的創新，但社區更多還是記得他們使用的共識算法，而且整個社區也會以為這些高性能公鏈能獲得這些性能就是來自於共識算法的創新。
但其實不是，如果想要獲得一個高性能的公鏈，共識算法和執行層是需要配套的，也符合木桶短板效應。而對於那些基於 EVM 並且只改進共識算法的公鏈，提升性能就需要更強的節點。比如參考 BSC 把區塊可以處理的 Gas 限制在了 2000 TPS 的水平，需要的機器配置數倍於以太坊全節點的投入。Polygon 理論 可以達到 1000 TPS，平時也就幾十到上百。
BSC 存檔節點 需要至少 16 核 CPU 和 128G 內存， 以太坊節點 只需至少 4 核 CPU 和 16G 內存。
BSC 團隊也早就意識到這些問題，所以也在和 NodeReal 合作開發 Parallel EVM 技術。只有這樣才能進一步提升每個區塊可以處理交易的數量，讓更多交易並行執行，提升 TPS 上限。
並行：不僅從單核升級為多核 CPU
在大多數的區塊鏈系統中，交易是完全按照順序執行的，你可以把它想像成一個單核 CPU，當前的計算完成後，才能進行下一次計算。這個方式雖然慢，但其優勢是簡潔且系統複雜度低。
但如果未來區塊鏈系統需要接入網際網路級別的用戶規模，單核 CPU 肯定不夠用。所以升級為多核 CPU 的並行化虛擬機，就能同時處理多筆交易，增加吞吐量。不過，這在工程實現上有很多的挑戰，比如同時處理的兩筆交易在對同一個智能合約寫入數據怎麼辦？就需要設計一套新的機制來解決這種矛盾。而對於其他完全不相關的智能合約的並行執行，就能按照並行處理的線程數，按規模提升吞吐量。
另外，Parallel EVM 不僅提升並行能力，還會優化單線程時的執行效率。Monad CEO Keone Hon 表示 ，「…（EVM 的）真正瓶頸在於處理事物時頻繁讀取寫入狀態…」。他還表示，並行執行只是路線圖的一部份，Monad 更大的使命是圍繞 EVM，使其儘可能高效。
所以，Parallel EVM 雖然字面意思僅代表了「並行化」，但其實也是對 EVM 各個組件性能的專項優化，所以它的努力很可能代表者著 EVM 標準下的性能極限。
EVM 不等於 Solidity
寫智能合約是大多數區塊鏈開發者的必備技能。工程師可以根據業務需求，用 Solidity 或其他智能合約的高級語言寫出相應的邏輯實現。但 EVM 其實並不能直接讀懂 Solidity 的邏輯，需要經過一些「翻譯」，將它翻譯（編譯）為一種機器能理解的低級語言後（opcode 操作碼 / bytecode 字節碼），才能被虛擬機執行。而這個翻譯的過程， Solidity 開發者也不需要理解，因為已經有成熟的工具實現了。
畢竟是「翻譯」，所以其中也會產生一些 overhead（額外開銷）。而對於有底層代碼經驗的工程師，可以在 Solidity 中直接用操作碼編寫程序邏輯，這樣能達到最高的效能，也就是用戶交易時能節省 Gas。比如 Opensea 推出的 Seaport 協議就在智能合約中大量使用了內聯彙編，儘可能為用戶減少 Gas 支出。
所以，如果 Parallel EVM 能最終實現，不僅能帶來並行化的能力，還會優化整個 EVM 堆棧的性能。普通的應用開發者也就不需要為了節省一點 Gas 就耗費巨大的精力優化，因為底層的虛擬機已經足夠強大了，能抹平這些差異。
EVM 性能各不相同，「標準」不等於「工程實踐」
「虛擬機」也可以被稱為「執行層」，是智能合約被編譯為操作碼後，最終被計算和處理的引擎。以太坊虛擬機（EVM）定義的「字節碼」目前成為了行業標準，無論是基於以太坊的二層網絡，還是其他獨立的公鏈，都更願意先直接且完整兼容 EVM 的標準，開發者寫一次智能合約就能部署到多個網絡中，性價比極高。
所以只要能完全兼容 EVM 的「字節碼」標準，就可以稱為 EVM，但是實現方式可以千差萬別。比如以太坊客戶端 Geth 中就用 Go 語言實現了 EVM 標準。但以太坊基金會的執行層研究團隊 Ipsilon 維護 了一個用 C++ 開發的 EVM 獨立實現，其他以太坊客戶端可以直接調用這個庫來作為 EVM 執行。
舉個例子，很多工業化生產的產品都有其對應的國際標準，比如某產品出廠時需要滿足菌落數小於某個特定的值才能銷售，這就是「標準」。但如何滿足這個出廠的標準，每家工廠可以從用幾十種不同的殺菌方式中選擇，而有些工廠能找到性價比更高的方式滿足這個要求，這就是「實踐」。
既然有 evmone 的實現，也可以做其他實現。所以在 EVM 的這個例子中，EVM 的標準就是定義了一些基礎的操作方式「字節碼」（比如支持加減乘等最基礎的算術），每個字節碼有確定的輸入時，就有確定的輸出。在滿足這個標準時，實現（實踐）方式天差地別，有大量的自定義空間和工程優化的可能性。
Parallel EVM 的異同
在 Parallel EVM 賽道中，除了最炙手可熱的 Monad 之外，還有 Sei、MegaETH、Polygon、Neon EVM、BSC 等，以及 Paradigm 的 Reth 客戶端也想實現並行化的功能。
從定位來看，Monad、Sei、Polygon、BSC 都是 Layer 1 區塊鏈，而 MegaETH 可能是 Layer 2，Neon EVM 是基於 Solana 網絡的。另外，Reth 是一個開源的客戶端，MegaETH 也會部分基於 Reth 的工程繼續開發。
當然這幾個團隊之間還存在競爭關係，而且也沒完全公開所有的技術細節和工程文件，更多的對比要等後續他們逐漸公開才能展開。或許這又像軍備競賽一樣，像 BTC Layer 2、Restaking、以太坊 Layer 2 一樣，儘管技術之間存在細微差異（且開源），但更重要的是如何構建生態的獨特性。
Parallel EVM 的技術難點
對於順序執行的交易來說，瓶頸在於 CPU 和讀取寫入狀態的過程。但好處是這種方式足夠簡單，不會出錯，所有事務都能按部就班的執行完成。而對於並行執行的虛擬機而言，是可能存在狀態衝突的，所以在執行前或執行後需要增加這部分的判斷。
一個簡單的例子就是，如果虛擬機支持四個線程並行執行，且每個線程都能同時處理一筆交易，萬一這四筆交易都是和 Uniswap 上的同一個交易池交易，那就不能並行計算，因為每次交易後都會影響這個交易池的交易價格。但是如果這四個線程同時處理四件完全不相關的事情，那就沒有問題。
這裡面會涉及不同團隊的設計和工程實現，但至少要確保的是在並行執行後，需要一個模塊來檢測衝突，如果遇到衝突就重新執行。當然，如果能提前預判並篩查可能存在衝突的交易，也可以增加整個虛擬機的並行效率。
除了 Parallel EVM 這個虛擬機的工程實現差異，各個團隊一般也會重新設計並增強狀態資料庫的讀寫性能，並配套設計一個共識算法，比如 Monad 設計的 MonadDb 和 MonadBFT。
挑戰
對於 Parallel EVM 而言，有兩個可能會存在的挑戰：長期的工程價值是否會被以太坊捕獲；節點的中心化。
由於各個團隊在 Parallel EVM 技術上還處於開發和測試階段，所以都還沒選擇開源所有工程細節，這是目前的護城河之一。但是但進入測試網和主網後，這些工程文件就會被公開，也可能會被以太坊或者其他公鏈吸收。所以在那個時間點，就需要更快推進生態建設，構建更多生態層面的護城河。
不過這個問題也沒這麼嚴重，一方面對於 Crypto 開發者而言，現在有更多的開源許可可供選擇（比如 Uniswap 的那種可以將代碼公開，但不允許分叉為商業項目的許可），另一方面是 Monad 的定位本就和以太坊有差異。就算以太坊在未來能實現單插槽終局性（SSF），交易的最終性還是至少 12 秒的，這對於更高頻的應用場景是遠遠不夠的。
另一個挑戰對於所有高性能公鏈都一樣，就是如何部署更多節點，以滿足用戶的無需許可（permissionless）、無需信任（trustless）的基本要求：去中心化。或許這其中還能量化一些指標，比如 「TPS 除以 節點的硬體需求」，這樣就能實現控制變量，對比在特定硬體需求的標準下，哪個公鏈/客戶端的 TPS 更高。畢竟節點的硬體需求越低，節點數量就可能越多。
接下來，我們還會持續跟蹤 Parallel EVM 各個項目的進展，並詳細深入討論他們的技術和差異。
