眾所周知，EVM的定位是以太坊的“執(zhí)行引擎”和“智能合約執(zhí)行環(huán)境”，可以說是以太坊最重要的核心組件之一。公鏈是一個包含成千上萬節(jié)點的開放性網(wǎng)絡(luò)，不同節(jié)點的硬件參數(shù)相差甚大，若想讓智能合約在多個節(jié)點上都跑出相同結(jié)果，滿足“一致性”，要設(shè)法在不同設(shè)備上都搭建出相同的環(huán)境，而虛擬機可以實現(xiàn)這個效果。

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

我們平時在區(qū)塊瀏覽器里看到的智能合約，都是先被編譯為EVM字節(jié)碼，然后才存儲到鏈上的。EVM在執(zhí)行合約時，直接按順序讀取這些字節(jié)碼，字節(jié)碼對應(yīng)的每條指令（opCode）都有相應(yīng)的Gas成本。EVM會跟蹤每條指令在執(zhí)行過程中的Gas消耗，消耗量則取決于操作的復(fù)雜度。

此外，作為以太坊的核心執(zhí)行引擎，EVM采用串行執(zhí)行的方式處理交易，所有交易在單一隊列里排隊并按照確定順序先后執(zhí)行。之所以不用并行化的方式，是因為區(qū)塊鏈要嚴格滿足一致性，一批交易在所有節(jié)點中都要按相同次序來處理，如果將交易處理并行化，難以**的預(yù)判交易次序，除非引入對應(yīng)的調(diào)度算法，但這會比較復(fù)雜。

2014~15年的以太坊創(chuàng)始團隊出于時間緊迫，選用了串行執(zhí)行的方式。因為它設(shè)計簡單且易于維護。然而隨著區(qū)塊鏈技術(shù)的迭代和用戶群體越來越大，區(qū)塊鏈對TPS和吞吐量的要求越來越高，在Rollup技術(shù)出現(xiàn)并成熟落地后，EVM串行執(zhí)行帶來的性能瓶頸在以太坊二層身上已經(jīng)**無疑。

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

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

下面我們將從更具體的細節(jié)入手，為大家詳細解釋傳統(tǒng)EVM的局限性，以及并行EVM的優(yōu)勢。

以太坊交易執(zhí)行的兩大核心組件

在代碼模塊層面，除EVM外，go-ethereum中與交易執(zhí)行相關(guān)的另一核心組件是stateDB，用于管理以太坊中的賬戶狀態(tài)和數(shù)據(jù)存儲。以太坊采用名為Merkle Patricia Trie的樹狀結(jié)構(gòu)來充當(dāng)數(shù)據(jù)庫索引（目錄），EVM每一次交易執(zhí)行都會變更stateDB中存放的某些數(shù)據(jù)，這些變更**會反映在Merkle Patricia Trie（后面簡稱全局狀態(tài)樹）中。

具體來說，stateDB負責(zé)維護所有以太坊賬戶的狀態(tài)，包括EOA賬戶和合約賬戶，其存儲的數(shù)據(jù)包括賬戶余額、智能合約代碼等。在交易執(zhí)行過程中，stateDB會對相應(yīng)賬戶的數(shù)據(jù)進行讀寫。而在交易執(zhí)行結(jié)束后，stateDB需要將新的狀態(tài)提交到底層數(shù)據(jù)庫（如LevelDB）中，進行**化處理。

總的來說，EVM負責(zé)解釋和執(zhí)行智能合約指令，根據(jù)計算結(jié)果變更區(qū)塊鏈上的狀態(tài)，而stateDB則充當(dāng)全局狀態(tài)存儲，管理所有賬戶和合約的狀態(tài)變化。兩者協(xié)作構(gòu)建了以太坊的交易執(zhí)行環(huán)境。

串行執(zhí)行的具體過程

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

與簡單的EOA轉(zhuǎn)賬不同，合約交易會涉及到智能合約的調(diào)用與執(zhí)行。EVM在處理合約交易時，要逐條解釋和執(zhí)行智能合約中的字節(jié)碼指令，合約的邏輯越復(fù)雜，涉及的指令越多，消耗的資源越多。

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

那么在串行執(zhí)行模式下， EVM與stateDB這兩個組件是如何協(xié)作處理交易的呢？

在以太坊的設(shè)計中，一個區(qū)塊內(nèi)的交易會按先后次序被一筆筆處理，每筆交易（tx）都會有一個獨立實例，用于執(zhí)行該交易的具體操作。盡管每筆交易會使用不同的EVM實例，但所有交易要共用同一個狀態(tài)數(shù)據(jù)庫，也就是stateDB。

在交易執(zhí)行過程中，EVM需要不斷與stateDB交互，從stateDB中讀取相關(guān)的數(shù)據(jù)，并將變更后的數(shù)據(jù)寫回stateDB。

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

1. processBlock()函數(shù)會調(diào)用Process()函數(shù)處理一個區(qū)塊中包含的交易；

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

