並行區塊鏈設計空間探索（第一部分）
摘要：本研究報告提供了對區塊鏈並行設計架構的全面概述，選取了Solana、Sei 和 Monad 三個案例進行分析。文中詳細比較了Optimistic並行化與決定性並行化的不同之處，並對這些區塊鏈系統中的狀態和內存訪問模式進行了細致考察。
介紹
1837年，計算機科學家和數學家查爾斯·巴貝奇設計了“分析機(Analytical Engine)”，爲並行計算奠定了理論基礎。在當今的加密技術領域，並行化成爲了一個核心議題，這是因爲區塊鏈技術正努力突破處理速度、效率及吞吐量的限制。
並行宇宙
並行計算使得許多計算或進程能夠同時執行，與串行執行或一個接一個地執行計算相反。並行計算指的是將較大的問題分解成較小的、獨立的部分，這些部分可以由多個處理器通過共享內存進行通信來執行。並行系統有許多優勢，例如提高效率和速度、可擴展性、提高可靠性和容錯能力、更好的資源利用以及能夠處理非常大的數據集。
然而，至關重要的是要認識到，並行化的有效性取決於底層架構和實現的具體情況。阻礙區塊鏈的兩個核心瓶頸是密碼學函數（哈希函數、籤名、橢圓曲線等）和內存/狀態訪問。在區塊鏈中，設計高效並行系統的關鍵組成部分之一在於訪問狀態的細微差別。狀態訪問指的是交易讀取和寫入區塊鏈狀態的能力，包括存儲、智能合約和帳戶餘額。要使並行化區塊鏈有效和高性能，必須優化狀態訪問。
目前關於優化並行化區塊鏈的狀態訪問有兩種思路：確定性並行化與Optimistic並行化。確定性並行化要求代碼明確聲明哪些區塊鏈狀態的部分將被訪問和修改。這允許系統事先確定哪些交易可以並行處理而不會發生衝突。確定性並行化允許可預測性和效率（特別是當交易大多是獨立的時候）。然而，它確實爲開發者創建了更多的復雜性。
Optimistic並行化不要求代碼事先聲明其狀態訪問，而是假設不會有衝突地並行處理交易。如果發生衝突，Optimistic並行化將重新運行、重新處理或串行運行衝突的交易。雖然Optimistic並行化爲開發者提供了更多的靈活性，但衝突需要重新執行，這使得這種方法在交易不衝突時最爲高效。關於這些方法哪一個更好，並沒有確切的答案。它們只是並行化的兩種不同（且可行的）方法。
在本系列的第一部分，我們首先探索一些非加密並行系統的基礎知識，隨後將關注區塊鏈的並行執行設計空間，重點是三個核心領域：
加密並行系統概述
內存與狀態訪問方法
並行設計的機會
非加密並行系統
根據我們上面剛剛讀到的有關並行計算的功能和並行系統的優點的內容，很容易理解爲什麼近年來並行計算的採用已經開始興起。僅在過去幾十年裏，並行計算的廣泛採用就實現了許多突破。
- 醫學影像：並行處理從根本上改變了醫學成像，使得MRI、CT、X光和光學層析等各種模式的速度和分辨率顯著提高。Nvidia站在這些進步的前沿，通過其並行處理工具包爲放射科醫生提供增強的人工智能能力，使成像系統能更有效地處理增加的數據和計算負載。
- 天文學： 一些新現象，例如理解黑洞，只有通過使用並行超級計算機才成爲可能。
- Unity的遊戲引擎：Unity的引擎利用GPU的能力——這些GPU爲處理大量圖形工作負載而構建——以幫助提高性能和速度。該引擎配備了多線程和並行處理功能，提供無縫的遊戲體驗，並創建復雜、詳細的遊戲環境。
接下來，讓我們檢視三個實施了並行執行環境的區塊鏈。首先，我們將解析Solana，其次是兩個基於EVM的鏈，Monad和Sei
並行設計概述 – Solana
Solana的設計哲學核心在於，隨着硬件技術的進步，區塊鏈創新也應相應發展。這一理念基於摩爾定律，即硬件的性能和可擴展性將隨時間不斷提高，Solana致力於充分利用這一趨勢。Solana的聯合創始人Anatoly Yakovenko於五年前最初設計了其並行架構，現在，這種基於並行性的區塊鏈設計原則正在快速普及。
Solana採納了基於Anatoly在嵌入式系統領域工作經驗的決定性並行化策略，在那裏，通常需要 upfront（提前）聲明所有狀態。這一做法讓CPU能夠預知所有依賴關係，並提前獲取所需的內存部分，優化了系統執行性能。但值得注意的是，這種方法要求開發者 upfront（提前）進行額外工作。在Solana上，程序的所有內存依賴都必須 upfront（提前）聲明，在構造交易時需要指明訪問列表，這樣運行時系統就能高效地並行調度和執行多個交易。
Solana架構的另一個關鍵組成部分是Sealevel VM，這是Solana的並行智能合約執行環境。Sealevel VM天生就支持根據驗證者所擁有的核心數量並行處理多個合約和交易。在區塊鏈中，驗證者負責驗證交易、提議新的區塊以及維護區塊鏈的完整性和安全。通過 upfront（提前）聲明哪些帳戶需要讀取和寫入鎖定，Solana的調度器能夠確定哪些交易可以並行執行。因此，對於驗證者來說，作爲“區塊生產者”或領導者，可以對數以千計的待處理交易進行排序，並並行調度非重疊的交易。
Solana的另一個設計特點是其“流水線”處理方式。流水線處理發生在數據需要經過一系列處理步驟時，由不同的硬件負責每個步驟。其核心思想是把需要串行處理的數據通過流水線技術實現並行化。這些流水線能夠並行運行，每個流水線階段能夠並行處理不同批次的交易。
這些優化使得Sealevel可以組織並同時執行獨立的交易，借助硬件的能力，通過單個程序同時處理多個數據點。Sealevel通過程序ID對指令進行排序，並在所有相關帳戶上並行執行相同指令。
綜上所述，Solana的設計創新明確旨在支持並行化處理，充分展示了其設計理念的先進性和對硬件發展趨勢的深刻理解。
並行設計概述 – Sei
Sei 是一個針對數字資產交換專門化的通用、開源的一級區塊鏈。Sei V2 利用Optimistic並行化，因此，與其確定性對手相比，對開發者更爲友好。在Optimistic並行化中，智能合約可以更順暢、更並發地執行，而無需開發者 upfront 聲明他們的資源。這意味着鏈Optimistic地並行運行所有交易。但是，當存在衝突時（即，多個交易訪問同一狀態），區塊鏈將跟蹤每個衝突交易影響的特定存儲組件。
Sei 的區塊鏈使用“Optimistic並發控制（OCC）”來執行交易。當系統中同時存在多個交易時，就會發生並發交易處理。這種交易方法有兩個階段：執行和驗證。
在執行階段，交易被Optimistic地處理，所有讀/寫操作臨時存儲在交易特定的存儲中。之後，每個交易都會進入驗證階段，此時，臨時存儲操作中的信息會與之前交易所做的任何狀態改變進行檢查。如果一個交易是獨立的，那麼該交易並行運行。如果一個交易讀取了由另一交易修改的數據，這將產生衝突。Sei 的並行系統會通過比較交易的讀取集合與多版本存儲中的最新狀態改變（這些由交易順序索引）來識別每個衝突。Sei 將重新執行和重新驗證出現衝突的實例。這是一個包括執行、驗證和重新運行的迭代過程，以解決衝突。下面的圖表說明了 Sei 在出現衝突時處理交易的方法。
來源：https://blog.sei.io/sei-v2-the-first-parallelized-evm/
Sei 的實現導致更低的Gas費用和更廣泛的設計空間，爲EVM開發者提供。歷史上，EVM環境限制在小於50 TPS，這迫使開發者創建遵循反模式的應用程序。Sei V2 使開發者能夠涉足通常需要高性能和低費用的領域，如DeFi、DePIN和遊戲。
並行設計概述 – Monad
Monad 正在構建一個具有完全字節碼兼容性的並行 EVM 第 1 層。Monad 獨特之處不僅在於其並行引擎，還在於他們爲優化該引擎所做的底層建設。Monad 採取了獨特的整體設計方法，包括管道化、異步 I/O、分離共識和執行，以及 MonadDB。
Monad 設計中的一個關鍵創新是帶有微小偏移的管道化。這種偏移使得通過同時運行多個實例，可以並行化更多的過程。因此，管道化用於優化許多功能，如狀態訪問管道化、交易執行管道化、共識與執行中的管道化，以及共識機制本身內的管道化。
接下來，我們將深入探討 Monad 的並行化部分。在 Monad 中，交易在區塊內線性排序，但目標是通過利用並行執行來更快地達到這一最終狀態。Monad 使用一種Optimistic 的並行算法來設計其執行引擎。Monad 的引擎同時處理交易，然後進行分析，以確保如果交易依次執行，結果會相同。如果存在任何衝突，就需要重新執行。這裏的並行執行是一個相對簡單的算法，但與 Monad 的其他關鍵創新結合起來，使得這種方法顯得新穎。需要注意的一點是，即使重新執行，通常也是低成本的，因爲無效交易所需的輸入幾乎總是保留在緩存中，因此它將是一個簡單的緩存查找。重新執行是有保證的成功，因爲你已經執行了區塊中的前一個交易。
Monad 還通過分離執行和共識來提高性能，類似於 Solana 和 Sei，此外還有延遲執行。這裏的想法是，如果你放寬執行完成的條件到共識完成的時間，你可以並行運行兩者，從而爲兩者提供額外的時間。當然，Monad 使用一個確定性算法來處理這個條件，以確保這些中的一個不會跑得太遠而沒有趕上的可能性。
獨特的狀態訪問與內存方法
如我在本文開頭所提到的，狀態訪問是區塊鏈的典型性能瓶頸之一。狀態訪問和內存的設計選擇最終決定了並行系統的特定實現是否能在實踐中提升性能。這裏，我們將解析並比較Solana、Sei和Monad採取的不同方法。
Solana狀態訪問：AccountsDB / Cloudbreak
Solana採用橫向擴展來分布和管理狀態數據，跨多個SSD設備。今天許多區塊鏈使用通用數據庫（例如，LevelDB）來處理大量並發讀寫狀態數據時的限制。爲了避免這一點，Solana構建了自己的定制AccountsDB，利用Cloudbreak。
Cloudbreak是爲跨I/O操作的並行訪問而設計的，而不是僅僅依賴於RAM，後者本質上是快速的。I/O操作（輸入/輸出）指的是從外部源（如磁盤、網路或外圍設備）讀取數據或寫入數據。最初，Cloudbreak採用了一個在RAM中的索引，用於映射公鑰到持有餘額和數據的帳戶。然而，截至撰寫本文和版本1.9，索引已經從RAM移出，存放到SSDs上。這一轉變允許Cloudbreak同時處理隊列中的32個I/O操作，提高了跨多個SSDs的吞吐量。因此，如同使用內存映射文件一樣，區塊鏈數據（如帳戶和交易）可以高效地被訪問，盡管RAM更快，但它的容量較少且通常更昂貴：
說明性的內存層次結構圖
通過水平擴展並在多個設備上分布狀態數據，Cloudbreak降低了延遲並提高了效率、去中心化和網路彈性，這些都是Solana生態系統內的重要改進。
狀態訪問：SeiDB
Sei重新設計了其存儲系統SeiDB，以解決幾個問題：寫放大（維護數據結構所需的元數據量，更小=更好）、狀態膨脹、操作緩慢以及隨時間性能降低。新的設計現在分爲兩個部分：狀態存儲和狀態提交。任何對數據變更的記錄和驗證都由狀態提交處理，而記錄任何時點所有數據的數據庫由狀態存儲（SS）處理。
在Sei V2中，狀態提交使用內存映射IAVL樹架構（MemIAVL）。內存映射IAVL樹存儲的元數據較少，這減少了狀態存儲和狀態同步時間，並且使運行全節點變得更加容易。內存映射IAVL樹表示爲磁盤上的三個文件（kv, branch, leaves）；因此，需要追蹤的元數據較少，這有助於將狀態存儲減少50%以上。新的MemIAVL結構有助於減少寫放大因子，因爲它減少了維護數據結構所需的元數據。
更新後的SeiDB允許狀態存儲層支持靈活的數據庫後端。Sei認爲，不同的節點操作者將有不同的需求和存儲需求。因此，SS被設計爲能夠適應不同的後端，爲操作者提供自由和靈活性，即PebbleDB、RocksDB、SQLite等。
狀態訪問：MonadDB
Monad的狀態訪問有一些重要的細微差別。首先，大多數以太坊客戶端利用兩種類型的數據庫：B-Tree數據庫（例如LMDB）或日志結構合並樹（LSM）數據庫（例如RocksDB, LevelDB）。這兩種都是通用數據結構，並非專爲區塊鏈設計。此外，這些數據庫沒有利用Linux技術最新的進步，特別是關於異步操作和I/O優化。最後，以太坊本身使用Patricia Merkle Trie管理狀態，專注於加密、驗證和證明。主要問題是，客戶端必須將這種特定的Patricia Merkle Trie整合到更通用的數據庫（即B-Tree / LSM）中，導致顯著的性能缺點，如過度的磁盤訪問。
上述所有這些都爲Monad決定創建專門設計的MonadDB數據庫鋪平了道路，這個數據庫旨在更高效地處理區塊鏈數據和狀態訪問。MonadDB的一些關鍵特性包括並行訪問數據庫、針對Merkle Trie數據優化的自定義數據庫、高效的狀態訪問與標準RAM使用之上、去中心化與可擴展性。
MonadDB專門爲區塊鏈設計，比利用通用數據庫更爲高效。定制的MonadDB專爲高效管理Merkle trie型數據而量身定做，使得可以同時並行訪問多個trie節點。盡管MonadDB與上述某些通用數據庫的單次讀取成本相同，但關鍵在於MonadDB可以並行進行多次讀取，從而大幅提速。
MonadDB通過並行訪問數據庫，實現了狀態的同時訪問。由於Monad從零開始構建這個數據庫，它能夠利用最新的Linux內核技術和SSD的全部能力進行異步I/O。通過異步I/O，如果交易需要從磁盤讀取狀態，這不應該阻止等待完成的操作。相反，它應該開始讀取，並同時繼續處理其他交易。這就是異步I/O顯著加速MonadDB處理的方式。Monad通過優化SSD的使用並減少對過量RAM的依賴，從硬件中提取了更好的性能。這還有助於與去中心化和可擴展性保持一致。
對Solana、Sei與Monad的比較總結
結論
通過 Solana、Sei 和 Monad 的視角探索區塊鏈中的並行化，爲理解不同架構和方法如何提高性能和可擴展性提供了全面的認識。Solana 的確定性並行化通過 upfront 聲明狀態訪問，提供了可預測性和效率，使其成爲需要高吞吐量應用的有力選擇。另一方面，Sei 的Optimistic 並行化方法優先考慮開發者靈活性，非常適合事務衝突不頻繁的環境。Monad 通過其獨特的Optimistic 並行化和定制的 MonadDB，提出了一個創新解決方案，利用最新技術優化狀態訪問和性能。
每個區塊鏈都呈現出獨特的並行化挑戰應對方法，擁有自己的權衡。Solana 的設計旨在最大化硬件利用率和吞吐量，而 Sei 關注於簡化開發過程，Monad 強調爲區塊鏈數據定制的數據庫解決方案。這些差異凸顯了區塊鏈生態系統的多樣性及基於應用特定需求選擇合適平台的重要性。
隨着區塊鏈領域的持續發展，Solana、Monad 和 Sei 所展示的並行化技術進步無疑將激發進一步的創新。朝着更高效、可擴展和開發者友好的區塊鏈前進的旅程正在進行中，從這些平台學到的經驗將在塑造區塊鏈技術未來中發揮關鍵作用。
在本系列的第二部分，我們將深入探討這些並行設計系統相關的經濟含義和權衡。
聲明：
- 本文轉載自[Reciprocal Ventures]，所有版權歸原作者[Ali Sheikh]所有。如果對此轉載有異議，請聯系Gate Learn團隊，他們將及時處理。
- 責任免責聲明：本文中表達的觀點和意見僅代表作者本人，並不構成任何投資建議。
- 文章的其他語言翻譯由 Gate Learn 團隊完成。除非另有說明，否則禁止復制、分發或抄襲翻譯文章。
相关文章
什麼是穩定幣 USDT？
並行區塊鏈設計空間探索（第一部分）
摘要：本研究報告提供了對區塊鏈並行設計架構的全面概述，選取了Solana、Sei 和 Monad 三個案例進行分析。文中詳細比較了Optimistic並行化與決定性並行化的不同之處，並對這些區塊鏈系統中的狀態和內存訪問模式進行了細致考察。
介紹
1837年，計算機科學家和數學家查爾斯·巴貝奇設計了“分析機(Analytical Engine)”，爲並行計算奠定了理論基礎。在當今的加密技術領域，並行化成爲了一個核心議題，這是因爲區塊鏈技術正努力突破處理速度、效率及吞吐量的限制。
並行宇宙
並行計算使得許多計算或進程能夠同時執行，與串行執行或一個接一個地執行計算相反。並行計算指的是將較大的問題分解成較小的、獨立的部分，這些部分可以由多個處理器通過共享內存進行通信來執行。並行系統有許多優勢，例如提高效率和速度、可擴展性、提高可靠性和容錯能力、更好的資源利用以及能夠處理非常大的數據集。
然而，至關重要的是要認識到，並行化的有效性取決於底層架構和實現的具體情況。阻礙區塊鏈的兩個核心瓶頸是密碼學函數（哈希函數、籤名、橢圓曲線等）和內存/狀態訪問。在區塊鏈中，設計高效並行系統的關鍵組成部分之一在於訪問狀態的細微差別。狀態訪問指的是交易讀取和寫入區塊鏈狀態的能力，包括存儲、智能合約和帳戶餘額。要使並行化區塊鏈有效和高性能，必須優化狀態訪問。
目前關於優化並行化區塊鏈的狀態訪問有兩種思路：確定性並行化與Optimistic並行化。確定性並行化要求代碼明確聲明哪些區塊鏈狀態的部分將被訪問和修改。這允許系統事先確定哪些交易可以並行處理而不會發生衝突。確定性並行化允許可預測性和效率（特別是當交易大多是獨立的時候）。然而，它確實爲開發者創建了更多的復雜性。
Optimistic並行化不要求代碼事先聲明其狀態訪問，而是假設不會有衝突地並行處理交易。如果發生衝突，Optimistic並行化將重新運行、重新處理或串行運行衝突的交易。雖然Optimistic並行化爲開發者提供了更多的靈活性，但衝突需要重新執行，這使得這種方法在交易不衝突時最爲高效。關於這些方法哪一個更好，並沒有確切的答案。它們只是並行化的兩種不同（且可行的）方法。
在本系列的第一部分，我們首先探索一些非加密並行系統的基礎知識，隨後將關注區塊鏈的並行執行設計空間，重點是三個核心領域：
加密並行系統概述
內存與狀態訪問方法
並行設計的機會
非加密並行系統
根據我們上面剛剛讀到的有關並行計算的功能和並行系統的優點的內容，很容易理解爲什麼近年來並行計算的採用已經開始興起。僅在過去幾十年裏，並行計算的廣泛採用就實現了許多突破。
- 醫學影像：並行處理從根本上改變了醫學成像，使得MRI、CT、X光和光學層析等各種模式的速度和分辨率顯著提高。Nvidia站在這些進步的前沿，通過其並行處理工具包爲放射科醫生提供增強的人工智能能力，使成像系統能更有效地處理增加的數據和計算負載。
- 天文學： 一些新現象，例如理解黑洞，只有通過使用並行超級計算機才成爲可能。
- Unity的遊戲引擎：Unity的引擎利用GPU的能力——這些GPU爲處理大量圖形工作負載而構建——以幫助提高性能和速度。該引擎配備了多線程和並行處理功能，提供無縫的遊戲體驗，並創建復雜、詳細的遊戲環境。
接下來，讓我們檢視三個實施了並行執行環境的區塊鏈。首先，我們將解析Solana，其次是兩個基於EVM的鏈，Monad和Sei
並行設計概述 – Solana
Solana的設計哲學核心在於，隨着硬件技術的進步，區塊鏈創新也應相應發展。這一理念基於摩爾定律，即硬件的性能和可擴展性將隨時間不斷提高，Solana致力於充分利用這一趨勢。Solana的聯合創始人Anatoly Yakovenko於五年前最初設計了其並行架構，現在，這種基於並行性的區塊鏈設計原則正在快速普及。
Solana採納了基於Anatoly在嵌入式系統領域工作經驗的決定性並行化策略，在那裏，通常需要 upfront（提前）聲明所有狀態。這一做法讓CPU能夠預知所有依賴關係，並提前獲取所需的內存部分，優化了系統執行性能。但值得注意的是，這種方法要求開發者 upfront（提前）進行額外工作。在Solana上，程序的所有內存依賴都必須 upfront（提前）聲明，在構造交易時需要指明訪問列表，這樣運行時系統就能高效地並行調度和執行多個交易。
Solana架構的另一個關鍵組成部分是Sealevel VM，這是Solana的並行智能合約執行環境。Sealevel VM天生就支持根據驗證者所擁有的核心數量並行處理多個合約和交易。在區塊鏈中，驗證者負責驗證交易、提議新的區塊以及維護區塊鏈的完整性和安全。通過 upfront（提前）聲明哪些帳戶需要讀取和寫入鎖定，Solana的調度器能夠確定哪些交易可以並行執行。因此，對於驗證者來說，作爲“區塊生產者”或領導者，可以對數以千計的待處理交易進行排序，並並行調度非重疊的交易。
Solana的另一個設計特點是其“流水線”處理方式。流水線處理發生在數據需要經過一系列處理步驟時，由不同的硬件負責每個步驟。其核心思想是把需要串行處理的數據通過流水線技術實現並行化。這些流水線能夠並行運行，每個流水線階段能夠並行處理不同批次的交易。
這些優化使得Sealevel可以組織並同時執行獨立的交易，借助硬件的能力，通過單個程序同時處理多個數據點。Sealevel通過程序ID對指令進行排序，並在所有相關帳戶上並行執行相同指令。
綜上所述，Solana的設計創新明確旨在支持並行化處理，充分展示了其設計理念的先進性和對硬件發展趨勢的深刻理解。
並行設計概述 – Sei
Sei 是一個針對數字資產交換專門化的通用、開源的一級區塊鏈。Sei V2 利用Optimistic並行化，因此，與其確定性對手相比，對開發者更爲友好。在Optimistic並行化中，智能合約可以更順暢、更並發地執行，而無需開發者 upfront 聲明他們的資源。這意味着鏈Optimistic地並行運行所有交易。但是，當存在衝突時（即，多個交易訪問同一狀態），區塊鏈將跟蹤每個衝突交易影響的特定存儲組件。
Sei 的區塊鏈使用“Optimistic並發控制（OCC）”來執行交易。當系統中同時存在多個交易時，就會發生並發交易處理。這種交易方法有兩個階段：執行和驗證。
在執行階段，交易被Optimistic地處理，所有讀/寫操作臨時存儲在交易特定的存儲中。之後，每個交易都會進入驗證階段，此時，臨時存儲操作中的信息會與之前交易所做的任何狀態改變進行檢查。如果一個交易是獨立的，那麼該交易並行運行。如果一個交易讀取了由另一交易修改的數據，這將產生衝突。Sei 的並行系統會通過比較交易的讀取集合與多版本存儲中的最新狀態改變（這些由交易順序索引）來識別每個衝突。Sei 將重新執行和重新驗證出現衝突的實例。這是一個包括執行、驗證和重新運行的迭代過程，以解決衝突。下面的圖表說明了 Sei 在出現衝突時處理交易的方法。
來源：https://blog.sei.io/sei-v2-the-first-parallelized-evm/
Sei 的實現導致更低的Gas費用和更廣泛的設計空間，爲EVM開發者提供。歷史上，EVM環境限制在小於50 TPS，這迫使開發者創建遵循反模式的應用程序。Sei V2 使開發者能夠涉足通常需要高性能和低費用的領域，如DeFi、DePIN和遊戲。
並行設計概述 – Monad
Monad 正在構建一個具有完全字節碼兼容性的並行 EVM 第 1 層。Monad 獨特之處不僅在於其並行引擎，還在於他們爲優化該引擎所做的底層建設。Monad 採取了獨特的整體設計方法，包括管道化、異步 I/O、分離共識和執行，以及 MonadDB。
Monad 設計中的一個關鍵創新是帶有微小偏移的管道化。這種偏移使得通過同時運行多個實例，可以並行化更多的過程。因此，管道化用於優化許多功能，如狀態訪問管道化、交易執行管道化、共識與執行中的管道化，以及共識機制本身內的管道化。
接下來，我們將深入探討 Monad 的並行化部分。在 Monad 中，交易在區塊內線性排序，但目標是通過利用並行執行來更快地達到這一最終狀態。Monad 使用一種Optimistic 的並行算法來設計其執行引擎。Monad 的引擎同時處理交易，然後進行分析，以確保如果交易依次執行，結果會相同。如果存在任何衝突，就需要重新執行。這裏的並行執行是一個相對簡單的算法，但與 Monad 的其他關鍵創新結合起來，使得這種方法顯得新穎。需要注意的一點是，即使重新執行，通常也是低成本的，因爲無效交易所需的輸入幾乎總是保留在緩存中，因此它將是一個簡單的緩存查找。重新執行是有保證的成功，因爲你已經執行了區塊中的前一個交易。
Monad 還通過分離執行和共識來提高性能，類似於 Solana 和 Sei，此外還有延遲執行。這裏的想法是，如果你放寬執行完成的條件到共識完成的時間，你可以並行運行兩者，從而爲兩者提供額外的時間。當然，Monad 使用一個確定性算法來處理這個條件，以確保這些中的一個不會跑得太遠而沒有趕上的可能性。
獨特的狀態訪問與內存方法
如我在本文開頭所提到的，狀態訪問是區塊鏈的典型性能瓶頸之一。狀態訪問和內存的設計選擇最終決定了並行系統的特定實現是否能在實踐中提升性能。這裏，我們將解析並比較Solana、Sei和Monad採取的不同方法。
Solana狀態訪問：AccountsDB / Cloudbreak
Solana採用橫向擴展來分布和管理狀態數據，跨多個SSD設備。今天許多區塊鏈使用通用數據庫（例如，LevelDB）來處理大量並發讀寫狀態數據時的限制。爲了避免這一點，Solana構建了自己的定制AccountsDB，利用Cloudbreak。
Cloudbreak是爲跨I/O操作的並行訪問而設計的，而不是僅僅依賴於RAM，後者本質上是快速的。I/O操作（輸入/輸出）指的是從外部源（如磁盤、網路或外圍設備）讀取數據或寫入數據。最初，Cloudbreak採用了一個在RAM中的索引，用於映射公鑰到持有餘額和數據的帳戶。然而，截至撰寫本文和版本1.9，索引已經從RAM移出，存放到SSDs上。這一轉變允許Cloudbreak同時處理隊列中的32個I/O操作，提高了跨多個SSDs的吞吐量。因此，如同使用內存映射文件一樣，區塊鏈數據（如帳戶和交易）可以高效地被訪問，盡管RAM更快，但它的容量較少且通常更昂貴：
說明性的內存層次結構圖
通過水平擴展並在多個設備上分布狀態數據，Cloudbreak降低了延遲並提高了效率、去中心化和網路彈性，這些都是Solana生態系統內的重要改進。
狀態訪問：SeiDB
Sei重新設計了其存儲系統SeiDB，以解決幾個問題：寫放大（維護數據結構所需的元數據量，更小=更好）、狀態膨脹、操作緩慢以及隨時間性能降低。新的設計現在分爲兩個部分：狀態存儲和狀態提交。任何對數據變更的記錄和驗證都由狀態提交處理，而記錄任何時點所有數據的數據庫由狀態存儲（SS）處理。
在Sei V2中，狀態提交使用內存映射IAVL樹架構（MemIAVL）。內存映射IAVL樹存儲的元數據較少，這減少了狀態存儲和狀態同步時間，並且使運行全節點變得更加容易。內存映射IAVL樹表示爲磁盤上的三個文件（kv, branch, leaves）；因此，需要追蹤的元數據較少，這有助於將狀態存儲減少50%以上。新的MemIAVL結構有助於減少寫放大因子，因爲它減少了維護數據結構所需的元數據。
更新後的SeiDB允許狀態存儲層支持靈活的數據庫後端。Sei認爲，不同的節點操作者將有不同的需求和存儲需求。因此，SS被設計爲能夠適應不同的後端，爲操作者提供自由和靈活性，即PebbleDB、RocksDB、SQLite等。
狀態訪問：MonadDB
Monad的狀態訪問有一些重要的細微差別。首先，大多數以太坊客戶端利用兩種類型的數據庫：B-Tree數據庫（例如LMDB）或日志結構合並樹（LSM）數據庫（例如RocksDB, LevelDB）。這兩種都是通用數據結構，並非專爲區塊鏈設計。此外，這些數據庫沒有利用Linux技術最新的進步，特別是關於異步操作和I/O優化。最後，以太坊本身使用Patricia Merkle Trie管理狀態，專注於加密、驗證和證明。主要問題是，客戶端必須將這種特定的Patricia Merkle Trie整合到更通用的數據庫（即B-Tree / LSM）中，導致顯著的性能缺點，如過度的磁盤訪問。
上述所有這些都爲Monad決定創建專門設計的MonadDB數據庫鋪平了道路，這個數據庫旨在更高效地處理區塊鏈數據和狀態訪問。MonadDB的一些關鍵特性包括並行訪問數據庫、針對Merkle Trie數據優化的自定義數據庫、高效的狀態訪問與標準RAM使用之上、去中心化與可擴展性。
MonadDB專門爲區塊鏈設計，比利用通用數據庫更爲高效。定制的MonadDB專爲高效管理Merkle trie型數據而量身定做，使得可以同時並行訪問多個trie節點。盡管MonadDB與上述某些通用數據庫的單次讀取成本相同，但關鍵在於MonadDB可以並行進行多次讀取，從而大幅提速。
MonadDB通過並行訪問數據庫，實現了狀態的同時訪問。由於Monad從零開始構建這個數據庫，它能夠利用最新的Linux內核技術和SSD的全部能力進行異步I/O。通過異步I/O，如果交易需要從磁盤讀取狀態，這不應該阻止等待完成的操作。相反，它應該開始讀取，並同時繼續處理其他交易。這就是異步I/O顯著加速MonadDB處理的方式。Monad通過優化SSD的使用並減少對過量RAM的依賴，從硬件中提取了更好的性能。這還有助於與去中心化和可擴展性保持一致。
對Solana、Sei與Monad的比較總結
結論
通過 Solana、Sei 和 Monad 的視角探索區塊鏈中的並行化，爲理解不同架構和方法如何提高性能和可擴展性提供了全面的認識。Solana 的確定性並行化通過 upfront 聲明狀態訪問，提供了可預測性和效率，使其成爲需要高吞吐量應用的有力選擇。另一方面，Sei 的Optimistic 並行化方法優先考慮開發者靈活性，非常適合事務衝突不頻繁的環境。Monad 通過其獨特的Optimistic 並行化和定制的 MonadDB，提出了一個創新解決方案，利用最新技術優化狀態訪問和性能。
每個區塊鏈都呈現出獨特的並行化挑戰應對方法，擁有自己的權衡。Solana 的設計旨在最大化硬件利用率和吞吐量，而 Sei 關注於簡化開發過程，Monad 強調爲區塊鏈數據定制的數據庫解決方案。這些差異凸顯了區塊鏈生態系統的多樣性及基於應用特定需求選擇合適平台的重要性。
隨着區塊鏈領域的持續發展，Solana、Monad 和 Sei 所展示的並行化技術進步無疑將激發進一步的創新。朝着更高效、可擴展和開發者友好的區塊鏈前進的旅程正在進行中，從這些平台學到的經驗將在塑造區塊鏈技術未來中發揮關鍵作用。
在本系列的第二部分，我們將深入探討這些並行設計系統相關的經濟含義和權衡。
聲明：
- 本文轉載自[Reciprocal Ventures]，所有版權歸原作者[Ali Sheikh]所有。如果對此轉載有異議，請聯系Gate Learn團隊，他們將及時處理。
- 責任免責聲明：本文中表達的觀點和意見僅代表作者本人，並不構成任何投資建議。
- 文章的其他語言翻譯由 Gate Learn 團隊完成。除非另有說明，否則禁止復制、分發或抄襲翻譯文章。
相关文章