Devs on Devs: tdot 和 Ben Jones 對談

在這期特別的 Devs on Devs 節目中，我們邀請到了 Plasma Mode 的核心協議開發者 tdot(同時也是 Redstone 的開發者)和 Optimism 的聯合創始人 Ben Jones。Optimism 是 OP Stack 的核心推動者。Plasma Mode 允許開發者在 OP Stack 上構建，但無需將數據發布到 L1，而是可以靈活地切換到鏈下數據提供者，從而節省成本並提高可擴展性。在對話中，他們討論了 Redstone 和 Optimism 合作的起源、復興 Plasma 的重要性、將實驗性協議引入生產環境的必要性、Plasma Mode 和 OP Stack 的未來路線圖，以及他們對全鏈遊戲領域發展的興奮之情。

如何使用 Plasma 模式改進 OP Stack

Ben: 開始改進 OP Stack 的過程是什麼樣的？

tdot: 我大約一年前加入 Lattice，專門負責 Plasma Mode。目標很明確:我們有很多 MUD 應用程序消耗大量 gas，同時我們試圖將大量數據放到鏈上，所以需要一種既支持這些需求又便宜的解決方案。Lattice 團隊已經在 OP Stack 上做了一些試驗，比如原型化一些鏈上世界並部署在 OP Stack 上。我們發現 OP Stack 已經非常好用了。

於是我們問自己，"怎麼才能讓它更便宜？" 基本假設是，"我們認爲 OP Stack 是最符合以太坊理念且完全兼容 EVM 的框架。" 在主網上運行的東西可以同樣在 OP Stack 上運行，這是理想的解決方案。但我們希望它更便宜。

當時，calldata 仍然是 OP Stack 鏈的數據可用性(DA)來源，這非常昂貴。所以我們顯然無法用 calldata 來啓動一個 L2，因爲我們的全鏈遊戲和 MUD 世界需要更高的吞吐量。因此，我們決定開始嘗試其他數據可用性(Alt DA)方案。實際上，在最初的 OP Stack 文檔中已經提到要探索 Alt DA。

於是我們問自己，"如果從鏈下 DA 開始會怎麼樣？" 我們希望整個安全模型和所有內容都能依賴 L1 以太坊。因此我們避開了其他 Alt DA 解決方案，決定將數據存儲在中心化 DA 存儲中，然後在 L1 上找到一個有效的安全模型。

這就是我們爲何要重新使用一些舊的 Plasma 概念並將其放在 rollup 之上。這裏有一些不同。最大的疑問是，如何在現有的 OP Stack 上實現鏈下 DA 和鏈上數據挑戰？我們的目標是盡量少改動 OP Stack，對 rollup 路徑沒有任何影響，因爲我們不想影響使用 OP Stack 的其他 rollup 鏈的安全性。

在設計 rollup 時，你不會想着，"如果有人改變了數據生成流程以從其他地方存儲數據會發生什麼？" 即使有這些改動，OP Stack 仍然非常強大，開箱即用效果很好。這是我們所做的第一個改動。

之後，我們需要編寫合約來創建這些挑戰。有用於強制將數據上鏈的 DA 挑戰。這是第二步，將合約集成到流程中。我們必須在派生過程中構建整個集成系統，這樣你就可以從一個鏈外的 DA 來源以及一個 L1 DA 挑戰合約中派生數據，以防數據在挑戰解決過程中提交到鏈上。

這就是事情的要點。很復雜，因爲我們希望保持事情的優雅和穩健。同時，這是一個相對簡單的概念。我們沒有嘗試重新發明一切或改變整個 OP Stack，而是嘗試在一個復雜的環境中保持事情的簡單。所以總體來說，這是一段非常酷的工程旅程。

Ben: 我可以從 OP 的角度來談談。你提到了一些 Lattice 早期的工作。恰好在同一時間，我們 Optimism 幾乎對整個 OP Stack 進行了端到端的重寫，這次發布我們稱之爲 Bedrock。

基本上，在構建 rollup 兩年之後，我們退後一步，反思說："好吧，如果我們要把學到的所有經驗都用到極致，這會是什麼樣子？" 這演變成了最終被稱爲 Bedrock 的代碼庫，這是我們對網路進行的最大升級。

在那個時候，我們與你們合作了一個叫 OPCraft 的項目，我認爲 Biomes 是它的精神繼承者，這是我們在鏈上玩得最開心的一次。同時，我們也松了一口氣，因爲其他人也可以使用 OP Stack 進行開發。我認爲在過去幾年裏，擴容的另一個重要轉折點是很多人可以運行鏈。

並不是只有那些開發了龐大復雜代碼庫的人才能做到這一點。當我們開始合作時，看到別人能夠接手這個代碼庫並做出一些非常了不起的事情，這是一種極大的肯定。然後看到這種情況在實際應用中擴展到 Plasma 上，真是太酷了。我甚至可以稍微談談那段歷史。

在 Optimism 成爲 Optimism 之前，我們實際上在研究一個叫 Plasma 的技術。當時我們承擔的任務遠超當時擴容社區的能力。你在早期的 Plasma 設計中看到的設計，可能與今天的 Plasma 並沒有直接的對應關係。

今天的 Plasma 要簡單得多。我們將狀態驗證的證明和挑戰與數據的挑戰分開來看。最終，我們幾年前認識到 Rollups 比 Plasma 要簡單得多。我認爲，當時社區的結論是"Plasma 已死"。這是那個時期以太坊擴容史上的一個梗。