3. 在所有交易處理完畢后，processBlock()函數(shù)調(diào)用writeBlockWithState()函數(shù)，再調(diào)用statedb.Commit()函數(shù)，提交狀態(tài)變更結(jié)果。

當(dāng)一個區(qū)塊中所有交易都被執(zhí)行完畢后，stateDB中的數(shù)據(jù)會被Commit到前面提到的全局狀態(tài)樹（Merkle Patricia Trie），并生成新的狀態(tài)根（stateRoot）。狀態(tài)根是每個區(qū)塊中的重要參數(shù)，它記錄了區(qū)塊執(zhí)行后新的全局狀態(tài)的“壓縮結(jié)果”。

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

EVM的多線程并行優(yōu)化方案

如果用生活中的例子來對比串行執(zhí)行與并行執(zhí)行，前者類比為只有一個柜臺的銀行，并行EVM則類比為有多個柜臺的銀行。在并行模式下，可以開啟多個線程同時處理多筆交易，效率可以得到幾倍速的提升，但棘手的地方在于狀態(tài)沖突問題。

如果多筆交易都聲明要改寫某個賬戶的數(shù)據(jù)，當(dāng)它們被同時處理時，就會產(chǎn)生沖突，比如某NFT僅能鑄造1個，而交易1和交易2都聲明要鑄造該NFT，如果他們的請求都得到滿足，顯然會出現(xiàn)錯誤，應(yīng)對這類情況需要進行協(xié)調(diào)處理。實際操作中的狀態(tài)沖突往往比我們提到的更頻發(fā)，所以如果要將交易處理并行化，就必須要有應(yīng)對狀態(tài)沖突的措施。

Reddio對EVM的并行優(yōu)化原理

我們可以看一下ZKRollup項目Reddio對EVM的并行優(yōu)化思路。Reddio的思路是為每個線程都分配一筆交易，并在每個線程中提供一個臨時的狀態(tài)數(shù)據(jù)庫，稱為pending-stateDB。具體細節(jié)如下：

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

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

3. 同步狀態(tài)變更：在一個區(qū)塊內(nèi)的所有交易都執(zhí)行完畢后，EVM會將每個pending-stateDB中記錄的狀態(tài)變更結(jié)果依次同步到全局stateDB中。如果不同交易在執(zhí)行過程中沒有發(fā)生狀態(tài)沖突，就可以將pending-stateDB中的記錄順利合并到全局stateDB中。

Reddio對讀寫操作的處理方式進行了優(yōu)化，以確保交易能夠正確訪問狀態(tài)數(shù)據(jù)并避免沖突。

·讀操作：當(dāng)一個交易需要讀取狀態(tài)時，EVM會首先檢查Pending-state的ReadSet。如果ReadSet顯示存在所需數(shù)據(jù)，EVM就直接從pending-stateDB中讀數(shù)據(jù)。如果ReadSet中沒有找到對應(yīng)的key-value（鍵值對），就從上一個區(qū)塊對應(yīng)的全局stateDB中讀取歷史狀態(tài)數(shù)據(jù)。

·

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

并行執(zhí)行的關(guān)鍵問題在于狀態(tài)沖突，當(dāng)多筆交易嘗試讀寫相同賬戶的狀態(tài)時，該問題尤為顯著。為此Reddio引入了沖突檢測機制：

· 沖突檢測：在交易執(zhí)行過程中，EVM會監(jiān)測不同交易的ReadSet和WriteSet。如果發(fā)現(xiàn)多個交易嘗試讀寫相同的狀態(tài)項，則視為發(fā)生沖突。

· 沖突處理：當(dāng)檢測到?jīng)_突時，沖突交易將被標記為需要重新執(zhí)行。

在所有交易都執(zhí)行完成后，多個pending-stateDB中的變更記錄會被合并到全局stateDB中。如果合并成功，EVM會將**狀態(tài)提交到全局狀態(tài)樹中，并生成新的狀態(tài)根。

多線程并行優(yōu)化對性能的提升是顯而易見的，特別是應(yīng)對復(fù)雜智能合約交易時。

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

總結(jié)

Reddio的EVM多線程并行優(yōu)化方案，通過為每個交易分配臨時狀態(tài)庫，并在不同線程中并行執(zhí)行交易，顯著提高了EVM的交易處理能力。通過優(yōu)化讀寫操作和引入沖突檢測機制，EVM系公鏈能夠在保證狀態(tài)一致性的前提下，實現(xiàn)交易的大規(guī)模并行化，解決了傳統(tǒng)串行執(zhí)行模式帶來的性能瓶頸。這為以太坊Rollup未來的發(fā)展奠定了重要基礎(chǔ)。

后續(xù)我們會進一步深入分析Reddio的實現(xiàn)細節(jié)，如如何進一步從優(yōu)化存儲效率提升效率，沖突高發(fā)時的優(yōu)化方案，以及如何借助GPU做優(yōu)化等等內(nèi)容。

本文 軟文網(wǎng) 原創(chuàng)，轉(zhuǎn)載保留鏈接！網(wǎng)址：/qkl/2451.html