並行執行引擎有望極大改善當前智能合約平台的吞吐量

原文：The Case for Parallel Processing Chains

作者： Mohamed Fouda

編譯： wesely，DeFi 之道

原用標題（譯後）： “並行式” 公鏈詳解

當我們審視整個區塊鏈技術發展時，我們可以看到一個非常大的趨勢，即新的 L1 更注重並行執行的能力。這個做法並不新鮮，比如在 Solana 的 Sealevel 執行環境就採用了並行執行，在過去的牛市當中，伴隨著 DeFi 和 NFT 迅猛地發展，表明了這種改進的迫切性。當前採用並行執行理念的知名項目主要有 Aptos, Sui, Linera 和 Fuel。

本文將會討論了這些項目的異同之處，以及它們所面臨的各種挑戰。

問題

智能合約平台支持創建各類去中心化的應用程序，為了執行這些應用程序，需要一個共享的計算引擎。公鍊網絡中的每個節點都會運行這個計算引擎，並執行應用程序和用戶的交互，當節點從執行後獲得相同的結果時，它們就會達成共識並推進上鍊。

以太坊虛擬機是最主要的智能合約 (SC) 執行引擎，擁有大約 20 種不同的實現方式。自 EVM 創建以來，它已經被開發人員廣泛採用。除了以太坊和以太坊的 L2 外，其他幾個鏈包括 Polygon、BNB Smart Chain 和 Avalanche c Chain 都採用了 EVM 作為執行引擎，並專注於改變共識機制來提高網絡吞吐量。

EVM 的一個主要限制因素是事務的順序執行。EVM 本質上是一次執行一個事務，執行時會將其他事務置於暫停狀態，直到此事務執行完成，並更新區塊鏈狀態。即使兩個交易是獨立的，例如，Alice 給 Bob 付款和 Carol 給 Dave 付款兩個事務，EVM 不能並行執行這兩筆交易。即使這種執行模型也有一些其他的用例，例如閃電貸款，但它既不高效，也無法擴展。

事務的執行順序也限制了是網絡吞吐量。首先，它會導致區塊中交易的執行時間的拉長，此外，它還限制了可添加到區塊中的交易數量，讓節點執行交易並確認區塊。以太坊的平均吞吐量約為 17 tx/sec。這種低吞吐量意味著在高活動期間，例如 NFT 鑄造事件中，節點礦工/驗證者無法處理所有交易，並會發生 GAS 費用的競標戰，來確保交易的優先執行。以太坊的平均費用在某些時候甚至超過了 0.2 ETH，讓許多用戶望而卻步。順序執行模式的第二個問題是網絡節點的低效率。順序執行的模式難以從多核處理器中受益，這會導致硬件利用率低，這阻礙了可擴展性，並造成不必要的能源浪費。

並行執行

EVM 的上述限制為專注並行執行（PE）的新 L1 提供了更多的發展契機。並行性允許在多個處理器內核之間劃分事務處理，從而提高硬件利用率，從而更好的實現可擴展性。在高吞吐量鏈中，增加硬件資源與可以執行的事務數量直接相關。在鏈上的高活動期間，驗證者節點可以委託更多核心來處理額外的交易負載。計算資源的動態擴展允許網絡在高需求時期實現更高的吞吐量，從而顯著改善用戶體驗。

這種方法的另一個優點是改進了交易確認的延遲性。節點資源的動態擴展使得低延遲交易成為可能，交易不需要等待數十或數百個區塊，也不會產生過多的 GAS 費用來搶跑確認，確認時間提高了交易的最終確定性，並為低延遲區塊鏈打開了大門。保證執行事務的低延遲可以實現以前難以實現的一些功能。

改變公鏈的執行模式的 PE 並不是一個概念，目前已有多個項目在進行探索。一種實現方法是將 EVM 使用的賬戶模型替換為 Unspent Transaction Output (UTXO) 模型。UTXO 執行模型用於比特幣，它允許並行交易的處理，這是實現支付的一種理想選擇。但由於 UXTO 的功能有限，因此需要進行擴展以實現智能合約相關的複雜交互。例如，Cardano 使用了擴展的 UTXO 模型，Findora 採用了混合 UTXO 模型，該模型融合兩種不同的模型，並允許用戶在兩​​種模型之間更改資產類型。

