自九年前以太坊推出首個去中心化、可編程的區塊鏈以來，加密貨幣在擴展去中心化應用至數十億用戶的過程中遭遇了多個障礙。爲了開發解決這一問題的擴展解決方案，加密貨幣行業不斷資助並開發全新類型的區塊鏈來解決“性能問題”。

然而，“性能問題”被定義和量化的方式欠妥。合成的概念如“每秒交易次數”將實際上並不需要等同計算工作的交易進行了簡單打包比較。這些指標缺乏細微差別，也遮蔽了我們評估區塊鏈各個組件對性能影響的能力，使我們從原則性方法中分心，無法識別我們可以進行優化的一組問題，這些問題高度相互依賴。

盡管有這種困擾，我們在過去幾年中看到了區塊鏈可擴展性的可信賴、持續的改進。隨着以太坊通過其以 Rollup 爲中心的路線圖，新一波的 Rollups、協處理器、數據可用性（DA）層和競爭的 L1 正在湧現，每個都帶有獨特的設計選擇，爲開發者提供更高性能的環境，用於建立可擴展、用戶友好的去中心化應用程式（dapps）。

今天，EIP4844 的引入和備選 DA 層已經緩解了關鍵的 DA 瓶頸。盡管達到了這個關鍵裏程碑，證據表明還需要解決其他重要的瓶頸。上個月，Base 在單日內收集了 157萬美元的交易費用，而只支付了5000美元的以太坊數據可用性成本。這表明，驗證和處理狀態更新所需的計算工作仍然是一個關鍵的瓶頸和改進的機會。

本文將評估集成和模塊化執行環境在解決更高性能，以及擴大鏈上應用程序範圍的過程中所做的設計選擇。

當今的挑戰

執行層的性能可以根據執行節點相對於其鏈的區塊時間所完成的計算工作來進行基準測試，或者叫作 “以秒計算的gas”。

‍有了這個思路，我們可以將執行層的瓶頸縮小到兩個相互關聯的因素：效率低下的狀態訪問和效率低下的計算。

效率低下的狀態訪問是指檢索和更新區塊鏈狀態的開銷，這可能會減慢交易處理速度。另一方面，效率低下的計算是由執行操作和狀態轉換的算法所帶來的開銷，這可能包括從簡單的轉帳到復雜的智能合約和籤名驗證的所有內容。

這些瓶頸是相互強化的 - 狀態訪問的延遲可能會延長計算時間，而效率低下的計算實踐可能會給狀態管理帶來壓力。而且，解決這些問題的建議的改進通常需要系統性的改進，比如分片或者採用無狀態架構，這些可以提高狀態訪問和計算效率，以提高執行性能。

瓶頸#1：低效的狀態訪問

訪問區塊鏈的狀態所需的成本和速度是影響執行環境性能的關鍵瓶頸，可以歸結爲狀態膨脹的問題。

在區塊鏈中，世界的狀態通過特定的數據結構——樹（Tree） 來管理和更新。樹對區塊鏈至關重要，爲執行節點外部的各方提供了一種安全而有效的方式，保證了對區塊鏈正確狀態的認證。樹中的每次更新都會生成一個新的根哈希，輕節點（light client）可以參照這個哈希來驗證交易和帳戶餘額，無需維護整個鏈。

以太坊特別依賴一種名爲 Merkle Patricia trie (MPT)的數據結構，它包含@chiqing/merkle-patricia-trie-explained-ae3ac6a7e123">四個子樹。

隨着以太坊向其狀態中添加更多的智能合約和代幣，其狀態樹變得越來越大，越來越復雜。狀態的增長需要更多的存儲空間，更多的計算資源來處理，以及更多的帶寬來傳輸。同時，節點的硬件限制大體保持不變。

這種狀態增長直接影響了以太坊的性能，因爲狀態是存儲在磁盤中的，磁盤操作產生了高額的開銷。從CPU寄存器訪問數據可能只需要0.1納秒，而從磁盤訪問數據可能需要10至100微秒——這是前者的100倍至1000倍，大致相當於在這段時間內可以執行的200,000個CPU指令。這等同於本可以進行的36次ERC-20轉帳！

區塊鏈有許多低效的讀取和寫入狀態的訪問模式，這加劇了這個問題。例如，Merkle Patricia trie 的非順序結構本質上導致了這些磁盤 輸入/輸出（I/O） 從磁盤上的各種不可預測的位置讀取和寫入的操作。交易輸入的隨機性以及它們觸發的後續狀態變化導致分散的數據訪問模式，這顯着減慢了驗證和更新狀態的過程，並且僅利用了硬件設備的容量的一部分。

總的來說，區塊鏈的狀態管理原語遠未實現其絕對的潛力，可以通過許多方式提高計算效率。

瓶頸#2：效率低下的計算

執行層還面臨計算效率低下的瓶頸，其表現形式多種多樣。

首先，許多交易處理是順序進行的，沒有充分利用現代多核處理器同時處理多個操作的能力。這種順序執行導致交易之間不可避免的CPU空閒時間，浪費了寶貴的計算資源。

其次，使用虛擬機涉及將高級智能合約操作翻譯成字節碼——一種更低級別、平台獨立的代碼——然後按指令執行。這種翻譯和執行過程帶來了大量的開銷，特別是對於具有復雜且頻繁重復的特定應用任務的應用程序。

這些效率低下的問題導致了計算資源的次優使用，阻礙了執行層的性能。

---

解決方案：低效的狀態訪問

