一些Rollups 通过提供不同的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 产品。随着模块化Rollups 及其SDK 的发展，该领域出现了许多有前途的Rollups。例如，Optimism推出了OPStack，zkSync开源了其zk Stack，Arbitrum推出了Abirtrum Nitro，Polygon开发了以Rollup为中心的2.0架构。公共块空间的可用性不再是主要限制；相反，重点已经转向便利性和定制化。
在上一篇文章中，我们比较了现有的RaaS 项目及其功能。然而，有一个相关问题仍未得到解答：在每个第2 层网络都有自己的第3 层和SDK 的多汇总生态系统中，为什么开发人员更喜欢RaaS，而不是使用成熟的SDK 构建自己的网络？ L3/汇总？
要回答这个问题，我们可以先看看Web2世界，探讨为什么开发者会选择KaaS而不是自己运行Kubernetes
容器是指支持虚拟打包和隔离应用程序以进行部署的软件技术。 Kubernetes（也称为K8s）是一个开源系统，旨在自动化容器化应用程序的部署、扩展和管理。通过提供用于调度和执行容器的平台，它为部署过程带来了结构和组织，同时还自动化了相关的操作职责。
如果我们比较KaaS 和RaaS，我们会发现这样的关系：
KaaS 和RaaS
Rollup SDK 和Kubernetes Cluster 的一个共同点是，两者都是完全开源、免费使用的，不太可能在SDK 层面收取费用。最初，Google 团队提出将Kubernetes 作为免费服务，但后来成为第一个提供KaaS 作为创收服务的团队。
虽然Kubernetes 本身是开源且免费的，但每个管理Kubernetes 集群的组织都必须承担一定的责任：
为团队提供技术培训（由于Kubernetes的学习曲线陡峭）；管理和升级多个版本的Kubernetes；负责Kubernetes系统的安装和升级；在集群上部署应用程序；管理可扩展性和集群配置；确保集群配置安全，防止未经授权的访问或数据泄露；此外，管理不同的集群也可能具有挑战性，因为它需要一个人跨不同集群处理各种任务。
企业在考虑战略实施时，最初的目标是自我管理。然而，他们可能很快就会意识到，管理多个集群同时保证每个集群的稳定性并不容易。自己管理不仅无法为他们提供竞争优势，而且供应商也可能比他们更擅长管理。
此外，Kubernetes 通过Pod 运行，Pod 包含支持容器应用程序或多个容器所需的所有存储资源，以及唯一的网络IP 和操作设置。然而，Pod 的使用寿命有限，这给使用Kubernetes 的DevOps 团队带来了独特的挑战。关键问题是如何保持必要的“后端”Pod 的稳定性，以确保其相应的“前端”Pod 继续正常运行。
这就是KaaS 发挥作用的地方。
同样，在Rollup 的世界里，既然有一个有价值的、免费的Rollup SDK，为什么我们还需要RaaS？
以Celestia 的Rollkit 为例，要使用Rollup SDK 并启动新的Rollup，至少必须完成以下步骤：
Rollup 由节点运行。如今，除了在本地运行Rollup 之外，使用云服务进行节点操作也很常见。使用云服务进行节点操作可能会产生固定成本。在KaaS领域，提供最有效节点服务的AWS、谷歌云等已成为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 接口和OPStack 的Engine API。因此，将各种虚拟机与每个SDK 集成将产生一个复杂的组合问题（SDK 虚拟机），需要大量资源、时间和人员。使用中介来处理这个问题比要求开发人员自己做是有意义的。
另外，针对不同类型的Rollup，设计了不同的SDK。例如，Sovereign SDK 针对主权汇总进行了优化，而OP Stack 主要用于智能合约汇总。由于每种类型的Rollup 都有其独特的特点和缺点，因此为开发人员提供一系列可供选择的SDK 选项比让一个SDK 与每种类型的Rollup 兼容更为明智。
虽然特定应用程序汇总可能需要它，但创建通用汇总的开发人员可能不需要。
在KaaS 世界中，版本控制对于开发人员至关重要。 KaaS 帮助管理各种Kubernetes 版本，并实现现有Kubernetes 工作负载的迁移，而不会出现兼容性问题。
在RaaS 世界中，如果Rollup SDK 具有更新版本，则更新和迁移所有智能合约或Rollup 本身可能会具有挑战性。对于那些使用SDK 构建汇总的人来说，管理、修补和更新汇总可能很复杂。
RaaS 支持使用预先建立的安全最佳实践来部署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 可能更喜欢有专用的执行器。或者，为了方便起见，您可以选择使用基础层作为执行器。
此外，原子事务可以在具有共享执行器集的Rollups 之间进行，这可能是一个显着的优势。
去中心化和成本之间的权衡。 Web2 游戏公司可能不会优先考虑Rollup 的去中心化。游戏工作室本身是中心化的，他们对希望发布到链上的数据进行签名，充当预言机。因此，他们可能不关心数据可用性层和排序器的去中心化。对于他们来说，DAC或者集中式DA节点会更合适，也更便宜。
因此，拥有一个能够代表用户处理所有这些功能和流程的中介至关重要，例如包装到各种SDK 中的虚拟机、版本控制、多种汇总类型以及MEV 保护等增值功能。此外，开发Rollup 涉及各种权衡。 RaaS 等解决方案提供商可以帮助您就这些权衡做出更好的决策。
然而，即使在KaaS 领域，35% 的开发人员选择在内部构建自己的Kubernetes，而不是使用KaaS。这主要是由于敏感的数据安全问题或具有挑战性的本地依赖关系，特别是对于像艾玛迪斯和彭博这样的大型复杂组织。这同样适用于RaaS 世界，出于隐私考虑，开发人员可能不会选择使用RaaS。
因此，RaaS 通常充当中介来处理开发人员可能难以自行完成的任务。但问题是，谁会是RaaS的赢家？
除了传统的订阅模式外，还有三种潜在的价值产生方式
付费订阅。用户可以通过向RaaS 支付代币来创建新的Rollups。这被认为是最糟糕的商业模式，因为它可能导致价格战。
验证者通过质押代币来赚取交易费、MEV 和奖励。验证器（例如Rollup 排序器和执行器）必须抵押代币才能运行。 RaaS 还可以获得一部分L1 类型费用（例如MEV、交易费用、奖励）作为收入。 Eigenlayer 和Vistara Labs 就采用了这种方法。
所有应用程序的汇总构建中心。为其原生代币开发中央链可以帮助积累价值，因为它充当桥梁、流动性和安全中心。这是RaaS 生态系统常用的方法，包括Optimism、Arbitrum、Polygon 2.0、Eclipse 等。
在我看来，质押代币和建立中心并不相互排斥，同时实施两者可以产生更多价值。
然而，当应用程序Rollup 获得广泛采用时，它可能不愿意与中心或验证器分享其部分价值。在这种情况下，启动自己的链来获取所有价值（类似于dYdX 的做法）仍然是一种可能性。
我们先看一下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 产品
确保节点/排序者的安全至关重要且不能受到损害。
OP Stack 可以被其他人使用，而不会成为Optimism 的L3。 OP Stack 的盈利模式与Cosmos Hub 类似，连接Optimism 的L3 越多，OP 能够获取的价值就越多。如果基于OP 堆栈的Rollup 选择未连接到Optimism，则OP 将不会捕获任何值。
例如，opBNB 使用OP Stack 构建，但不使用Optimism 的orderer，也不与OP DAO/Foundation 共享交易费用，所有价值将由他们自己的项目捕获。相比之下，Base 链会将一部分交易费用给予OP，以奖励OP 生态中的公共物品，但这不是强制性的。
为了充分放大ARB 的价值，需要注意的是，Arbitrum Orbit 许可证不会自动包含与非Arbitrum-DAO 托管链相关的链。开发者只能使用Nitro 在Arbitrum 链之上构建L3。如果他们想建立一个直接结算到以太坊的L2，他们必须获得Artbitrum DAO的同意。
值得注意的是，Nitro 仅适用于与EVM 兼容的Rollups。那些想要尝试与EVM 不兼容的ZKVM 的人必须使用RaaS。
Starknet 提出了多Rollup 宇宙的路线图。虽然StarkEx 目前为客户提供L2 解决方案，但它将迁移到L3 以进一步降低成本。
除了StarkEx 之外，还将有一席之地用于构建在Starknet 之上的特定于应用程序的L3。与StarkEx 服务相比，它实现了更高级别的定制和主权。 Stakrware 团队通过构建Madara 序列器来处理此功能，该序列器允许任何人启动自己的Starknet 应用程序链。用户可以利用Cairo 的功能，同时保持对其自定义应用程序链的完全控制。
Madara 基于Substrate，使用Cairo VM 执行Cairo 程序和Starknet 智能合约。在Kakarot 的帮助下，用户可以构建zkEVM Rollups。最终，证明者或证明者市场可以监听链产生的区块并生成证明。所以，从技术上来说，Madara 可以解决任何L1/L2 问题。
zkSync最近推出了构建独立零知识链的框架。但ZK Stack 并不适合所有人。如果创建一个通用的DeFi DApp 或NFT 项目，将其部署在现有的超链接上（例如zkSync Era）将是一个更简单的解决方案。
ZK Stack专注于跨链通信过程，并实现共享证明者来聚合不同超链的证明。这允许快速确定跨链消息。生态系统中的超链接越多，ZkSyncEra 捕获的价值就越少。
Polygon 2.0的目标是从发散阶段过渡到收敛阶段，所有Polygon链将运行在相同的架构下。这将包括一个质押层，供验证者质押Polygon 的原生代币并为Rollup 提供服务。此外，还将有一个统一的互操作层来聚合zk 证明并促进跨链通信。随着Polygon链上的活动增加，Polygon原生代币的价值也会增加。
开发Rollup应用程序必然会遇到开发摩擦并做出权衡。因此，一个能够代表用户管理所有这些功能和流程的中介至关重要。这包括增值功能，例如各种SDK 中包含的虚拟机、版本控制、多种汇总类型和MEV 保护。此外，该中介在构建应用程序Rollup 时协助做出更好的权衡决策将是有益的。到目前为止，RaaS已经能够履行这个角色。在评估一个好的RaaS 时，所提供的虚拟机(VM) 的多样性比其他服务更重要。在提供任何附加功能之前，RaaS 应优先考虑其作为虚拟机即服务提供商的角色。
本站声明：网站内容来源于互联网。如有侵权，请联系我们，我们将及时处理。