PE 的另一種方法不會改變賬戶模型，而是專注於改進鏈狀態的架構。這種方法的一個例子是 Solana 的 Sealevel ‌框架，後文將會講述。

並行執行如何工作？

並行執行的工作原理是識別獨立的事務並同時執行它們。如果一個事務的執行會影響另一個事務的執行，那麼兩個事務就是相互依賴的，這是就會按照順序執行。例如，同一個池中的 AMM 事務是依賴的，他們就必須按順序執行。

雖然並行處理的概念很簡單，但問題在於細節。其中主要挑戰是如何有效識別 “獨立” 的交易。獨立交易的分類需要了解每筆交易如何改變區塊鏈內存或鏈狀態，與同一智能合約交互的交易可以同時更改合約狀態（例如 AMM 池），因此不能同時執行。在當前應用程序的可組合程度下，識別依賴關係是一項很具有挑戰性的任務。比如有一個 AMM 事務是將 Uni 轉換為 USDC, AMM 路由器發現執行該事務最有效的路由是 Uni -> ETH -> DAI -> AAVE -> USDC，在事務完全執行並更新所有涉及的池狀態之前，該事務涉及的所有池不能處理任何其他事務。

識別獨立交易

在本節中，我們將對不同的並行執行引擎所使用的方法進行了比較。討論的重點是控制狀態（內存）訪問的方法，區塊鏈狀態可以被認為是一個 RAM 存儲器，每個鏈上的賬戶或智能合約，都擁有一系列它可以修改的內存位置。我們可以將依賴交易看成是那些試圖改變同一區塊中相同內存位置的交易，不同的公鏈採取了不同的內存架構和不同的機制來識別依賴交易。

這一類中的幾個公鏈大都是建立在 Facebook 的前公鏈 Diem 的技術架構之上。Diem 團隊創建了智能合約語言 Move，專門改善 SC 的執行，Aptos、Sui 和 Linera 都屬於這一範圍，除此之外，Fuel 是另一個專注於 PE 的知名項目，它使用自己的智能合約語言。

Aptos

Aptos 是一條建立在 Move 語言和 MoveVM 之上並實現了並行執行的高吞吐量公鏈。Aptos 的方法是在對用戶/開發人員透明的情況下去檢測依賴關係，即不需要事務顯式聲明它們使用的狀態的哪一部分 (內存位置)。Aptos 使用的是對軟件事務性內存（STM）的修改，稱為 Block-STM ‌，在 Block-STM 中，事務在區塊中預先排序，在執行期間會在處理器線程之間進行分割，以便樂觀執行，所謂的樂觀執行就是假定事務的執行沒有依賴關係。這時會記錄被事務修改的內存位置，執行之後，將驗證所有事務結果。

在驗證期間，如果發現一個事務訪問了被前一個事務修改的內存位置，則該事務將失效，接著會刷新事務的結果，並重新執行事務，這個過程不斷重複，直到區塊中的所有事務都被執行。當使用多核處理器時，Block-STM 可以顯著提高執行速度，當然，這種速度還取決於事務之間的相互依賴程度。據 Aptos 團隊的研究的結果顯示，當使用 32 核處理器時，即使是在高度相互依賴的情況下速度也能提高 8 倍，而在低相互依賴的情況下則可以提高 16 倍。如果一個區塊中的所有事務都是相互依賴的，那麼與順序執行相比，Block-STM 也只會導致較小的性能損失。Aptos 聲稱，這種方法可以造就 160,000 TPS 的吞吐量。

Sui

另一種 PE 方法是要求交易明確聲明它們修改的鏈狀態部分。Solana 和 Sui 目前正在使用這種方法，在 Solana 網絡中，當調用內存單元帳戶時，交易就必須聲明它修改了哪些內容，Sui 使用的也是類似的方法。

