撰文：PREDA；編譯：ChainFeeds Research
本文的內容與目的
無論是在傳統的資料庫領域或是區塊鏈技術中，並行執行模型的設計都較為複雜。 這是因為，在設計過程中，需要綜合考慮多個維度，而每個維度的選擇都會對系統的整體效能和可擴展性產生深遠影響。本文將深入探討目前最具代表性的幾種區塊鏈執行層並行架構，並詳細呈現我們針對這些架構在效能和可擴展性方面所做的實驗結果。
從一個維度來說，區塊鏈領域一直處於對鏈的高效能和高可擴展性的持續追求中。即使在多鏈系統和Layer2 系統出現後，每個智慧合約的執行能力仍受限於單一虛擬機器VM 的能力。隨著並行虛擬機器（Parallel VM）的出現，這一限制得到了突破。平行虛擬機器允許單一智慧合約的交易在多個EVM/VM 上同時執行，從而利用更多的CPU核心來提高效能。
我們認為，在眾多支援平行VM的高效能區塊鏈系統中，Sei（V2）、Aptos、Sui、Crystality 和 PREDA 最具代表性，每個系統都具備設計上的獨特優勢。
在本文開篇，我們展示了第一組實驗結果。下圖展示了在128 核心的機器上，執行相同的ERC20 智慧合約時，Sei、Aptos、Sui、Crystality 和PREDA 的每秒交易數（TPS）的絕對值。從這組實驗結果來看，PREDA 模型在五個平行執行系統的TPS 和可擴展性比較中佔了顯著優勢。
其他實驗數據和分析，我們將在後文詳細展開。
以下，我們將詳細說明我們實驗中的具體方法和操作：
我們先比較了五個系統的TPS 值，也就是吞吐量。在不同鏈上進行的TPS 比較實驗中所使用的交易量相同。
考慮到不同系統中採用的不同程式語言和底層虛擬機器不同，單一的吞吐量比較不能完全說明系統的優劣，我們也進行了相對加速結果即Speedup Ratio 的比較，即同樣數量的交易在多個VM 相對於在一個VM 上執行的加速效果。在Sui、Aptos、Crystality 和PREDA 中，每個執行緒都分配了一個專用CPU core。
所有詳細的實驗數據，包括絕對TPS 值和加速比，請參閱完整的實驗報告。
下表中展示了實驗中所使用的資料來源、實施過程和評估方法。
平行執行模型一覽
Aptos 和Sui 兩個項目，都衍生於Meta（ 曾名Facebook）宣告失敗的區塊鏈項目Diem。兩個專案均由前Meta 工程師創立－Aptos 由Avery Ching 創立，Sui 由Sam Blackshear 創立。二者隨後沿循的技術路線卻不盡相同，Aptos 嚴格遵循為Diem 開發的原始Move 程式語言，但Sui 對Move 進行了大量修改。
接下來，我們將探討Aptos 和Sui 的平行化模型的差異，分析它們採取的不同方法如何影響效能，並重點介紹它們各自的優勢。
Aptos：採用樂觀並行化的高效能Layer 1
Aptos 是Layer 1，透過樂觀平行化機制實現智慧合約的平行執行，進而提升高效能。具體來說在樂觀並行化中，交易被初步假設為無狀態衝突並以並行方式執行。執行後，系統會檢查衝突，並透過回溯和串列執行方式或透過不同的調度，重新執行衝突交易來解決衝突。這種推測執行方法假設大多數交易不會發生衝突，從而最大化並行執行的優勢，同時提供了處理衝突的備用機制。
樂觀並行化的優點：(1) 不需要修改程式：無需對現有程式碼進行更改即可輕鬆實現。 (2) 在衝突只佔低到中等百分比的場景下的效率：透過允許許多交易並發進行，並在出現衝突時再處理衝突，最大化吞吐量，在許多現實場景中，衝突相對較少。
Aptos 使用MOVE 程式語言進行智慧合約開發，並在系統實作中使用Aptos MOVE 虛擬機器。
Sui：採用悲觀並行化的高效能Layer 1
Sui 採用了一種悲觀並行化策略。在悲觀並行化中，系統在執行前會預先檢查交易是否可能發生資源爭用。程式設計師需要指定每筆交易需要存取的資源（即狀態）。系統對每個接收到的交易進行預檢查，以偵測潛在衝突。只有不涉及與目前執行中的交易發生資源爭用的交易，才會被送至執行引擎進行並行執行。
悲觀並行化的優點：(1) 避免回溯：透過在執行前識別並避免衝突，此方法最小化了回滾和重新執行的需求，從而實現更可預測的性能。 (2) 在高衝突場景中的效率：在高爭用環境中非常有效，確保只有不衝突的交易並行執行，減少衝突解決所帶來的開銷。
Sui 也使用MOVE 程式語言，但具有自己的Sui MOVE 擴展，並在系統實作中使用Sui MOVE 虛擬機器。
Sei：與Solidity 和EVM 相容的樂觀並行化
Sei最初推出公鏈時，其定位是基於Cosmos SDK 構建的交易型應用鏈，現在已升級為首個平行化EVM 鏈。在平行執行這一層面，Sei 採用了一種類似Aptos 模型的方法，我們稱之為樂觀並行化。
Sei (V2) 所採用的樂觀並行，其與眾不同之處在於使用Solidity 程式語言和標準以太坊虛擬機器（EVM），確保EVM 和Solidity 相容性。
Crystality 和PREDA：平行接力執行架構
Crystality 和PREDA 都支援平行接力執行分散式架構（Parallel Relay-Execution Distributed Architecture）。 PREDA 是為多EVM 區塊鏈架構裡的平行化通用智慧合約而特別設計。二者的關係是，Crystality 是一種用於平行EVM/GPU 的程式語言，其基礎是PREDA 模型。從系統的角度來說，PREDA首次在區塊鏈領域，使合約功能的完全並行化成為可能，因此能最大化一組交易的並發性。這確保了所有EVM 實例的高效利用，從而達到一定硬體配置條件下的最佳效能和可擴展性。
與Solidity 和Move 的順序執行，和Shared Everything的架構設計不同，PREDA 模型首次採用了Shared Nothing架構，以打破並行執行中的狀態依賴，並確保不同的EVM 實例永遠不會訪問同一片合約狀態，從而幾乎完全避免了寫衝突。
在PREDA 中，合約函數被分解為多個有序步驟，每個步驟都依賴狀態中可並行化且無衝突的部分。用戶發起的交易首先會被送到一個持有用戶地址狀態的EVM 上。在交易執行過程中，執行流程可以透過發出接力交易從一個持有當前管理所需合約狀態的EVM 切換到另一個EVM的方式，實現資料不動，而執行流根據資料依賴關係在EVM 之間移動。
五大代表性合約的實驗數據
在我們的評估中，我們測試了五個廣泛使用的智慧合約—ETH TokenTransfer、Voting、Airdrop、CryptoKitties 和MillionPixel，以及MyToken (ERC20)。這些合約在包括Sei、Aptos、Sui、Crystality 和PREDA 在內的各種區塊鏈系統上執行。我們進行了詳細的實驗，以比較不同平行執行系統的效能，重點關注每秒交易量(TPS) 和加速比，這些指標衡量了在多個虛擬機器上與各系統單一虛擬機器上執行時相對的性能提升。
所有詳細的實驗數據，包括絕對TPS 值和加速比，請參閱完整的實驗報告。
-
ETH TokenTransfer 合約：此實驗使用了與標準ERC20 智能合約相同的實際歷史ETH 交易。
-
Voting 合約：Voting 合約是PREDA 模型如何簡化平行投票演算法的絕佳範例。它利用Crystality 和PREDA 的資料分割、接力和執行機制，在絕對TPS 和加速比上均優於樂觀（Aptos）和悲觀（Sui）並行化方法。原本在Solidity 的順序演算法現在允許跨虛擬機器並行投票，並將結果從臨時數組中聚合。
-
AirDrop：此合約從一個地址向多個地址觸發多次代幣或NFT 轉移。它具有一對多的狀態變更模式。在這種情況下，Sei、Aptos 或Sui 中的兩個交易不能並行。只有透過並行粒度更高的PREDA 模型，才能使這些交易能夠以管線模式並行處理。
-
CryptoKitties：這個合約是以太坊上的一款流行遊戲合約，涉及根據父母貓的基因繁殖子代貓。與前述合約不同，這個合約在處理用戶發起的交易時需要存取多個地址狀態，包括「父貓」、「母貓」和「新生貓」。該合約在從父母基因中計算新生貓的基因時還涉及比前述合約更複雜的計算。
-
MillionPixel：在以太坊上的這個遊戲合約中，用戶們要搶先在地圖上標記座標。這個智能合約用來展示PREDA 模型的靈活性。除了按地址劃分合約狀態外，程式設計師還可以自訂分區鍵，例如在這種情況下從地址類型切換為uint32 類型。
為了方便讀者理解上述大量數據，以下將重點放在分析兩個特別有代表性的合約。
ETH Token轉帳合約：在回放ETH 歷史交易資料時，五個系統的絕對吞吐量和可擴展性比率均較ERC20 實驗下降。這是因為歷史交易中重複的地址導致了狀態爭用（讀寫衝突或寫寫衝突），從而阻礙了這些交易在並行EVM 中的並發執行。
Voting 合約：Sei 合約幾乎只能依序執行，在運行多個EVM 時沒有速度提升。如果演算法沒有轉變為平行演算法，其他系統也會出現類似的結果。對於Aptos 和Sui 的平行實現，必須為「proposal」變數的臨時結果在不同位址初始化多個資源。此外，並行實作還必須基於投票者的地址提供手動調度，將投票者的交易引導至不同的虛擬機，並存取臨時結果以進行並行執行。
由實驗結果所得到的啟發
從實驗結果我們得到了以下啟示：
對比樂觀與悲觀並行方法
Aptos 和Sui 在不同的特定場景中各有其最佳表現。在ERC20 轉帳案例中，Aptos 表現優於Sui，這是因為ERC20 轉帳的每筆交易中使用隨機產生的位址，導致衝突非常少。相反，在ETH 測試案例中，由於回放ETH 歷史交易帶來的大量衝突，Sui 的表現優於Aptos。
Aptos 執行中的時間分析
下表展示了在運行這2 個合約時Aptos 的性能分析數據（使用相同的智能合約，但交易數據分別採用的隨機生成或歷史交易數據）。由於效能分析十分耗時，測試所使用的平行虛擬機器數量最多限制在64 個。
Aptos 交易執行包含執行和驗證兩個步驟，測試資料顯示其中大量的交易執行狀態被標記為「SUSPEND」（暫停），且這些交易執行耗時很長。 「SUSPEND」表示交易執行暫停，直到其狀態依賴關係解決才可以恢復執行。對於64個虛擬機器上的隨機交易，執行和驗證的總次數分別為102,219 次和139,426 次。而對於歷史交易，這些數字增加到186,948 次和667,148 次，交易掛起次數從66 次增加到46,913 次。因此，當交易執行中發生大量狀態衝突時，回溯成為樂觀並行化的沉重負擔。
Sui 執行中的時間分析
以下圖表展示了Sui 在ETH Token 轉帳合約測驗和Voting 合約測驗中的耗時明細。在Sui 的平行執行引擎中，有三個主要步驟：(1) 排隊時間：交易被事務管理器選取之前的等待時間；(2) 任務管理時間：交易放入Sui 的Executing Txns 雜湊圖或Pending Txns 雜湊圖，到它被Sui 的Execution Driver 接收之間的時間；(3) 函數執行時間：由Execution Driver 中的工作執行緒執行合約函數的時間。
任務管理時間涉Locking和等待兩個部分。比較這兩個圖表可以看出，Voting測驗中的任務管理時間佔整個執行時間的比例明顯比ETH Token轉帳測驗大得多。這是因為在Voting測試中，存取共享物件需要透過Locking和等待來避免衝突，使得任務管理時間比函數執行時間和排隊時間多了2到4個數量級。相較之下，在ETH Token轉帳測試中，由於只使用了Owned Objects，繞過了並發控制，任務管理時間要少得多。
Aptos 和Sui 的局限性
總結來說，Aptos 採用樂觀並行化，即使在存在衝突的情況下也允許並行交易執行。這種基於樂觀並發控制（OCC）的方法對以讀取為主的工作負載非常有效，這在寫入請求稀少的資料庫和大數據系統中較為常見。然而，在區塊鏈系統中，由於鏈上執行涉及的gas 費用，這種方法可能會產生巨大的Gas 開銷。實際上，用戶通常將只讀請求（例如歷史交易或區塊查詢）發送到像Etherscan 這樣的鏈下資料庫，而寫入請求則用於鏈上執行。在這種情況下，像Aptos 這樣的OCC 系統將頻繁地遇到交易「Suspend」（中止）和掛起，從而降低並行虛擬機器的整體效能。
相較之下，Sui 採用悲觀並行化，嚴格驗證交易之間的狀態依賴性，並透過Locking 機制防止執行過程中的衝突。這種基於悲觀並發控制（PCC）的方法更適合計算密集型工作負載，在這種情況下，PCC相關的開銷甚至小到忽略不計。但在邏輯簡單的操作中，PCC 相關的開銷很容易成為效能瓶頸。在現實世界裡，許多在區塊鏈系統上執行的交易，如ERC20 Token 轉帳、Move Token 轉帳或NFT 轉賬，都涉及相對簡單的操作。具體來說，ERC20 代幣轉帳通常涉及從一個地址減去一定金額並將其加到另一個地址。類似地，Move Token 轉帳或NFT 轉帳涉及將一個資源或物件從一個位址移至另一個位址。即使要考慮所有權驗證等額外檢查， 這些操作也非常快速。此時，PCC 的相關開銷就會成為平行系統效能的限制因素。
為了解決這些挑戰，PREDA 提出了一個幾乎完全避免PCC 開銷和OCC 重新執行需求的系統。該方法透過高效地拆分鏈上狀態實現幾乎無衝突的並行執行。
Crystality 和PREDA 的效能表現
在所有合約測試中，Crystality 和PREDA 的效能數據都顯著優於Sei、Aptos 和Sui，其中PREDA 表現尤為突出，因為它以原生二進位模式而非WASM 執行。這種高效能得益於幾乎無衝突的並行執行。 PREDA 從設計之初就考慮了以下2個關鍵環節：
-
定義不同的合約狀態範圍，系統將依據這個範圍進行狀態拆分和維護。
-
要實現交易的執行流程從一個虛擬機器到另一個虛擬機器的切換。
PREDA 的核心在於引入了可程式化作用域（Programmable Contract Scopes），將合約狀態拆分為不重疊、可並行的細粒度片段；並引入了非同步函數接力（Asynchronous Functional Relay），用於描述不同EVM 之間的執行流切換。
我們來進一步解釋這些概念的意義，在PREDA 中，一個合約函數被分解為多個有序步驟，每個步驟都依賴單一的、可並行的狀態片段，且不產生衝突。
舉個例子：通常情況下，Token 轉帳涉及兩個步驟：一是提取步驟，即訪問Sender的狀態並提取指定數量的Token 的，二是存入步驟，即訪問Recipient 的狀態並存入相應數量的Token。像Sei、Aptos 和Sui 等實現的最新並行機制，試圖同步執行每個交易中的所有步驟。如果兩個交易之間的存取狀態是共享的或被更新的，例如當Sender 或Recipient 相同時，這兩個交易將無法並行執行。
然而，PREDA 採用了一種可分割且非同步的機制，其中交易的各個步驟根據其資料存取依賴性進行分解，使每個步驟能夠獨立於其他步驟非同步執行。對相同狀態的存取嚴格按照原始交易區塊中確定的順序進行序列化，並由共識演算法保證，即由區塊創建者排序。
例如，Token轉帳交易Txn 0（將代幣從地址狀態A 轉移到狀態B）和Txn 1（從狀態A 轉移到狀態C）可以依照順序兩次存取A（分別用於Txn 0 和Txn 1），然後並行存取B 和C。
Aptos，Sei 和PREDA 中並行執行的架構比較
PREDA 和Crystality 的局限性
儘管PREDA 和Crystality 能為區塊鏈系統賦能， 提供顯著的效能優勢，但它們的限制也體現在如下方面。
並行EVM 之間工作負載不平衡
Crystality 的資料分割和執行流重新導向機制可能會導致並行EVM 在執行時出現負載不均衡的問題。我們在用MyToken 合約重播歷史ETH Token轉帳交易時觀察到了這個問題。
為了評估負載分佈情況，我們統計了每個EVM 上執行的交易數量，包括原始交易和接力交易，然後計算了這些數量的極差和標準差。結果顯示，在64 個EVM 上執行的交易數量極差與2 個EVM 上的範圍相當，這意味著在某些EVM地址存在熱點問題（即歷史交易集中發生在一部分地址上）。對ETH 資料集的進一步調查發現，每個熱點地址涉及高達4000 多筆交易。這裡必須指出的是，據我們了解，Aptos 和Sui 在這種情況下，也無法做並行化執行。
我們的測試數據表明，隨著EVM 數量的增加，標準差有所降低，這意味著增加更多的EVM 有助於緩解負載不平衡問題。
為了解決區塊鏈上的熱點問題，一個可行的解決方案是使用多個地址而不是單一地址來發送或接收代幣。如果負載不均衡是由於幾個非熱點位址對應到同一虛擬機器造成的，那麼分片（Sharding）區塊鏈中的現有方法，例如資料遷移，可能會有所幫助。
程式重寫
PREDA 和Crystality 的另一個顯著的限制是，開發者需要使用directives 重寫智慧合約。如果有工具可以自動將Solidity、Move 或Rust 編寫的現有智慧合約翻譯為等效的Crystality 智慧合約，將會大幅優化開發者的體驗。從前人經驗看來，也不難實現，已經有一些研究探討了不同語言之間的翻譯，例如從Solidity 到Move 和從Python 到Solidity。
自然語言處理的技術進步，大大增強了自動程式碼產生的潛力。這些進展結合基於規則和模式的編譯器翻譯技術（如用於大數據的SQL 到MapReduce 翻譯和用於深度學習的計算圖到矩陣計算的翻譯）完全可以為開發自動化的智能合約翻譯工具， 提供助力。
結論
Sei、Aptos、Sui 與Crystality/PREDA 之間的績效對比突顯了區塊鏈並行化領域的不斷演變。 Aptos（與Sei）和Sui 分別展示了樂觀並行化和悲觀並行化機制的潛力，各自在不同場景下展現了優勢。然而，Crystality 和PREDA 顯著的性能提升表明，更先進的平行化模型可能是解鎖更高層級的可擴展性和效率的關鍵。
為了總結我們對區塊鏈領域三種主要並行化方法的探索和觀察，我們整理匯總了一張表格。如果您想從這篇文章中獲得一份Takeaway，那就是本表格中的內容。