團隊們通過幾種不同的方式提升了狀態從執行節點的硬件中被檢索和更新的速度，包括簡化復雜的數據結構以及找到減少導致狀態膨脹的昂貴的磁盤 I/O 操作的方法。

無狀態和內存計算

一些執行層通過短期內簡單地接受狀態膨脹來解決此問題。他們將狀態數據存儲從較慢的基於磁盤的系統轉移到更快的隨機訪問內存（RAM）。在 RAM 中訪問狀態信息顯著減少了與磁盤操作相關的開銷，因爲這些操作更慢且更消耗資源。

然而，這種方法挑戰了去中心化的核心原則。在 RAM 中存儲越來越大的狀態數據需要更先進和昂貴的硬件，這可能限制個人作爲節點操作者的能力。因此，隨着硬件要求的升級，能夠運行這些節點的實體數量將減少。

爲了平衡內存計算的吸引力和信任最小化，L1（例如以太坊）和 L2 都在追求可擴展性路線圖，該路線圖依賴於將驗證者的角色分解爲具有許多驗證節點的單獨的集中式執行節點。在這個模型中，具有在內存中計算的硬件要求的高性能區塊生產者負責生成區塊，並通過驗證節點來利用加密證明（欺詐和有效性證明）來讓區塊生產者承擔責任。

因此，這些系統應該允許區塊生產者最大化他們的速度，因爲他們可以預期在內存中計算，完全消除執行期間的磁盤 I/O。由於 RAM 的延遲通常在 100 納秒以下，相對於基於磁盤的實現，狀態訪問的延遲降低了近 1000 倍。

同時，欺詐性和有效性證明取代了去中心化的共識，以便隨着系統吞吐量的擴大，也能擴展系統的信任最小化屬性。因此，強大的、中心化的區塊生成節點被可以在更便宜的硬件上運行的驗證節點所平衡。這些節點執行着關鍵的功能，獨立地驗證狀態轉換（或無效的狀態轉換）的證明，以維持對狀態的準確視圖，而無需承擔存儲整個區塊鏈狀態的負擔。

爲了以信任最小化的方式促進這一過程，執行層必須實現一定程度的無狀態性，最流行的是“弱無狀態性”的概念。弱無狀態性是通過要求區塊生產者向驗證節點提供一種稱爲見證的加密聲明來實現的。這個見證封裝了新區塊提出的所有狀態更改，使驗證者可以驗證這些更改，而無需額外的歷史數據。

雖然這個概念可以應用各種樹結構，但Verkle樹通常比Merkle樹更受歡迎，因爲它們的效率更高。Merkle樹需要包含從數據點（葉）到樹根的路徑上的所有兄弟節點哈希，以證明數據的完整性。這個要求意味着見證（完整性的證明）的大小隨着樹的高度增長，因爲每個級別都需要額外的哈希。因此，在Merkle樹中驗證數據完整性變得計算密集和昂貴，特別是對於大型數據集。相比之下，Verkle樹簡化了這個過程，減少了在生成和驗證新區塊時與計算和存儲相關的開銷。

來自 Inevitable Ethereum 的“Verkle Tree”的擴展

Verkle 樹優化了傳統 Merkle 樹的結構，簡化了葉子節點與根節點之間的連接，並消除了在驗證過程中需要包含兄弟節點的需求。在 Verkle 樹中，驗證一個證據只涉及到葉節點處的值，對根節點的承諾，以及基於多項式承諾的單一向量承諾，這替換了 Merkle 樹中發現的多個基於哈希的承諾。這種轉變使 Verkle 樹能夠保持固定大小的證人，不會隨着樹的高度或驗證的葉子數量的增加而增加，顯著提高了在數據驗證過程中的存儲和計算的效率。

在未來幾年中，我們將看到在L1和L2級別上實現無狀態性的實現，這些實現將具有多種配置。根據最新的以太坊路線圖，驗證者可以依靠區塊構建者提供關於某些區塊狀態的Verkle證明，並驗證這些輕量級證明，而不是直接維護以太坊的狀態。

在L2級別，像MegaETH這樣的團隊正在積極將無狀態性的概念應用到樂觀性rollup的設計中。在他們的設計中，序列器節點爲每一個區塊生成一個包含必要的狀態值和中間哈希的證人，同時發出表示狀態變化的狀態增量。然後，驗證節點可以通過從DA層或點對點網路檢索證人來重新執行任何區塊，而無需存儲全部狀態。同時，全節點通過應用通過網路傳播的狀態增量來更新他們的狀態，使他們能夠保持同步，而無需重新執行交易或存儲全部的狀態歷史。

然而，也值得指出的是，無狀態性的好處以及由此產生的在內存中計算的能力並不是執行層性能的靈丹妙藥。

來自 MegaETH 的”理解以太坊執行層性能”的實時TPS

正如 MegaETH 的聯合創始人Yilong Li（李一龍）在他的以太坊執行研究報告中所指出的，區塊鏈上的數據結構和訪問模式仍存在其他的效率問題。

改進數據庫

在執行層工作的團隊正在尋找改進數據庫結構的方法，以消除以太坊和其他與EVM兼容的區塊鏈在處理低效率狀態訪問方面遇到的一些瓶頸，這對計算效率產生了連鎖反應。

事實上，EVM現有的數據庫設計的局限性促使了 Monad決定超越純粹的優化計算效率，以實現並行化。Monad發現，即使實現了並行執行，他們也只看到了性能的微小提速，因爲多線程的讀寫請求互相阻塞。因此，Monad實現了一個與*異步I/O（AIO）或並行訪問兼容的數據庫，作爲解決方案的關鍵部分。

