Dapp Rollup技術解讀：如何讓高輸送量APP走向主流？

撰寫：Mohamed Fouda 編譯：深潮 TechFlow

! Dapp Rollup技術解讀：如何讓高輸送量APP走向主流？

應用程式 Rollup 正在成為擴展一組特定乙太坊應用程式的明顯贏家。 這些應用程式受益於無需許可和強大的擁有權保證，但不需要所有應用程式用戶之間同時交互。 完全鏈上的遊戲是最好的例子。 鏈上遊戲受益於遊戲資產強有力的擁有權，允許匿名參與遊戲和允許匿名修改遊戲。 儘管如此，大多數遊戲不需要所有玩家同時互動。 其他可以受益於應用程式 Rollup 擴展策略的應用包括 NFT 市場，永續交換和鏈上 AI 推理。

! Dapp Rollup技術解讀：如何讓高輸送量APP走向主流？

應用程式 Rollup 已經是許多這些使用方式的首選實現。 但是，標準的 Rollup 實現，即 EVMRollup，仍然有重要的可擴充性限制。 它們可能達到每秒大約 100 筆交易的輸送量。 對於某些鏈上遊戲來說，這種輸送量可能足夠，這取決於遊戲類型。 但是，大多數遊戲需要更高的輸送量來支援大量的併發玩家（超過1000）。 本文重點介紹應用程式 Rollup 擴展以覆蓋數十萬併發參與者的方法。 對於每種方法，我都會討論合適的應用程式/遊戲類型及其面臨的挑戰。

水平擴展

水平可擴充性是擴充應用程式 Rollup 的最簡單方法。 但是，這種簡單性以犧牲組合性為代價，這使它們只適合於一小部分應用，例如單人遊戲。

水平可擴充性的意思就是簡單地部署多個應用程式 Rollup（Optimistic 或 ZK），並在所有 Rollup 上部署相同的智慧合約。 應用程式的前端會根據容量、位置或特定的應用程式選項，無縫地將用戶引導到其中一個 Rollup。 Alt Layer 最近通過啟動一個可擴展的 2048 FOCG 遊戲來演示了這個概念。 在遊戲的前端，用戶可以根據他們的地理位置選擇加入哪個 Rollup。 由於其簡單性和 Caldera 等 Rollup 即服務提供者的可用性，這些供應商處理與旋轉和管理這些 Rollup 相關的所有基礎設施工作，這種方法可以被遊戲開發者輕鬆採用。

! Dapp Rollup技術解讀：如何讓高輸送量APP走向主流？

儘管如此，多 Rollup 擴充方法存在一些問題。 第一個問題是 Rollup 網路切換。 當前錢包，例如 Metamask，需要手動批准連接到一個新的網路，即 Rollup 實例。 這會給玩家帶來困難和混亂的用戶體驗，因為玩家需要手動連接到多個「網路」來玩同一個遊戲。 幸運的是，可以用帳戶抽象（AA）解決方案來抹去這種複雜性。 例如 EIP 4337 和嵌入式錢包，如 Privy 和 0xPass。

另一個挑戰是在 Rollup 之間過渡期間管理玩家的狀態。 在某些情況下，例如容量下降，應用程式可能需要將多個 Rollup 實例合併到單個實例中，以節省資源。 在這種情況下，所有活動玩家的狀態都需要遷移到新的實例。 當前的橋接解決方案，特別是 zk 橋，可以在解決此問題方面發揮關鍵作用。 使用這些解決方案，可以將玩家的遊戲狀態橋接到一個新的 Rollup 實例，同時保持對該狀態有效性的證明。 但是，現有橋接解決方案的延遲對遊戲用例來說可能不是最佳的。

ZK 狀態通道

另一種更適合多人遊戲（例如撲克）的應用程式 Rollup 擴展方法是 ZK 狀態通道。 在這些遊戲中，玩家交互發生在少量玩家之間，例如 2-10 人。 這些玩家之間的遊戲玩法只在遊戲進行時很重要。 然而，遊戲的最終結果更重要，因為它會影響每個玩家的資產餘額。 因此，將結果存儲在共用的持久層中很重要。

