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

2023-10-20 19:33

免责声明 免责声明:内容来源于网络收集,不构成任何投资建议!

撰稿:Mohamed Fouda 编译:Deep Wave TechFlow

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

应用程序Rollup 正在成为扩展一组特定以太坊应用程序的明显赢家。这些应用程序受益于无权限和强大的所有权保证,但不需要所有应用程序用户之间同时交互。完全链上的游戏就是最好的例子。链上游戏受益于游戏资产的强大所有权,允许匿名参与游戏并允许匿名游戏修改。尽管如此,大多数游戏并不要求所有玩家同时互动。其他可以从Application Rollup 的扩展策略中受益的应用程序包括NFT 市场、永久交易所和链上人工智能推理。

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

应用程序汇总已经成为许多此类用例的首选实现。然而,标准Rollup 实现EVMRollup 仍然具有重要的可扩展性限制。他们可以实现每秒大约100 个事务的吞吐量。对于某些链上游戏来说,这个吞吐量可能足够了,具体取决于游戏类型。然而,大多数游戏需要更高的吞吐量来支持大量并发玩家(超过1000 人)。本文重点介绍应用程序Rollup 可以扩展以覆盖数十万并发参与者的方法。对于每种方法,我都会讨论适当的应用程序/游戏类型及其挑战。

水平扩展

水平可扩展性是扩展Rollup 应用程序的最简单方法。然而,这种简单性是以牺牲可组合性为代价的,这使得它们仅适用于一小部分应用程序,例如单人游戏。

水平可扩展性意味着只需部署多个应用程序汇总(Optimistic 或ZK)并在所有汇总上部署相同的智能合约。该应用程序的前端根据容量、位置或特定应用程序选项无缝地将用户引导至其中一个汇总。 Alt Layer 最近通过推出可扩展的2048 FOCG 游戏展示了这一概念。在游戏前端,用户可以根据自己的地理位置选择加入哪个Rollup。这种方法很容易被游戏开发者采用,因为它很简单,并且有像Caldera 这样的Rollup 即服务提供商,可以处理与旋转和管理这些Rollup 相关的所有基础设施工作。

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

尽管如此,多种Rollup 扩展方法仍存在一些问题。第一个问题是Rollup网络切换。当前的钱包(例如Metamask)需要手动批准才能连接到新网络(Rollup 实例)。这给玩家带来了困难且令人困惑的用户体验,因为玩家需要手动连接到多个“网络”才能玩同一个游戏。幸运的是,这种复杂性可以通过帐户抽象(AA) 解决方案消除。示例包括EIP 4337 和嵌入式钱包(例如Privy 和0xPass)。

另一个挑战是在Rollups 之间的转换期间管理玩家的状态。在某些情况下,例如容量下降,应用程序可能需要将多个Rollup 实例合并为单个实例以节省资源。在这种情况下,所有活跃玩家的状态都需要迁移到新实例。当前的桥接解决方案,特别是zk 桥接器,可以在解决这个问题上发挥关键作用。使用这些解决方案,可以将玩家的游戏状态桥接到新的Rollup 实例,同时维护该状态有效性的证明。然而,现有桥接解决方案的延迟对于游戏用例来说可能不是最佳的。

ZK 状态通道

另一种更适合多人游戏(例如扑克)的应用Rollup 扩展方法是ZK 状态通道。在这些游戏中,玩家互动发生在少数玩家之间,例如2-10人之间。这些玩家之间的游戏玩法只有在游戏进行时才重要。然而,游戏的最终结果更为重要,因为它会影响每个玩家的资产平衡。因此,将结果存储在共享持久层中非常重要。

在这种情况下,应用程序Rollup 代表共享信息层,其中存储游戏结果和游戏资产。对于Rollup上的每个游戏,都可以启动一个ZK状态通道来服务这个游戏。在游戏过程中,每个玩家都会生成交易并创建ZKP,证明他们遵循游戏规则。其他玩家交互的证明使用递归证明来聚合先前的证明。当游戏结束时,最终的ZKP被提交给应用程序Rollup,以证明游戏玩法和最终结果的有效性。游戏生成的状态更改会更改应用程序Rollup 上的玩家状态。

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

ZK 状态通道将游戏交互移至链下。因此,游戏内活动和交易不计入应用程序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 是实现超越原生加密用户的主流采用的关键。