解讀並行EVM L1 公鏈Monad：圍繞以太坊做了哪些優化 TPS可高達10000

作者：Rachit Srivastava，Avail建設者；翻譯：金色財經xiaozou

Monad是一個EVM兼容L1鏈，但圍繞以太坊的核心支柱重新進行了一些重大思考。所以，Monad能夠每秒處理高達10,000筆交易。最近Monad發布了他們的devnet。

它應用如下兩個概念：Pipelining和異步I/O。Pipelining是一種通過將任務劃分爲一系列可以並行處理的小任務來實現並行性的技術。而異步I/O是一種輸入/輸出處理形式，允許CPU在通信進行時就可進行並發執行。

那么MonadBFT有什么不同之處呢？MonadBFT是一種具有樂觀響應形式的pipelined兩階段BFT算法，在一般情況下採用线性通信开銷，在超時情況下採用二次通信开銷。

下面我們假設所有節點具有相同權益。

--MonadBFT需要2/3的節點達成共識。

--Leader發送一個新區塊以及“QC”或“TC”（閾值籤名是一種加密技術，它將生成數字籤名的能力分配給多個參與方。沒有任何一方可以代表整個團體籤名，必須由各方的一個子集（“閾值”）協作來生成籤名。）

--驗證者驗證區塊，並向leader發送Yes或No的響應。Leader通過聚合Yes和No投票（通過閾值籤名）派生QC（Quorum Certificate）。

--如果驗證失敗，驗證者會廣播一條經過籤名的超時消息，發送給所有節點。此消息包括驗證者觀察到的最高QC。如果任何驗證者累積的這些超時請求超過驗證者數量的2/3，將生成一個TC（Timeout Certificate）並將其發送給下一個leader。

--每個驗證者在收到第k+1輪的QC後，才能最終確定在第k輪提議的區塊。

--如果假設leader在第k+1輪中惡意作爲，在第k+2輪中，至少有一個驗證者將爲第k+1輪生成TC，第k+2輪的leader將進行查驗並生成該輪TC。

延遲執行

在以太坊中，執行是達成共識的先決條件，因此當節點就一個區塊達成共識時，它們是就區塊中的交易列表達成一致，也就執行該交易列表後總結所有狀態的默克爾根達成一致。因此，leader必須在共享提議之前執行提議區塊中的所有交易，驗證節點必須在投票響應之前執行這些交易。

從上面可以看出，在交易順序正式確定後，真實狀態是完全確定的。揭示真實狀態需要執行，但真實狀態已經確定。這是Monad優化的基礎。Monad利用了這一洞察，消除了共識達成前的節點執行要求。節點協議只關乎正式交易排序，各節點獨立執行區塊N中的交易，同時开始在區塊N+1上達成共識。

以太坊的做法使用共識以非常嚴格的方式實施狀態機復制：在節點達成共識後，我們知道絕對多數節點就正式排序以及該排序產生的狀態達成一致。Monad稍稍放松了這種嚴格。

--Monad的最終確定性爲單個slot（1秒）

--交易的執行結果（成功還是失敗？之後的余額是多少？）的最終確定通常會在全節點上延遲不到1秒。

--任何想要在不運行完整節點的情況下安全查詢交易結果的人都可以運行一個輕客戶端使用默克爾證明查詢完整節點余額。在這種情況下，查詢將因默克爾根的延遲而延遲。

運載成本

在網絡上以區塊形式進行網絡交易是有費用的。此項費用是與執行成本分开的。儲備余額用於支付運載成本。而執行余額則用來支付交易執行。

並行執行

Monad使用樂觀執行方式。這意味着Monad將在區塊中較早一批交易完成之前开始執行交易。有時（但不總是），這會導致執行錯誤。

如果所有交易都依賴於前一個交易，樂觀執行將通過跟蹤執行交易2時使用的輸入數據並將其與交易1的輸出數據進行比較來解決這個問題。

如果兩個數據不一致，而且我們檢測到交易2在執行時使用了錯誤數據，就需要使用正確數據再次執行。當Monad並行執行交易時，每個交易的狀態更新被按順序“合並”。

MonadDb

MonadDb是用於存儲區塊鏈狀態的自定義數據庫。大多數以太坊客戶端使用鍵值數據庫，這些數據庫被部署爲B-Tree（例如LMDB）或LSM-Tree（例如LevelDB和RocksDB）數據結構。

MonadDb在磁盤上和內存中部署Patricia Trie數據結構。Monad並行執行多個交易。當一個交易需要從磁盤讀取狀態時，不需要等待操作完成，而應發起讀取操作，然後在此期間开始處理另一個交易。