異步I/O（Async I/O）

I/O操作——如讀取或寫入存儲設備——經常造成瓶頸，特別是在機械硬盤驅動器（HDD）中。這些驅動器需要物理移動讀/寫頭來訪問數據，這可能大大減慢數據處理速度。

AIO通過允許程序與其他進程並行執行I/O操作來解決這個挑戰。本質上，一個程序可以啓動一個I/O操作，然後繼續執行，而不需要等待它完成。它通過註冊一個回調函數或一個操作系統或I/O庫在I/O操作完成後將兌現的承諾來實現這一點。這種異步方法允許主程序繼續執行其他任務，通過不等待I/O任務完成來提高整體效率。

異步I/O可以在傳統的HDD和固態驅動器（SSD）中實現，盡管在SSD中的效益更爲明顯。HDDs可以執行AIO，但由於它們的機械性質，它們本質上比SSD慢，SSD在閃存上存儲數據，沒有移動部件，導致更快的訪問時間。

例如，Monad 利用針對 SSD 存儲優化的自定義狀態後端，支持高水平的並行數據處理並減少 I/O 延遲。這種設置比僅依賴傳統的基於磁盤的存儲或使用內存數據庫的系統更有效，後者可能仍面臨因頻繁向較慢的存儲介質寫入和讀取數據而導致的延遲。

類似地，Reth採用了將數據庫操作與核心EVM執行引擎分離的方法。此設置允許 EVM 字節碼在單個線程上順序執行以保持一致性，同時將數據庫 I/O 任務卸載到並行進程。 Reth 使用參與者（actor）模型（一種軟件架構模式）來有效管理這些並行進程，確保 I/O 操作不會中斷 EVM 解釋器。

狀態默克爾化頻率（State Merklization Frequency）

另一個優化的向量是狀態默克爾化的頻率。以太坊當前在每個區塊後默克爾化狀態的模型引入了重要的開銷，需要頻繁地從磁盤讀取和寫入，並持續進行trie遍歷。默克爾樹通常通過將中間哈希分組到16個（稱爲節點）的集合中，並將它們存儲在鍵值存儲數據庫中，其中鍵是節點哈希，值是節點本身。

遍歷這棵樹來查找和更新數據需要對樹的每一層進行一次隨機磁盤訪問，而遍歷一棵普通的 Merkle 樹，每個條目大約需要八次順序數據庫查詢。

Solana的方法是在每個epoch結束時更新狀態提交，這允許在該期間的多個交易上攤銷寫入成本。如果在同一epoch中修改了多次狀態條目，每次寫入都不需要立即更新默克爾根。這減少了在epoch期間與狀態更新相關的整體計算開銷。因此，與狀態相關的讀取成本保持常數，或者是O(1)，因爲可以直接讀取狀態，而不需要每次都遍歷默克爾路徑。

減少以太坊中默克爾化的頻率可能會減少狀態讀取和寫入的開銷，提高性能。然而，輕客戶端需要回放區塊更改以跟蹤epoch之間的狀態或提交鏈上交易以進行狀態驗證，這種改變目前與以太坊不兼容。

高效和專用的數據結構

此外，現有以太坊客戶端內的分層樹結構通常會導致低效的狀態訪問模式，進一步加劇了狀態膨脹。雖然以太坊的狀態被構造爲 MPT，但它也存儲在以太坊客戶端數據庫中，例如水平數據庫（LevelDB）, Pebble數據庫 （由 go-ethereum 使用）或 MDBX（由 Erigon 使用），它們將數據存儲在 Merkle 樹中，例如B樹 或者LSM樹。

在這種設置中，一個數據結構被根入另一種類型的數據結構，創建了通過在基於另一個基於默克爾樹的系統的客戶端上操作的內部樹結構來導航的”讀放大”。讀放大可以理解爲在狀態中訪問或更新信息需要的多個步驟，這需要導航外部樹以找到進入MPT的入口點，然後執行所需的操作。因此，對於隨機讀取，磁盤訪問的數量乘以一個log(n)因素。

爲了解決這個問題，Monad 在硬盤和內存中本地使用了 Patricia trie 數據結構。從技術角度來看，Patricia tries通常優於其他默克爾樹結構，因爲它們獨特的空間效率，高效的前綴匹配和最小的節點遍歷的結合。trie的設計使得單一子節點的節點崩潰並簡化了查找，插入和刪除，減少了需要的磁盤或網路I/O操作的數量。此外，Patricia trie在處理前綴匹配方面的熟練性提高了需要快速部分鍵搜索的應用程序的性能。

另一個特定於基於樹的結構的瓶頸是，訪問或更新數據需要遍歷多個層次，導致許多順序磁盤訪問。Sovereign Labs通過倡導使用二叉默克爾樹配置來解決這種低效率問題。這個關鍵的轉變到二元結構大大減少了樹遍歷時的可能路徑，直接減少了更新，插入和密碼學證明所需的哈希運算。

來自Sovereign Labs的”幾乎最優的狀態默克爾化（Merklization）“的二元默克爾樹配置

在這個類別中的另一個例子是Reth團隊通過在執行過程中從磁盤預取中間trie節點來配置Reth，通過通知狀態根服務觸及的存儲槽和帳戶。

狀態過期

狀態過期是一種通過移除一段設定時間內未被訪問的數據來管理和減少區塊鏈狀態大小的機制。雖然過期經常被歸類爲“無狀態”範疇，但在執行環境中區分這些概念非常關鍵。

