Monad Labs 首席執行官兼聯合創始人 Keone Hon 和開發者關係工程師 Kevin G 參加了 The Pipeline 播客的第三期節目，討論 Monad Labs 團隊過去兩年的工作內容。

嘉賓介紹：

Keone 是 Monad Labs 首席執行官兼聯合創始人，此前在 Jump Trading 擔任量化分析師，專注於高頻交易（HFT）領域；

James Hunsaker 是 Monad 聯合創始人兼首席技術官；

Kevin G 是 Solana Labs 核心開發人員，此前在蘋果公司工作，專注於 Airpods 的本地系統工程設計。

為什麼選擇 Monad？在 L2 和其他擴展解決方案如此流行的環境下，您為什麼要改造 EVM？

Keone：

幾年前我們剛開始時，很多人問我們：「為什麼不建立一個 L2？」我們當時的答案和現在是一樣的：我們認為有人需要專注於提高 EVM 執行堆棧的性能。通過引入優化，如並行執行、自定義狀態數據庫、流水線執行和對異步 IO 的支持，Monad 能夠更好地利用硬體，實現更高效、更去中心化的系統。

隨著時間的推移，越來越明顯的是，以太坊虛擬機中的許多瓶頸可以通過合適的工程師團隊來解決和優化。回到 2020 年，當 Monad 首次概念化時，並沒有太多團隊專注於這些優化，尤其是與投入到其他基礎設施（如 rollup、零知識證明或數據可用性）的努力相比。

作為智能合約的主導標準，EVM 鏈擁有最多的 TVL、最大的開發者和研究網路，以及一個經受住時間考驗（和多個熊市）的令人難以置信的社區。當我們希望擴大採用並支持更複雜的應用程序時，這使得優化變得更加重要。

「使 EVM 性能大幅提升確實是一個有趣且具有挑戰性的問題。我很高興我們的團隊在當時就開始着手這個項目。這讓我非常興奮，期待在未來幾個月向全世界展示。」

Kevin G：

Monad 正在做的很多事情都是將計算機科學的最佳實踐應用於區塊鏈網路。這是可能實現的，因為團隊在這個領域擁有如此深厚的背景。

並非每個開發團隊都能夠解決協議的根本問題並提出高性能的解決方案。這些優化不僅令人興奮，它們在也充滿雄心。

你是如何挑選出能夠應對這一挑戰的團隊的？

Keone：

我只是覺得非常幸運，能夠在 Monad Labs 這裡擁有一群了不起的工程、增長、市場、社區建設和商業開發方面的人才。我們大約有 25 人，試圖保持超級精簡的團隊，以便能夠專注於需要解決的問題。

隨著時間的推移，我們的團隊將會不斷壯大，以支持我們試圖達到的規模和採用率。這肯定需要更廣泛的技能和額外的人力。

大多數工程團隊在構建高性能、低延遲系統方面擁有豐富的經驗。開發真正高性能的基礎層系統的一個常見模式是，你需要對整個系統的性能有所了解。有時候你需要深入到內核級別，以獲得你需要的優化。最終，區塊鏈實際上本身就是一個數據庫。

為什麼建設者要來看看 Monad？

Keone：

一個關鍵優勢在於 Monad 的潛力，它可能能夠促進廣泛的可組合性，超越以太坊現有的限制，甚至比 Solana 等更高性能的系統還要好。

因為 Monad 與 EVM 字節碼和 RPC 兼容，工程師的學習曲線比在許多其他環境中要低得多。我們很高興能夠利用大量的研究和工具，這些研究和工具為 EVM 的蓬勃發展鋪平了道路，並讓開發人員能夠在他們已經了解和信任的環境中構建性能更高、可擴展的應用程序。

Monad 在更廣泛的 Layer 1 解決方案領域的戰略定位是什麼？

Keone：

最終目標是創建一個更可擴展、成本更有效的平台，用於構建多樣化的應用程序，消除現有區塊鏈生態系統中阻礙可組合性的限制。

