並行執行引擎有望極大改善當前智能合約平台的吞吐量
作者：Mohamed Fouda由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對本文的評論和反饋！
展開全文打開碳鏈價值APP 查看更多精彩資訊