作者：霧月，極客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每秒最多可執行約2,000多筆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做最佳化等等內容。