在這種情況下，應用程式 Rollup 表示共用資訊層，遊戲結果存儲在這裡，遊戲資產也存在這裡。 對於 Rollup 上的每個遊戲，可以啟動一個 ZK 狀態通道來服務這個遊戲。 在遊戲玩法期間，每個玩家生成交易並創建 ZKP，證明他們遵循了遊戲規則。 其他玩家交互的證明使用遞歸證明聚合上一個證明。 當遊戲結束時，最終 ZKP 被提交到應用程式 Rollup，以證明遊戲玩法和最終結果的有效性。 遊戲產生的狀態變化改變了應用程式 Rollup 上的玩家狀態。

! Dapp Rollup技術解讀：如何讓高輸送量APP走向主流？

ZK 狀態通道將遊戲交互轉移到鏈下。 因此，遊戲中的活動和交易不計入應用程式 Rollup 的輸送量。 使用這種方法，應用程式 Rollup 可以大規模擴展，支援成千上萬的併發玩家。 應用程式 Rollup 的交易將只是驗證生成的 ZKP 和狀態更新交易，擴展因數為 100-1000 倍。 包括 Ontropy 在內的多個團隊一直在開發這項技術。

這種方法的一個缺點是，它要求玩家在自己的設備上運行遊戲邏輯並生成 ZKP。 通常這些證明很輕量，並藉助Halo2等前沿證明系統，證明可以在短短幾秒內完成。 然而，這仍可能導致資源有限的設備的玩家體驗下降。

緩解此問題的方法修改之一是將 zk 狀態通道參與者之一指定為臨時排序器。 該排序器將接收每個玩家的交易並生成相應的 ZKP，並與所有通道參與者共用 ZKP。 這個修改可以被認為是向應用程式 Rollup 進行結算的短暫 ZK L3。 Cartridge 團隊通過設計名為 Katana 的專用排序器來實現這種架構。

zk 狀態通道方法具有巨大的潛力。 然而，與 zk 狀態通道內的執行環境以及如何優化遞歸證明有關的幾個開放性問題。 當前的 zkEVM 環境效率不高，而且大多數目前不支持證明遞歸。 替代方案包括輕量級的 zkVM，或者如果玩家的可能動作數量有限，甚至使用專門的 zk 電路來處理玩家交互。

改變執行環境

擴展應用程式 Rollup 的第三種方法是改變 Rollup 的執行環境。 儘管 EVM 開發工具的成熟和豐富，但它們不適合高性能應用，如遊戲。 此外，EVM 的單線程執行和存儲模型會導致輸送量降低，這可以通過改進來提高。

這種方法的主要優勢在於，提高 Rollup 輸送量不需要犧牲組合性或限制用例數量。 只要執行環境可以達到應用程式所需的輸送量，這種方法就可以用於任何 Web 3 應用程式。 這使它們成為需要訪問共享狀態的應用程式的唯一可行解決方案，例如AMM、借貸協定和其他DeFi應用程式。

通過預編譯擴展 EVM 功能

首先，Rollup 保持 EVM 相容，並通過預編譯位址輸送量的一些限制。 這裡的想法很簡單。 預編譯就是將計算密集型的EVM操作下移到節點級別。 一個需要數百或數千個 EVM 操作碼並消耗 10 萬+Gas 的操作可以簡化為一個操作，Gas 成本降低 100 倍。 擴展 Rollup 環境的預編譯通常稱為 EVM+。 這種方法的範例包括支援鏈上隱私和支援更高效的簽名方案，例如BLS簽名。 例如，zkHoldem 撲克遊戲使用專用的 FHE 和 zk 操作實現私人撲克牌發牌和展示。 這些專用預編譯的開發通常是應用程式 Rollup 開發者和管理應用程式 Rollup 基礎設施部署和維護的 Raas 供應商之間的共同努力。

使用非 EVM 執行環境

改進 Rollup 執行環境的另一種方法是擺脫 EVM。 這種方法在乙太坊生態系統中的新開發者以及認為 Solidity 不是開發複雜應用程式的最佳語言的開發者中越來越受歡迎。

