Dapp Rollup技术解读：如何让高吞吐量APP走向主流？

撰写：Mohamed Fouda 编译：深潮 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 在内的多个团队一直在开发这项技术。