如何擴展應用程序彙總（rollup）
應用程序rollup正在成爲擴展一組特定以太坊應用程序的明顯贏家。這些應用程序受益於無需許可和強大的所有權保證，但不需要所有應用程序用戶之間衕時交互。完全鏈上游戲（FOG）是符合此描述的最佳示例。 FOG 受益於強大的游戲內資産所有權、無需許可的游戲參與和無需許可的游戲模組。盡管如此，大多數游戲併不要求所有玩家衕時互動。其他可以從應用程序rollup擴展策略中受益的應用程序包括 NFT 市場、永久交易所和鏈上人工智能推理。
應用程序rollup已經成爲許多此類用例的首選實現。然而，標準rollup實現（即 EVM rollup）仍然具有重要的可擴展性限製。他們可能可以實現每秒 100 個交易左右的吞吐量。對於某些鏈上游戲來説，這樣的吞吐量已經足夠了，具體取決於游戲類型。然而，大多數游戲需要更高的吞吐量來支持大量（> 1000）的併髮玩家。本文重點介紹擴展應用程序rollup以覆蓋數十萬併髮參與者的方法。對於每種方法，我都會討論合適的應用程序/游戲類型及其麵臨的挑戰。
鼓勵正在使用應用rollup的開髮者或正在構建基礎設施以擴展應用rollup的開髮者聯繫我併申請聯盟。我期待與創始人在這些領域合作。
水平擴容
水平擴容是擴展應用程序rollup的最簡單方法。然而，這種簡單性是以失去可組合性爲代價的，這使得它們隻適合一小部分應用程序，例如單人游戲。
水平擴容意味著隻需部署多個應用程序rollup（OP 或 ZK），併將相衕的智能合約部署到所有rollup。應用程序的前端根據容量、位置或特定應用程序選項無縫地將用戶引導至其中一個rollup。 Alt Layer 最近通過推出可擴展的 2048 FOCG 展示了這一概念。在游戲的前端，用戶可以根據自己的地理位置選擇要加入的rollup。由於 Rollup 即服務提供商（例如 Caldera 負責處理與旋轉和管理這些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 OP 併消耗 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+ 架構。
混合執行環境
在全鏈游戲（FOGs）中特別流行的第三種方法是結合前兩種方法的最佳功能。這種方法將 EVM 兼容性與專用的非 EVM 執行環境結合起來。非 EVM 環境專註於核心游戲原語的高性能執行。游戲內資産管理，例如游戲內 NFT 的交易可以通過標準 Solidity 合約來處理。
這種方法的優點是 EVM 兼容性可確保與更大的開髮者生態繫統和現有産品保持一緻。它還允許無需許可的可組合性。開髮者可以通過添加 EVM/solidity 智能合約來修改和擴展游戲邏輯。衕時，專門的非EVM游戲引擎實現了EVM無法滿足的高吞吐量。
這種方法的示例包括來自 Argus 的 World Engine 和來自Curio的 Keystone。世界引擎將游戲邏輯的執行分離到一個名爲游戲碎片的單獨層中，該層在 EVM 兼容層之上運行。游戲碎片還被設計爲允許水平擴容以根據需求調整總rollup吞吐量。衕樣，Curio 的 Keystone 架構將高吞吐量游戲引擎與 EVM 捆綁在一起作爲rollup執行環境。這裡的挑戰是實現 EVM 引擎和游戲引擎之間的無縫互操作性。
數據可用性（Data Availability）註意事項
在前麵的討論中，重點是擴展應用程序rollup的主要方麵，即增加rollup交易吞吐量。還有其他與吞吐量增加相關的主題，例如數據可用性 (DA)、排序器去中心化和結算速度。對於高吞吐量應用程序rollup來説，數據可用性是最緊迫的問題。
單個應用rollup可能會實現超過 10k tps 的吞吐量。使用以太坊作爲這些交易的 DA 層是不可能的。首先，在 L1 上髮布簡單的 L2 ETH 轉賬數據的平均成本可能超過 0.10 美元。對於大多數應用程序rollup來説，這些成本太高了。更重要的是，對於使用 L1 進行 DA 的rollup，以太坊的 L1 目前無法支持超過大約 8k TPS [1]。
應用程序rollup將主要依賴於外部 DA 解決方案。 Celestia 和 EigenDA 目前被定位爲應用程序rollup的最可行的選擇。例如，Eclipse 計畫使用 Celestia 來實現基於 SVM 的高吞吐量rollup。 Argus 和高吞吐量游戲引擎最初也計畫使用 Celestia。衕樣，EigenDA 承諾高達 10MB/秒的數據吞吐量，可以成爲多個應用程序rollup的可行解決方案。
然而，集成 Celestia 或 EigneDA 的主要缺點是經濟價值泄漏。除了以太坊 L1 上的結算費用外，App Rollup 還必鬚支付 DA 層的費用。結算費用對於應用程序rollup至關重要，因爲它使rollup安全性與以太坊的安全性保持一緻。 DA 保證不太重要，尤其是在交易價值小得多的 FOG 背景下。此外，Celestia 和 EigenDA 承諾低廉的費用，因爲這些網絡是新的，最初的利用率較低。當這些 DA 網絡實現高利用率時，DA 費用也可能變得過高。在我看來，應用rollup應該使用簡單的數據可用性委員會 (DAC) 來證明rollup數據的可用性[3]。
總之，我相信應用程序rollup是現有的最佳解決方案，可以擴展一般的高吞吐量應用程序，特別是完全鏈上的游戲。擴展這些應用程序rollup是實現超越本地加密用戶的主流採用的關鍵。在 Alliance，我們希望通過支持正在構建這個項目的創始人來將這一願景變爲現實
我要感謝Matt Katz、Kevin Zhang、Tarrence van As 和 Larry Liu 感謝他們對這篇文章。
[1] 假設以太坊區塊的Gas限製的50％僅用於使用calldata存儲數據，平均每個交易大小爲10字節，區塊時間爲12秒。
聲明：
- 本文轉載自[Alliance]，著作權歸屬原作者[Mohamed Fouda]，如對轉載有異議，請聯繫Gate Learn團隊，團隊會根據相關流程盡速處理。
- 免責聲明：本文所錶達的觀點和意見僅代錶作者個人觀點，不構成任何投資建議。
- 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。
相關文章
如何質押 ETH？
什幺是瑞波幣（XRP）？
什麼是穩定幣 USDT？
如何擴展應用程序彙總（rollup）
應用程序rollup正在成爲擴展一組特定以太坊應用程序的明顯贏家。這些應用程序受益於無需許可和強大的所有權保證，但不需要所有應用程序用戶之間衕時交互。完全鏈上游戲（FOG）是符合此描述的最佳示例。 FOG 受益於強大的游戲內資産所有權、無需許可的游戲參與和無需許可的游戲模組。盡管如此，大多數游戲併不要求所有玩家衕時互動。其他可以從應用程序rollup擴展策略中受益的應用程序包括 NFT 市場、永久交易所和鏈上人工智能推理。
應用程序rollup已經成爲許多此類用例的首選實現。然而，標準rollup實現（即 EVM rollup）仍然具有重要的可擴展性限製。他們可能可以實現每秒 100 個交易左右的吞吐量。對於某些鏈上游戲來説，這樣的吞吐量已經足夠了，具體取決於游戲類型。然而，大多數游戲需要更高的吞吐量來支持大量（> 1000）的併髮玩家。本文重點介紹擴展應用程序rollup以覆蓋數十萬併髮參與者的方法。對於每種方法，我都會討論合適的應用程序/游戲類型及其麵臨的挑戰。
鼓勵正在使用應用rollup的開髮者或正在構建基礎設施以擴展應用rollup的開髮者聯繫我併申請聯盟。我期待與創始人在這些領域合作。
水平擴容
水平擴容是擴展應用程序rollup的最簡單方法。然而，這種簡單性是以失去可組合性爲代價的，這使得它們隻適合一小部分應用程序，例如單人游戲。
水平擴容意味著隻需部署多個應用程序rollup（OP 或 ZK），併將相衕的智能合約部署到所有rollup。應用程序的前端根據容量、位置或特定應用程序選項無縫地將用戶引導至其中一個rollup。 Alt Layer 最近通過推出可擴展的 2048 FOCG 展示了這一概念。在游戲的前端，用戶可以根據自己的地理位置選擇要加入的rollup。由於 Rollup 即服務提供商（例如 Caldera 負責處理與旋轉和管理這些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 OP 併消耗 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+ 架構。
混合執行環境
在全鏈游戲（FOGs）中特別流行的第三種方法是結合前兩種方法的最佳功能。這種方法將 EVM 兼容性與專用的非 EVM 執行環境結合起來。非 EVM 環境專註於核心游戲原語的高性能執行。游戲內資産管理，例如游戲內 NFT 的交易可以通過標準 Solidity 合約來處理。
這種方法的優點是 EVM 兼容性可確保與更大的開髮者生態繫統和現有産品保持一緻。它還允許無需許可的可組合性。開髮者可以通過添加 EVM/solidity 智能合約來修改和擴展游戲邏輯。衕時，專門的非EVM游戲引擎實現了EVM無法滿足的高吞吐量。
這種方法的示例包括來自 Argus 的 World Engine 和來自Curio的 Keystone。世界引擎將游戲邏輯的執行分離到一個名爲游戲碎片的單獨層中，該層在 EVM 兼容層之上運行。游戲碎片還被設計爲允許水平擴容以根據需求調整總rollup吞吐量。衕樣，Curio 的 Keystone 架構將高吞吐量游戲引擎與 EVM 捆綁在一起作爲rollup執行環境。這裡的挑戰是實現 EVM 引擎和游戲引擎之間的無縫互操作性。
數據可用性（Data Availability）註意事項
在前麵的討論中，重點是擴展應用程序rollup的主要方麵，即增加rollup交易吞吐量。還有其他與吞吐量增加相關的主題，例如數據可用性 (DA)、排序器去中心化和結算速度。對於高吞吐量應用程序rollup來説，數據可用性是最緊迫的問題。
單個應用rollup可能會實現超過 10k tps 的吞吐量。使用以太坊作爲這些交易的 DA 層是不可能的。首先，在 L1 上髮布簡單的 L2 ETH 轉賬數據的平均成本可能超過 0.10 美元。對於大多數應用程序rollup來説，這些成本太高了。更重要的是，對於使用 L1 進行 DA 的rollup，以太坊的 L1 目前無法支持超過大約 8k TPS [1]。
應用程序rollup將主要依賴於外部 DA 解決方案。 Celestia 和 EigenDA 目前被定位爲應用程序rollup的最可行的選擇。例如，Eclipse 計畫使用 Celestia 來實現基於 SVM 的高吞吐量rollup。 Argus 和高吞吐量游戲引擎最初也計畫使用 Celestia。衕樣，EigenDA 承諾高達 10MB/秒的數據吞吐量，可以成爲多個應用程序rollup的可行解決方案。
然而，集成 Celestia 或 EigneDA 的主要缺點是經濟價值泄漏。除了以太坊 L1 上的結算費用外，App Rollup 還必鬚支付 DA 層的費用。結算費用對於應用程序rollup至關重要，因爲它使rollup安全性與以太坊的安全性保持一緻。 DA 保證不太重要，尤其是在交易價值小得多的 FOG 背景下。此外，Celestia 和 EigenDA 承諾低廉的費用，因爲這些網絡是新的，最初的利用率較低。當這些 DA 網絡實現高利用率時，DA 費用也可能變得過高。在我看來，應用rollup應該使用簡單的數據可用性委員會 (DAC) 來證明rollup數據的可用性[3]。
總之，我相信應用程序rollup是現有的最佳解決方案，可以擴展一般的高吞吐量應用程序，特別是完全鏈上的游戲。擴展這些應用程序rollup是實現超越本地加密用戶的主流採用的關鍵。在 Alliance，我們希望通過支持正在構建這個項目的創始人來將這一願景變爲現實
我要感謝Matt Katz、Kevin Zhang、Tarrence van As 和 Larry Liu 感謝他們對這篇文章。
[1] 假設以太坊區塊的Gas限製的50％僅用於使用calldata存儲數據，平均每個交易大小爲10字節，區塊時間爲12秒。
聲明：
- 本文轉載自[Alliance]，著作權歸屬原作者[Mohamed Fouda]，如對轉載有異議，請聯繫Gate Learn團隊，團隊會根據相關流程盡速處理。
- 免責聲明：本文所錶達的觀點和意見僅代錶作者個人觀點，不構成任何投資建議。
- 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。
相關文章
如何質押 ETH？
什幺是瑞波幣（XRP）？