Dapp Rollup技術解讀:如何讓高吞吐量APP走向主流?

撰寫:Mohamed Fouda 編譯:深潮TechFlow

應用程式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 是實現超越原生加密用戶的主流採用的關鍵。

Total
0
Shares
Related Posts