無狀態性通過提高執行節點在內存中計算的能力來改善執行，但是執行的改進源於在較少的執行交易的節點上對更強大的硬件要求。相比之下，狀態過期可以應用於擁有少數或衆多執行節點的區塊鏈。

目前討論用於實現狀態過期的常見方法有兩種：

• 租金過期：這種方法涉及對維持狀態數據庫中活動帳戶的維護費用或“租金”進行收費。如果未支付租金，帳戶會被歸檔，直到支付費用將其恢復。
• 時間過期：在這裏，如果帳戶在指定的時間段內未被訪問（即無交易或互動），則視爲不活動。

這兩種方法的目標都是只在即時、可訪問的狀態中維護活動使用的數據，而將較老、較少訪問的數據推送到不會給主系統帶來負擔的歸檔狀態。

通過維護更小、更易管理的狀態，狀態過期減少了可能嚴重阻礙區塊鏈性能的“狀態膨脹”。較小的狀態大小使節點可以快速導航和更新狀態，這轉化爲更快的執行，因爲節點花費更少的時間掃描，更多的時間處理。

執行分片

分片通過在有限數量的專用節點（並非每個節點都執行全局狀態）之間分配任務和數據，優化資源利用率和性能。

在分片的區塊鏈架構中，全局狀態被劃分爲稱爲分片的明確部分。每個分片都維護其狀態部分，並負責處理網路交易的一個子集。交易根據確定性分片函數分配到特定分片，該函數考慮各種因素，如發送方地址、接收方地址和交易數據的哈希。這最小化了跨分片通信的需求，並使得交易執行更加高效。

來自 Vitalik 的 “區塊鏈可擴展性的限制” 的分片圖

當探索NEAR協議的分片設計 Nightshade 時，這一點變得顯而易見。Nightshade 實現了無狀態性，以在不妥協信任最小化的情況下擴展分片。

在Nightshade中，區塊鏈被構建爲一個單一的邏輯鏈，每個區塊由多個“塊”組成，每個分片分配一個塊。這些塊包含每個分片特定的交易和狀態轉換。在一個區塊中包含所有分片的塊，可以對整個區塊鏈狀態有一個統一的視圖，並簡化跨分片通信的過程。

與以太坊的提案者- 構建者分離（PBS）類似，Nightshade 明確劃分了有狀態和無狀態節點的角色。在NEAR上，有狀態的驗證者被分配到特定的分片，並負責收集交易，執行它們，並產生特定於分片的塊。他們維護其分配分片的完整狀態，並爲驗證者在驗證過程中生成狀態證明。

同時，無狀態的驗證者在每個區塊的基礎上被隨機分配驗證特定的分片。他們不需要維護完整的分片狀態，並依賴其他分片的區塊生成器提供的狀態證明來驗證一個塊內的狀態轉換和交易。驗證者到分片的隨機分配有助於確保網路的安全性和完整性，因爲它讓惡意行爲者合謀控制特定分片變得更加困難。

由於網路中的每個節點只需要處理其各自分片的數據，而不是整個網路的數據，所以降低了單個節點的存儲和計算負擔。

---

解決方案：效率低下的計算

並行化執行

是時候解決眼前的主要問題了：並行化。並行化交易執行可以同時利用多個計算資源並行處理多個交易。這在高需求時期可以通過擴展硬件資源來提高吞吐量。

然而，重要的是要考慮到可以並行化多個執行組件，其中許多已經由協處理器如Lagrange* 和替代區塊鏈客戶端如Firedancer 實現，以顯著提高區塊鏈的性能。具體來說，可以並行化以下操作：

• 並行狀態訪問
• 並行化特定操作
• 並行化共識和執行

並行化狀態訪問

並行化狀態訪問帶來了兩個關鍵的好處：

• 並行 EVM 將交易處理分布在多個 CPU 核心上。此設置允許同時處理多個交易，而不是強制它們排隊等待單個資源。
• 當一個交易等待來自存儲的數據——可能引入顯著的延遲——系統不會處於空閒狀態。相反，它可以切換到另一個準備執行的交易。這是可能的，因爲多個核心可以獨立並同時處理不同的任務。

並行化事務執行的主要挑戰源於管理並發訪問共享全局狀態而不違反更新分布式系統的ACID規則。如果一個區塊鏈有大量並行執行的交易，其中一些將會衝突。因此，主要的並行化狀態訪問方法在何時分配資源來解決衝突上有所不同：悲觀執行（或內存鎖）模型和樂觀執行模型。

悲觀執行模型（Pessimistic Execution）

悲觀執行模型是一種處理交易的方式，要求交易在執行過程中聲明它們將要訪問（讀取或寫入）的狀態變量。這些信息包含在交易的元數據中，使運行時可以在執行前分析訪問模式。

通過檢查讀寫訪問模式，運行時可以識別出訪問集不重疊的交易，從而使非重疊和只讀交易並行執行，提高吞吐量。運行時爲驗證節點上的每個CPU線程創建並行交易隊列，確保處理具有非衝突訪問模式的交易時的並行性。

由於這種設計選擇，悲觀執行模型從對資源分配的細粒度控制中獲益，允許對區塊鏈的狀態空間進行分段或劃分。

並行化有效地在統一的安全模型支撐下創建了多個，同步可組合的獨立執行分片。它通過精確的資源管理和動態費用市場，幫助解決網絡擁塞和優化gas成本。通過識別狀態訪問的“熱點”（高交易需求區域），系統可以實施針對性的優化，如差異化的費用定價，速率限制，或爲高爭用狀態分配額外資源。需要注意的是，Solana當前對並行化的實現並未充分實現本地化費用市場的潛力。

