交易擴充功能一直是熱門話題。在過去幾週中，我們一直在探索 Monad 如何幫助擴展 TPS。
以下是由Saurabh Deshpande撰寫的關於 Monad 工作原理的詳細說明。
TPS 是我們非常關注的指標。我們希望我們的鏈能夠支援更高的 TPS，因為它們可以支援更多的用戶和應用程式。下面的圖表顯示了以太坊和 L2 的 TPS 數字。沒有一條鏈曾經突破過 100 TPS 的標誌。請注意，TPS 是一個通用的用於衡量規模的術語。 TPS 是不準確的，因為並非所有交易都相同，它們在複雜性上有所不同。但出於簡單起見，我們使用 TPS 作為衡量規模的指標。
如果我們想增加 TPS，我們該怎麼辦？
第一種方法是建立一個全新的系統，就像 Solana 所做的那樣。它犧牲了與速度相比的 EVM 相容性。它使用多執行緒執行而不是單執行緒執行（想想多核心 CPU 與單核心 CPU），進行平行化交易並使用了不同的共識機制。
第二種方法是使用鏈下執行，並使用中心化的排序器來擴展以太坊。
第三種方法是將 EVM 分解為單獨的元件，並對其進行最佳化以提高可擴展性。
Monad 是一個新的與 EVM 相容的 L1，最近籌集了 2.25 億美元，它正在從頭開始建立 EVM，而不是直接使用。它選擇了這第三種方法來增加可擴展性。
我們討論了 Monad 帶來的幾個重大變化。
以太坊虛擬機器（EVM）依序執行交易。在執行一個交易之前，下一個交易必須等待。可以這樣想。假設在一個摩托車組裝車間中有一個平台。多輛卡車運送摩托車零件（每輛卡車都有組裝 50 輛摩托車所需的所有零件）。組裝車間分別執行四種不同的功能：卸貨、分類、組裝和裝貨。
在目前的 EVM 設定中，只有一個平台，並且載入和卸載使用相同的位置。因此，當卡車停放時，摩托車零件被卸載、分類、組裝和裝載在同一輛卡車上。當分類團隊在工作時，其他團隊都在等待。因此，如果將它們的工作看作不同的插槽，每個團隊只在四個插槽中工作一次。這導致了顯著的低效率，突出了需要更加流暢的方法。
現在，想像有四個不同的裝載和卸載區域的平台。即使卸貨團隊一次只能與一輛卡車一起工作，他們也不需要等待下三個插槽。他們可以直接轉移到下一輛卡車。
分類、組裝和裝載團隊也是如此。一旦卸貨完成，卡車移動到裝載區等待裝載團隊裝載組裝好的摩托車。因此，只有一個平台和加載/卸載區域的倉庫按順序執行所有操作，而具有 4 個平台和不同加載/卸載區域的倉庫進行並行化。
將 Monad 視為基礎設施，相當於擁有多個卡車平台的倉庫。但並不簡單。當卡車依賴時，複雜性增加。例如，如果一輛卡車沒有所有零件來組裝 50 輛摩托車會怎麼樣？交易可能並不總是獨立的。因此，當 Monad 並行執行它們時，它必須處理彼此依賴的交易。
怎麼處理？它執行一種稱為樂觀並行執行的方法。協議只能並行執行獨立的交易。例如，考慮4 筆交易，其中Joel 的餘額為1 個ETH：
#Joel 將0.2 個以太發送給Saurabh
Sid 鑄造一個NFT
Joel 將0.1 個乙太傳送給Sid
Shlok 購買PEPE
所有這些交易都是並行執行的，待定結果逐一提交。如果待定結果的輸出與任何交易的原始輸入有衝突，則重新執行交易。交易 2 和 4 沒有與其他交易的輸入衝突的待定結果，因為它們彼此獨立。但交易 1 和 4 並不獨立。
請注意，由於所有 4 個交易都從同一狀態開始，所以關注的是 Joel 的餘額為 1 個ETH。 Joel 將 0.2 個ETH送出後，餘額為 0.8 個ETH。在 Joel 將 0.1 個ETH發送給 Sid 後，他的餘額為 0.9 個ETH。結果逐一提交，確保輸出不會與任何輸入衝突。在提交了 1 的待定結果後，Joel 的新餘額為 0.8 個ETH。
這個輸出與第 3 個交易的輸入衝突。所以現在 3 被重新執行，輸入為 0.8 個ETH。在執行了 3 之後，Joel 的餘額為 0.7 個ETH。
在這一點上，一個明顯的問題是我們如何知道我們不必重新執行大部分交易。答案在於重新執行並不是瓶頸。瓶頸是存取以太坊的記憶體。事實證明，以太坊在資料庫中儲存狀態的方式使得存取狀態變得困難（耗時且因此昂貴）。這就是 Monad 的另一個改進：MonadDb。 Monad 建構資料庫的方式減少了與讀取操作相關的開銷。
當交易必須重新執行時，所有輸入已經在快取記憶體中，與整體狀態相比，這更容易存取。
Solana 在其測試網上有 50k TPS，但現在在主網上只有大約1k TPS。 Monad 聲稱在其內部測試網上已實現了 10k 實際 TPS。儘管這並不總是代表實際性能，但我們迫不及待地想看看 Monad 在實際應用中的表現。
以上是Monad入門指南：快速理解並行EVM與效能提升的詳細內容。更多資訊請關注PHP中文網其他相關文章！
