EVM的串行執行瓶頸與並行化優化探索

衆所周知，EVM是以太坊的核心執行引擎和智能合約運行環境，是以太坊最關鍵的組件之一。在由衆多節點構成的公鏈網路中，爲了確保智能合約在不同節點上都能得到一致的執行結果，虛擬機技術起到了至關重要的作用。

EVM能夠在各種操作系統和設備上以統一的方式執行智能合約，這種跨平台兼容性保證了每個節點運行合約後都能獲得一致的結果。這與Java虛擬機JVM的工作原理類似。

通常情況下，智能合約會先被編譯爲EVM字節碼，然後存儲到區塊鏈上。EVM執行合約時，會按順序讀取這些字節碼，每條指令都對應特定的Gas成本。EVM會追蹤每條指令執行過程中的Gas消耗，具體消耗量取決於操作的復雜程度。

作爲以太坊的核心執行引擎，EVM採用串行方式處理交易，所有交易在單一隊列中排隊並按確定順序依次執行。選擇串行而非並行的原因是爲了嚴格滿足區塊鏈的一致性要求，確保一批交易在所有節點中都按相同順序處理。

2014-2015年間，以太坊創始團隊出於時間緊迫，選擇了設計簡單且易於維護的串行執行方式。然而，隨着區塊鏈技術的發展和用戶羣體的擴大，對TPS和吞吐量的要求不斷提高。特別是在Rollup技術成熟落地後，EVM串行執行帶來的性能瓶頸在以太坊二層網路中變得更加明顯。

作爲Layer2的關鍵組件，Sequencer以單個服務器的形式承擔所有計算任務。如果與Sequencer配合的外部模塊效率都足夠高，最終的瓶頸將取決於Sequencer本身的效率，此時串行執行將成爲重大障礙。

某團隊通過對DA層和數據讀寫模塊進行極致優化，使Sequencer每秒最多可執行約2000多筆ERC-20轉帳。這個數字看似很高，但對於更復雜的交易，TPS數值必然會大幅下降。因此，交易處理的並行化將是未來的必然趨勢。

以太坊交易執行的兩大核心組件

除EVM外，與交易執行相關的另一核心組件是stateDB，用於管理以太坊中的帳戶狀態和數據存儲。以太坊採用Merkle Patricia Trie樹狀結構作爲數據庫索引，EVM每次交易執行都會改變stateDB中的某些數據，這些變更最終會反映在全局狀態樹中。

stateDB負責維護所有以太坊帳戶的狀態，包括EOA帳戶和合約帳戶，存儲的數據包括帳戶餘額、智能合約代碼等。在交易執行過程中，stateDB會對相應帳戶的數據進行讀寫。交易執行結束後，stateDB需要將新狀態提交到底層數據庫中進行持久化處理。

總的來說，EVM負責解釋和執行智能合約指令，根據計算結果變更區塊鏈上的狀態，而stateDB則充當全局狀態存儲，管理所有帳戶和合約的狀態變化。兩者共同構建了以太坊的交易執行環境。

串行執行的具體過程

以太坊的交易類型分爲EOA轉帳和合約交易兩種。EOA轉帳是最簡單的交易類型，即普通帳戶之間的ETH轉帳，不涉及合約調用，處理速度很快，收取的gas費極低。

相比之下，合約交易涉及智能合約的調用與執行。EVM在處理合約交易時，需要逐條解釋和執行智能合約中的字節碼指令，合約邏輯越復雜，涉及的指令越多，消耗的資源也就越多。

例如，ERC-20轉帳的處理時間約爲EOA轉帳的2倍，而更復雜的智能合約，如某DEX上的交易操作，耗時可能是EOA轉帳的十幾倍。這是因爲DeFi協議在交易時需要處理流動性池、價格計算、代幣交換等復雜邏輯，需要進行大量計算。

在串行執行模式下，EVM與stateDB這兩個組件協作處理交易的過程如下：

以太坊設計中，一個區塊內的交易會按先後順序逐筆處理，每筆交易都有一個獨立實例用於執行具體操作。雖然每筆交易使用不同的EVM實例，但所有交易共用同一個狀態數據庫stateDB。

在交易執行過程中，EVM需要不斷與stateDB交互，從stateDB中讀取相關數據，並將變更後的數據寫回stateDB。