爲了在並發訪問中確保數據一致性，悲觀執行模型使用了鎖定機制。在交易可以訪問特定的狀態變量之前，它必須在該變量上獲得一個鎖。該鎖爲交易提供對該變量的專有訪問，防止其他交易同時修改它。一旦交易執行，鎖就會被釋放，允許其他交易訪問變量。

在Solana 的 Sealevel 運行時中，實現了這種悲觀執行模型，交易在執行期間指定它們將讀取或寫入的帳戶。Sealevel 分析訪問模式，並爲驗證器節點上的每個CPU線程構建並行交易隊列。如果一個帳戶被多次訪問，它會在一個隊列中按順序列出，以防止衝突。未在領導者節點的塊時間內處理的交易會被打包並轉發到下一個計劃的領導者進行處理。

未消費的交易輸出(UTXO)基礎的系統類似地提高了計算效率。UTXO涉及與個人錢包相關的特定貨幣單位—UTXO。對於該錢包的每一筆交易，UTXOs被消耗並被新的替換；爲接收者創建一個或多個UTXO，代表支付，通常也爲發起者創建另一個UTXO，代表找零。

通過定義哪些合約會被觸及，可以並行執行觸及不相交合約集的交易。這可以通過在“帳戶”數據模型中設定嚴格的訪問列表來實現。然而，爲了與以太坊風格的智能合約保持兼容，像Fuel這樣的UTXO方案對區塊生產節點執行具有重疊訪問列表的交易的順序進行了限制。

然而，悲觀執行模型也存在局限性。交易必須預先準確聲明其訪問模式，這對於那些訪問模式可能依賴於輸入數據或條件邏輯的復雜或動態交易來說，可能是個挑戰。不準確或不完整的訪問模式聲明可能導致性能下降和潛在的運行時錯誤。此外，當許多交易爭奪相同狀態變量時，鎖定機制可能會導致延遲並降低並發性。這種競爭可能形成性能瓶頸，因爲交易可能會花費大量執行時間等待獲取高需求狀態變量的鎖。

更重要的是，這種模型給開發人員帶來了相當大的負擔，他們必須深入了解合約的數據依賴關係，才能準確地預先指定必要的狀態訪問。這種復雜性可能會帶來挑戰，特別是在設計具有動態和復雜狀態交互的應用程序時，例如去中心化交易所或自動化做市商。

樂觀執行（Optimistic Execution）

相比之下，樂觀執行模型採用了一種“推測性”的交易執行方式，允許交易在不需要預先聲明狀態訪問的情況下並行執行。

這種模型並不是在衝突發生之前就阻止它們，而是樂觀地並行執行交易，假定它們是獨立的。運行時採用了如多版本並發控制（MVCC）和軟件交易內存（STM）等技術來在執行過程中跟蹤讀寫集。執行後，運行時檢測任何衝突或依賴關係。它採取糾正措施，例如中止並重新執行衝突的交易，但可以通過從內存而不是磁盤讀取來識別衝突的交易。

樂觀執行模型簡化了開發過程，讓程序員可以專注於編寫合約邏輯，而不必擔心聲明狀態訪問模式。由於交易不需要預先聲明其狀態交互，因此開發人員在設計智能合約時擁有更多自由，從而允許與區塊鏈狀態進行更復雜和動態的交互。樂觀執行模型特別適合支持大量交易和復雜 dapp 的平台，因爲它可以提供比悲觀模型更高的吞吐量和可擴展性。

這個模型的一個顯著實現在 Aptos 和 Movement Labs 的 MoveVM 中，它採用了一種名爲 Block-STM 的技術。在 Block-STM 中，交易首先並行執行；然後，識別衝突的交易，並根據檢測到的依賴關係安排重新執行。這種方法確保了處理資源的連續利用，提高了吞吐量，同時保持了交易工作流的完整性。

Aptos的Block-STM來自”通過將排序詛咒（_Ordering Curse）轉變爲性能祝福來擴展區塊鏈執行（Performance Blessing）”_

盡管樂觀執行模型具有優勢，但也帶來了挑戰。需要進行運行時衝突檢測，存在交易中止和重試的可能性，這增加了計算開銷和復雜性。此外，還需要維護狀態的多個版本，並管理與衝突解決相關的開銷，需要復雜的系統設計和強大的並發控制機制來確保區塊鏈的完整性和性能。

Block-STM利用MVCC（多版本並發控制）有效地管理並發寫操作並維護數據的多個版本，從而防止同時進行的寫操作之間發生衝突。它結合一個協作調度器在多個線程之間協調執行和驗證任務，確保交易按照啓動的順序進行提交。這種設置通過使用動態依賴估計來最小化交易中止，使得具有依賴關係的交易可以在繼續執行之前有效地等待並解決這些依賴關係。

此外，MoveVM使用的帳戶模型與以太坊的EVM不同，這導致碰撞更少。在以太坊中，通常由單一的智能合約管理一個代幣，可能導致多個代幣交易通過相同的合約地址交互，增加了衝突的可能性。相比之下，MoveVM將代幣分配給個人用戶帳戶，減少了這種衝突的可能性，因爲每個交易通常與不同的帳戶地址交互。

在Monad中，可以將並行執行的初始交易集合視爲一個I/O階段，這可能產生立即可提交的結果，以及隨後的“重試”階段，這需要少量的工作來清除剩餘的有衝突的交易。這些衝突轉換被發現並拉入緩存，允許執行開銷減少，因爲它們存在於內存中。雖然大部分狀態都存在於磁盤上，但在執行時可以快速訪問衝突的交易。

