以太坊的 EVM 由於其單執行緒架構，面臨嚴重的效能問題，尤其是在處理高並發交易時。這種串行執行方式限制了網路的吞吐量，導致處理速度遠遠無法滿足日益增長的用戶需求。我們透過一步一步分析EVM 串列執行的全流程，發現了以太坊想要實現並行執行的兩個主要軟體問題： 1. 狀態識別2. 資料架構以及IPOS 消耗，針對這兩個問題，各家都有自己的解決方案，面臨多個權衡包括EVM 相容與否、識別使用樂觀還是悲觀並行、資料庫的資料架構、更多的使用記憶體高效率或硬碟的高並發通道、開發者開發體驗、硬體的要求、模組化還是單片鏈架構，這些都值得仔細衡量。
我們同時也注意到了，雖然並行執行像是指數級拓展了區塊鏈，但是其仍然有瓶頸，這個瓶頸是分散式系統天生的，包括P2P網路、資料庫本身吞吐量等問題。區塊鏈運算想要達到傳統電腦的運算能力，仍然有很長的路要走。目前並行執行本身也面臨一些問題，包括並行執行的硬體要求越來越高，節點越來越專業化帶來的中心化、審查風險，並且在機制設計上依賴記憶體、中心集群或節點也會帶來宕機風險，同時，在平行區塊鏈間跨鏈通訊也會是一個問題。這仍然值得更多團隊去探索。
從各家的架構以及對 EVM 的兼容的思考中，我們深知，顛覆性創新來自於對過去的不妥協。區塊鏈技術仍然在早期，而效能提升也遠未到達終局，我們迫不及待的想要見到更多不願意妥協、不循規蹈矩的創業者建構更強大且有趣的產品。
Ethereum 的單線程問題
Ethereum EVM 一直以來在效能上都飽受詬病，主要是由於其落後的架構設計，其中不支援並行化的問題是最為嚴重的。對於交易並行化，相當於一條馬路變成了多道跑道，這能為道路上的可容納流量帶來指數級的提升。
深入 Ethereum，在目前執行層與共識層分離的背景下，我們會發現 EVM 的交易處理全部是串列執行。
以太坊的交易執行流程
在以太坊的交易中，使用者首先會將交易透過 RPC 發送到 Mempool，之後 Builder 選擇利潤最大化的交易，並且將其排序，此時交易的順序已經確定。 Proposer 將交易廣播給共識層，共識層確定該區塊的有效性，例如是來自有效的發送著，區塊中的交易作為執行負載發送給執行層，執行層執行交易，執行交易的簡略過程如下：（以Alice 發送1 ETH 給Bob 為例）
1. 在執行節點的 EVM 中，其會把 NO.0 的交易指令轉換為 EVM 能夠辨識的 OPcode 代碼。
2. 然後根據 OPcode 硬編碼，確定這筆交易所需的 Gas。
3. 執行的交易過程中，需要存取資料庫得到 Alice 和 Bob 餘額的狀態，然後執行交易 opcode 知道 Alice 餘額減一，Bob 加一，向資料庫寫入/更新此餘額狀態。
4. 從區塊中，取出 NO.1 的交易繼續順序的循環執行，直到該區塊的交易執行完畢。
5. 資料庫中的資料主要是以Merkel 數的形式來儲存的，最終該區塊的交易全部順序執行完畢以後，資料庫中的狀態根（儲存帳戶狀態）、交易根（儲存交易的順序）、收據根（儲存交易的附帶訊息，如成功狀態和Gas Fees）會提交到共識層。
6. 共識層收到狀態根即可非常輕的證明交易的真實性，執行層將驗證資料傳回共識層，區塊現在被視為已驗證。
7. 共識層將區塊添加到其自己的區塊鏈的頭部並對其進行證明，並透過網路廣播該證明。
這個就是整個全流程，裡面涉及了區塊內交易的順序執行，主要是每一筆交易都有自己的 NO，並且每一筆交易都可能需要讀取資料庫中的狀態，並且重寫狀態。如果不是順序執行，那麼就會導致狀態衝突，因為有一些交易是相互依賴狀態的。所以，這也是為什麼 MEV 選擇串列執行的原因。
MEV 的簡單，這同時也意味著，帶來了串行執行帶來了極低的性能表現，這是以太坊僅僅兩位數TPS 的主要原因之一。在現在的聚焦消費者應用程式的發展背景下，EVM 作為落後的設計範式，面臨著亟待改善的效能問題，雖然當前EVM 已經走向了一個完全以Layer 2 為中心的路線圖，但是其EVM 的問題，如MPT trie 結構，資料庫如LevelDB 的低效率等都是亟待解決的。
伴隨著這個問題的演進，有許多專案開始著手建構並行高效能 EVM，以解決以太坊老舊的設計範式。透過在 EVM 的流程中，能夠看出這裡有兩個高效能 EVM 主要解決的問題：
1. 交易狀態分離：交易由於存在狀態的相互依賴，因此需要串行運行，需要將狀態獨立的交易分離出來，然後想依賴的仍然需要順序執行。那麼就可以分發給多個核心並行處理。
2. 資料庫架構改進：以太坊使用MPT 樹，由於一筆交易涉及大量的讀取操作，通常情況下，這會導致極高的資料庫的讀寫操作，也就是IOPS（IO Per Second）要求極高，通常的消費級SSD 無法滿足這一需求。
總的來說，在目前的主流的區塊鏈建構方案中，往往在軟體上的最佳化主要是交易狀態的分離以建立可並行的交易以及資料庫的最佳化以支援高並發的交易狀態讀取。伴隨著對高效能的需求，大多數專案的對硬體的需求也在提高。以太坊一直以來對 Layer 1 的性能拓展都非常謹慎，因為這意味著中心化與不穩定性。但是目前的高效能 EVM 往往拋棄了這些為自己添加的桎梏，引入了極致的軟體改進、P2P網路優化、資料庫重構、企業級專業硬體。
衍生的資料庫 IOPS 問題
平行執行的辨識與分離其實在理解上不難，主要難和較少被大眾討論的是資料庫的 IOPS 問題。在本文中，我們也將用實際例子，讓讀者感受到區塊鏈資料庫面臨的複雜難題。
在以太坊中，全節點實際上安裝的是虛擬機，可以認為是我們的普通計算機，我們的資料都儲存在專業的軟體中——資料庫。以這個軟體來管理龐大的數據。不同的產業資料有不同的資料庫類型的需求，例如 AI 這種資料種類龐雜的領域比較火熱的就是向量資料庫。在區塊鏈領域如以太坊所使用的就是較簡單的 Key-Value Pair 的資料庫。
以太坊資料組織方式示意圖，圖源： Github
通常資料庫中的資料都會以一種抽象的方式組織在一起，以太坊就是以 MPT 樹的方式。 MPT 樹最後的資料狀態會形成一個根節點，如果任何的資料有了更改，根節點都會變化，因此使用 MPT 能夠很方便的驗證資料完整性。
我們舉一個例子來感受一下目前資料庫的資源消耗：
在一個擁有n 個葉子節點的k 叉Merkle Patricia Tree（MPT）中，更新單一鍵值對需要進行O( klog kn ) 次讀取操作和O( log kn ) 次寫入操作。例如，對於一個擁有160 億個鍵（即1 TB 區塊鏈狀態）的二元MPT，這相當於大約68 次讀取操作和34 次寫入操作。假設我們的區塊鏈想要處理每秒10, 000 筆轉帳交易，需要更新狀態樹中的三個key-value，總共需要10 ， 000 x 3 x 68 = 2 ， 040 ， 000 次，也就是2 M IOPS（I/O Per Second）操作（在實務中，可以透過壓縮和快取來減少一個數量級，大約是20 萬IOPS，我們不做展開）。目前主要的消費級 SSD 完全無法支援此操作（Intel Optane DC P 580 0X 800 GB 僅為 10 萬 IOPS）。
MPT 樹目前面臨了許多問題，包括：
● 效能問題：MPT 由於其層次化的樹狀結構，在更新資料時，往往需要遍歷多個節點。每次狀態更新（如轉帳或智慧合約執行）需要進行大量的雜湊計算，並且由於需要存取許多層的節點，因此效能較低。
● 狀態膨脹：隨著時間推移，區塊鏈上的智慧合約、帳戶餘額等狀態資料會不斷增加，導致MPT 樹的大小持續膨脹。這會導致節點需要儲存越來越多的數據，為儲存空間和同步節點帶來了挑戰。
以太坊狀態膨脹情況（涉及狀態修剪），圖源： Etherscan
● 無法有效率地處理部分更新：當樹結構中的某個葉子節點改變時，整個路徑上的節點都會受到影響。以太坊MPT 需要重新計算從葉節點到根節點的所有雜湊值，這導致即便是局部的狀態變更，也需要對大量的節點進行更新，從而影響效能。
我們能夠看到，目前 MPT 下的以太坊面臨多種問題，其也提出了多種解決方案，例如針對狀態膨脹會進行狀態修剪、針對 MPT 效能問題會建構新的 Verkel Tree。透過建立新的Verkel Tree 結構的資料庫，透過減少樹的深度來減少部分更新時資料庫的存取次數，使用向量承諾（主要以KZG 承諾為主）來減少證明的體積同時也減少資料庫的存取量。
總之，過去的 MPT 樹的涉及以及過於老舊，面臨了許多新的挑戰，因此改變資料的儲存方式如使用 Verkel tree 已經被列入其路線圖。但這只是非常微弱的修改，仍然沒有涉及並行執行以及高並發下要求的高 IOPS 的解決方案。
新公鏈標配並行執行
就如我們上一部分所言，並行執行意味著從單車道改為多車道，在多車道的十字路口往往需要一個中間件如紅綠燈協調，發送信息以使各個車道能夠順暢通過。區塊鏈也是，在平行交易中，我們需要把用戶的交易通過一個狀態識別的中間件，讓狀態互不相干的交易能夠分離從而達到並行執行，並行執行帶來的高TPS，同時意味著對底層資料庫的大量IOPS 需求。幾乎所有的新 Layer 1 都有以並行執行作為標配 feature。
平行執行的實作方案有多種分類方式，依照底層的虛擬機，分為 EVM（Sei、MegaETH、Monad）和 None-EVM（Solana、Aptos、Sui）。依照交易狀態的分離方式，可以分為樂觀執行（假設全部交易都不想幹，如果狀態衝突則回退這部分交易重新執行）和提前聲明（開發者需要在程式中聲明存取的狀態資料）。這些分類也同時意味著權衡。
接下來，我們將不以是否為 EVM 作為劃分，而是單純的從各個公鏈在狀態分離以及資料庫方面的改善情況來進行比較。
MegaETH
MegaETH 嚴格來說是一個以性能為主要目標的異質區塊鏈，其依賴以太坊的安全性使用 EigenDA 作為共識層和 DA 層。而其作為執行層，將最大程度的釋放硬體效能提升 TPS。
對於交易處理的優化手段其分為三種：
1. 狀態分離：採用交易優先順序的方式的串流區塊建構。這個模式和 Solana 的 POS 有相似之處，實際上 Solana 的交易也是流式構建的，但是 Solana 沒有優先級，全部靠速度來競爭。而 MegaETH 希望能夠為交易建構某種優先權演算法。
2. 資料庫：針對 MPT Trie 的問題，其建構了新的資料結構來提供更高的 IOPS。我們查閱 MegaETH 的程式碼庫時，發現其也有同時參考 Verkel Trie 的設計方式。
3. 硬體專業化：透過將排序器中心化和專業化，實現記憶體計算從而顯著提高 IO 的效率。
實際上，MegaETH 希望作為Layer 2 將安全性和抗審查性委託給Ethereum，這樣就能夠最大限度的優化節點，透過POS 的經濟安全性來保障排序器的不作惡，這裡有許多值得chanllenge 的點，但是我們不做展開。雖然 MegaETH 在構建並行執行的交易，但是實際上，其目前並未實現並行執行，其希望將單一排序器節點的性能做到極限以此最大程度的以硬體拓展性能，然後再通過並行執行拓展性能。
Monad
與 MegaETH 不同，Monad 是一條單獨的鏈，其符合我們介紹的平行執行需要最佳化的兩個重要的點，並行執行的狀態分離以及資料庫重構。我們簡述 Monad 使用的具體方法：
● 樂觀並行執行：對於交易的識別，採用了最為經典的默認所有交易的狀態都是不想關的，當遇到狀態衝突時，再重新運行交易，這一方式目前在Aptos 的Block-STM 機制上運作良好。
●資料庫重構：Monad 為了提高資料庫的IOPS，因此重構了相容EVM 的資料結構MPT（Merkel Patricia Tree），Monad 實作了相容於Patricia Tree 的資料結構，並且支援最新的資料庫的非同步I/O，能夠支援在讀取某個狀態時，不需要等待對該資料的寫結束。
● 非同步執行：在以太坊上，雖然我們嚴格的識別了具體的共識層以及執行層，但是我們發現共識層與執行層（與Layer 2 作為執行層的概念不相同，在這裡指以太坊仍然需要執行節點以執行以太坊上的交易）仍然是耦合在一起的，執行將執行後更新的Merkel Root 給到共識，以便共識層才能投票以達成共識。 Monad 認為狀態在排序完成的那一刻就已經定下來了，所以只需要對排序後的交易達成共識，甚至不需要執行來揭示這一結果。這個想法，讓 Monad 能夠巧妙的將共識層與執行層拆離開來，以此來實現共識同時執行。節點可以在維持對 N 區塊的共識投票的同時，去執行 N-1 區塊的交易。
當然，Monad 還有許多其它的技術包括新的共識演算法 MonadBFT 等共同建構了一個高效能的平行 EVM Layer 1 。
Aptos
Aptos 從Facebook 的Diem 團隊拆分而來，其與Sui 共同視為Move 雙雄，雖然如此，兩家因為技術理念的不一致，導致了當前兩家的Move 語言已經大不相同，整體來說，Aptos更遵循當初Diem 的設計，而Sui 對此設計進行了大刀闊斧的修改。
針對並行執行需要解決的問題：
●狀態辨識：樂觀並行執行，Aptos 開發了 Block-STM 並行執行引擎，預設樂觀執行交易，如果遇到狀態衝突，則重新執行。目前這項技術已被普遍接受，如 Polygon、Monad、Sei、StarkNet 均使用此技術。
● IO 改進：Block-STM 使用了多版本的資料結構以避免狀態衝突。舉個例子，假設我們其他人正在寫一個資料庫，那麼正常來說，我們是無法存取的，因為需要避免資料的衝突，但是多版本的資料結構可以允許我們存取過去的版本。問題在於，這個方案會造成巨大的資源消耗，因為你需要為每個執行緒產生一個可見的版本。
● 非同步執行：和 Monad 類似，交易傳播、交易排序、交易執行、狀態儲存和區塊驗證都是同時進行的。
目前Block-STM 已經被大多數公鏈接受，並且被Monad 稱為多虧了這項技術的出現，能夠有效減緩開發者的壓力，但是Aptos 面臨的問題是，Block-STM 的智能化帶來了對節點要求過高的問題，這問題需要專業化硬體以及中心化的去解決。
Sui
Sui 也和 Aptos 一樣，繼承自 Diem 計畫。相較之下，Sui 使用悲觀並行化，嚴格驗證交易之間的狀態依賴關係，並採用鎖定機制來防止執行期間發生衝突。而 Aptos 希望能夠減輕開發者的開發負擔。
● 狀態識別：與Aptosb 不同，採用了悲觀並行化，因此開發者需要聲明自己的狀態訪問，而不是將並行的狀態識別交給系統來處理，增加了開發者的開發負擔，減輕了系統的設計複雜度，同時也增加了並行化的能力。
● IO 改進：IO 改進目前主要是改進模型，以太坊使用基於帳戶的模型，每個帳戶維護其數據，但是Sui 採用了Objects 的結構代替帳戶模型，該架構的改進會顯著影響並行性實施的難度與峰值性能。
Sui 因為不存在EVM 的歷史遺留問，也沒有兼容性的問題，其基於Move 係都進行大刀闊斧的更改，對於帳戶模型，其也提出了創新性的想法Objects，這種抽象層面上的創新實際上更難。但其 Objects 模型帶來了對平行處理的許多好處，也是因為 Objects 模型，其建構了一個非常與眾不同的網路架構，在理論上確實能夠無限拓展。
Solana - FireDancer
Solana 被視為平行運算的先驅，Solana 的理念一直以來都是區塊鏈系統應該隨著硬體的進步而進步，以下是當前 Solana 的平行處理方式：
●狀態辨識：與 SUI 一樣，Solana 也使用確定性並行方式，這來自於Anatoly 過去處理嵌入式系統的經驗，在嵌入式系統中，通常會預先聲明所有狀態。這使CPU 能夠知道所有的依賴關係，從而使它能夠預先載入記憶體的必要部分。結果就是優化了系統執行，但再一次，它要求開發人員預先做好額外的工作。在Solana 上，程式的所有記憶體依賴都是必需的，並在建置的交易（即存取清單）中進行聲明，從而使運行時（runtime）能夠高效地調度及並行執行多個交易。
● 資料庫：Solana 利用Cloudbreak 建立了自己的自訂帳戶資料庫，其使用的是以帳戶為模型，帳戶資料分佈在多個「分片」上，類似於將圖書館分為幾層，並且其可以根據需要增加或減少層數以負載平衡。其在 SSD 上會映射給內存，因此透過管線設計可以快速透過內存操作 SSD，同時支援多數據的並行訪問，能夠同時並行處理 32 個 IO 操作。
Solana 透過確定性並行方式要求開發者聲明其需要訪問的狀態，這確實與傳統的變成情況相似，在程序構建方面是需要開發者自己構建並行應用程序，而程序調度和運行時流水線異步並行則是專案需要建構的。在資料庫方面，其透過自建自己的 DataBase 進行資料並行化以提高 IPOS。
同時，後續的Solana 迭代的客戶端，Firedancer 是由Jump Trading 這一具有非常強大工程能力的量化巨頭所推動研發的，與Solana 的願景相同，目標是消除軟體效率低下並將性能推向硬件的極限。其改進主要是針對硬體底層的改進，包括P2P傳播、硬體的 SIMD 資料並行處理等，這與 MegaETH 的想法非常相似。
Sei
Sei 目前使用的是
●樂觀並行執行：參考自 Aptos 的 Block-STM 設計。 Sei V1版本使用的是類似 Sui、Solana 的負面並行方案也就是需要開發者自己宣告使用的對象，但是在 Sei V2後，其改成了 Aptos 的樂觀並行方案。這會對可能缺乏開發者的 Sei 有所助益，能夠更便捷的將合約從 EVM 生態遷移過來。
SeiDB 設計，圖源： Sei
● SeiDB：整個資料庫解決方案是基於Cosmos 的ADR-065 提案基礎上建構的，其實體使用的是PebbleDB ，資料結構的設計上將資料分為活動資料和歷史數據，SSD 硬碟內的資料映射成內存上的數據，同時SSD 數據使用MemIAVL 樹結構，而記憶體數據使用IAVL 樹（ Cronos 發明）進行狀態承諾，就是其提供運行共識的狀態根。 MemIAVL 的抽像想法是，每次提交新區塊時，我們都將從該區塊的交易中提取所有變更集，然後將這些變更應用於目前記憶體中的IAVL 樹，從而為最新區塊生成樹的新版本，以便我們可以獲得區塊提交的Merkle 根雜湊。因此，相當於使用記憶體進行熱更新，這能讓大部分的狀態存取都位於記憶體上，而不是 SSD，以此來提升 IOPS。
SeiDB 的主要問題是，如果最新的活躍資料存放在記憶體上，那麼會出現宕機資料遺失的情況，所以 MemIAVL 引入了WAL 檔案和樹快照。在一定的時間內，需要快照記憶體上的數據，存放在本地的硬碟上，控制一定的時間快照間隔，及時控制資料膨脹對記憶體的 OOM 影響。
平行對比
Full-node Requirement
運行全節點要求
FireDancer 對節點的運作需求是最高的，可以稱為是效能怪獸。 MegaETH 的主要性能要求集中在 Sequencer 要求具備 100+cores。而由於存在中心化的節點 sequencer，所以其它 full node 節點要求並不高。目前 SSD 價格都較低，所以一般我們看 CPU 和 Memory 的效能要求即可。我們將 Full Node 性能要求從高到底排序分別是：Firedancer > Sei > Monad > Sui > Aptos > MegaETH > Ethereum.
方案
目前的平行處理的方案，一般來說，我們在軟體層面的最佳化主要是1. 資料庫 IOPS 消耗問題2.狀態辨識問題3. 管線非同步問題，這三方面進行軟體層面的最佳化。狀態辨識目前分為兩個陣營，分別是樂觀並行執行和聲明式程式設計。這兩種都有利有弊，其中樂觀並行執行主要是以Aptos 的Block-STM 方案為主，其主要c 採用者包括Monad、Sei V2，而Sui、Solana、Sei V1都是聲明式編程，這個比較類似於傳統的並發或非同步程式設計的範式。對於資料庫的 IPOS 消耗問題，各家的解決方案較為不同：
方案對比
對於資料結構，我們看到一個比較有趣的一點，Monad 盡量放在 SSD，但是硬碟的讀取速度遠低於 Memory 內存，但是價格便宜很多。 Monad 放在 SSD 考慮了價格、硬體門檻以及並行程度，因為現在 SSD 能夠支援 32 通路的 I/O 操作，以此提升更多的平行能力。相反，Solana、Sei 選擇記憶體映射，因為記憶體的速度遠高於 SSD。一個是橫向拓展平行通路，一個是縱向拓展降低 I/O 消耗。這也是出現了 Monad 的節點要求是 32 GB，但是 Sei 和 Solana 需要更多記憶體的原因。
除此之外，以太坊的資料結構是由Patrci Tree 演進得到Merkel Patric Tree 得來，所以EVM 相容的公鏈需要相容於Merkel Trie，因此其無法建構像Aptos、Sui、Solana 等抽象方式去思考資產，以太坊是以帳戶模型，但Sui 是Objects 模型、Solana 是資料與程式碼分離的帳戶模型，而以太坊確實耦合在一起的。
顛覆性創新來自於對過去的不妥協，在商業的角度確實也需要考慮開發者群體以及過去的兼容性，對 EVM 的兼容有其利弊。
展望
目前並行執行的主要最佳化元件都有了比較清晰的目標，主要集中在如何識別狀態、如何提高資料的讀取和儲存的速度，因為這些資料的儲存方式會導致讀取或儲存一個資料造成額外的開銷與消耗，特別是Merkel trie 引入了根驗證這一有點，但是帶來了超級高額的IO 開銷。
雖然並行執行，像是指數級拓展了區塊鏈，但仍有瓶頸，這個瓶頸是分散式系統天生的，包括P2P網路、資料庫、等問題。區塊鏈運算想要達到傳統電腦的運算能力，仍然有很長的路要走。目前並行執行本身也面臨一些問題，包括並行執行的硬體要求越來越高，節點越來越專業化帶來的中心化、審查風險，並且在機制設計上依賴記憶體、中心集群或節點也會帶來宕機風險，同時，在平行區塊鏈間跨鏈通訊也會是一個問題。
雖然，目前並行執行仍然有一定問題，各家都在探索最佳的工程實踐，包括以 MegaETH 為首的模組化設計架構和 Monad 為首的單晶片設計架構。目前並行執行的優化方案，確實證明了區塊鏈技術正在不斷的朝著傳統的電腦優化方案靠近，並且越來越底層進行優化，特別是數據存儲、硬體、流水線等技術上的細緻優化。但是，這句話仍然存在瓶頸和問題，因此仍有非常廣闊的探索空間留給創業者。
顛覆性創新來自於對過去的不妥協，我們迫不及待的想要見到更多不願意妥協的創業者建構更強大且有趣的產品。
免責聲明：
以上內容僅供參考，不應被視為任何建議。在進行投資之前，請務必尋求專業建議。
關於Gate Ventures
Gate Ventures是Gate.io 旗下的創投部門，專注於對去中心化基礎設施、生態系統和應用程式的投資，這些技術將在Web 3.0 時代重塑世界。 Gate Ventures與全球產業領袖合作，賦予那些擁有創新思維和能力的團隊和新創公司，重新定義社會和金融的互動模式。
官方網站： https://ventures.gate.io/ Twitter： https://x.com/gate_ventures Medium： https://medium.com/gate_ventures