在以太坊最初設計的背景下：目的是使構建者能夠在其生態系統內創建任何東西。Monad 是這一概念的加速發展，擺脫了十多年來一直存在的限制。我們可以用燃油汽車過渡到電動汽車的轉變作為類比，標誌着當引入新技術時所能實現的事物的範式轉變。

考慮到以太坊開發者面臨的實際挑戰，如 Gas 限制。如果沒有這些限制，以太坊上會有更多的應用程序和功能，但是因為費用過高而被禁用。Monad 的主要目標之一是將現有的 EVM 應用程序從當前的 Gas 限制中解放出來。

Monad 還利用了 EVM 生態系統中豐富的現有代碼和產品，為雄心勃勃的建設者提供了一個平台，讓他們真正能夠構建在其他地方不可能的 dApp。

總的來說，Monad 的重點是加密社區的集體性質。當前階段是一個實驗期，在這個期間，加密愛好者正在為去中心化個人金融構建應用程序。Monad 旨在使這些應用程序更具成本效益，解鎖它們真正的潛力，擴展到更廣泛的用戶群。

你最希望在 Monad 上看到哪種類型的應用程序？

Keone：

對我來說，我最希望看到兩個領域——去中心化金融（DeFi）和面向消費者的應用程序。

DeFi

任何能夠讓普通人以去中心化的方式管理個人財務的應用程序。當然，像貨幣市場、去中心化交易所、衍生品、高精度和高規模的預言機等應用程序。這是一個我非常興奮的垂直領域。

在 Monad 之前，我是 Jump 加密團隊的一員。Jump 對 Solana 生態系統深感興趣並興奮不已，因為這是有道理的。如果費用只有一美分的幾分之一，並且您可以擴展到數百萬用戶，那麼你實際上基本上可以取代現有的主導者所做的事情。中心化交易所對數據收取非常高的費用。

我們喜歡 Solana 的原因之一是它是一項非常棒的技術。儘管它缺乏 EVM 兼容性，這可能使得開發體驗有些棘手，但自 2021 年 James 和我致力於開發它以來，Solana 已經取得了長足的進步。

消費者應用程序

我也對 Monad 上的面向消費者的應用程序感到非常興奮。例如，體育博彩、賭場、社交，基本上任何在手機上作為行動應用程序有意義的事情都可以。

如果我知道我所有的數據都在我的錢包里，我會更願意與應用程序、服務和內容互動；這是因為錢包是加密安全的。

EVM 的哪些方面讓您對 Monad 路線最感興趣？

Keone：

對我來說，關鍵在於構建能夠最終幫助最多開發者擴展他們應用程序的東西。歸根結底，Monad 是一個開發者平台。前往開發人員所在的地方並解決他們真正緊迫的問題非常重要。我認為純粹的 EVM 兼容性是解決這些問題的一部分，但未來還會出現其他問題，本質上使對更多加密功能的支持變得更容易、更便宜。

歸根到底，這只是為了解決阻礙開發者構建在 iOS 商店中排名第一的應用程序的問題。對於我來說，我覺得 EVM 是實現這一目標的最佳場所。

令人驚訝的是，真的沒有人專注於執行棧。鑒於我們團隊以前的背景，以及我們認為解決這個問題的迫切性，這是一個非常自然的工作領域。

Monad 為 EVM 和以太坊社區的理想提供了一條真正實現產品規模的道路。

「歸根結底，Monad 是一個非常酷的組合，我們可以在 EVM 上擁有類似 Solana 的用戶體驗。然後，開發人員就可以根據系統的需求來選擇他們想要構建的位置。」

合作確實很重要。我們的團隊意識到我們並不知道所有問題的答案。我們是專家。我們對構建高性能並行系統、拜占庭容錯共識和其他非常具體的問題了解很多。但還有很多人在以太坊的研究方面投入了精力，重點關注 MEV 最小化、治理和密碼學等問題。所以我認為遵循標準，我們所做的工作與他人的工作可組合的地方也很重要。