悲觀和樂觀執行模型提供了處理區塊鏈中交易執行和狀態管理的不同方案。選擇這兩種模型涉及在預設的狀態訪問規範的復雜性和動態衝突解決相關的計算成本之間做出權衡。

數據和任務並行

數據並行和任務並行主要通過將計算負載分布到多個處理器來優化性能：數據並行將數據集進行切分以實現同時處理，而任務並行將不同的任務分配給多個處理器以並行操作。

這些優化與狀態訪問並行性有所不同但互相依賴，狀態訪問並行管理和同步對共享資源（如內存或數據庫）的訪問，以防止在多個進程或線程同時操作時發生衝突，並確保數據完整性。

數據並行性

數據並行涉及到在多個數據元素上並行執行特定操作。這種方法在需要對大型數據集應用相同操作或對多個輸入值執行計算密集型操作時特別有益。關鍵的突破在於將數據分布在多個處理單元上，並同時對不同的數據元素執行相同的操作。

數據並行的一種常見技術是單指令，多數據（SIMD），它允許一條指令同時在多個數據元素上執行。現代CPU通常具有內置的SIMD能力，使其能夠在多個數據點上執行並行操作。通過利用SIMD指令，開發者可以對某些類型的操作，如數學計算，數據轉換或信號處理，實現顯著的加速。

例如，考慮一個場景，您必須將復雜的數學函數應用於大量數字。 SIMD 可以同時處理多個數字，而不是按順序處理每個數字。這種同步處理是通過將數字子集加載到 CPU 的 SIMD 寄存器中、對所有加載的數字並行執行數學函數、然後將結果存儲回內存來實現的。通過一次處理多個數字，SIMD 可以大大減少總體執行時間。

Firedancer關於ED25519 籤名驗證的工作展示了SIMD在優化復雜計算方面的威力。籤名驗證過程涉及伽羅華域（Galois Fields）內的算術運算，這可能是計算密集型的。通過利用SIMD指令，Firedancer可以同時對多個數據元素進行這些操作，從而實現顯著的性能提升。這些優化將對改善Solana的性能至關重要，Solana已經實現了狀態訪問的並行化。

任務並行性

任務並行涉及在程序的多個處理單元中並行化不同的任務或操作。當程序由多個可以並發執行的獨立任務組成時，這種方法很有用。通過將每個任務分配給單獨的處理單元，如CPU核心或GPU，可以減少總體執行時間。

任務並行通常用於程序需要同時執行多個復雜操作的場景。例如，考慮一個需要實時對視頻流應用不同濾鏡和效果的視頻處理應用。任務並行可以將工作負載分布在多個處理單元，而不是使用每個計算單元集體順序地應用每個濾鏡。一個處理單元可以負責應用模糊濾鏡，而另一個單元應用色彩校正濾鏡，依此類推。通過並行執行這些任務，應用程序可以實現更快的處理並保持流暢的用戶體驗。

Lagrange的@lagrangelabs/a-big-data-primer-introducing-zk-mapreduce-12cf404eab75">ZK MapReduce (ZKMR)利用數據並行和任務並行來有效地並行化和生成大數據集上分布式計算的證明。在映射階段，輸入數據集被劃分爲更小的塊，每個塊被一個獨立的映射器工作器或機器並行處理（任務並行）。”映射”操作可以在每個映射任務的多個核或處理器上並行化（數據並行）。同樣，在規約階段，每個鍵關聯的值的”規約”操作可以在每個規約任務中並行化（數據並行）。相反，規約任務在多個工作器上並行執行（任務並行）。

通過結合數據並行和任務並行，ZKMR可以在保持零知識保證的情況下，通過遞歸證明組合實現大規模數據集上復雜計算的高效擴展和性能。

Lagrange在其“Introducing ZK MapReduce”一文中，闡述了如何在ZK中驗證任意的MapReduce過程

Lagrange成功實現了在1分鍾20秒內爲@lagrangelabs/announcing-testnet-euclid-ethereum-s-first-verifiable-database-and-zk-coprocessor-cc4a5595365c">888,888個存儲槽的SQL計算生成存儲證明，這充分展示了ZKMR的強大能力，以及支持它的任務和數據並行性。此外，Lagrange最近的Reckle Trees論文強調了並行性的必要性，它確保了鏈上數據的批量證明也可以在𝑂(log𝑛)內計算，與批量大小無關。

並行化共識和執行

雖然這篇文章並未討論共識，但區塊鏈也可以並行化共識和執行的過程。傳統的區塊鏈通常順序處理交易，在對一個區塊的交易（區塊N）達成共識後再執行它們。像Monad這樣的系統就是並行處理共識和執行階段的典型例子，它顯著提高了執行效率。在網路達成區塊N的共識的同時，它並行地執行前一個區塊（N-1）的交易。

這種策略確保了計算資源的持續、有效利用，有效減少了空閒時間，提高了網路處理交易的能力。這些改進提高了系統的吞吐量和對抗網路垃圾信息的資本成本。

解釋器與減少開銷

當智能合約用如Solidity這樣的語言編寫時，首先被編譯成較低級別的字節碼。然後，EVM使用解釋器執行這個字節碼。解釋器逐個讀取並執行指令，類似於在外語被說出的同時實時進行翻譯。Paradigm的最新文章Reth指出，這導致了開銷，因爲在運行時每個指令都必須單獨處理並從字節碼轉換爲機器指令。

