并行執行Blockchain系統調研
撰文：PREDA；編譯：ChainFeedsResearch本文的內容和目的
無論是在傳統的數據庫領域還是在Blockchain技術中，并行執行模型的設計都較為復雜。這是因為，在設計過程中，需要綜合考慮多個維度，而每個維度的選擇都會對系統的整體性能和可擴展性產生深遠影響。本文將深入探討當前最具代表性的幾種Blockchain執行層并行架構，并詳細呈現我們針對這些架構在性能和可擴展性方面所做的實驗結果。
從一個維度來說，Blockchain領域一直處在對鏈的高性能和高可擴展性的持續追求中。即使在多鏈系統和Layer2系統出現后，每個智能合約的執行能力仍受限于單一虛擬機VM的能力。隨著并行虛擬機（ParallelVM）的出現，這一局限得到了突破。并行虛擬機允許單個智能合約的交易在多個EVM/VM上同時執行，從而利用更多的CPU核心來提高性能。
我們認為，在眾多支持并行VM的高性能Blockchain系統中，Sei（V2）、Aptos、Sui、Crystality和 PREDA 最具代表性，每個系統都具備設計上的獨特優勢。
在本文開篇，我們展示了第一組實驗結果。下圖展示了在128核的機器上，執行相同的ERC20智能合約時，Sei、Aptos、Sui、Crystality和PREDA的每秒交易數（TPS）的絕對值。從這組實驗結果來看，PREDA模型在五個并行執行系統的TPS和可擴展性比較中占據了顯著優勢。
其他實驗數據和分析，我們將在后文詳細展開。
并行執行模型一覽
Aptos和Sui兩個項目，都衍生于Meta（曾名Facebook）宣告失敗的Blockchain項目Diem。兩個項目均由前Meta工程師創立——Aptos由AveryChing創立，Sui由SamBlackshear創立。二者隨后沿循的技術路線卻不盡相同，Aptos嚴格遵循為Diem開發的原始Move編程語言，但Sui對Move進行了大量修改。
接下來，我們將探討Aptos和Sui的并行化模型的差異，分析它們采取的不同方法如何影響性能，并重點介紹它們各自的優勢。Aptos：采用樂觀并行化的高性能Layer1
Aptos是一個Layer1，通過樂觀并行化機制實現智能合約的并行執行，從而提升高性能。具體來說在樂觀并行化中，交易被初步假設為無狀態沖突并以并行方式執行。執行后，系統會檢查沖突，并通過回滾和串行執行方式或通過不同的調度，重新執行沖突交易來解決沖突。這種推測執行方法假設大多數交易不會發生沖突，從而最大化并行執行的優勢，同時提供了處理沖突的備用機制。
樂觀并行化的優勢：(1)不需要修改程序：無需對現有代碼進行更改即可輕松實現。(2)在沖突只占低到中等百分比的場景下的效率：通過允許許多交易并發進行，并在出現沖突時再處理沖突，最大化吞吐量，在許多現實場景中，沖突相對較少。
Aptos使用MOVE編程語言進行智能合約開發，并在系統實現中使用AptosMOVE虛擬機。Sui：采用悲觀并行化的高性能Layer1
Sui采用了一種悲觀并行化策略。在悲觀并行化中，系統在執行前會預先檢查交易是否可能發生資源爭用。程序員需要指定每筆交易需要訪問的資源（即狀態）。系統對每個接收到的交易進行預檢查，以檢測潛在沖突。只有不涉及與當前執行中的交易發生資源爭用的交易，才會被送至執行引擎進行并行執行。
悲觀并行化的優勢：(1)避免回滾：通過在執行前識別并避免沖突，此方法最小化了回滾和重新執行的需求，從而實現更可預測的性能。(2)在高沖突場景中的效率：在高爭用環境中非常有效，確保只有不沖突的交易并行執行，減少沖突解決所帶來的開銷。
Sui也使用MOVE編程語言，但具有自己的SuiMOVE擴展，并在系統實現中使用SuiMOVE虛擬機。Sei：與Solidity和EVM兼容的樂觀并行化
Sei最初推出公鏈時，其定位是基于CosmosSDK構建的交易型應用鏈，現在已升級為首個并行化EVM鏈。在并行執行這一層面，Sei采用了一種類似于Aptos模型的方法，我們稱之為樂觀并行化。
Sei(V2)所采用的樂觀并行，其與眾不同之處在于使用Solidity編程語言和標準Ethereum虛擬機（EVM），確保EVM和Solidity兼容性。Crystality和PREDA：并行接力執行架構
Crystality和PREDA都支持并行接力執行分布式架構（ParallelRelay-ExecutionDistributedArchitecture）。PREDA是為多EVMBlockchain架構里的并行化通用智能合約而專門設計。二者的關系是，Crystality是一種用于并行EVM/GPU的編程語言，其基礎是PREDA模型。從系統的角度來說，PREDA首次在Blockchain領域，使合約功能的完全并行化成為可能，因此能最大化一組交易的并發性。這確保了所有EVM實例的高效利用，從而達到一定硬件配置條件下的最佳性能和可擴展性。
與Solidity和Move的順序執行，和SharedEverything的架構設計不同，PREDA模型首次采用了SharedNothing架構，以打破并行執行中的狀態依賴，并確保不同的EVM實例永遠不會訪問同一片合約狀態，從而幾乎完全避免了寫沖突。
在PREDA中，合約函數被分解為多個有序步驟，每個步驟依賴于狀態中一個可并行化且無沖突的部分。用戶發起的交易首先會被發送到一個持有用戶地址狀態的EVM上。在交易執行過程中，執行流可以通過發出接力交易從一個持有當前管理所需合約狀態的EVM切換到另一個EVM的方式，實現數據不動，而執行流根據數據依賴關系在EVM之間移動。五大代表性合約的實驗數據
在我們的評估中，我們測試了五個廣泛使用的智能合約——ETHTokenTransfer、Voting、Airdrop、CryptoKitties和MillionPixel，以及MyToken(ERC20)。這些合約在包括Sei、Aptos、Sui、Crystality和PREDA在內的各種Blockchain系統上執行。我們進行了詳細的實驗，以比較不同并行執行系統的性能，重點關注每秒交易量(TPS)和加速比，這些指標衡量了在多個虛擬機上與各系統單個虛擬機上執行時相對的性能提升。
所有詳細的實驗數據，包括絕對TPS值和加速比，請參閱完整的實驗報告。
ETHTokenTransfer合約：該實驗使用了與標準ERC20智能合約相同的實際歷史ETH交易。
Voting合約：Voting合約是PREDA模型如何簡化并行投票算法的絕好例子。它利用Crystality和PREDA的數據拆分、接力和執行機制，在絕對TPS和加速比上均優于樂觀（Aptos）和悲觀（Sui）并行化方法。原本在Solidity中的順序算法現在允許跨虛擬機并行投票，并將結果從臨時數組中聚合。
AirDrop：此合約從一個地址向多個地址觸發多次Tokens或NFT轉移。它具有一對多的狀態更改模式。在這種情況下，Sei、Aptos或Sui中的兩個交易不能并行執行。只有通過并行粒度更高的PREDA模型，能使這些交易能夠以流水線模式并行處理。
CryptoKitties：這個合約是Ethereum上的一款流行游戲合約，涉及根據父母貓的基因繁殖子代貓。與前述合約不同，這個合約在處理用戶發起的交易時需要訪問多個地址狀態，包括「父貓」、「母貓」和「新生貓」。該合約在從父母基因中計算新生貓的基因時還涉及比前述合約更復雜的計算。
MillionPixel：在Ethereum上的這個游戲合約中，用戶們要搶先在地圖上標記坐標。這個智能合約用于展示PREDA模型的靈活性。除了按地址劃分合約狀態外，程序員還可以定制分區鍵，例如在這種情況下從地址類型切換為uint32類型。
Aptos交易執行包括執行和驗證兩個步驟，測試數據顯示其中大量的交易執行狀態被標記為「SUSPEND」（掛起），且這些交易執行耗時很長。「SUSPEND」意味著交易執行暫停，直到其狀態依賴關系得到解決才可以恢復執行。對于64個虛擬機上的隨機交易，執行和驗證的總次數分別為102,219次和139,426次。而對于歷史交易，這些數字增加到186,948次和667,148次，交易掛起次數從66次增加到46,913次。因此，當交易執行中發生大量狀態沖突時，回滾成為樂觀并行化的沉重負擔。
Sui執行中的時間分析
以下圖表展示了Sui在ETHToken轉賬合約測試和Voting合約測試中的耗時明細。在Sui的并行執行引擎中，有三個主要步驟：(1)排隊時間：交易被事務管理器選中之前的等待時間；(2)任務管理時間：交易被放入Sui的ExecutingTxns哈希圖或PendingTxns哈希圖，到它被Sui的ExecutionDriver接收之間的時間；(3)函數執行時間：由ExecutionDriver中的工作線程執行合約函數的時間。
任務管理時間涉Locking和等待兩個部分。對比這兩個圖表可以看出，Voting測試中的任務管理時間占整個執行時間的比例明顯比ETHToken轉賬測試大得多。這是因為在Voting測試中，訪問共享對象需要通過Locking和等待來避免沖突，使得任務管理時間比函數執行時間和排隊時間多了2到4個數量級。相比之下，在ETHToken轉賬測試中，由于只使用了OwnedObjects，繞過了并發控制，任務管理時間要少得多。
Aptos和Sui的局限性
總結來說，Aptos采用樂觀并行化，即使在存在沖突的情況下也允許并行交易執行。這種基于樂觀并發控制（OCC）的方法對以讀取為主的工作負載非常有效，這在寫入請求稀少的數據庫和大數據系統中較為常見。然而，在Blockchain系統中，由于鏈上執行涉及的gas費用，這種方法可能會產生巨大的Gas開銷。實際上，用戶通常將只讀請求（例如歷史交易或區塊查詢）發送到像Etherscan這樣的鏈下數據庫，而寫入請求則用于鏈上執行。在這種情況下，像Aptos這樣的OCC系統將頻繁遇到交易「Suspend」（中止）和掛起，從而降低并行虛擬機的整體性能。
相比之下，Sui采用悲觀并行化，嚴格驗證交易之間的狀態依賴性，并通過Locking機制防止執行過程中的沖突。這種基于悲觀并發控制（PCC）的方法更適合計算密集型工作負載，在這種情況下，PCC相關的開銷甚至小到忽略不計。但在邏輯簡單的操作中，PCC相關的開銷很容易成為性能瓶頸。在現實世界里，許多在Blockchain系統上執行的交易，如ERC20Token轉賬、MoveToken轉賬或NFT轉賬，都涉及相對簡單的操作。具體來說，ERC20Tokens轉賬通常涉及從一個地址減去一定金額并將其加到另一個地址。類似地，MoveToken轉賬或NFT轉賬涉及將一個資源或對象從一個地址移動到另一個地址。即使要考慮所有權驗證等額外檢查，這些操作也非常快速。此時，PCC的相關開銷就會成為并行系統性能的限制因素。
為了解決這些挑戰，PREDA提出了一個幾乎完全避免PCC開銷和OCC重新執行需求的系統。該方法通過高效地拆分鏈上狀態實現幾乎無沖突的并行執行。
Crystality和PREDA的性能表現
在所有合約測試中，Crystality和PREDA的性能數據都顯著優于Sei、Aptos和Sui，其中PREDA表現尤為突出，因為它以原生二進制模式而非WASM進行執行。這種高性能得益于幾乎無沖突的并行執行。PREDA從設計之初就考慮了以下2個關鍵環節：
定義不同的合約狀態范圍，系統將依據這個范圍進行狀態拆分和維護。
要實現交易的執行流從一個虛擬機到另一個虛擬機的切換。
PREDA的核心在于引入了可編程作用域（ProgrammableContractScopes），將合約狀態拆分為不重疊、可并行的細粒度片段；并引入了異步函數接力（AsynchronousFunctionalRelay），用于描述不同EVM之間的執行流切換。
我們來進一步解釋這些概念的含義，在PREDA中，一個合約函數被分解為多個有序步驟，每個步驟依賴于單一的、可并行的狀態片段，且不產生沖突。
舉個例子：通常情況下，Token轉賬涉及兩個步驟：一是提取步驟，即訪問Sender的狀態并提取指定數量的Token的，二是存入步驟，即訪問Recipient的狀態并存入相應數量的Token。像Sei、Aptos和Sui等實現的最新并行機制，試圖同步執行每個交易中的所有步驟。如果兩個交易之間的訪問狀態是共享的或被更新的，比如當Sender或Recipient相同時，這兩個交易將無法并行執行。
然而，PREDA采用了一種可拆分且異步的機制，其中交易的各個步驟根據其數據訪問依賴性進行分解，使每個步驟能夠獨立于其他步驟異步執行。對相同狀態的訪問嚴格按照原始交易塊中確定的順序進行序列化，并由共識算法保證，即由區塊創建者排序。
例如，Token轉賬交易Txn0（將Tokens從地址狀態A轉移到狀態B）和Txn1（從狀態A轉移到狀態C）可以按照順序兩次訪問A（分別用于Txn0和Txn1），然后并行訪問B和C。
