https://ethresear.ch/t/rollup-as-a-service-opportunities-and-challenges/13051
Rollup as a Service: Opportunities and Challenges
Cosmos and Polkadot adopt the multi-chain structure for their scaling solutions. Their blockchain SDK, Tendermint and Substrate, are applied by many projects to customize blockchains. These blockchains use cross-chain protocols like Cosmos IBC 1, Polkadot XCM, and bridges to interact with each other. However, such protocols are difficult to guarantee high security, which leads to frequent exploit events. As a result, cross-chain protocols did not work as expected, resulting in relative independence between blockchains.
Later, a more secure scaling technology called rollup emerged. Rollup compresses Layer 2 transactions into a “batch”, uploads it to Layer 1, and proves the validity of state transition on Layer 1 through Fraud Proof (Optimistic-rollup) or Validity Proof (ZK-rollup). Since data availability and state validity are verified on Layer 1, rollup obtains the same level of security as Layer 1, ensuring that assets can be safely transferred between Layer 1 and Layer 2.
So far, many rollup projects such as Arbitrum, Optimism, ZkSync, and StarkNet have already been in use. In addition to these universal rollups, there also came up some application-specific rollups, including StarkEx rollup SDK 2-based dYdX (order book DEX) and DeversiFi (AMM DEX), etc. Although the rollup technology is not yet fully developed, and few teams have mastered it, there is still strong demand for this technology on the market.
Universal and application-specific rollups listed at https://l2beat.com/
Rollup provides a standalone execution environment with high TPS, low gas, and access to all assets from Layer 1, which helps applications on the blockchain scale from DeFi to more general fields like games and social networks. We expect rollup will gradually become a sort of service provided to Web3 applications, i.e., Rollup as a Service (Raas). Some projects are now heading in this direction. Ethereum’s rollup-centric roadmap and StarkNet’s Layer 3 architecture both demonstrate an application-specific multi-rollup future.
StarkNet’s architecture described in Fractal Scaling: From L2 to L3. It’s layers all the way down | by StarkWare | StarkWare | Medium 1 , where Layer3 are multiple application-specific rollups.
Rollup still faces the following challenges in providing RaaS.
First of all, let’s talk about the rollup SDK. One can deploy some configuration and launch rollups quickly based on an SDK. The open-source rollups are better choices for SDK development to avoid reinventing the wheel. For Optimistic-rollups, both Arbitrum and Optimism are open-source. From L2beat, we can see that both Metis and Boba are developed on Optimism’s code base. In contrast, ZK-rollups are not very open-source. ZkSync releases complete code for v1 but merely the contract code for v2 (zkEVM enabled). StarkEx releases only the contract code and provides other modules to third parties through a closed source. StartNet provides code solely in Cairo.
Though Optimistic-rollups have more mature codebases and better support for EVM, the inherent characteristics of fraud-proof leave them far behind ZK-rollups in terms of finality and security. A ZK-rollup Layer 2 transaction is finalized immediately after being proved on Layer 1, while an Optimistic-rollup Layer 2 transaction requires several days before the finalization due to the challenge period. On the other hand, Optimistic-rollups need more assumptions for security: at least 1-out-of-N honest operators for fraud-proof submission and a censorship-resistant Layer 1 for fraud-proof acceptance.
In sum, we can quickly build an Optimistic-rollup SDK right now based on the existing open-source code, but a ZK-rollup SDK seems more attractive in the long run. Of course, in addition to the codebase issue, a design of ZKVM, i.e., ZKP-provable smart contracts, is also in urgent need. Currently, a variety of ZKVM solutions are under development. The methods of each solution are still not unified.
As mentioned, batched transactions are required to send to Layer 1 in a rollup, so the TPS of the rollup is limited by Layer 1’s storage space, aka the Data Availability (DA) problem. Ethereum has proposed a series of Layer 1 storage scaling solutions, including EIP-4488, Proto-Danksharding, and the full Danksharding (currently seeking proposals). Besides the scaling for Layer 1, many projects like Celestia and Polygon Avail are also attempting to expand the storage capacity for Layer 2. However, these solutions’ security and ease of use still need further examination.
How the block size will be increased by EIP-4488 and Proto-danksharding in Vitalik’s " Proto-Danksharding FAQ "
In terms of ZK-rollup, the TPS is additionally limited by ZKP calculation speed. Paradigm and 6block have different hardware choices on GPU, FPGA, and ASIC to accelerate the calculation. In addition, 6block compares several software architectures for ZKP distributed computing, including mining pool, proof aggregation, and DIZK. ZPrize, an upcoming competition, also incentivizes developers to find valuable solutions to accelerating ZKP calculation.
Ensuring the high availability of the rollup service is another critical issue. Current rollups on the market are almost centralized, i.e., only specific operators can submit batches and proofs to Layer 1. This is a vulnerable design since the SPOF (single point of failure) will easily lead to service unavailability. Arbitrum has suffered hours of downtime on several occasions due to software bugs and hardware failures. Many projects are working on decentralizing rollups to avoid SPOF, including zkSync, StarkNet, Polygon Hermes, PoVP, and taikocha.in.
A good economic model is under consideration for RaaS. For now, the profits of service providers mainly come from the transaction fee gap between Layer 1 and Layer 2, i.e., charging fees from Layer 2 as the revenue and paying fees to Layer 1 as the costs. Optimism has issued its governance token, but it’s still not a good way to maintain a sustainable income.
Most of the existing rollups are third-party services built on the blockchain, so their primary income is merely from the transaction fee. However, we can get out of this mindset and regard rollups as native services the blockchain provides. Like Cosmos’ and Polkadot’s design, the whole system contains one blockchain and multiple rollups attached to the blockchain, forming a decentralized network with infinite scalability. In this way, the network can reward both Layer 1 blockchain validators and Layer 2 rollup operators with the same native token. This idea is similar to “enshrined rollups 1” proposed by Polynya and is worth further research.
Like the cross-chain protocols in Cosmos and Polkadot, a cross-rollup protocol is necessary when multiple rollups are deployed on one blockchain. Users can also withdraw their assets from Layer 1 and deposit them to another rollup, but the process requires additional fees on Layer 1 and more operation steps. Some third-party cross-rollup bridges leverage liquidity pools to help users transfer between rollups instantly, but these bridges are as vulnerable to exploits as cross-chain bridges.
A future blockchain architecture described by Vitalik in " Endgame 1 ", with multiple rollups and cross-rollup bridges among them
Ideally, the blockchain should provide a native cross-rollup bridge maintained by its validators for security. Moreover, such a bridge should preferably support synchronous message calls from one rollup to another, i.e., a user on one rollup can directly call the contract on another. This will maximize user experience in a multi-rollup architecture. The underlying technology is complicated, but we look forward to its emergence.
This article describes RaaS, i.e., providing rollup services to DApps. Apparently, blockchain will usher in a multi-rollup future for Web3. Anyone can quickly launch their rollup with an SDK and run applications on the rollup with high performance and low costs. After discussing all the possible challenges faced by RaaS, we finally came up with the idea of native rollups, which will help the blockchain reward rollup validators with its native token and provide a cross-rollup bridge maintained by its validators. We plan to study it further carefully and elaborate on it in future articles.
RaaS 机会，从多链到多汇总
Cosmos 和 Polkadot 的扩容解决方案采用多链结构。他们的区块链 SDK、Tendermint 和 Substrate 被许多项目用于定制区块链。这些区块链使用Cosmos IBC等跨链协议 1, Polkadot XCM , 以及相互交互的桥梁。然而，此类协议难以保证高安全性，导致漏洞利用事件频繁发生。结果，跨链协议没有按预期工作，导致区块链之间相对独立。
后来，出现了一种更安全的扩展技术，称为 rollup。Rollup 将 Layer 2 交易压缩成一个“batch”，上传到 Layer 1，并通过欺诈证明（Optimistic-rollup）或有效性证明（ZK-rollup）在 Layer 1 上证明状态转换的有效性。由于在 Layer 1 上验证了数据可用性和状态有效性，因此 Rollup 获得了与 Layer 1 相同级别的安全性，确保资产可以在 Layer 1 和 Layer 2 之间安全传输。
到目前为止，Arbitrum、Optimism、ZkSync 和 StarkNet 等许多汇总项目已经投入使用。除了这些通用汇总之外，还出现了一些**特定于应用程序的汇总，**包括StarkEx 汇总 SDK 2- 基于dYdX（order book DEX）和DeversiFi（AMM DEX）等。虽然rollup技术还没有完全发展起来，掌握的团队也很少，但市场上对这项技术的需求仍然很旺盛。
*https://l2beat.com/中列出的通用和特定于应用程序的汇总*
Rollup 提供了一个独立的执行环境，具有高 TPS、低 gas 和从第 1 层访问所有资产的权限，这有助于区块链上的应用程序从 DeFi 扩展到更通用的领域，如游戏和社交网络。我们预计 Rollup 将逐渐成为一种提供给Web3 应用程序的服务，即Rollup as a Service (Raas)。一些项目现在正朝着这个方向发展。以太坊以汇总为中心的路线图和 StarkNet 的第 3 层架构都展示了特定于应用程序的多汇总未来。
StarkNet 的架构在 Fractal Scaling: From L2 to L3 中描述。层层叠叠 | 通过 StarkWare | 斯塔克软件 | 中等的 1 ，其中 Layer3 是多个特定于应用程序的汇总。
Rollup 在提供 RaaS 方面仍然面临以下挑战。
首先，我们来谈谈rollup SDK。可以基于 SDK 快速部署一些配置和启动汇总。开源汇总是 SDK 开发避免重复发明轮子的更好选择。对于 Optimistic-rollups，Arbitrum 和 Optimism 都是开源的。从 L2beat 可以看出，Metis 和 Boba 都是在 Optimism 的代码库上开发的。相比之下，ZK-rollups 不是很开源。ZkSync 发布了v1的完整代码，但仅发布了 v2 的合约代码（启用了 zkEVM）。StarkEx 仅发布合约代码，并通过封闭源代码向第三方提供其他模块。StartNet 仅在开罗提供代码。
尽管 Optimistic-rollups 拥有更成熟的代码库和对 EVM 更好的支持，但防欺诈的固有特性使其在最终性和安全性方面远远落后于 ZK-rollups。ZK-rollup 第 2 层交易在第 1 层证明后立即完成，而 Optimistic-rollup 第 2 层交易由于挑战期需要几天才能完成。另一方面，Optimistic-rollups 需要更多的安全性假设：至少 N 中的 1 个诚实操作员用于防欺诈提交和一个抗审查的第 1 层用于防欺诈接受。
总而言之，我们现在可以基于现有的开源代码快速构建一个 Optimistic-rollup SDK，但从长远来看，ZK-rollup SDK 似乎更有吸引力。当然，除了代码库问题之外，ZKVM 的设计，即 ZKP 可证明的智能合约，也是急需的。目前，各种 ZKVM 解决方案正在开发中。各个方案的方法还没有统一。
如前所述，批量事务需要在汇总中发送到第 1 层，因此汇总的TPS受到第 1 层的存储空间的限制，即数据可用性(DA) 问题。以太坊提出了一系列 Layer 1 存储扩展方案，包括 EIP-4488、Proto-Danksharding 和完整的 Danksharding（目前正在寻求提案）。除了第 1 层的扩展外，Celestia 和 Polygon Avail 等许多项目也在尝试扩展第 2 层的存储容量。但是，这些解决方案的安全性和易用性仍有待进一步检验。
Vitalik 的“ Proto-Danksharding FAQ ”中的 EIP-4488 和 Proto-danksharding 如何增加块大小
在 ZK-rollup 方面，TPS还受到 ZKP 计算速度的限制。Paradigm 和 6block 在 GPU、FPGA 和 ASIC 上有不同的硬件选择来加速计算。此外，6block 比较了 ZKP 分布式计算的几种软件架构，包括矿池、证明聚合和 DIZK。ZPrize是一项即将到来的竞赛，它也激励开发者寻找有价值的解决方案来加速 ZKP 计算。
确保汇总服务的高可用性是另一个关键问题。目前市场上的 rollup 几乎是中心化的，即只有特定的运营商可以向 Layer 1 提交批次和证明。这是一个易受攻击的设计，因为 SPOF（单点故障）很容易导致服务不可用。由于软件错误和硬件故障，Arbitrum 曾多次遭受数小时的停机。许多项目正在致力于分散汇总以避免 SPOF，包括zkSync、StarkNet、Polygon Hermes、PoVP和taikocha.in。
RaaS 正在考虑**一个好的经济模型。**目前，服务商的利润主要来自Layer 1和Layer 2之间的交易费用差距，即从Layer 2收取费用作为收入，向Layer 1支付费用作为成本。Optimism 已经发行了它的治理代币，但这仍然不是维持可持续收入的好方法。
现有的 rollup 大部分是建立在区块链上的第三方服务，因此它们的主要收入仅来自交易费用。但是，我们可以摆脱这种心态，将汇总视为区块链提供的原生服务。与 Cosmos 和 Polkadot 的设计一样，整个系统包含一个区块链和多个附加在区块链上的 rollup，形成一个具有无限可扩展性的去中心化网络。通过这种方式，网络可以使用相同的原生代币奖励第 1 层区块链验证者和第 2 层汇总运营商。这个想法类似于“神圣的汇总 1”由 Polynya 提出，值得进一步研究。
与 Cosmos 和 Polkadot 中的跨链协议一样，当在一个区块链上部署多个汇总时，交叉汇总 **协议是必要的。**用户还可以从 Layer 1 提取资产并将其存入另一个 rollup，但该过程需要 Layer 1 的额外费用和更多操作步骤。一些第三方跨链桥利用流动性池来帮助用户在汇总之间即时转移，但这些桥与跨链桥一样容易受到攻击。
Vitalik 在“ Endgame ”中描述的未来区块链架构 1 "，其中有多个 rollup 和 cross-rollup 桥
理想情况下，区块链应该提供一个由其验证者维护的**本地交叉汇总桥以确保安全。**此外，这样的桥最好支持从一个 rollup 到另一个 rollup 的同步消息调用，即一个 rollup 上的用户可以直接调用另一个 rollup 上的合约。这将最大限度地提高多汇总架构中的用户体验。底层技术复杂，但我们期待它的出现。
本文介绍RaaS，即为DApps提供汇总服务。显然，区块链将迎来 Web3 的多汇总未来。任何人都可以使用 SDK 快速启动他们的汇总，并以高性能和低成本在汇总上运行应用程序。在讨论了 RaaS 可能面临的所有挑战之后，我们最终提出了原生rollup 的想法，这将有助于区块链以其原生代币奖励 rollup 验证者，并提供由其验证者维护的交叉汇总桥梁。我们计划进一步仔细研究它，并在以后的文章中详细阐述。