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