撰文：Decentralised.Co
編譯：深潮TechFlow
交易擴展性一直是熱門話題。在過去幾週中，我們一直在探索 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。
MonadDb
在這一點上，一個明顯的問題是我們如何知道我們不必重新執行大部分交易。答案在於重新執行並不是瓶頸。瓶頸是訪問以太坊的內存。事實證明，以太坊在數據庫中存儲狀態的方式使得訪問狀態變得困難（耗時和因此昂貴）。這就是 Monad 的另一項改進：MonadDb。Monad 構建數據庫的方式減少了與讀取操作相關的開銷。
當交易必須重新執行時，所有輸入已經在緩存存儲器中，與整體狀態相比，這更加容易訪問。
Solana 在其測試網上有 50k TPS，但現在在主網上只有大約1k TPS。Monad 聲稱在其內部測試網上已實現了 10k 實際 TPS。儘管這並不總是代表實際性能，但我們迫不及待地想看看 Monad 在實際應用中的表現。