Kevin G：

EVM 是如此多應用密碼學研究、構建應用程序、發展更好的安全實踐的中心。能夠處於標準的位置並幫助推動整個領域向前發展是非常好的。

因為這樣，我們可以深入專注於擴展基礎層（這是我們擅長的）同時利用研究社區在該領域的專業知識。此外，我們不必重新構建已經為 EVM 開發的所有開發者工具。

在 EVM 環境中做 Builder，最大挑戰是什麼？

Keone：

我認為有幾個。對構建者來說，吸引資金現在相當具有挑戰性；投資者社區非常偏向美國。對國際構建者來說，獲得資金真的很難。

此外，從安全角度來看，構建 dApp 是具有挑戰性的。有大量黑帽駭客不斷探尋漏洞，尋找攻擊的機會。這使得環境非常具有對抗性。我們需要更好的安全實踐，包括 Gas 優化。

通過大幅降低 Gas 成本，Monad 消除了開發者面臨的一個巨大抉擇；是否包含額外的防禦性斷言（這會消耗更多 Gas）。

構建加密產品，被忽視的優勢是什麼？

Keone：

加密社區的強大令人驚嘆。如果你正在建立一個傳統的科技創業公司，假設你的 Twitter 沒有關注者，你可以發布更新，但沒人會關心。沒有人急於去嘗試你的產品。你必須費盡周折，才能讓人們免費試用它。

在加密領域，我們有如此強大的社區（社區實際上是核心的一部分），這實際上是對其他科技領域的巨大優勢，也是加密最終會成功的一個原因。這實際上只是利用優勢並儘量減少劣勢，然後我們就可以作為一個行業進行擴展。

作為一個行業，區塊鏈剛剛開始成熟。隨著時間的推移，區塊鏈將變得更加高性能（到那時，我不希望 Monad 僅因其性能而與其他區塊鏈不同）。

其他系統將做出額外的改進，將會有理念或技術的交叉傳播。這最終將推動空間向前發展，使更高性能的應用程序得以構建。我們將繼續推動區塊鏈可能性的極限，並引入其他基礎設施支持新的實現。

加密 Twitter 上有很多關於 TPS 作為一般交易和投票交易指標的討論。TPS 什麼時候是一個有價值的指標？

Keone：

關於 TPS 的一般測量，我們認為它應該僅計算真實交易，即發生在鏈上的智能合約互動和轉賬：而不僅僅是投票交易。對於 Monad 來說，我們不會在任何 TPS 展示中包括投票。

一般來說，關於什麼應該算作真正的交易存在很多混淆。許多團隊使用不同的指標來計數交易。現在這個領域在如何宣傳性能方面非常不統一。例如，有些人將一次交易計為一條指令。所以如果有一個單一的智能合約調用執行了幾個子指令，其他人會將其計為約 10 筆交易，這實際上是不正確的。

你真正能夠衡量的只是通過系統的交易數量。如果在任何給定時刻，系統沒有達到滿負荷，那麼實際可觀察的 TPS 會低得多。所以在這裡也存在很多混淆。

我認為真正的解決方案是在 GitHub 倉庫中有可重複的基準測試。每個團隊都應該為這個倉庫做出貢獻，並推出一個完整的腳本，定義了在世界各地部署許多不同服務器的過程。然後，腳本能夠向系統中的各個節點發送大量交易，並實際重現完整的交易吞吐量測試。

這是我們團隊計劃引入的東西，至少對於 Monad 來說是這樣，但希望也適用於其他競爭性基準測試。這類似於正常的科學研究過程，你不僅要發布你的結果，還要發布你用來生成這些結果的過程。這樣，第三方可以重新實驗並重現這些基準。這對我們來說非常重要，也是我們打算做的事情。

原文連結