但我們一直認爲"Plasma 並沒有死，只是我們可以先嘗試一個更簡單的任務"。現在我們使用不同的術語。比如，當時有退出(exits)等概念，現在你可以回過頭來看，說"哦，那是一個帶有一些額外步驟的數據可用性挑戰"。所以看到不僅 OP Stack 被其他人使用，還被演化成我們最初嘗試但以非常混亂和不成熟的抽象方式做的事情，真是令人驚嘆。我們已經完成了一個完整的循環，你們圍繞它們做了非常棒的抽象，並使其以一種合理和理智的方式工作。這真的很酷。

最重要的是盡快進入生產環境

tdot: Plasma 模式仍然存在一些挑戰和未解決的問題，我們還在努力解決。關鍵是如何避免耗費長達十年的時間？你懂我的意思吧？我們需要盡快達到可以交付成果的階段。

這就是我們的想法。我們已經有很多基於 MUD 開發的應用想要立即上線主網。我們需要盡快爲這些遊戲準備一個主網。人們已經在等待，並且準備好了。你需要一個快速上線並能運行的鏈，來運行所有這些應用程序，這樣這些應用可以在我們解決問題的同時並行發展，變得更好。從研發到實現生產穩定性需要很長時間。

要將某個東西上線主網，使其無許可、穩健和安全，需要耗費大量時間。看到我們實現這一目標的整個過程已經很令人驚嘆了。這就是爲什麼我們需要保持高度的敏捷，因爲事情太多了。整個生態系統發展得非常快。我認爲每個人都在交付大量的創新。這就是爲什麼你必須跟上，但你也不能在安全性和性能上妥協，否則系統就無法運行。

Ben： 或者說是技術負擔。你提到的最小改動原則，這是我們進行 Bedrock 重寫時的核心理念之一。我談到了整個端到端的重寫，但更重要的是，我們減少了大約 50,000 行代碼，這本身就非常有力。因爲你說得對，這些事情確實很難。

每增加一行代碼都會讓你離生產環境更遠，使得事情更難以經過實戰測試，並引入更多的錯誤機會。所以，我們非常感謝你們在推動這一過程中的所有努力，尤其是爲 OP Stack 的新操作模式做出的貢獻。

tdot： OP Stack 確實創造了一種方式，使你可以在這類事情上快速推進。協調大家非常困難，因爲我們顯然是兩家不同的公司。在 Lattice，我們正在構建一個遊戲，一個遊戲引擎，以及一條鏈。

而你們正在構建成百上千的東西，並且定期交付所有這些產品。從協調方面來看，這確實非常不易。

Ben: 是的，確實還有很長的路要走。但這正是模塊化的核心魅力所在。對我來說，從 OP Stack 的角度來看，這是最令人興奮的事情之一，暫且不提現在在 Redstone 上構建的那些令人驚嘆的遊戲和虛擬世界。純粹從 OP Stack 的角度來看，這是一個非常有力的例子，證明了很多優秀的核心開發者已經加入進來並對這個棧進行了改進，這非常了不起。

這是第一次，你可以通過一個關鍵的布爾值顯著改變系統的屬性。能夠徹底做到這一點，正如你所說，確實還有很長的路要走。但即使是接近有效地做到這一點，也需要模塊化的支持，對吧？對我們來說，看到你們實現了這一點，而不需要例如重寫 L2 Geth，真是讓人松了一口氣。對我來說，這證明了模塊化正在發揮作用。

tdot: 現在情況變得更好了。從這個例子來看，你們把所有東西都變成了獨立的小模塊，可以進行調整和改變屬性。所以我非常期待看到還有哪些新功能會被集成進來。我記得我們曾經擔心的是，我們有一個分叉，包含所有對 OP Stack 的改動，需要將其合並到主幹中。我們當時想，"天啊，要審查所有內容會很瘋狂。"

我們不得不將其分解成更小的部分，但整個過程進行得非常順利。我們和團隊的合作氛圍非常好，所以審查過程也很愉快。這感覺非常自然。而且我認爲在審查和解決一些潛在問題方面，這個過程進行得非常快。一切都出乎意料地順利。

Ben: 這真是太好了。今年我們的一個重點是爲 OP Stack 創建貢獻路徑。所以我非常感謝你們參與測試，推動這些流程。我很高興這些流程並沒有讓人難以承受，並且我們取得了一些成果。說到這，我很好奇，從你的角度來看，接下來這項工作會如何發展？你接下來最期待開發的是什麼？

tdot: 有很多不同的工作方向。主要是與故障證明機制的集成。我們採用一種漸進的方法來去中心化整個技術棧，並增加其無許可特性，最終目標是實現無許可和強制退出等功能。

我們有這個終極目標，並在保持安全性的同時逐步實現。一個挑戰是，有時候不上主網會更容易，因爲這樣就不需要進行硬分叉。你可能會想，"哦，我只要等到一切都完全準備好再發布，這樣就不需要進行硬分叉，也沒有技術負擔。"但是，如果你想快速上線主網，就必須處理這些復雜的升級，並且頻繁發布。做到這一點並保持高可用性總是一個挑戰。

我認爲在故障證明機制和所有這些部分都準備好之後，Plasma 模式方面會有很多升級。我認爲在批量提交 commitment 方面仍有一些優化空間。現在我們做得很簡單，每筆交易一個 commitment。而 commitment 只是鏈下存儲的輸入數據的哈希值。

我們暫時保持盡可能的簡單，這樣審查起來便可以簡單且快速，並且對 OP Stack 沒有大的差異。但是現在有一些優化可以使其更便宜，比如將 commitment 進行批處理或者將它們提交到 blob 中，或者採用其他