來源：老雅痞
本文旨在通過Aptos、Sui、Linera 和Fuel 來闡明並行執行技術的原理，以及這些項目之間的異同和麵臨的挑戰。
當觀察區塊鏈技術的發展時，我們可以看到一個強大的趨勢，即新的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/ 秒。這種低吞吐量意味著在高活動時期，網絡礦工/ 驗證者不能處理所有的交易，並會引發確保交易優先執行而推高交易費用的費用競標戰。以太坊的平均費用在某些點超過0.2 ETH( 約800 美元)，讓許多用戶望而卻步。順序執行的第二個問題是網絡節點的低效。順序指令的執行不能從多核處理器中受益，這會導致硬件利用率低，效率低下。這阻礙了可擴展性，並導致了不必要的能源消耗。
並行執行可以解決這個問題？
EVM 結構的基本限制為專注於並行執行(PE) 的L1 新領域奠定了基礎。並行允許在多個處理器核心之間劃分交易處理，提高了硬件利用率，從而實現了更好的可擴展性。在高吞吐量鏈中，硬件資源的增加與可執行的交易數量直接相關。在高頻活動期間，驗證者節點可以委託更多的核心來處理額外的交易負載。計算資源的動態擴展允許網絡在高需求時期實現更高的吞吐量，從而顯著改善用戶體驗。
這種方法的另一個優點是改善了交易確認延遲。節點資源的動態擴展使低延遲確認交易成為可能。交易不需要等待數十或數百個區塊，也不需要支付過多的費用來確定優先級。確認時間的改進提高了交易的最終確定性，為低延遲區塊鏈打開了大門。保證執行交易的低延遲可以實現以前不可能實現的幾個用例。
改變鏈的執行模式，以允許PE 並不是一個新想法，已經有一些項目已經對此進行了探索。一種方法是將EVM 使用的會計模型從帳戶模型替換為未支出交易輸出(UTXO) 模型。比特幣就使用了UTXO 執行模型，它允許並行處理交易，這使其成為了支付的理想選擇。由於UXTOs 的功能有限，因此需要擴展來實現智能合約所需的複雜交互。作為示例，Cardano 為此使用了一個擴展的UTXO 模型，Findora 使用了一個實現了兩種會計模型，並允許用戶在其間進行更改資產類型的混合UTXO 模型。
PE 的另一種方法並不改變賬戶模型，而是專注於改進鏈狀態的架構。這種方法的一個例子是Solana 的Sealevel框架，本文主要討論後一種方法。
並行執行是如何運作的
並行執行的工作原理是識別獨立的交易並同時執行它們。如果一個交易的執行會影響另一個交易的執行，那麼兩個交易是相互依賴的。例如，同一個池中的AMM 交易是相互依賴的，必須按順序執行。
雖然並行處理的概念很簡單，但問題在於細節。其主要的挑戰是有效地識別“獨立”的交易。分類獨立交易需要理解每個交易如何更改區塊鏈內存或鏈狀態。與同一個智能合約交互的交易可以同時改變合約狀態，因此不能同時執行。在目前應用程序之間的可組合程度下，識別依賴關係是一項具有挑戰性的任務。
識別獨立交易
本節中將比較不同的並行執行引擎所使用的方法。討論的重點是控制狀態( 內存) 訪問的方法。區塊鏈狀態可以被看作是RAM 存儲器。每個鏈上賬戶或智能合約都擁有一系列可修改的存儲位置。相互依賴的交易是那些試圖改變同一區塊中相同內存位置的交易。不同的鏈使用不同的內存架構和不同的機制來識別依賴交易。
這個類別中的幾條鏈都建立在Facebook 已經砍掉的區塊鏈項目Diem 所開發的技術之上。 Diem 團隊創建了智能合約語言Move，以專門改善SC 的執行。 Aptos、Sui 和Linera 是屬於這一類別的三個備受矚目的項目。除了它們之外，Fuel 是另一個專注於PE 的知名項目，它使用自己的SC 語言。
Aptos
Aptos 構建在Diem 的Move 語言和MoveVM 之上，創建了實現並行執行的高吞吐量鏈。 Aptos 的方法是檢測依賴關係，同時對用戶/ 開發者透明，也就是說不要求交易明確聲明它們使用的是哪一部分狀態( 內存位置)。 Aptos 使用了軟件交易內存(STM) 的一種稱為Block-STM 的修改。在Block-STM 中，交易在區塊中被預先排序，並在執行期間在處理器線程之間進行劃分，以便optimistic execution。在執行中，交易的執行被假定沒有依賴關係。被交易修改的內存位置會被記錄下來。執行之後將驗證所有交易結果。在驗證期間，如果發現一個交易訪問了被前一個交易修改過的內存位置，該交易就會被宣布無效。交易結果將被刷新，然後重新執行交易。這個過程重複進行，直到區塊中的所有交易都被執行。當使用多個處理器核心時，Block-STM 可以提高執行速度。該速度取決於交易之間的相互依賴程度。 Aptos 團隊的結果顯示，使用32 個核心可以將速度在高度相互依賴的情況下提高8 倍，在低相互依賴的情況下提高16 倍。如果一個區塊中的所有交易都是相互依賴的，那麼與順序執行相比，Block-STM 的性能損失會更小。 Aptos 公司聲稱，這種方法可以實現160，000 TPS 的吞吐量。
Sui
另一種PE 方法是要求交易明確聲明他們修改了鏈狀態的哪些部分。目前Solana 和Sui 使用了這種方法。 Solana 將內存單元稱為賬戶，而交易必須說明它修改了哪些賬戶。 Sui 也使用了類似的方法。
Sui 還利用MoveVM 構建在了Diem 的技術之上。然而，Sui 使用了不同版本的Move 語言。 Sui Move 的實現改變了Diem 的核心存儲模型和資產權限。這代表了它與使用核心Diem Move 的Aptos 的主要區別。 （此前我們分析過Sui 和Aptos 的區別，感興趣的朋友請前往Allrecord 重構查看）Sui Move 定義了一個狀態存儲模型，使識別獨立交易更加容易。在Sui 中，狀態存儲被定義為對象。對象通常代表資產，並且可以被共享，這意味著多個用戶都可以修改一個對象。每個對像在Sui 執行環境中都有一個惟一的ID，並具有指向所有者地址的內部指針。通過使用這些概念，很容易通過檢查交易是否使用相同的對象來識別依賴關係。
通過將聲明依賴關係的工作轉移給開發者，執行引擎的實施變得更加容易，這意味著理論上它可以擁有更好的性能和可擴展性。然而，這樣做的代價是開發人員體驗不夠理想。
Sui 還沒有上線，該項目最近剛剛上線了他們的測試網。 Sui 的創始人聲稱，並行執行的實現以及Narwhal & Tusk 共識機制的使用可以讓吞吐量超過10 萬tx/ 秒。如果這是真的，比起Solana 目前約2400 tx/ 秒的吞吐量，Sui 將有一個巨大的提升，並將超過Visa 和萬事達的吞吐量。
Linera
Linera 是並行處理領域的最新成員，他們最近宣布了由a16z 領投的第一輪融資。關於項目實施的細節並不多。然而，根據他們的融資公告，我們知道它基於同樣在Facebook 開發的FastPay 協議。 Fastpay 基於一種叫做Byzantine Consistent Broadcast 的技術。這項技術專注於加速獨立支付，比如發生在銷售點網絡中的支付。它允許一組驗證者確保支付的完整性，只要其中三分之二以上是誠實的。 Fastpay 是銀行和金融機構網絡中使用的實時總結算(RTGS) 系統的變體。
Linera 計劃在FastPay 的基礎上建立一個區塊鏈，通過並行執行支付交易，專注於快速結算和低延遲。值得注意的是，Sui 也使用了Byzantine Consistent Broadcast 方式進行簡單支付。對於其他交易，Sui 使用自己的共識機制Narwhal 和Tusk 來高效地處理DeFi 交易等更複雜和具依賴性的交易。
Fuel
Fuel 致力於成為模塊化區塊鏈堆棧中的執行層。這意味著Fuel 不實施共識，也不將區塊鏈的數據存儲在Fuel 鏈上。對於一個功能性的區塊鏈，Fuel 與其他鏈( 如以太坊或Celestia) 進行交互，以獲得共識和數據可用性。
Fuel 使用UTXO 創建嚴格的訪問列表，用一個列表來控制對同一片狀態的訪問。該模型建立在經典交易排序的概念之上。在這個方案中，區塊中的交易排序大大簡化了交易之間依賴關係的檢測。為了實現這個架構，Fuel 構建了一個名為FuelVM 的新虛擬機和一種名為Sway 的新語言。 FuelVM 是EVM 的兼容和簡化的實現方式，它可以有效地引導開發人員進入Fuel 生態系統。此外，由於Fuel 專注於模塊化區塊鏈堆棧，Fuel SC 的執行可以在以太坊主網上進行。這種方法與以太坊在合併後作為一個以rollup 為中心的結算和數據可用層的願景一致。
作為一種概念驗證，Fuel 團隊創建了一個名為SwaySwap 的Uniswap 風格的AMM，目前它正在測試網上運行，以證明與EVM 相比，FuelVM 的性能有所提高。
並行執行方法的挑戰
並行執行方法看起來合乎邏輯且簡單明了。然而，還有一些挑戰需要討論。首先是要估計可以使用這種並行執行加速的交易的實際比例。第二個挑戰是網絡的去中心化，也就是說，如果驗證者可以輕易擴展計算能力以提高吞吐量，那麼經常使用商品硬件的完整節點如何跟上以確保鏈的正確性？
可並行交易的百分比
準確估計可並行執行的鏈上交易的百分比是一個挑戰。此外，根據網絡活動的類型，這個百分比在不同區塊之間可能會有很大的變化。例如，一個NFT 鑄幣活動可能會導致依賴交易劇增。也就是說，我們可以使用一些假設來獲得可並行交易平均百分比的粗略估計。例如，我們可以假設大多數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 可以加速SC 平台上大約70-80% 的交易。這意味著依賴交易的順序執行可能佔所有交易的20-30%。換句話說，如果使用相同的gas 限制，PE 吞吐量可能會提高3 – 5 倍。關於構建並行執行EVM 的一些實驗也顯示了類似的估計。在實踐中，高吞吐量鏈將通過使用更高的每區塊gas 限制和更短的區塊時間來以實現至少比以太坊提高100 倍的吞吐量。增加的吞吐量需要強大的驗證者節點來處理這些區塊。這一需求導致了網絡集中化的問題。
網絡集中化
對並行處理的另一個常見批評是，它極大地推動了網絡的集中化。在高吞吐量網絡中，網絡每秒可以處理數以萬計的交易。驗證者節點受到費用和網絡獎勵的激勵來處理這些交易，並投資於專用服務器或可擴展的雲架構來處理這些交易。而對於使用該鏈並需要運行完整節點與鏈交互的公司或個人來說，情況就不一樣了。這些實體無法負擔複雜的服務器來處理如此龐大的交易負載。這將推動鏈上用戶依賴於Infura 等專門的RPC 節點供應商，從而導致更多的集中化。
如果不選擇使用消費級硬件來運行整個節點，高吞吐量鏈可能會變成一個封閉的系統，其中一小群實體對網絡擁有絕對的權力。在這種情況下，這些實體可以協調審查交易、實體甚至應用程序，從而將這些鏈轉變為與Web 2 沒有區別的許可系統。
目前，在Sui 測試網上運行全節點的要求低於Aptos 測試網節點。然而，我們預計當主網啟動、應用程序開始出現在鏈上時，這些需求將發生重大變化。去中心化的倡導者一直在提出解決這些預期問題的方案。其中解決方案包括使用輕型節點，通過zk 有效性證明或欺詐證明來驗證區塊的正確性。 Fuel 團隊在這方面非常積極，並在去中心化的重要性上與以太坊社區的理念達成了一致。 Aptos 和Sui 團隊還未清晰表明執行這些方法的優先次序或其他促進去中心化的方法。 Linera 團隊在他們的介紹文章中簡要地討論了這些問題，但協議的實施尚未證實這一承諾。
結論
並行執行引擎有望改善智能合約平台的吞吐量。通過結合共識機制的創新，交易的並行執行可以使鏈的吞吐量接近或超過100k TPS。這樣的性能可以與Visa 和Mastercard 相媲美，從而可以實現完全的鏈上游戲和去中心化小額支付等目前具有挑戰性的幾個用例。這些令人印象深刻的改進面臨著如何確保去中心化的挑戰。我們期待著致力於解決這些問題的創始人。
信息來源自Alliance DAO，略有修改
作者：Mohamed Fouda
編譯：RR
