应用程序 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 技术详解：高吞吐量 APP 走向主流采用的关键】的延伸阅读

• 加密杂谈：对RaaS和Eigenlayer的一些看法

  本文讨论了加密货币领域的热门话题，包括Rollup技术、Restaking、LRT、AVS和Eigenlayer。作者认为目前情况并不乐观，团队进展缓慢，Rollup部署过多也不利。对于Restaking、LRT、AVS和Eigenlayer的不满，存入ETH数量巨大，但空投效果不佳。团队发布庞大白皮书，但工作原理和概念仍不清楚。Eigenlayer决定暂不启用惩罚机制，但是否有必要为每个新兴协议提供近十亿美元的用户Restaking ETH并面临风险？惩罚机制将在不到一年内启用，操作者是否意识到Restaking风险？或许会有其他平台蚕食Eigenlayer的市场份额。

• 详解 OP Stack Rollup 流程及对应代码

  Optimism Bedrock是当前版本的OP Stack，提供了启动生产质量的Optimistic Rollup区块链的工具。它包括op-batcher和op-proposer两个服务，负责从sequencer读取交易内容并rollup到链上，以及将交易状态rollup到合约。文中介绍了如何使用recordL1Tip和l1Tip来获取最新的L1BlockRef，以及如何收集和提交交易数据。每个事务仅使用一帧，如果通道已满，则仅返回剩余帧，直到成功发送到L1。sendTransaction将交易发送到一层，并更新交易发送状态。FetchNextOutputInfo获取L2上的区块output，NextBlockNumber获取下一批次需要提交的区块区间，SyncStatus获取L2块的状态和块信息，OutputAtBlock根据块高获取output，sendTransaction使用output构建stateRoot提交交易到一层链。

这种方法的主要优势在于，提高 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 是实现超越原生加密用户的主流采用的关键。

免责声明：本文仅代表作者个人观点，不代表链观CHAINLOOK立场，不承担法律责任。文章及观点也不构成投资意见。请用户理性看待市场风险，以及遵守所在国家和地区的相关法律法规。
图文来源：Mohamed Fouda，如有侵权请联系删除。转载或引用请注明文章出处！

标签：Rollup