以太坊的EVM（以太坊虛擬機器）是其核心執行引擎，負責在不同作業系統上一致地運行智慧合約。 EVM的串列執行模式導致效能瓶頸，尤其是在用戶量增加、對TPS要求提升後。為解決此問題，Reddio專案提出多執行緒優化方案，透過為每個執行緒分配臨時狀態資料庫，減少狀態衝突，顯著提高交易處理能力。研究表明，在低衝突情況下，TPS提升可達3-5倍，高衝突情況下甚至可達60倍。這為建構高效的以太坊二層解決方案提供了基礎。
作者：霧月，極客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 層和資料讀寫模組進行最大限度優化，排序器每秒最多可執行約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協議在交易時需要處理流動性礦池、價格計算、代幣互換等複雜邏輯，需要進行非常複雜的計算。
現在在執行串列模式下，EVM與stateDB這兩個元件是如何協作處理交易的呢？
在以太坊的設計中，一個區塊內的交易會依序被筆交易處理，每筆交易（tx）都會有一個獨立的實例，用來執行該交易的特定操作。雖然每筆交易都會使用不同的EVM實例，但所有交易都要佔用同一個狀態資料庫，OnestateDB。
在交易執行過程中，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的任務最佳化原理
我們可以看看專案ZKRollupReddio對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做最佳化等等內容。
資訊來源：0x資訊編譯自網際網路。版權歸作者極客Web3所有，未經許可，不得轉載