當一個區塊中所有交易都執行完畢後，stateDB中的數據會被提交到全局狀態樹，並生成新的狀態根。狀態根是每個區塊中的重要參數，記錄了區塊執行後新的全局狀態的"壓縮結果"。

顯然，EVM的串行執行模式存在明顯瓶頸：交易必須按順序排隊執行，如果出現耗時很長的智能合約交易，其他交易只能等待，無法充分利用硬件資源，效率受到較大限制。

EVM的多線程並行優化方案

如果用生活中的例子來類比，串行執行就像只有一個櫃臺的銀行，而並行EVM則類似於有多個櫃臺的銀行。並行模式下可以開啓多個線程同時處理多筆交易，效率可以得到幾倍提升，但需要解決狀態衝突問題。

如果多筆交易都聲明要修改某個帳戶的數據，同時處理時就會產生衝突。例如，某NFT只能鑄造1個，而交易1和交易2都聲明要鑄造該NFT，如果兩個請求都得到滿足，顯然會出錯。實際操作中的狀態衝突往往更加頻繁，因此並行化處理必須有應對狀態衝突的措施。

某項目對EVM的並行優化原理

某ZKRollup項目對EVM的並行優化思路是爲每個線程分配一筆交易，並在每個線程中提供一個臨時的狀態數據庫，稱爲pending-stateDB。具體細節如下：

1. 多線程並行執行交易：設置多個線程同時處理不同的交易，線程之間互不幹擾，可以幾倍速提升交易處理速度。

2. 爲每個線程分配臨時狀態數據庫：爲每個線程都分配一個獨立的臨時狀態數據庫（pending-stateDB）。各個線程在執行交易時，不直接修改全局stateDB，而是將狀態變化結果暫時記錄在pending-stateDB中。

3. 同步狀態變更：在一個區塊內的所有交易執行完畢後，EVM將每個pending-stateDB中記錄的狀態變更結果依次同步到全局stateDB中。如果不同交易在執行過程中沒有發生狀態衝突，就可以將pending-stateDB中的記錄順利合並到全局stateDB中。

該項目對讀寫操作的處理方式進行了優化，以確保交易能夠正確訪問狀態數據並避免衝突：

• 讀操作：當交易需要讀取狀態時，EVM首先檢查Pending-state的ReadSet。如果ReadSet中存在所需數據，直接從pending-stateDB中讀取。如果ReadSet中沒有找到對應的鍵值對，則從上一個區塊對應的全局stateDB中讀取歷史狀態數據。

• 寫操作：所有寫操作（即對狀態的修改）不會直接寫入全局stateDB，而是先記錄到Pending-state的WriteSet中。待交易執行完成後，通過衝突檢測再嘗試將狀態變更結果合並到全局stateDB中。

並行執行的關鍵問題在於狀態衝突，當多筆交易嘗試讀寫相同帳戶的狀態時，該問題尤爲顯著。爲此引入了衝突檢測機制：

• 衝突檢測：在交易執行過程中，EVM會監測不同交易的ReadSet和WriteSet。如果發現多個交易嘗試讀寫相同的狀態項，則視爲發生衝突。

• 衝突處理：當檢測到衝突時，衝突交易將被標記爲需要重新執行。

在所有交易執行完成後，多個pending-stateDB中的變更記錄會被合並到全局stateDB中。如果合並成功，EVM會將最終狀態提交到全局狀態樹中，並生成新的狀態根。

多線程並行優化對性能的提升是顯著的，特別是在處理復雜智能合約交易時。研究顯示，在低衝突工作負載中，基準測試的TPS相比傳統串行執行提升了3-5倍左右。在高衝突工作負載中，理論上如果將所有優化手段都應用，甚至可以達到60倍的提升。

總結

EVM多線程並行優化方案通過爲每個交易分配臨時狀態庫，並在不同線程中並行執行交易，顯著提高了EVM的交易處理能力。通過優化讀寫操作和引入衝突檢測機制，EVM系公鏈能夠在保證狀態一致性的前提下，實現交易的大規模並行化，解決了傳統串行執行模式帶來的性能瓶頸。這爲以太坊Rollup未來的發展奠定了重要基礎。

未來還可以進一步探索如何優化存儲效率以提升性能，高衝突情況下的優化方案，以及如何利用GPU進行優化等內容。