今天，我們有在 WASM、SVM、Cairo 甚至 Linux 運行時上運行的 Rollup 應用程式。 這些方法中的大多數允許開發者使用高級語言（如 Rust 或 C）編寫智能合約。 缺點是經常會丟失與現有 Solidity 合約的互操作性。 但是，仍然可以創建與 EVM 的相容性。 例如，Aributrum 的 stylus 採用協處理器使 Stylus 合約相容 EVM。 這種設計使 Stylus 更接近於 EVM+體系結構而不是非 EVM。

! Dapp Rollup技術解讀：如何讓高輸送量APP走向主流？

混合執行環境

第三種方法，特別受到FOG歡迎，是結合前兩種方法的最佳特性。 這種方法將 EVM 相容性與專用非 EVM 執行環境相結合。 非 EVM 環境專注於核心遊戲原語的高性能執行。 遊戲資產管理，例如遊戲內 NFT 交易可以由標準 Solidity 合約處理。

這種方法的優勢在於 EVM 相容性確保與更大的開發者生態系統和現有產品保持一致。 它還允許無需許可的可組合性。 開發者可以通過添加 EVM/Solidity 智慧合約來修改和擴展遊戲邏輯。 與此同時，專用非EVM遊戲引擎實現了EVM無法滿足的高輸送量。

這種方法的例子是 Argus 的 World Engine 和 Curio 的 Keystone。 World Engine 將遊戲邏輯的執行分離到一個單獨的層，稱為 Game Shard，它在 EVM 相容層之上運行。 Game Shard 還設計為允許水平擴展，以根據需求調整總 Rollup 輸送量。 類似地，Curio 的 Keystone 架構將高輸送量遊戲引擎與 EVM 捆綁在一起作為 Rollup 執行環境。 這裡的挑戰是實現EVM引擎和遊戲引擎之間的無縫互操作性。

! Dapp Rollup技術解讀：如何讓高輸送量APP走向主流？

數據可用性考慮因素

在前面的討論中，重點是增加 Rollup 交易輸送量，這是擴展應用程式 Rollup 的主要方面。 與這種增加的輸送量相關的其他話題包括數據可用性（DA）、排序器去中心化和結算速度。 對於高輸送量的應用程式 Rollup，數據可用性是這些問題中最緊迫的。

單個應用程式 Rollup 的輸送量可能超過每秒 1 萬筆交易。 使用乙太坊作為這些交易的數據可用層是不可能的。 首先，在 L1 上發布簡單 L2 ETH 轉帳數據的平均成本可以超過 0.1 美元。 這些成本對大多數應用程式 Rollup 來說太高了。 更重要的是，乙太坊的 L1 當前不能支援超過大約每秒 8 千筆交易用於利用 L1 進行數據可用性的 Rollup。

應用程式 Rollup 將主要依賴於外部 DA 解決方案。 Celestia 和 EigenDA 目前被定位為應用程式 Rollup 的最可行選擇。 例如，Eclipse 計劃使用 Celestia 作為其高輸送量 SVM 基礎 Rollup 的數據可用層。 Argus 和高輸送量遊戲引擎也計劃最初使用 Celestia。 類似地，EigenDA 承諾的數據輸送量高達每秒 10MB，也可以為多個應用程式 Rollup 提供可行的解決方案。

然而，集成 Celestia 或 EigneDA 的主要缺點是經濟價值洩漏。 應用程式 Rollup 必須為 DA 層支付費用，以及乙太坊 L1 上的結算費用。 結算費對應用程式 Rollup 很關鍵，因為它將 Rollup 的安全性與乙太坊的安全性聯繫在一起。 DA 保證在FOG背景下交易價值遠小於這些網路的情況下不太重要。 此外，Celestia 和 EigenDA 承諾低費用，因為這些網路剛剛啟動，最初利用率會很低。 當這些 DA 網路實現高利用率時，DA 費用也可能變得過高。 在我看來，應用程式 Rollup 應該使用一個簡單的數據可用性委員會（DAC）來證明 Rollup 數據的可用性。

總之，我認為應用程式 Rollup 是擴展高輸送量應用程式（尤其是完全鏈上遊戲）的最佳現有解決方案。 擴展這些應用程式 Rollup 是實現超越原生加密使用者的主流採用的關鍵。