Reth 通過引入即時（JIT）編譯器來解決EVM的效率問題。這個編譯器在執行前不久將字節碼翻譯成本地機器代碼，規避了在運行時通常需要的資源密集型的解釋過程。

Reth文章提到，在基於解釋器的系統中，EVM執行時間的50%用於JIT理論上可以優化的過程，這暗示了用JIT實現可以使執行速度加倍的可能性。然而，正如Yilong在此演示中指出的，JIT可以顯著減少處理特定操作碼所需的時間，但可能不會大幅影響總體執行時間。這是因爲JIT佔用的EVM執行時間的50%中的大部分涉及到“主機” 和 “系統” 操作（第13頁），由於它們的非計算性質，這些操作不適合進行JIT優化，如”算術”或”控制”。

雖然解釋器可能會限制性能，但它們確實創造了“翻譯”的機會，增加了可以利用新虛擬機的代碼的範圍，降低了開發者使用設計師區塊空間的開銷。例如，Movement Labs開發了Fractal，使開發者能夠在MoveVM上部署他們基於Solidity的合約。Fractal的工作方式是將Solidity編譯成包含用EVM操作碼表達的指令的中間語言，然後將這些指令映射到它們在MoveVM字節碼中的對應物，從而讓Solidity合約在MoveVM環境中運行。

專業化和定制化的狀態機

定制執行層涉及設計專門針對特定應用優化的狀態機。這不僅意味着執行環境可以完全放棄虛擬機的需要，而且還使應用可以根據其特定需求來定制指令集架構（ISA）、數據結構和執行模型。定制一個ISA以適應特定應用的主要性能優勢來自於減少將應用的計算模式翻譯成傳統ISA的通用指令的開銷。通用CPU使用基本指令集（如：加、載、分支）來支持運行不同類型的軟件。然而，當應用頻繁地重復相同的多步操作時，使用簡單指令的序列實現這些模式變得效率低下。

例如，數據庫應用可能需要不斷地遍歷樹形數據結構，查找條目，更新值和重新平衡樹。在普通的CPU上，將這些高級操作映射需要將它們分解爲長序列的低級微操作，如負載、存儲、分支和算術，在普通硬件上單獨執行。相比之下，爲數據庫定制的ISA可以將這些反復出現的模式合並到優化的更寬指令中，利用專門設計的並行比較電路。”TraverseTree” 指令可能會計算內存地址，加載相關節點，並使用專門爲該操作設計的比較鍵。”UpdateEntry”可能直接從優化的數據庫存儲布局中獲取條目，修改它，並在一個指令中提交新狀態。

這消除了從高級操作向簡單指令翻譯的冗餘開銷。它還允許硬件以更少但更寬的，明確並行的指令，精確地滿足其需求來最優化地執行應用。

LayerN的Nord通過他們特定用例的可驗證訂單簿來展示專業化執行環境和數據結構的性能優勢。LayerN的方法主要是優化將交易放入訂單簿數據結構的位置，同時他們的流水線機制被設計爲高效地在訂單簿的數據樹內插入新的訂單。通過將數據結構和插入算法定制到訂單簿的特定要求，LayerN實現了低延遲訂單放置和高吞吐量。

另外，也可以傾向於通用執行環境，使應用可以插入任意可編程的模塊以優化其性能。這種方法優先考慮開發者體驗而不是原始性能。

Fluent 和CWD採用了一種策略，平衡了優化原始計算性能與提高開發者體驗和生態系統兼容性之間的權衡。這種方法的核心是使用WebAssembly（Wasm）作爲虛擬機來執行代碼。由於Wasm的廣泛語言支持和廣泛採用程度，Wasm已經成爲web開發的首選。

開發者選擇使用Wasm而不是本地客戶端執行反映了對通用執行環境的廣泛可用性和多功能性的戰略優先考慮。盡管本地執行（直接在硬件上運行代碼，無需虛擬機）可以提供更好的性能，但它限制了跨平台的兼容性，對開發者來說不夠方便。相比之下，Wasm確保了在不同平台上的統一和安全的執行環境，盡管沒有達到與本地執行相同的原始速度。這種權衡符合Fluent和CWD的設計理念，優先考慮開發者的生產力和更廣泛的生態系統集成，而不是最大的性能效率。

特別地，CosmWasm 部署（CWD）不僅採用Wasm執行智能合約，還將其融入到一個更廣泛的框架中，以支持區塊鏈操作的復雜性。這個框架豐富了”週邊邏輯”，提供了高級帳戶管理、可定制的gas機制和優化的交易排序。這些功能爲開發者提供了一個靈活、高效、安全的開發環境，使開發者可以更輕鬆地構建出可擴展、復雜的去中心化應用程式（dapps）。

Stackr* 採用了不同的方法，通過結合定制執行環境的優點和傳統智能合約平台的靈活性。Stackr允許開發者將應用編碼爲rollups，使他們可以定義自己的交易排序、執行和配置規則。在Stackr模型中，開發者可以選擇最適合其應用需求的ISA、數據結構和執行模型。

來自“介紹Stackr SDK”的Stackr的微型Rollup設計

借助Stackr，開發者可以直接在應用程序的運行時應用狀態轉換規則，而不受通用虛擬機規則的限制，使他們能夠簡化指令集以提高效率，並重新定義運行時環境中可以執行的操作集。

這導致了更輕量級、更高效的執行，因爲業務邏輯在客戶端級別實現，消除了需要昂貴的智能合約調用和驗證的必要性。因此，開發者可以在不犧牲性能的情況下，擴展應用程序的配置可能性，包括可以爲單個應用程序使用的不同類型的語言、數據結構和籤名。

