This article understands the emerging hot spot in the blockchain field "application-specific rollup".
Written by:Smrti Lab
Compilation: Modular 101
The original English text was published on March 28, 2023. This article is the first half of the content.
This article comprehensively analyzes the RollApp ecosystem and compares the advantages and disadvantages of four existing solutions.
Too long to be too lazy to read:
- The current application-specific rollup ( RollApp ) ecosystem includes four types : RollApp SDK, Rollup as a Service (RaaS), Rollup-SDK as a Service and Unified Sequencing Network (Unified Sequencing Network).
- RollApp SDK helps developers create personalized RollApps. Usually, RaaS providers use Rollup-SDK to develop services, which eliminates the need to write RollApp deployment and provides a development experience similar to smart contracts.
- Although RaaS is mainly aimed at smart contract developers (2C), there is also a need to aggregate all these different SDKs for developers, which has triggered the emergence of 2B service provider Rollup-SDK as a service.
- Unified sequencing providers specialize in certain features of sequencers, such as decentralization, scalability, and security.
- There are four main types of rollups : settlement rollup, sovereign rollup, basic rollup and embedded rollup. Different RollApp SDKs and RaaS focus on different types of Rollups and have their own trade-offs.
- Current RaaS projects offer a similar degree of customization. The main focus is how well these features are implemented, as well as the speed and stability of deployment.
- Unified interfaces bring modularity . Modularity brings composability and unlocks the potential of various RollApps. Without a unified interface, you may be faced with a bunch of Lego bricks that are incompatible with each other.
- In the market, decentralization of sequencers may require compromises . Instead, more emphasis is placed on the efficient execution of the business model and the ease of launching and customizing the RollApp application, even if the node is not initially decentralized.
Application-specific rollups (i.e. RollApp) are becoming an important topic in the blockchain field. While the idea of “RollApp” is still young at the moment, we have seen several projects emerge in this space over the past year.
In this overview, we would like to highlight and compare some of the different solutions within this specific area, as they are likely to become important factors in the blockchain space in the foreseeable future. Before we dive into these individual solutions, it’s worth discussing how we got here.
Initially, developers can only choose to deploy on existing Layer 1 (L1) chains (such as Ethereum, etc.). While deploying on existing layers provides builders with adequate security guarantees, they lack the scalability features needed to scale to mass users.
To solve this scaling problem, we started to see more and more Rollups appearing, rather than more L1 chains. Rollup provides sufficient scalability while retaining the security of the underlying chain. While this solves some scaling issues, the issue developers now face is customizability.
Each dapp deployed on Ethereum's Layer 2 (L2) shares computing resources with all other dapps in that rollup, which results in intense gas competition for limited block space. In addition to this, dapps also lack customizability as they must follow the same rules of the underlying chain they are deployed on.
Limited block space and lack of customizability have prompted the rise of application-specific blockchains (application chains) . This type of framework was popularized by the Cosmos ecosystem and subsequently adopted by Polygon Superchains, Avalanche Subnets, and others. However, even Appchains have their own drawbacks, such as having to launch their own validator network and be responsible for their own security.
But wouldn't it be better if developers could combine the security benefits of deploying on Rollup with the flexibility of having their own dedicated environment ?
This is exactly what an application-specific Rollup or "RollApp" attempts to achieve. The idea is essentially to combine the security and flexibility borrowed from Rollup with the feature of having your own dedicated environment.
1. RollApp Ecosystem
Currently, there are four main players in the RollApp ecosystem.
RollApps SDK
This is a framework and toolkit for developers to easily build custom RollApps. However, developers need to understand basic blockchain logic to build their own application-specific rollups. Different SDKs focus on different types of rollups, with different validity and fraud proof options. Therefore, it is important for developers to choose an SDK that suits their specific needs.
Rollup as a Service (RaaS)
RaaS refers to Rollup service provider. RaaS providers often build services on top of Rollup-SDK (for example, Caldera uses Op Stack). Rollup deployment requires no code. All nodes/calls are handled by the RaaS operator. For smart contract developers, there is no need to understand the block logic, and the development experience is very similar to the process of developing smart contracts.
Rollup-SDK as a service
Although RaaS is mainly aimed at smart contract developers (2C), there is also a need to integrate various SDKs, thus giving birth to a 2B service provider for developers, namely Rollup-SDK as a service. Currently, there are a limited number of projects focusing on this area. The Modular Cloud team demonstrated this feature in 2022, but their current focus is on building a browser for multiple modular blockchains.
unified sorting network
Although each RaaS or App Rollup SDK may have its own sequencer, there is still a need for a dedicated sequencer provider focused on consensus and security of a decentralized sequencer network. A shared and unified ordering network simplifies the implementation of atomicity and interoperability across different RollApps.
Figure 1. RollApp ecological panorama
2. What are the different types of Rollups?
Rollup is designed to provide scaling benefits to L1. They are composed of different components, including user clients, VMs, sequencers, attestation systems (especially for zk Rollup), one or more memory pools, and bridge contracts on L1.
Although it is controversial whether a rollup should be defined by a bridge contract, we can distinguish between "sovereign" and "settled" rollups based on which chain/layer serves as the source of truth, just like we distinguish between bridge protocols.
Figure 2. Settlement Rollup and Sovereign Rollup
Settlement rollup refers to types that rely on smart contracts on the settlement layer to verify proofs and bridge assets. This smart contract acts as the source of truth for the Rollup chain. In order to protect this bridge smart contract, many Rollup teams (such as Arbitrum and Optimism) hold onto upgrade keys to fix obvious vulnerabilities on Rollup at any time. However, this authority also creates the risk of making random changes to the code without being noticed.
Sovereign Rollup was introduced by Celestia , and Rollup itself operates like a Layer 1 blockchain. The sovereign Rollup itself is the source of truth, not L1. Rollup nodes transmit fraud (validity) proofs through their own P2P network and verify them locally, while only using the underlying chain to store ordered transactions.
Additionally, the sovereign Rollup community can upgrade the chain through hard forks without permission from the base layer. This is beneficial when some malicious behavior occurs and the sovereign rollup wants to reverse it.
Figure 3. Basic Rollup and embedded Rollup
Basic Rollup refers to the Rollup type that uses the L1 node as the sorter. The L1 sorting design can help it inherit the liveness and decentralization of L1, mitigating harmful MEV from centralized or short-term sorters. Currently, there is no SDK or RaaS protocol using the basic Rollup design.
Embedded Rollup means building the Rollup block within L1 itself. On Ethereum, the execution client constructs a block containing a block header and a block body. If we wrap this block into a Rollup block with a (validity/fraud) proof, then other validators don't need to recalculate all transactions, they just need to calculate the state difference and verify the proof.
The idea is very similar to the stateless idea, where only one builder contains the complete state to generate the witness, which can then be verified directly by others without downloading all the state. Currently, Dymension is an embedded Rollup structure, a detailed discussion of this structure will be provided later in this article.
3. Learn more about RollApp SDK solutions
3.1 Rollkit and OP Stack
On February 21 this year, the Celestia team launched Rollkit, a modular Rollup framework that allows developers to freely choose different functions to build their own customized Rollups. A key difference between Rollkit and OP Stack is that Rollkit supports sovereign rollups.
(1) The VM provided by Rollkit may be more flexible than OP Stack
The main benefit of sovereign Rollup is not its ability to fork, but that it allows developers to not have to write Solidity light clients for Rollup.
This can encourage more flexible VM innovation because they are not constrained by the L1 of already processed and settled zk and fraud proofs. In many cases, the underlying settlement layer (such as Ethereum) may not be able to handle it efficiently.
OP Stack aims to alleviate this problem by building its own settlement layer for all Superchains. However, the settlement layer may still be subject to Ethereum's settlement capabilities, which may not be the perfect place for Superchains wishing to settle on other VMs.
Each VM module that wishes to be integrated into the OP Stack must support the Engine API, which is a set of methods implemented by all Ethereum execution clients. The Engine API is currently under development, and not all virtual machines natively support this interface. Therefore, there is still a lot of work to be done to ensure compatibility with a wider range of virtual machines.
(2) VM packaging and language incompatibility may be major challenges when introducing other VMs into Rollkit
However, if Rollkit can achieve a more flexible VM design, why are there not many VMs (such as SolVM, MoveVM) included in Rollkit?
Rollkit provides an ABCI-like client implementation for Rollup. This means that it handles requests and forwards them to its local application instance through the Application Blockchain Interface (ABCI), which was originally introduced by the Cosmos SDK. In other words, ABCI allows blockchain clients and applications to communicate with each other even if they are written in completely different languages.
On the other hand, if a client on the blockchain wants to communicate with an application (such as a VM), then the only way is to call the ABCI method by sending a request.
Therefore, for any application or VM, it must be wrapped into ABCI interface in order to be integrated into Rollkit. This is a complex process, so so far, the only VM wrapped by ABCI is the EVM (Etheremint).
In addition, when developing, it will also bring some other problems. ABCI is designed by Cosmos-SDK. Therefore, most of the tools currently used to build applications on top of ABCI are Golang-specific, which creates difficulties for those who want to bring Fuel or Aptos stacks (written in Rust and other languages) into Rollkit.
The easiest way for Rollkit to communicate with applications using other programming languages is to use socket connections. However, Rollkit currently has no native ability to communicate with applications using sockets, which may limit the speed of migration of other VMs or applications.
On the other hand, OP Stack has its own ABCI-like interface requirements, called Engine API, which is under development. Any VM integrated into OP Stack must be compatible with Engine API.
Figure 4. Rollkit structure
(3) Rollkit can be integrated into non-EVM chains (such as Bitcoin) to inherit its security, but OP Stack cannot
For OP Stack, it must rely on the third-party chain as the settlement layer of other OP Stack chains, which requires deploying the light client or smart contract of the source chain on the settlement layer.
Using non-EVM compatible chains as settlement layers requires each chain to understand and verify the proofs and status of other VM systems. This requires the complex process of building light clients or full clients of each other. However, it is almost impossible to build a light/full client of OP Stack on a chain like Bitcoin, making integration into Bitcoin almost impossible.
However, since sovereign Rollup is proven through its own light client verification, it may be relatively easy to pull data into Bitcoin to use it as a DA layer.
(4) Bitcoin sovereign rollup cannot inherit validity from Bitcoin
Bitcoin Sovereignty Rollup uses Bitcoin as the DA layer and verifies proofs off-chain, but how much security can it inherit from Bitcoin?
Given that it is almost impossible to write a full or light client for a sovereign rollup on Bitcoin. This means that without a trustless bridge to move assets between Bitcoin and its sovereign rollup, interpreting proofs and states from a sovereign rollup is impossible.
Sreeram Kannan provides an excellent framework for evaluating blockchain security. Applying this framework to evaluate the security of Bitcoin's sovereign rollup, we see that reorganization resistance, censorship resistance, and data availability can be inherited from Bitcoin, leaving only validity properties as special challenges.
Figure 5. Security of Bitcoin Sovereign Rollup
Therefore, Bitcoin Sovereign Rollup is not suitable for applications that require native use of BTC, or require the ability to combine other application logic on Bitcoin. However, it may be a good choice for projects that prioritize censorship resistance and resistance to reorganization, such as NFT projects.
However, can Bitcoin be a suitable data availability layer for its sovereign rollup? Taproot witnesses give Bitcoin the ability to include up to 4MB of arbitrary data in each block. While the cost of storing sovereign Rollup data still needs further discussion, according to Taproot founder Eric Wall, it could be 7 times cheaper than Ethereum on a byte basis.
3.2 ZK Sovereign SDK and ZK Settlement Rollup
ZK rollup should have faster finalization time than optimistic rollup, but due to the high cost of verifying proofs, ZK rollup still suffers from longer finalization time.
The cost of verifying a single proof in Ethereum rollup may range from 300,000 to 5 million gas, depending on the underlying proof system. However, the size of the proof grows slowly with the number of transactions. Therefore, rollup often chooses to wait and accumulate batches of transactions to amortize the proof verification cost of each transaction.
The main reason for the long finalization time of zk in the current zk settlement rollup is the delay in cost reduction. However, by using and trusting a centralized orderer, the ZK settlement rollup can achieve faster "soft finality".
From this perspective, the Sovereign SDK offers the unique advantage of enabling fast and “true” finalization by reducing verification costs. Nodes in a sovereign rollup can create proofs in real time and later use recursion to aggregate them into a batch of proofs. Additionally, sovereign rollups require no additional on-chain verification costs, which eliminates the additional waiting time required to amortize transaction costs.
Again, finalization is still limited by the DA and consensus layers, but delays due to the high cost of proof verification can be greatly reduced.
3.3 Embedded Rollup (Dymension)
As mentioned above, embedded rollup means building the rollup block within L1 itself. In Ethereum, the execution client constructs blocks containing block headers and bodies. If we wrap this block as a rollup block with proof (zk/fraud), other validators do not need to recompute all transactions. Instead, they simply compute the state difference and verify the proof.
This can yield several advantages:
- No re-execution is required and is particularly suitable for state witness solutions. This can also speed up the node synchronization process due to light historical load.
- Almost all values will go directly to L1 - Dymension Hub.
- There is no need to build bridge contracts at the settlement layer, enabling smaller latency and faster finalization.
Incorporating inline rollup into Ethereum is difficult, which is why projects like Dymension choose to build within the Cosmos ecosystem.
However, the biggest potential problem with the embedded rollup SDK is its lack of flexibility and sovereignty. The basic logic of block production, proof verification, and rollup types is "embedded" in the settlement layer and cannot be freely modified or "Legoized" by developers.
Therefore, an embedded Rollup SDK (such as Dymension) is tightly connected to its settlement layer, making it difficult to freely modify each module of Rollup like Rollkit or Sovereign SDK.
3.4 What are the key features of the Rollup SDK?
Modularity promotes composability. For example, the modular SDK can be customized and implemented for different uses, from DEX to game projects requiring high TPS, by combining various modules, from execution environments to proof solutions. The more specific development modules that can be smoothly integrated into the same SDK, the higher the composability, which in turn significantly lowers the barrier to use.
However, modularity also requires unified interfaces. Having standard interfaces will make it easier to replace components. On the contrary, different interfaces may lead to fragmentation of the application rollup ecosystem. In the absence of a unified interface, there is a risk of ending up with LEGO sets that are incompatible with each other. Unified interfaces will bring modularity. Modularity in turn brings composability, unlocking potential for numerous application rollups.
Figure 6. Modularity and composability
