從 Reddio 看並行 EVM 的優化之路

撰文：霧月，極客 web3

眾所周知，EVM 的定位是以太坊的「執行引擎」和「智能合約執行環境」，可以說是以太坊最重要的核心組件之一。公鏈是一個包含成千上萬節點的開放性網絡，不同節點的硬件參數相差甚大，若想讓智能合約在多個節點上都跑出相同結果，滿足「一致性」，要設法在不同設備上都搭建出相同的環境，而虛擬機可以實現這個效果。

以太坊的虛擬機 EVM 能在不同操作系統（如 Windows、Linux、macOS）和設備上以相同的方式來運行智能合約，這種跨平臺兼容性確保每個節點運行合約後，都能得到一致的結果。最典型的例子就是 Java 虛擬機 JVM。

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

此外，作為以太坊的核心執行引擎，EVM 採用串行執行的方式處理交易，所有交易在單一隊列裡排隊並按照確定順序先後執行。之所以不用並行化的方式，是因為區塊鏈要嚴格滿足一致性，一批交易在所有節點中都要按相同次序來處理，如果將交易處理並行化，難以精確的預判交易次序，除非引入對應的調度算法，但這會比較複雜。

2014~15 年的以太坊創始團隊出於時間緊迫，選用了串行執行的方式。因為它設計簡單且易於維護。然而隨著區塊鏈技術的迭代和用戶群體越來越大，區塊鏈對 TPS 和吞吐量的要求越來越高，在 Rollup 技術出現併成熟落地後，EVM 串行執行帶來的性能瓶頸在以太坊二層身上已經暴露無疑。

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

opBNB 團隊曾通過對 DA 層和數據讀寫模塊進行極致優化，Sequencer 每秒最多可執行約 2000 多筆 ERC-20 轉賬。這個數字看起來很高，但如果要處理的交易比 ERC-20 轉賬複雜很多，TPS 數值必然會大打折扣。所以說，交易處理的並行化將是未來的必然趨勢。

下面我們將從更具體的細節入手，為大家詳細解釋傳統 EVM 的侷限性，以及並行 EVM 的優勢。

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

在代碼模塊層面，除 EVM 外，go-ethereum 中與交易執行相關的另一核心組件是 stateDB，用於管理以太坊中的賬戶狀態和數據存儲。以太坊採用名為 Merkle Patricia Trie 的樹狀結構來充當數據庫索引（目錄），EVM 每一次交易執行都會變更 stateDB 中存放的某些數據，這些變更最終會反映在 Merkle Patricia Trie（後面簡稱全局狀態樹）中。

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

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

串行執行的具體過程

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

與簡單的 EOA 轉賬不同，合約交易會涉及到智能合約的調用與執行。EVM 在處理合約交易時，要逐條解釋和執行智能合約中的字節碼指令，合約的邏輯越複雜，涉及的指令越多，消耗的資源越多。

舉例來說，ERC-20 轉賬的處理時間大約是 EOA 轉賬的 2 倍，而對於更復雜的智能合約，如 Uniswap 上的交易操作，耗時更長，甚至可以比 EOA 轉賬慢十幾倍。這是因為 DeFi 協議需要在交易時處理流動性池、價格計算、代幣 swap 等複雜邏輯，需要進行非常複雜的計算。

那麼在串行執行模式下， EVM 與 stateDB 這兩個組件是如何協作處理交易的呢？

在以太坊的設計中，一個區塊內的交易會按先後次序被一筆筆處理，每筆交易（tx）都會有一個獨立實例，用於執行該交易的具體操作。儘管每筆交易會使用不同的 EVM 實例，但所有交易要共用同一個狀態數據庫，也就是 stateDB。

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

我們從代碼角度大致看下 EVM 和 stateDB 是如何協作執行交易的：

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

2. Process() 函數中定義了一個 for 循環，可以看到交易是被一筆一筆執行的；

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

當一個區塊中所有交易都被執行完畢後，stateDB 中的數據會被 Commit 到前面提到的全局狀態樹（Merkle Patricia Trie），並生成新的狀態根（stateRoot）。狀態根是每個區塊中的重要參數，它記錄了區塊執行後新的全局狀態的「壓縮結果」。

我們不難理解，EVM 的串行執行模式瓶頸很明顯：交易必須按順序排隊執行，如果出現耗時很久的智能合約交易，在其處理完畢前，其他交易只能等待，這顯然無法充分利用 CPU 等硬件資源，效率會受到較大限制。

EVM 的多線程並行優化方案

如果用生活中的例子來對比串行執行與並行執行，前者類比為只有一個櫃檯的銀行，並行 EVM 則類比為有多個櫃檯的銀行。在並行模式下，可以開啟多個線程同時處理多筆交易，效率可以得到幾倍速的提升，但棘手的地方在於狀態衝突問題。

如果多筆交易都聲明要改寫某個賬戶的數據，當它們被同時處理時，就會產生衝突，比如某 NFT 僅能鑄造 1 個，而交易 1 和交易 2 都聲明要鑄造該 NFT，如果他們的請求都得到滿足，顯然會出現錯誤，應對這類情況需要進行協調處理。實際操作中的狀態衝突往往比我們提到的更頻發，所以如果要將交易處理並行化，就必須要有應對狀態衝突的措施。

Reddio 對 EVM 的並行優化原理

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

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

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

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

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

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

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

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

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

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

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

多線程並行優化對性能的提升是顯而易見的，特別是應對複雜智能合約交易時。

根據並行 EVM 的研究顯示，在低衝突工作負載（交易池中較少矛盾的或者佔用相同資源的交易）中，基準測試的 TPS 相比傳統的串行執行，提升了 3~5 倍左右。在高衝突工作負載中，理論上如果將所有優化手段都用上甚至可以達到 60 倍。

總結

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

後續我們會進一步深入分析 Reddio 的實現細節，如如何進一步從優化存儲效率提升效率，衝突高發時的優化方案，以及如何藉助 GPU 做優化等等內容。