---

結論

實現最佳執行層性能的途徑有多種。

在試圖吸引去中心化應用時，狀態訪問或並行優化中沒有一項突出成爲執行層之間的技術差異化點。正如我們所探討的，Solana上的基於資源的並行化的好處可以同樣應用到Fuel的UTXO模型上。任何人都可以使用Amazon的通過分片提高水平擴展性的深思熟慮的解決方案來提升執行層性能。

雖然執行層性能是贏得去中心化應用開發者的關鍵向量，但新的L1s和L2s以改進執行爲中心必須在其他變量上進行競爭，包括安全性、互操作性和與現有工具的兼容性。因此，新的互操作性層——從Nebra到Statenet到Polygon的AggLayer——對開發者購買定制的區塊空間至關重要，因爲他們可以在不犧牲傳統的、通用的L1的同步組合性和共享流動性的前提下，構建或購買專用的區塊空間。

狀態管理和計算效率的改進是相互依賴的。

在設計新執行層的社區中，狀態訪問的並行化已經成爲他們承諾帶來性能改進的一個定義性特徵。這有充分的理由，因爲它可能導致EVM執行的提升5倍。然而，從Monad早期的並行化實驗中得到的證據表明，如果不同時開發其他的改進，如異步I/O，那麼並行化的作用就被過分強調了。

基於此，我們可以得出結論，只有在改善狀態的訪問和存儲方式時，才能實現計算效率的顯著提高。高效的狀態管理減少了訪問和操縱數據所需的時間和資源，加快了處理速度，減輕了計算負荷。

深入一步，現有的區塊鏈可能會做出路徑依賴的選擇，這會阻礙他們與重新設計狀態管理和更新方式的新區塊鏈設計競爭，因爲硬分叉帶來的慣性。因此，專門的、模塊化的執行層和其他的L1可能能夠圍繞更有效的狀態存儲和讀寫協議的設計選擇創建防御性。這些設計決策提供了競爭優勢，因爲現有的區塊鏈可能在不進行硬分叉的情況下，遇到更新數據庫結構的慣性。

歸根結底，一個區塊空間的價值觀影響了執行層的設計空間。

在了解如何改進執行層時，我們現在可以根據兩個關鍵設計選擇來描述優化類別的不同：誰在執行交易，以及需要涉及多少節點？解決執行瓶頸的技術對於開發人員來說，根據團隊對這些問題的初始答案，差別顯著。

一方面，像Solana和Monad這樣的單一L1不接受將驗證者的角色分離成強大和弱小的節點以提高性能。短期內“接受”狀態膨脹並不是可行的解決方案，因此他們依賴於數據庫層和塊生產引擎的其他組件（如共識）的改進，以彌補廣大數目的執行節點被視爲網路的關鍵組件和核心價值。因爲這些L1的安全模型依賴於更分散的一組具有較弱硬件要求的驗證者的共識，他們的數據需要寫入落在磁盤上的數據庫，這對於無需許可和最大程度去中心化的區塊鏈來說必然更加便宜。

另一方面，像以太坊及其 L2 的項目正在追求一條路線圖，通過集中執行節點中的塊構建者，通過欺詐或有效性證明讓弱小的驗證者節點對其負責。

假設交易和狀態轉換的集中“執行者”在追求去中心化未來中被認爲是可接受的。那麼，物理定律表明，那些可以1）不需要多個參與者重新執行交易就能在鏈上添加區塊，2）增加驗證者要求以最大化內存計算（並忽略狀態膨脹問題），3）減少延遲和共識瓶頸的系統，明顯勝過依賴廣泛去中心化和節點之間共識的系統。

在尋求可伸縮性和信任最小化之間的平衡時，顯然執行層的目標不應該是盲目地優化去中心化，也不必總是完全無需許可的執行。

隨着我們開發和實施更廣泛的加密工具，如有效性和欺詐證明，我們實際上減少了抵抗審查和維護安全性和活力所必需的節點數量。然而，這個方法涉及到權衡，可能會由於執行者可能集中化，影響審查抗性、排序完整性和活力保證。

正如 Sreeram 所指出的，”最小可行的去中心化”並不意味着”驗證應該是無需許可的”，而是應該”正確地被激勵”。這意味着在一個受到嚴密監控的系統中，驗證者如果行爲不當會面臨嚴重的後果，可以在不需要過度去中心化的情況下維持安全性和活力（感謝Sreeram）。

這樣的治理模型已經在實際應用中被測試。例如，像Arbitrum這樣的rollups正在探索基於治理或委員會的系統來執行交易排序和領導者選擇規則，他們正在考慮使用鏈上數據的序列器來維護交易排序策略。

盡管有這些進步，但在平衡去中心化與性能之間並沒有明確的”帕累托最優邊界（pareto optimal frontier）”。

出於意識形態和技術考慮，仍然傾向於去中心化執行節點以驗證狀態。雖然集中節點可以減少共識開銷，升級硬件也可以顯著提高性能，但這些優化措施能否吸引開發人員專注於創建抗審查應用程序，以及抗審查在多大程度上仍是行業的核心價值，都還有待觀察。

*表示 Archetype 投資組合的公司

聲明：

1. 本文轉載自[鏡子]，轉發原標題《Designer Blockspace：執行環境的未來》，所有版權歸原作者所有[本傑明·馮克]。若對本次轉載有異議，請聯系Gate Learn團隊，他們會及時處理。

2. 免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。

3. Gate Learn 團隊將文章翻譯成其他語言。除非另有說明，否則禁止復制、分發或抄襲翻譯文章。