为什么开发人员更喜欢 RaaS，而不是使用成熟的 SDK 构建自己的 L3/Rollup？
原文：Towards the Multi-rollup Future（Smrti Lab）
作者：0xfan
编译：Luffy，Foresight News
封面：Photo by Milad Fakurian on Unsplash
TL;DR：
- 一些 Rollup 正在通过提供不同的 SDK 来构建各自的 L2/L3 应用生态系统。然而，采用率的扩张却并非一帆风顺。对此，一种可能的原因是：构建应用程序 Rollup 存在开发摩擦。
- 使用 SDK 构建 Rollup 通常涉及多个阶段，这些过程可能会带来开发摩擦，包括节点服务、安装调试、定制、智能合约开发和维护。
- 定制 Rollup（例如集成新的虚拟机（VM））对于 Rollup 开发团队来说是一项复杂的工程。它需要全面了解每个虚拟机的工作原理，提取代码库，并将虚拟机适配到每个 Rollup SDK 提供的各种接口中（例如 Rollkit 的 ABCI 接口）。此外，开发 Rollup 难免遇到各种错误和问题，解决这些问题通常耗时费力。
- 构建 Rollup 还需要进行一些权衡，例如平衡去信任性和效率。Rollup 交易的最终性分为三个级别，最终性时间越短，所需的信任级别也就越高。
- 事实上，能够减轻开发困难并促进相关权衡的中介对于构建应用程序 Rollup 是必不可少的。这正是 RaaS 的用武之地。
- 付费使用的业务模式并不是 RaaS 创造收入的必要条件。不同的策略可能包括提供免费访问，同时通过捕获 MEV 和潜在的交易费用来产生收入。另一个可行的选择是建立一个中央平台，简化所有应用程序 Rollup 的桥接、流动性和安全性，从而捕获其价值。
- 如何识别优质的 RaaS 产品？最关键的因素是提供各种虚拟机的能力。虚拟机的种类丰富程度比其他服务更重要。在提供任何附加功能之前，RaaS 应优先考虑其作为虚拟机即服务提供商的角色。
- 此外，具有完善节点和强大节点管理结构的项目也是 RaaS 的可行候选者。例如，Eigenlayer 可能会利用其现有平台来开发另一种 RaaS 产品。
随着模块化 Rollup 及其 SDK 的发展，该领域涌现出许多前景广阔的 Rollup。例如，Optimism 推出了 OP Stack，zkSync 开源了其 zk Stack，Arbitrum 推出了 Abirtrum Nitro，而 Polygon 则开发了以 Rollup 为中心的 2.0 架构。通用区块空间的可用性不再是主要限制；相反，重点已经转向便利性和定制化。
在上一篇文章中，我们对现有的 RaaS 项目及其特性进行了比较。然而，还有一个相关的问题仍未得到解答：在每个 Layer 2 网络都有自己的 Layer 3 和 SDK 的多 Rollup 生态系统中，为什么开发人员更喜欢 RaaS，而不是使用成熟的 SDK 构建自己的 L3/Rollup？
为了回答这个问题，我们可以首先研究一下 Web2 世界，并探讨为什么开发人员可能会选择 KaaS 而不是自己运行 Kubernetes。
什么是 Kubernetes 和 Kubernetes 即服务 (KaaS)
容器（Containers）是指一种软件技术，它支持为部署目的对应用程序进行虚拟打包和隔离。而 Kubernetes（也称为 K8s）是一个旨在自动化容器化应用程序的部署、扩展和管理的开源系统。通过提供一个调度和执行容器的平台，它为部署流程带来了结构和组织，同时还自动化了相关的操作职责。
如果比较 KaaS 和 RaaS，我们会发现这样的关系：
Rollup SDK 和 Kubernetes Cluster 有一个共同点，即两者都是完全开源且免费使用，它们不太可能在 SDK 层面收取费用。最初，Google 团队提出将 Kubernetes 作为免费服务，但后来成为第一个提供 KaaS 作为创收服务的团队。
虽然 Kubernetes 本身是开源且免费的，但管理 Kubernetes 集群的每个组织都必须承担一定职责：
- 为团队提供技术培训（原因是 Kubernetes 的学习曲线陡峭）；
- 管理和升级多个版本的 Kubernetes；
- 处理 Kubernetes 系统的安装和升级；
- 在集群上部署应用程序；
- 管理可扩展性和集群配置；
- 确保集群配置安全，以防止未经授权的访问或数据泄露；
此外，管理不同的集群可能也具有挑战性，因为它需要一个人跨不同集群处理各种任务。
当企业考虑战略实施时，他们最初的目标是自行管理。然而，他们可能很快就会意识到管理多个集群同时确保每个集群的稳定性并不容易。自行管理不仅无法为他们提供竞争优势，而且供应商也可能比他们更擅长管理。
而且，Kubernetes 通过 Pod 运行，Pod 包含支持容器应用程序或多个容器所需的所有存储资源，以及唯一的网络 IP 和操作设置。然而，Pod 的使用寿命有限，这给使用 Kubernetes 的开发运营团队带来了独特的挑战。关键问题是如何保持必要的「后端」Pod 的稳定性，以确保其相应的「前端」Pod 继续正常运行。
这就是 KaaS 发挥作用的地方。
同样，在 Rollup 的世界中，当存在有价值的、免费的 Rollup SDK 时，为什么我们还需要 RaaS？
使用 Rollup SDK（例如 Rollkit）启动 Rollup 需要什么？
以 Celestia 的 Rollkit 为例，要利用 Rollup SDK 并启动一个新的 Rollup，必须至少完成以下步骤：
节点服务
Rollup 由节点运行。如今，除了在本地运行 Rollup 之外，使用云服务进行节点运营是非常普遍的。使用云服务进行节点运营可能会产生固定成本。在 KaaS 领域，提供最有效节点服务的 AWS、Google Cloud 等成为了 KaaS 服务提供商。
目前，Vistara Labs 等 RaaS 团队利用云服务为其 RaaS 产品启动 Kubernetes 集群。最终，网络参与者有责任确保模块化 Rollup 节点的可靠运行。
安装调试
开发人员在启动 Rollup 时可能会遇到一些问题或错误。
例如，当使用 Rollkit 启动本地 Rollup 时，解决大量错误和问题可能会消耗启动普通 Rollup 所需时间的大约 80%。这是因为，尽管 SDK 提供了操作 Rollup 的抽象方法，但设置环境和依赖项、执行 bash 脚本以及与 RPC API 交互等任务必须独立处理，这增加了过程的复杂性。
定制化
当开发人员打算自定义网络时，他们不能仅仅使用代码库中提供的模板。他们必须理解 SDK 的底层逻辑，这可能有一个陡峭的学习曲线。此外，每个 SDK 都有不同的逻辑和编程语言；例如，Arbitrum Nitro 使用 Go 和 Rust，而 Op Stack 使用 Go 和 Solidity。
在虚拟机方面，分叉现有项目是不够的。那些希望将虚拟机合并到 SDK 中的人必须了解每个 VM 的运行方式，提取 VM 初始化和服务器代码库，然后将 VM 包装到每个 SDK 提供的不同接口中，例如 Rollkit 的 ABCI 接口和 OP Stack 的 Engine API。因此，将各种虚拟机与每个 SDK 集成将带来复杂的组合问题（SDK ↔ 虚拟机），需要大量的资源、时间和人员。借助中介来处理这个问题而不是要求开发人员自己做是合理的。
此外，不同类型的 Rollup 设计了不同的 SDK。例如，Sovereign SDK 针对主权 Rollup 进行了优化，而 OP Stack 主要用于智能合约 Rollup。由于每种类型的 Rollup 都有其独特性和缺点，因此为开发人员提供一系列可供选择的 SDK 选项比让一个 SDK 兼容各种类型的 Rollup 更为明智。
智能合约开发
虽然特定的应用程序 Rollup 可能需要它，但对于创建通用 Rollup 的开发人员来说可能不是必需的。
版本控制
在 KaaS 领域，版本控制对于开发人员来说至关重要。KaaS 有助于管理各种 Kubernetes 版本，实现现有 Kubernetes 工作负载的迁移而不会出现兼容性问题。
在 RaaS 领域，如果 Rollup SDK 具有较新的版本，则更新和迁移所有智能合约或 Rollup 本身可能会具有挑战性。对于那些使用 SDK 构建汇总的人来说，管理、修补和更新汇总会很复杂。
安全
RaaS 能够使用预先建立的安全最佳实践来部署 Rollup。在没有彻底了解代码库的情况下修改 Rollup 可能会导致新的错误或问题，从而给用户和资金带来风险。
Rollup 定制的进一步思考
即使在比较 Optimism、Starknet 和 Arbitrum 当前提供的 L3 解决方案时，开发人员也必须选择或设计某些功能。
排序方案。排序方案需要进行定制或调整，以满足应用程序 Rollup 开发人员的需求。这可能包括 FCFS、PGA 或更复杂的方案，例如已被 Sui 和 Aptos 使用的 Narwhall & Bullshark 或 Hotstuff。开发者可能会选择第三方提供商（例如共享排序器）来处理此问题，因为独立管理仍然具有挑战性。
最终性和去信任性之间的权衡。zk Rollup 和 Optimistic Rollup 都具有不同程度的最终性。一般来说，最终确定性有三种类型：预确认、软最终确定性和硬最终确定性。软最终性取决于对 L1 验证器者 L2 执行者的信任（例如，Optimistic Rollup 的挑战者和 zk Rollup 的证明者 / 验证者），并且最终性时间由排序器批处理时间和 L1 最终性时间确定。相比之下，硬最终性对于 Optimistic Rollup 而言是在 Rollup 交易最终在基础层上结算之后实现的，并且只需要信任 L2 执行者。对于 zk Rollup，当证明得到验证时就达到了硬最终性。
共享执行者和自运执行者之间的权衡。执行者负责执行交易并更新链下数据库，而排序器负责对交易进行排序并将其提交到基础层。
这个角色有灵活性的设计空间。专用的执行者可以提供更好、更个性化的性能，但这需要应用程序 Rollup 开发人员付出巨大的努力，并且对硬件要求很高。例如，渴望高性能的 GameFi 可能更喜欢拥有专用的执行者。或者，为了方便起见，可以选择使用基础层作为执行者。
此外，拥有共享执行者集的 Rollup 之间可以进行原子交易，这可能是一个显着的优势。
去中心化和成本之间的权衡。 Web2 游戏公司可能不会优先考虑 Rollup 的去中心化。 游戏工作室本身是中心化的，他们签署希望发布到链上的数据，充当预言机。因此，他们可能不关心 数据可用性层和排序器的去中心化。 对他们而言，DAC 或中心化 DA 节点会更合适，而且更加便宜。
因此，能够代表用户处理所有这些功能和流程的中介至关重要，例如包装到各种 SDK 中的虚拟机、版本控制、多种 Rollup 类型以及 MEV 保护等增值功能。此外，开发 Rollup 还涉及各种权衡。像 RaaS 这样的解决方案提供商可以帮助您就这些权衡做出更好的决策。
然而，即使在 KaaS 领域，35% 的开发人员也选择在内部构建自己的 Kubernetes，而不是使用 KaaS。这主要是由于敏感的数据安全问题或具有挑战性的本地依赖关系导致，特别是对于艾玛迪斯和彭博这些大型复杂组织而言。这同样适用于 RaaS 世界，出于隐私考虑，开发人员可能不会选择使用 RaaS。
因此，RaaS 通常作为中介来处理开发人员可能难以自行完成的任务。但问题是，谁将成为 RaaS 的赢家？
RaaS 如何创造价值？
除了传统的订阅模式之外，还有三种潜在的方式来产生价值：
付费订阅。 用户可以通过向 RaaS 支付代币来创建新的 Rollup。这被认为是最糟糕的商业模式，因为它可能会导致价格战。
验证者质押代币以赚取交易费、MEV 和奖励。 验证者，例如 Rollup 排序器和执行者，必须抵押代币才能发挥作用。RaaS 还可以接收一部分 L1 类型费用（例如 MEV、交易费用、奖励）作为收入。Eigenlayer 和 Vistara Labs 已采用这种方法。
为所有应用程序 Rollup 构建中心。 为其原生代币开发中心链可以帮助积累价值，因为它充当桥梁、流动性和安全中心。这是 RaaS 生态系统使用的常见方法，其中包括 Optimism、Arbitrum、Polygon 2.0、Eclipse 等。
在我看来，质押代币和建立中心并不排斥，同时实施两者可以产生更多价值。
然而，当应用程序 Rollup 得到广泛采用时，它可能不愿意与中心或验证者分享其部分价值。在这种情况下，推出自己的链来捕获所有价值（类似于 dYdX 所做的），仍然是一种可能性。
RaaS 的主要特点是什么？
让我们先看一下 KaaS，它对开发人员最有吸引力的功能是什么？
EKS 的成功仍然依赖于亚马逊云服务，因为亚马逊目前在全球云服务商市场占据主导地位。因此，亚马逊云服务的用户可能会发现选择 EKS 作为他们的 KaaS 服务，可以获得对亚马逊架构的最佳支持。
EKS 允许自带操作系统选项，几乎可以使用任何操作系统，而 GKE 在这方面有更多限制。
虽然 EKS 在配置集群时提供了高度的灵活性，但这也意味着开发人员必须承担管理负担。例如，虽然 EKS 支持 Calico CNI 的网络策略，但用户需要手动安装和升级。
首先，Google Kubernetes Engine 是一个更好的产品。它始终比市场上的任何竞争对手（包括 EKS）拥有更多的功能。
在功能、支持和易用性方面， GKE 无疑仍然是托管 Kubernetes 的王者。GKE 也是唯一提供完全自动化的主节点和节点升级过程的服务。
总之，EKS 广泛的客户群归功于亚马逊的云服务，它为操作系统和安全性提供了更大程度的定制。然而，这会导致便利性和自动化之间的权衡。
GKS 提供了最多的功能，并支持降低开发者的使用门槛。然而，它在一定程度上损害了操作系统的安全性和定制性。
把这个结论放到 RaaS 生态中。
最关键的因素是提供商提供各种虚拟机 (VM) 的能力，更多种类的虚拟机比其他服务更重要。在提供任何附加功能之前，RaaS 应优先考虑其作为虚拟机即服务提供商的角色。
具有完善的节点和强大的节点管理结构的项目是 RaaS 的可行候选者。例如，Eigenlayer 可能会利用其现有平台来开发另一种 RaaS 产品。
确保节点 / 排序器的安全性至关重要且不能受到损害。
现有的 L2 解决方案如何？
Optimism
OP Stack 可供其他人使用，而无需成为 Optimism 的 L3。OP Stack 的收入模式与 Cosmos Hub 类似，与 Optimism 连接的 L3 越多，OP 可以捕获的价值就越多。如果基于 OP Stack 的 Rollup 选择不连接到 Optimism，则 OP 将不会捕获任何值。
例如，opBNB 使用 OP Stack 进行构建，但不使用 Optimism 的排序器，也不与 OP DAO/ 基金会共享交易费用，所有的价值都将被他们自己的项目所捕获。相比之下，Base 链会将一部分交易费用给予 OP，以奖励 OP 生态中的公共产品，但这不是强制性的。
Arbitrum
为了充分放大 ARB 的价值，必须注意 Arbitrum Orbit 许可证不会自动包含与非 Arbitrum-DAO 管理的链相关的链。开发人员只能使用 Nitro 在 Arbitrum 链之上构建 L3。如果他们想建立一个直接结算到以太坊的 L2，他们必须获得 Artbitrum DAO 的同意。
值得注意的是，Nitro 仅用于与 EVM 兼容的 Rollup。那些想要尝试与 EVM 不兼容的 ZKVM 的人不得不使用 RaaS。
Starknet
Starknet 提出了多 Rollup 宇宙的路线图。虽然 StarkEx 目前以 L2 解决方案为客户服务，但会移植到 L3 以进一步降低成本。
除了 StarkEx 之外，构建在 Starknet 之上的特定应用程序的 L3 也会有一席之地。它可以实现比 StarkEx 服务更高级别的定制和主权。Stakrware 团队通过构建 Madara 排序器来处理此功能，该排序器允许任何人启动自己的 Starknet 应用链。用户可以利用 Cairo 的功能，同时保持对自定义应用程序链的完全控制。
Madara 基于 Substrate，使用 Cairo VM 来执行 Cairo 程序和 Starknet 智能合约。在 Kakarot 的帮助下，用户可以构建 zkEVM Rollup。最终，证明者或证明者市场可以监听链产生的区块并生成证明。因此，从技术上讲，Madara 可以解决任何 L1/L2 问题。
zkSync
zkSync 最近推出了构建独立零知识链的框架。但 ZK Stack 并不适合所有人。如果创建一个通用的 DeFi DApp 或 NFT 项目，将其部署在现有的超链（例如 zkSync Era）上将是一个更简单的方案。
ZK Stack 专注于跨链通信过程，实现共享证明者来聚合不同超链的证明。这允许跨链消息的快速确定。生态系统中的超链越多，ZkSync Era 捕获的价值就越少。
Polygon 2.0
Polygon 2.0 的目标是从发散阶段过渡到收敛阶段，所有 Polygon 链将在同一架构下运行。这将包括一个质押层，供验证者质押 Polygon 的原生代币并为 Rollup 提供服务。此外，还将有一个统一的互操作层来聚合 zk 证明并促进跨链通信。随着 Polygon 链上活动的增加，Polygon 原生代币的价值也会增加。
总结
开发应用程序 Rollup 必然会遇到开发摩擦和做出权衡选择。因此，能够代表用户管理所有这些功能和流程的中介机构至关重要。这包括包含在各种 SDK 中的虚拟机、版本控制、多种 Rollup 类型以及 MEV 保护等增值功能。此外，对于这个中介来说，在构建应用程序 Rollup 时协助做出更好的权衡决策是有益的。到目前为止，RaaS 能够胜任这一角色。在评估良好的 RaaS 时，所提供的虚拟机 (VM) 多样性比其他服务更为重要。在提供任何附加功能之前，RaaS 应优先考虑其作为虚拟机即服务提供商的角色。
