應用程序 Rollup 技術詳解：高吞吐量 APP 走向主流採用的關鍵

撰寫：Mohamed Fouda

原文標題：《How to Scale App-Rollups》

編譯：深潮 TechFlow

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

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

水平擴展

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

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

儘管如此，多 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 上的玩家狀態。

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。

混合執行環境

第三種方法，特別受到 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 引擎和遊戲引擎之間的無縫互操作性。

數據可用性考慮因素

在前面的討論中，重點是增加 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 是實現超越原生加密用戶的主流採用的關鍵。