EVM並行化優化:提升以太坊交易處理效率

EVM作爲以太坊的核心執行引擎,其定位是"智能合約執行環境"。爲確保智能合約在不同節點上都能得到一致的結果,EVM提供了跨平台的虛擬機環境,類似於Java虛擬機JVM。

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

傳統EVM採用串行方式處理交易,所有交易在單一隊列中按確定順序執行。這種設計簡單易維護,但隨着用戶規模擴大和Rollup技術的應用,串行執行的性能瓶頸日益凸顯。

在Rollup架構中,Sequencer作爲Layer2的關鍵組件承擔所有運算任務。如果其他外部模塊效率足夠高,Sequencer本身的串行執行將成爲最大瓶頸。有團隊通過極致優化使Sequencer每秒最多可執行2000多筆ERC-20轉帳,但對於更復雜的交易,TPS仍會大幅下降。因此,交易處理並行化成爲未來發展趨勢。

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

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

EVM和stateDB協作構建了以太坊的交易執行環境。EVM負責解釋執行智能合約指令,根據計算結果變更區塊鏈狀態,stateDB則作爲全局狀態存儲,管理所有帳戶和合約的狀態變化。

在串行執行模式下,一個區塊內的交易會按順序逐筆處理。每筆交易使用獨立的EVM實例,但所有交易共用同一個stateDB。EVM在執行過程中需要不斷與stateDB交互,讀取相關數據並寫回變更結果。

區塊內所有交易執行完畢後,stateDB中的數據會被提交到全局狀態樹,生成新的狀態根。這種串行模式的主要瓶頸是交易必須排隊執行,無法充分利用硬件資源,特別是面對復雜的智能合約交易時效率較低。

爲提高交易處理效率,一些項目開始嘗試EVM的多線程並行優化。這類似於銀行開設多個櫃臺同時服務客戶,可以幾倍提升處理速度,但需要解決可能出現的狀態衝突問題。

某ZKRollup項目對EVM的並行優化思路是爲每個線程分配一個臨時狀態數據庫(pending-stateDB)。具體實現包括:

1. 多線程並行執行交易,互不幹擾。

2. 每個線程有獨立的pending-stateDB,交易執行時先將狀態變化記錄在此。

3. 所有交易執行完畢後,將pending-stateDB中的變更同步到全局stateDB。

該方案對讀寫操作進行了優化:

• 讀操作時先檢查pending-stateDB的ReadSet,如有所需數據直接讀取,否則從全局stateDB讀取歷史狀態。

• 寫操作不直接寫入全局stateDB,而是先記錄到pending-stateDB的WriteSet中。

爲處理狀態衝突,引入了衝突檢測機制:

• 監測不同交易的ReadSet和WriteSet,發現多個交易讀寫相同狀態項時視爲衝突。

• 衝突交易會被標記爲需要重新執行。

所有交易執行後,多個pending-stateDB的變更記錄會合並到全局stateDB,成功後提交到全局狀態樹並生成新狀態根。

研究顯示,在低衝突工作負載中,並行EVM的TPS相比傳統串行執行提升了3-5倍。在高衝突工作負載中,理論上最高可達60倍提升。

這種多線程並行優化方案,通過臨時狀態庫和並行執行,顯著提高了EVM的交易處理能力。優化讀寫操作和引入衝突檢測機制,使得在保證狀態一致性的同時實現交易大規模並行化,解決了串行執行的性能瓶頸,爲以太坊Rollup的未來發展奠定了基礎。