從Reddio看并行EVM的優化之路
作者：霧月，極客web3
眾所周知，EVM的定位是Ethereum的“執行引擎”和“智能合約執行環境”，可以說是Ethereum最重要的核心組件之一。公鏈是一個包含成千上萬Node的開放性網絡，不同Node的硬件參數相差甚大，若想讓智能合約在多個Node上都跑出相同結果，滿足“一致性”，要設法在不同設備上都搭建出相同的環境，而虛擬機可以實現這個效果。
Ethereum的虛擬機EVM能在不同操作系統（如Windows、Linux、macOS）和設備上以相同的方式來運行智能合約，這種跨平臺兼容性確保每個Node運行合約后，都能得到一致的結果。最典型的例子就是Java虛擬機JVM。
Sequencer作為Layer2的關鍵組件，以單個服務器的形式承接所有運算任務，如果與Sequencer配合的外部模塊的效率都足夠高，則最終的瓶頸將取決于Sequencer本身的效率，此時串行執行將成為巨大的阻礙。
opBNB團隊曾通過對DA層和數據讀寫模塊進行極致優化，Sequencer每秒最多可執行約2000多筆ERC-20轉賬。這個數字看起來很高，但如果要處理的交易比ERC-20轉賬復雜很多，TPS數值必然會大打折扣。所以說，交易處理的并行化將是未來的必然趨勢。
下面我們將從更具體的細節入手，為大家詳細解釋傳統EVM的局限性，以及并行EVM的優勢。
Ethereum交易執行的兩大核心組件
在代碼模塊層面，除EVM外，go-ethereum中與交易執行相關的另一核心組件是stateDB，用于管理Ethereum中的賬戶狀態和數據存儲。Ethereum采用名為MerklePatriciaTrie的樹狀結構來充當數據庫索引（目錄），EVM每一次交易執行都會變更stateDB中存放的某些數據，這些變更最終會反映在MerklePatriciaTrie（后面簡稱全局狀態樹）中。
我們從代碼角度大致看下EVM和stateDB是如何協作執行交易的：
1.processBlock()函數會調用Process()函數處理一個區塊中包含的交易；
processBlock()函數調用writeBlockWithState()函數，再調用statedb.Commit()函數，提交狀態變更結果。
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中讀取歷史狀態數據。
·沖突檢測：在交易執行過程中，EVM會監測不同交易的ReadSet和WriteSet。如果發現多個交易嘗試讀寫相同的狀態項，則視為發生沖突。
·沖突處理：當檢測到沖突時，沖突交易將被標記為需要重新執行。
在所有交易都執行完成后，多個pending-stateDB中的變更記錄會被合并到全局stateDB中。如果合并成功，EVM會將最終狀態提交到全局狀態樹中，并生成新的狀態根。
多線程并行優化對性能的提升是顯而易見的，特別是應對復雜智能合約交易時。
根據并行EVM的研究顯示，在低沖突工作負載（交易池中較少矛盾的或者占用相同資源的交易）中，基準測試的TPS相比傳統的串行執行，提升了3~5倍左右。在高沖突工作負載中，理論上如果將所有優化手段都用上甚至可以達到60倍。
總結
Reddio的EVM多線程并行優化方案，通過為每個交易分配臨時狀態庫，并在不同線程中并行執行交易，顯著提高了EVM的交易處理能力。通過優化讀寫操作和引入沖突檢測機制，EVM系公鏈能夠在保證狀態一致性的前提下，實現交易的大規模并行化，解決了傳統串行執行模式帶來的性能瓶頸。這為EthereumRollup未來的發展奠定了重要基礎。
后續我們會進一步深入分析Reddio的實現細節，如如何進一步從優化存儲效率提升效率，沖突高發時的優化方案，以及如何借助GPU做優化等等內容。