RollApp 生态深度解析：四类应用特定的 Rollup 方案各有什么优劣？

撰文：Smrti Lab

编译：Modular 101

英文原文发布于 2023 年 3 月 28 日，本文为上半部分内容。

本文全面分析了 RollApp 生态，比较了四种现存方案的优劣。

太长懒得读版：

• 目前的应用特定 rollup（RollApp）生态包括四种类型：RollApp SDK、Rollup 即服务（RaaS）、Rollup-SDK 即服务和统一排序网络（Unified Sequencing Network）。
• RollApp SDK 帮助开发者创建个性化的 RollApp。通常，RaaS 提供商利用 Rollup-SDK 来开发服务，这样可以省去编写 RollApp 部署的需求，提供了类似智能合约的开发体验。
• 虽然 RaaS 主要面向智能合约开发者 (2C），但也需要为开发者聚合所有这些不同的 SDK，这引发了 2B 服务提供商 Rollup-SDK 即服务的出现。
• 统一排序提供商在序列器的某些特性上进行了专业分工，例如去中心化、可扩展性和安全性。
• Rollup 有四种主要类型：结算 Rollup、主权 Rollup、基础 Rollup 和内嵌式 Rollup。不同的 RollApp SDK 和 RaaS 专注于不同类型的 Rollup，并具有各自的权衡。
• 当前的 RaaS 项目提供了相似程度的定制化。主要关注点是这些特性的实施程度，以及部署的速度和稳定性。
• 统一的接口带来了模块化。而模块化则带来了组合性，解锁了多种 RollApp 的潜力。如果没有统一的接口，可能会面临一堆彼此不兼容的乐高积木。
• 在市场上，序列器的去中心化可能需要做出妥协。相反，有效执行商业模式以及启动和定制应用 RollApp 的便利性更受重视，即使节点最初并非去中心化的。

应用特定 rollup（即 RollApp）正在成为区块链领域的重要议题。虽然 “RollApp” 的理念目前仍然很年轻，但我们在过去一年中见证了该领域出现了几个项目。

在此概览中，我们希望强调并比较这个特定领域内的一些不同解决方案，因为它们可能在可预见的未来成为区块链领域的重要因素。在深入讨论这些单独的解决方案之前，有必要先讨论一下我们是如何走到今天的。

最初，开发者只能选择在现有的 Layer 1（L1）链上部署（如以太坊等）。虽然在现有层上部署为构建者提供了足够的安全保证，但它们缺乏扩展到大众用户所需的可扩展性功能。

为了解决这个扩展问题，我们开始看到出现越来越多 Rollup，而不是更多的 L1 链。Rollup 提供了足够的可扩展性，同时保留了基础链的安全性。虽然这解决了一些扩展问题，但开发者现在面临的问题是可定制性。

每个在以太坊的 Layer 2（L2）上部署的 dapp 都与该 Rollup 中的所有其他 dapp 共享计算资源，这导致了激烈的 gas 竞争来争夺有限的区块空间。除此之外，dapp 还缺乏可定制性，因为它们必须遵循所部署的基础链的相同规则。

有限的区块空间和缺乏可定制性，促使了应用特定区块链（应用链）的兴起。这种类型的框架由 Cosmos 生态系统推广，随后被 Polygon Superchains、Avalanche Subnets 等采用。然而，即使是应用链也有其自身的缺点，比如必须启动自己的验证人网络，和负责自身的安全性。

但是，如果开发者既能够结合在 Rollup 上部署的安全性优势，又能拥有自己专用环境的灵活性，岂不是更好？

这正是应用特定 Rollup 或 “RollApp” 试图实现的目标。这个想法本质上是将从 Rollup 借来的安全性与灵活性，和拥有自己的专用环境的特性相结合。

1. RollApp 生态系统

目前，RollApp 生态系统有四个主要参与者。

RollApps SDK

这是一个供开发者轻松构建定制 RollApp 的框架和工具包。但是，开发者需要理解基本的区块链逻辑，才能构建自己的应用特定 Rollup。不同的 SDK 专注于不同类型的 Rollup，具有不同的有效性和欺诈证明选项。因此，对于开发者来说，选择适合其特定需求的 SDK 非常重要。

Rollup 即服务（RaaS）

RaaS 指的是 Rollup 服务提供商。RaaS 提供商通常在 Rollup-SDK（例如，Caldera 使用 Op Stack）之上构建服务。Rollup 部署无需代码。所有节点 / 调用都由 RaaS 运营商处理。对于智能合约开发者来说，无需理解区块逻辑，开发体验与开发智能合约的过程非常相似。

Rollup-SDK 即服务

虽然 RaaS 主要针对智能合约开发者 (2C），但也有将各种 SDK 整合到一起的需求，从而诞生了面向开发者的 2B 服务提供商，即 Rollup-SDK 即服务。目前，专注于这一领域的项目数量有限。模块化 Cloud 团队在 2022 年展示了这一功能，但他们目前的重点是构建一个浏览器，用于多种模块化区块链。

统一排序网络

尽管每个 RaaS 或 App Rollup SDK 可能都有自己的排序器，但仍然需要一个专门的排序器提供商，专注于去中心化排序器网络的共识和安全。一个共享和统一的排序网络可以简化跨不同 RollApp 实现原子性和互操作性的实现。

图 1. RollApp 生态全景图

2. 有哪些不同类型的 Rollup？

Rollup 旨在为 L1 提供扩展优势。它们由不同的组件组成，包括用户客户端、VM、排序器、证明系统（特别是对于 zk Rollup）、一个或多个内存池，以及 L1 上的桥接合约。

尽管 Rollup 是否应由桥接合约定义存在争议，我们可以根据哪个链 / 层作为真理源来区分 “主权” 和 “结算” Rollup，就像我们区分桥接协议一样。

图 2. 结算 Rollup 与主权 Rollup

结算 Rollup 是指依赖于结算层上的智能合约来验证证明和桥接资产的类型。这个智能合约充当 Rollup 链的真理源。为了保护这个桥接智能合约，许多 Rollup 团队（如 Arbitrum 和 Optimism）紧握升级密钥，以便在任何时候修复 Rollup 上的明显漏洞。然而，这种权威另一方面也给了随意更改代码而不被注意到的风险。

主权 Rollup 是由 Celestia 引入的，Rollup 本身就像一个 Layer 1 区块链一样运作。主权 Rollup 本身是真理的来源，而不是 L1。Rollup 节点通过自己的 P2P 网络传输欺诈（有效性）证明，并在本地验证它们，同时只使用基础链来存储有序交易。

此外，主权 Rollup 社区可以在不经基础层许可的情况下通过硬分叉升级链。当一些恶意行为发生并且主权 Rollup 想要撤销它时，这是有益的。

图 3. 基础 Rollup 与嵌入式 Rollup

基础 Rollup 是指使用 L1 节点作为排序器的 Rollup 类型。L1 排序设计可以帮助它继承 L1 的活跃性和去中心化，减轻来自中心化或短期排序器的有害 MEV。目前，还没有使用基础 Rollup 设计的 SDK 或 RaaS 协议。

嵌入式 Rollup 意味着在 L1 本身内构建 Rollup 区块。在以太坊上，执行客户端构建包含区块头和区块体的区块。如果我们将这个区块包装成带有（有效性 / 欺诈）证明的 Rollup 区块，那么其他验证者就不需要重新计算所有交易，只需要计算状态差异并验证证明。

这个想法与无状态（stateless）想法非常相似，即只有一个构建者包含完整状态以生成见证，然后其他人可以在不下载所有状态的情况下直接验证。目前，Dymension 是一个内嵌式的 Rollup 结构，稍后将在本文中提供对这种结构的详细讨论。

3. 深入了解 RollApp SDK 解决方案

3.1 Rollkit 和 OP Stack

今年 2 月 21 日，Celestia 团队推出了 Rollkit，一个模块化 Rollup 框架，使开发者能够自由选择不同的功能来构建自己的定制 Rollup。Rollkit 和 OP Stack 之间的一个关键区别是，Rollkit 支持主权 Rollup。

(1) Rollkit 提供的 VM 可能比 OP Stack 更灵活

主权 Rollup 的主要好处不是其分叉的能力，而是它允许开发者不必为 Rollup 编写 Solidity 轻客户端。

这可以鼓励更灵活的 VM 创新，因为它们不受已处理和结算 zk 和欺诈证明的 L1 的限制。在许多情况下，基础结算层（例如以太坊）可能无法有效处理。

OP Stack 旨在通过为所有 Superchain 构建自己的结算层来缓解这个问题。然而，结算层可能仍然受制于以太坊的结算能力，这对于希望在其他 VM 上结算的 Superchain 来说可能不是完美的场所。

希望融入 OP Stack 的各个 VM 模块必须支持 Engine API，它是所有以太坊执行客户端实现的一组方法。Engine API 目前正在开发中，并不是所有虚拟机都天然支持这个接口。因此，为了确保与更广泛的虚拟机兼容，还有很多工作要做。

(2) 在将其他 VM 引入 Rollkit 时，VM 包装和语言不兼容可能是主要挑战

然而，如果 Rollkit 可以实现更灵活的 VM 设计，为什么 Rollkit 中没有包含许多 VM（如 SolVM、MoveVM）？

Rollkit 为 Rollup 提供了类似 ABCI 的客户端实现。这意味着它处理请求，并通过应用区块链接口（ABCI）将它们转发到其本地应用实例，该接口最初由 Cosmos SDK 引入。换句话说，ABCI 允许区块链客户端和应用程序相互通信，即使它们是用完全不同的语言编写的。

另一方面，如果区块链上的客户端想要与应用程序（例如 VM）通信，那么唯一的方法就是通过发送请求调用 ABCI 方法。

因此，对于任何应用程序或 VM，它必须被包装成 ABCI 接口，以便融入 Rollkit。这是一个复杂的过程，因此，到目前为止，唯一被 ABCI 包装的 VM 是 EVM（Etheremint）。

此外，当开发时，它也会带来一些其他问题。ABCI 是由 Cosmos-SDK 设计的。因此，目前在 ABCI 之上构建应用程序所用的大多数工具都是针对 Golang 的，这给那些希望将 Fuel 或 Aptos 堆栈（使用 Rust 和其他语言编写）引入 Rollkit 的人带来了困难。

Rollkit 与使用其他编程语言的应用程序通信的最简单方法是使用套接字（sockets）连接。然而，Rollkit 目前没有与套接字使用应用程序通信的本地能力，这可能限制了其他 VM 或应用程序的迁移速度。

另一方面，OP Stack 有自己类似 ABCI 的接口要求，称为 Engine API，该接口正在开发中，任何融入 OP Stack 的 VM 都必须与 Engine API 兼容。

图 4. Rollkit 结构

(3) Rollkit 可以集成到非 EVM 链（如比特币）以继承其安全性，而 OP Stack 不能

对于 OP Stack，它必须依赖第三方链作为其他 OP Stack 链的结算层，这需要在结算层上部署源链的轻客户端或智能合约。

使用非 EVM 兼容链作为结算层，需要每条链理解和验证其他 VM 系统的证明和状态。这需要构建彼此的轻客户端或全客户端的复杂过程。然而，在像比特币这样的链上构建 OP Stack 的轻 / 全客户端几乎是不可能的，使得集成到比特币几乎不可能。

然而，由于主权 Rollup 通过自己的轻客户端验证证明，将数据拉入比特币来将其用作 DA 层可能相对容易。

(4) 比特币主权 Rollup 无法从比特币继承有效性

比特币主权 Rollup 使用比特币作为 DA 层，并在链下验证证明，但它能从比特币继承多少安全性？

鉴于几乎不可能为比特币上的主权 Rollup 编写完整或轻客户端。这意味着没有在比特币和其主权 Rollup 之间移动资产的去信任桥，从主权 Rollup 解释证明和状态是不可能的。

Sreeram Kannan 提供了一个评估区块链安全性的出色框架。将此框架应用于评估比特币主权 Rollup 的安全性，我们会看到抗重组性、抗审查性和数据可用性可以从比特币继承，只留下有效性属性作为特殊挑战。

图 5. 比特币主权 Rollup 的安全性

因此，比特币主权 Rollup 不适合需要原生使用 BTC 的应用程序，或需要在比特币上组合其他应用程序逻辑的能力。然而，对于优先考虑抗审查性和抗重组性的项目（例如 NFT 项目）来说，它可能是一个很好的选择。

然而，比特币是否可以成为其主权 Rollup 的合适数据可用性层？Taproot 见证赋予比特币在每个区块中包含多达 4MB 任意数据的能力。尽管存储主权 Rollup 数据的成本仍需进一步讨论，但据 Taproot 创始人 Eric Wall 称，按字节计算，它可能比以太坊便宜 7 倍。

3.2 ZK 主权 SDK 和 ZK 结算 Rollup

ZK rollup 的最终确定时间应该比乐观 rollup 快，但由于验证证明的高成本，ZK rollup 仍然受到较长最终确定时间的影响。

在以太坊 rollup 中验证单个证明的成本，可能在 30 万到 500 万 gas 不等，这取决于底层的证明系统。然而，证明的大小随交易数量的增加而缓慢增长。因此，rollup 经常选择等待并积累批量交易，以分摊每笔交易的证明验证成本。

当前 zk 结算 rollup 中 zk 的最终确定时间长的主要原因，是降低成本所需时间的延迟。然而，通过使用和信任中心化的排序器，zk 结算 rollup 可以实现更快的“软最终确定”。

从这个角度来看，主权 SDK 提供了独特的优势，通过降低验证成本实现快速和“真实”的最终确定。主权 rollup 中的节点可以实时创建证明，并稍后使用递归将它们聚合成一批证明。此外，主权 rollup 不需要额外的链上验证成本，这消除了为了分摊交易成本而需要的额外等待时间。

再次强调，最终确定仍然受到 DA 和共识层的限制，但可以大大减少由于证明验证高成本造成的延迟。

3.3 内嵌式 Rollup（Dymension）

如上所述，内嵌式 rollup 意味着在 L1 本身内构建 rollup 区块。在以太坊中，执行客户端构建包含区块头和主体的区块。如果我们将此区块作为带有证明（zk/ 欺诈）的 rollup 区块进行包装，则其他验证者无需重新计算所有交易。相反，他们只需计算状态差异并验证证明。

这可以产生一些优势：

• 不需要重新执行，特别适合状态见证解决方案。这也可以由于历史负载轻，而加速节点同步过程。
• 几乎所有值将直接交给 L1 —— Dymension Hub。
• 不需要在结算层构建桥接合约，实现更小的延迟和更快的最终确定。

将内嵌式 rollup 纳入以太坊是困难的，这就是为什么像 Dymension 这样的项目选择在 Cosmos 生态系统中构建的原因。

然而，内嵌式 rollup SDK 最大的潜在问题是其缺乏灵活性和主权。区块生产、证明验证和 rollup 类型的基本逻辑是 “内嵌” 在结算层中的，不能被开发者自由修改或 “乐高化”。

因此，内嵌式 Rollup SDK（例如 Dymension）与其结算层紧密相连，很难像 Rollkit 或 Sovereign SDK 那样自由修改 Rollup 的每个模块。

3.4 Rollup SDK 的关键特性是什么？

模块化促进可组合性。例如，模块化 SDK 可以针对不同用途进行定制和实现，从 DEX 到需要高 TPS 的游戏项目，通过结合各种模块，从执行环境到证明方案。能够顺利集成到同一 SDK 中的特定开发模块越多，可组合性就越高，这反过来显著降低了使用门槛。

然而，模块化也需要统一接口。拥有标准接口会更容易更换组件。相反，不同的接口可能会导致应用 rollup 生态的分裂。在缺乏统一接口的情况下，有最终成为彼此不兼容的乐高集合的风险。统一接口会带来模块化。模块化反过来带来组合性，为众多应用 rollup 解锁潜力。

图 6. 模块化和组合性