EVM並行化優化:突破性能瓶頸的關鍵

衆所周知,EVM是以太坊最重要的核心組件之一,被定位爲"執行引擎"和"智能合約執行環境"。由於公鏈是一個包含大量節點的開放網路,不同節點的硬件參數差異很大。爲了讓智能合約在多個節點上都能得到相同結果,滿足"一致性"要求,虛擬機技術可以在不同設備上搭建相同的環境。

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

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

作爲以太坊的核心執行引擎,EVM採用串行方式處理交易,所有交易在單一隊列中排隊並按確定順序執行。之所以不採用並行化方式,是因爲區塊鏈需要嚴格滿足一致性,一批交易在所有節點中都要按相同順序處理。如果將交易處理並行化,難以精確預判交易順序,除非引入復雜的調度算法。

以太坊創始團隊在2014-2015年出於時間緊迫,選擇了設計簡單且易於維護的串行執行方式。然而,隨着區塊鏈技術的迭代和用戶羣體擴大,對TPS和吞吐量的要求越來越高。在Rollup技術成熟後,EVM串行執行帶來的性能瓶頸在以太坊二層網路中已經顯露無疑。

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

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

接下來,我們將深入探討傳統EVM的局限性,以及並行EVM的優勢。

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

在代碼模塊層面,除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的協作處理交易過程如下:

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

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

從代碼角度看,EVM和stateDB協作執行交易的大致流程如下:

1. processBlock()函數調用Process()函數處理一個區塊中的交易。

2. Process()函數中定義了一個for循環,交易被逐筆執行。

3. 所有交易處理完畢後,processBlock()函數調用writeBlockWithState()函數,再調用statedb.Commit()函數,提交狀態變更結果。

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

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

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進行優化等內容。