Sui 也是以 Diem 的 MoveVM 技術為基礎，但 Sui 使用不同版本的 Move 語言。Sui Move 語言是為了改變 Diem 體系下的核心移動存儲模型和資產權限，這也是與 Aptos 的主要區別。Sui Move 定義了一種狀態存儲模型，可以更輕鬆地識別獨立交易。在 Sui 中，狀態存儲被定義為對象，而對象通常代表資產並且可以共享，這意味著多個用戶可以修改對象，每個對像在 Sui 執行環境中都有一個唯一的 ID，並具有指向所有者地址的內部指針。通過使用這些概念，就可以很容易的通過檢查事務是否使用相同的對象來識別依賴關係。

通過將工作轉移給開發人員來聲明依賴關係，執行引擎的實現變得更加容易，這意味著它理論上可以擁有更好的性能和可擴展性，然而，這也伴隨著開發人員體驗欠佳的問題。

目前，Sui 尚未啟動，該項目剛剛啟動了他們的測試網。Sui 的創始人聲稱，並行執行的實現以及使用 Narwhal & Tusk 共識機制可以讓吞吐量超過 100,000 tx/sec，如果這個吞吐量是真的，那麼它將超過 Solana 當前 2400 tx/sec 的吞吐量，並超過 Visa 和 Mastercard 的吞吐量。

Linera

Linera 是並行處理領域的最新成員，最近宣布了由 a16z 牽頭的第一輪融資。關於項目的細節並未透露很多，然而，根據他們的資金公告，我們知道它是基於 Facebook 開發的 FastPay 協議。Fastpay 基於一種稱為拜占庭一致廣播的技術，該技術專注於加速獨立支付，例如發生在銷售點網絡中的支付，它允許一組驗證者確保支付的完整性，只要其中三分之二以上是誠實的。Fastpay 是實時總結算 (RTGS) 系統的一種變種，主要用於銀行和金融機構之間的網絡。

在 FastPay 的基礎上，Linera 計劃通過並行執行支付交易來構建一個專注於快速結算和低延遲的公鏈。值得注意的是，Sui 也使用了拜占庭一致廣播方法來進行簡單的支付，對於其他交易，Sui 自己的共識機制 Narwhal 和 Tusk 會用於高效處理 DeFi 交易等更複雜和依賴交易。

Fuel

Fuel 專注於成為模塊化區塊鏈堆棧中的執行層。也就是說，Fuel 不實現共識，也沒有將區塊鏈的數據存儲在 Fuel 鏈上。對於一個功能性區塊鏈，Fuel 與其他公鏈（例如 Ethereum 或 Celestia）交互以獲得共識和數據可用性，這篇文章‌對模塊化區塊鏈概念進行了很好的分析。

Fuel 使用 UTXO 創建了嚴格的訪問列表，即通過列表來控制對同一區塊狀態的訪問。該模型建立在經典的交易排序的概念之上。在該方案中，區塊中的事務排序會讓檢測事務之間的依賴關係變得簡單。為了實現這種架構，Fuel 構建了一個名為 FuelVM 的新虛擬機和一種名為 Sway 的新語言。FuelVM 是對 EVM 的兼容且簡化的實現方式，可以有效地將開發人員引入 Fuel 生態系統。此外，由於 Fuel 專注於模塊化區塊鏈，Fuel 智能合約的執行可以在以太坊主網上進行。這種方法與合併後以太坊的願景一致，即作為以 Rollup 為中心的結算和數據可用層。在這種架構中，Fuel 可以實現在以太坊上批量和結算的高效執行。

作為概念驗證，Fuel 團隊創建了一個與 Uniswap 風格類似的 SwaySwap AMM ，目前它還在測試網上運行，以證明與 EVM 相比 FuelVM 的性能有所提高。

並行執行的挑戰

並行執行方法看起來合乎邏輯且簡單明了。然而，還有一些挑戰需要討論，首先是估計可以使用這種並行執行加速的事務的實際百分比。第二個挑戰是網絡的去中心化，也就是說，如果驗證器可以輕鬆地擴展計算能力以提高吞吐量，那麼經常使用商品硬件的完整節點如何能夠跟上以確保鏈的正確性?

可並行交易的百分比

