如何扩展应用程序汇总（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？
如何扩展应用程序汇总（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？