EVM的並行化優化之路

衆所周知，EVM是以太坊最重要的核心組件之一，作爲"執行引擎"和"智能合約執行環境"發揮着關鍵作用。在由成千上萬節點組成的公鏈網路中，虛擬機的存在使得智能合約能夠在不同硬件配置的節點上以相同方式運行，確保了結果的一致性。這種跨平台兼容性與Java虛擬機JVM頗爲相似。

智能合約在上鏈前會被編譯爲EVM字節碼。EVM執行合約時，按順序讀取這些字節碼，每條指令都有相應的Gas成本。EVM會跟蹤指令執行過程中的Gas消耗，消耗量取決於操作的復雜度。

作爲以太坊的核心執行引擎，EVM採用串行執行方式處理交易。所有交易在單一隊列中排隊，按確定順序依次執行。這種設計簡單易維護，但隨着用戶羣體擴大和技術迭代，其性能瓶頸日益凸顯，尤其在Rollup技術成熟後，在以太坊二層網路中表現得尤爲明顯。

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

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

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

除EVM外，go-ethereum中與交易執行相關的另一核心組件是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的協作過程如下：

1. 區塊內的交易按先後次序被逐筆處理，每筆交易都有一個獨立實例執行具體操作。
2. 雖然每筆交易使用不同的EVM實例，但所有交易共用同一個狀態數據庫stateDB。
3. 交易執行過程中，EVM需要不斷與stateDB交互，讀取相關數據並將變更後的數據寫回stateDB。
4. 所有交易處理完畢後，stateDB中的數據會被提交到全局狀態樹，並生成新的狀態根。

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

EVM的多線程並行優化方案

並行EVM類似於有多個櫃臺的銀行，可以開啓多個線程同時處理多筆交易，效率可以得到幾倍速的提升。但棘手的是狀態衝突問題，需要進行協調處理。

某ZKRollup項目對EVM的並行優化思路如下：

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

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

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

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

• 讀操作：交易需要讀取狀態時，EVM首先檢查Pending-state的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未來的發展奠定了重要基礎。