準確估計在任何鏈中可以並行執行的鏈交易的百分比是一個挑戰。此外，根據網絡活動的類型，這個百分比在不同區塊之間可以有很大的變化。例如，一個 NFT mint 事件可能會導致網絡活動的大幅增長，其中依賴事務的比例可能會很高。我們可以使用一些假設來粗略估計可並行事務的平均百分比。例如，我們可以假設大多數 ETH 和 ERC20 傳輸是獨立的，只有 25% 的簡單 ETH 和 ERC20 轉賬是相互依賴的，主要包含存款到智能合約，熱錢包到冷錢包的聚合交換等。另一方面，同一個資金池中的所有 AMM 事務都是相互依賴的，考慮到大多數 AMM 通常由少數池控制，而且 AMM 交易是高度組合併與多個池交互，所以我們假設至少 50% 的 AMM 交易是相互依賴的。

通過對以太坊中的交易類別進行分析，我們發現，在以太坊上大約 120 萬筆的每日交易中，20-30% 是 ETH 轉賬，10-20% 是穩定幣轉賬，10-15% 是 DEX 轉賬，4- 6% 是 NFT 交易，8-10% 是 ERC20 批准，12-15% 是其他 ERC20 轉賬。使用這些數字和假設，我們可以估計 PE 可以加速只能合約平台上大約 70-80% 的交易。這意味著最長的執行路徑，即依賴事務的順序執行可能只佔所有事務的 20-30%。換句話說，如果使用相同的 GAS 限制，PE 的吞吐量可能會提高 3 到 5 倍，一些實驗關於構建並行執行 EVM 的研究也顯示了類似的結果。在實踐中，高吞吐量的鏈使用每個區塊更高的 GAS 限制和更短的區塊時間來實現比以太坊 100 倍的吞吐量改進，增加的吞吐量需要強大的驗證器節點來處理這些區塊，這一要求也導致了第二個問題的出現——即網絡的集中化。

網絡集中化

對並行處理的另一個常見批評是：它極大地推動了網絡向集中化方向的發展。在高吞吐量網絡中，網絡每秒可以處理數万筆交易。驗證者節點受到費用和網絡獎勵的激勵來處理這些交易，並投資於專用服務器或可擴展的雲架構來處理這些交易。對於使用鏈並需要運行完整節點與鏈交互的項目或個人，情況就不一樣了。這些實體負擔不起復雜的服務器來處理如此龐大的事務負載，這將促使鏈上用戶依賴專門的 RPC 節點提供商，例如 Infura，從而導致更多的中心化。

如果沒有 “消費級硬件可運營完整節點” 的選項，高吞吐量鏈可能會變成一個封閉系統，其中一小部分實體對網絡擁有絕對權力。在這種情況下，這些實體可以協調審查相關交易、其他實體甚至是應用程序，例如在 Tornado Cash 事件中，它可以將這些鏈變成與 Web 2 沒有區別的許可系統。

目前，Sui 測試網運行全節點的要求低於 Aptos 測試網節點。但是，我們預計當主網啟動和應用程序開始部署在鏈上時，這些要求會發生顯著的變化。當然，一些去中心化的倡導者也在提出解決這些問題的方案。解決方案包括使用輕節點，通過使用 zk 有效性證明或欺詐證明來驗證塊的正確性。Fuel 團隊在這方面很活躍，並與以太坊社區關於去中心化重要性的精神保持一致。Aptos 和 Sui 團隊還未清晰表明執行這些方法的優先次序或促進權力下放的替代方法。Linera 團隊在他們的介紹文章中簡要地討論了這些問題，但協議的具體實施尚未公佈。

結論

並行執行引擎有望改善智能合約平台的吞吐量。結合創新的共識機制，事務的並行執行可以催生吞吐量接近 10 萬 TPS 的鏈，與 Visa 和萬事達一決高下或成為可能，此外，一些現在難以實現的應用也能得到進一步的發展，比如：全鏈上游戲和去中心化的微支付。但這些令人印象深刻的吞吐量改進也對如何確保去中心化的問題提出了新的挑戰。

非常感謝 Aries 團隊的創始人和 Robert Chen 對本文的評論和反饋！

免責聲明：作為區塊鏈信息平台，本站所發布文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。本文內容僅用於信息分享，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。