13 min read

Overview

This guide is designed to help developers and enterprises navigate the complex landscape of rollup frameworks. With the rise of Layer 2 (L2) solutions, launching your own rollup has become an attractive option for scalability, security, and cost efficiency.

In this guide, we will explore and compare four popular rollup stacks: OP Stack, ZK Stack, Arbitrum Orbit, and Polygon CDK. Our goal is to provide you with a clear understanding of each framework's strengths, weaknesses, and unique features.

Whether you're a blockchain developer looking to launch your own rollup or a company exploring Layer 2 solutions for your blockchain application, this guide will serve as a valuable resource in your decision-making process.

Understanding Layer 2 and Rollups

What are Layer 2 Solutions?

Layer 2 (L2) solutions are protocols built on top of existing blockchain networks (Layer 1) to improve their scalability and efficiency. These solutions process transactions off the main chain while inheriting the security guarantees of the underlying blockchain.

The primary goal of L2 solutions is to address the scalability trilemma faced by many blockchain networks, which involves balancing scalability, security, and decentralization.

Rollups Explained

Rollups, a specific type of Layer 2 solution, bundle or "roll up" multiple transactions into a single batch, which is then submitted to Layer 1 blockchain. This approach significantly reduces transaction costs and increases throughput while maintaining the security of the underlying Layer 1.

Rollups achieve this security by posting transaction data back to the Layer 1 (such as Ethereum), where it is validated and stored. This allows rollups to derive their security from the Layer 1's consensus mechanism while offloading the execution of transactions, leading to cheaper and more efficient processing. For a deeper dive into rollups, check out our Ethereum Rollups guide.

Types of Rollups: Optimistic vs. ZK

There are two main types of rollups: Zero-Knowledge (ZK) rollups and Optimistic rollups. Both aim to increase scalability, but they differ in their approach to ensuring the validity of transactions.

Optimistic Rollups

Optimistic rollups assume that all transactions are valid by default, allowing for faster processing times. However, they include a challenge period during which anyone can dispute the validity of a transaction, introducing a delay before finality.

This challenge period typically lasts between 1 and 7 days, depending on the specific implementation. Some projects may adjust this duration based on security requirements or user preferences for faster finality. For example, Optimism has a standard 7-day challenge period, while other rollup implementations may opt for shorter or longer durations.

During the challenge period, "challengers" (the selection of challengers depends on the Layer2 implementation) can submit fraud proofs if they suspect a fraudulent transaction. If the challenge is successful, the transaction is re-executed on Layer 1 to validate its legitimacy. To discourage invalid disputes, challengers must stake a bond, as do the parties submitting transactions. If the transaction is deemed fraudulent, the submitter’s bond is slashed, creating a financial incentive to ensure valid transactions.

Optimistic Rollups - Permissionless Fault Proofs (Image source)

As a summary;

• Optimistic rollups assume transactions are valid by default and only run computations in case of disputes.
• Optimistic rollups have a "challenge period" where transactions can be disputed before finalization.
• The selection of challengers depends on the L2 protocol; for example, anyone can be a challenger on OP Mainnet (Optimism), while Arbitrum uses a whitelist of actors for fraud proofs.
• It is typically easier to implement and more compatible with existing Ethereum tools.

Examples of Optimistic Rollups: OP Mainnet (Optimism), Arbitrum, Base, Blast

For more detailed insights and a list of projects using Optimistic Rollups, visit L2Beat.

Zero-Knowledge (ZK) Rollups

ZK rollups use cryptographic proofs to verify the validity of transactions offchain, which are then submitted to Layer 1. This approach provides faster finality without the need for a challenge period but requires more complex computation.

• Use cryptographic proofs (i.e., ZK-SNARKs) to validate transactions.
• Provide near-instant finality once the proof is verified on the main chain.
• Generally offer higher throughput but can be more complex to implement.

Examples of ZK Rollups: ZKsync Era, Scroll, Linea, Starknet

For more examples of ZK Rollups, visit L2Beat.

Key Components: Settlement, Data Availability, Consensus, and Execution Layers

Now that we've covered the basics of rollups, let's dive deeper into the key components that make up a rollup architecture. Let's explore these components and their roles in the rollup ecosystem:

Data Availability (DA) Layer

• This layer is responsible for storing transaction data and making it available for verification.
• Data can be stored onchain (Layer 1) or offchain (using separate data availability solutions such as Celestia).
• It's critical for enabling anyone to reconstruct the state of the rollup and ensure its integrity.
• The data availability layer often involves data compression techniques, calldata optimization, and potentially separate DA networks.

Onchain vs. OffChain Data Availability

Onchain (Layer 1): Storing data on Layer 1 provides the highest level of security, as the data inherits the security guarantees of the base layer (Ethereum). However, it can be expensive due to high costs associated with storing data directly onchain. The introduction of blob storage (EIP-4844) has improved scalability and reduced costs, making onchain storage more efficient for rollups.

Offchain: Offchain solutions, offer more cost-effective and scalable options by moving data storage outside of Layer 1. This allows rollups to handle a higher volume of transactions at a lower cost. The downside is that offchain solutions may not always provide the same level of security as onchain storage, although they often use robust verification methods to ensure data integrity.

Consensus Layer

• This layer determines how nodes agree on the state of the rollup.
• It can vary between frameworks (e.g., single sequencer, multi-party computation, etc.).
• The consensus layer significantly impacts the decentralization and security properties of the rollup.
• It often involves sequencer selection mechanisms, leader election algorithms, or threshold signature schemes.

Settlement Layer

• This is the blockchain where the final state of the rollup is settled and secured, typically the Layer 1 chain (e.g., Ethereum mainnet).
• It ensures the security and finality of transactions processed on the rollup by verifying and arbitrating proofs (fraud proofs for Optimistic rollups, validity proofs for ZK rollups).
• The settlement layer involves smart contracts on the L1 that manage state roots, handle deposits/withdrawals, and process fraud proofs or validity proofs.

Execution Layer

• This is where transactions are actually processed, and state changes occur.
• It typically involves a Virtual Machine (VM) environment (e.g., EVM, zkEVM, AVM).
• The execution layer determines the computational environment and smart contract capabilities of the rollup.

Key Considerations for Launching a Rollup

Before we dive into chain and rollup frameworks, it's crucial to understand some key concepts and challenges you might face when launching and operating a rollup.

Rollup Maturity Stages

Rollups typically go through several stages of maturity, often referred to as "training wheels" stages. These stages reflect the level of decentralization and the extent of control retained by the developers.

1. Full Training Wheels (Stage 0):

• High centralization with developers having significant control.
• Ability to upgrade systems quickly without governance.
• Useful for rapid iterations and bug fixes.
• Higher centralization risks.

2. Limited Training Wheels (Stage 1):

• Partial decentralization with some developer control.
• Upgrades may require time delays or multi-sig approvals.
• Balance between flexibility and decentralization.

3. No Training Wheels (Stage 2):

• Full decentralization with community governance.
• All major decisions and upgrades decided by token holders.
• Highest level of decentralization but slower to implement changes.

Rollup Stages on L2Beat.com

Exit Windows and Withdrawal Periods

Exit windows are a critical security feature in rollup systems. They refer to the amount of time users have to withdraw their assets from the rollup to the main chain before a potentially unwanted upgrade takes effect. This concept is crucial for user protection and system integrity.

Withdrawal periods refer to the period during which users can withdraw their assets from a rollup to the main chain. This is particularly longer for Optimistic rollups due to their challenge period compared to ZK rollups.

Common Operational Challenges

When operating a rollup, several challenges can arise that test the system's resilience and decentralization. Understanding these challenges and how different frameworks address them is crucial for maintaining a secure and efficient rollup.

Let's explore two common challenges: sequencer failures and proposer failures.

Sequencer Failures

Sequencers are responsible for ordering transactions within a rollup. A sequencer failure can potentially halt or delay transaction processing.

Different frameworks handle sequencer failures in various ways:

L1 Queue Submission:

• Users can submit transactions to a queue on the Layer 1 (L1) blockchain.
• The sequencer processes this queue, ensuring transactions are included even if delayed.
• In some implementations, the sequencer cannot selectively skip transactions but may stop processing the entire queue.

Self-Sequencing with Delay:

• Users can force transaction inclusion by submitting them directly to L1.
• This often involves a delay (e.g., 24 hours) to allow the primary sequencer to recover.
• Balances security with the need for timely transaction processing.

No Immediate Mechanism:

• Some frameworks may not have an active mechanism for users to bypass a failed sequencer.
• This approach relies on the sequencer's reliability but may lead to temporary system halts if the sequencer fails.

Decentralized Sequencer Pool:

• Multiple backup sequencers can take over if the primary fails.
• Enhances decentralization and resilience but may increase complexity.

Proposer Failures

Proposers submit state updates from the rollup to the L1 chain. Proposer failures can delay finality and affect withdrawals.

Frameworks handle proposer failures in different ways:

Whitelisted Proposers Only:

• Only pre-approved proposers can publish state roots on L1.
• If all fail, it may freeze withdrawals until resolved.
• Provides control but at the cost of centralization.

Self-Propose with Delay:

• After a set period of inactivity (e.g., 12 days), anyone can become a proposer.
• Balances the need for reliable known proposers with a fallback for resilience.

Open Proving with Delay:

• Users can submit proofs to the L1 bridge after a delay.
• May involve separate delays for proving and finalizing states.
• Provides a decentralized fallback but with potential time constraints.

Multiple Backup Proposers:

• Several entities are authorized to act as proposers.
• If one fails, others can step in, enhancing resilience.

Understanding these approaches helps in choosing a framework that aligns with your project's goals for decentralization, security, and operational efficiency.

Introduction to Chain Frameworks

In the context of blockchain development, a chain framework or stack refers to a set of software components, tools, and protocols that work together to create a functional blockchain network or, in this case, a rollup solution.

Chain frameworks serve several important purposes:

• Standardization: They provide a consistent set of tools and interfaces, making it easier for developers to build and deploy applications.
• Modularity: Frameworks often have a modular design, allowing developers to customize or replace specific components as needed.
• Abstraction: They abstract away much of the underlying complexity of blockchain systems, enabling developers to focus on building applications rather than reinventing core functionalities.
• Ecosystem Support: Frameworks often come with extensive documentation, community support, and additional tools that facilitate development and deployment.
• Interoperability: Many frameworks are designed with interoperability in mind, making it easier to connect with other blockchain networks or Layer 1 solutions.

In the context of rollups, chain frameworks provide the necessary components to create, deploy, and operate a Layer 2 solution. This includes tools for transaction processing, state management, proof generation (for ZK rollups), fraud proof systems (for Optimistic rollups), and interfaces with the underlying Layer 1 blockchain.

The choice of framework can significantly impact various aspects of your rollup, including:

• Performance and scalability
• Security model
• Developer experience
• Compatibility with existing tools and applications
• Customizability and flexibility
• Community support and ecosystem growth

As we explore the four main rollup frameworks (OP Stack, ZK Stack, Arbitrum Orbit, and Polygon CDK), we'll examine what features they provide to developers.

Detailed Analysis of Rollup Frameworks

OP Stack

The OP Stack, developed by Optimism, is an open-source framework for building optimistic rollups. It's designed to be modular and customizable, allowing developers to create their own Layer 2 (L2) and Layer 3 (L3) solutions with varying degrees of similarity to the Optimism mainnet.

Key Features:

• Optimistic rollup architecture
• EVM equivalence for seamless Ethereum compatibility
• Modular design allowing customization of various components
• Fault proof system for transaction verification
• Superchain concept for interconnected L2 chains
• Custom native gas token supported

Superchain

The Superchain is OP Stack's vision for a network of standardized L2 chains (OP Chains) that share security, communication protocols, and core technology. This approach aims to create a unified layer of interoperable chains, allowing developers to build applications that can seamlessly operate across multiple chains within the ecosystem.

Architecture:

• Consensus Layer / Transaction Sequencing: Uses a single-sequencer model (using multiple-sequencer model option is possible with customization)
• Data Availability: Onchain data posting to Ethereum (using other EVM or non-EVM chains as DA is possible with customization)
• Execution Layer: EVM-equivalent environment
• Settlement Layer: Ethereum mainnet (settlement mechanisms on multiple external chains are possible with customization)

ZK Stack

The ZK Stack, developed by Matter Labs, is a framework for building ZK rollups (L2s and L3s). It's the technology behind ZKsync, one of the leading ZK rollup solutions in the Ethereum ecosystem.

Key Features:

• Zero-knowledge rollup architecture
• LLVM-based zkEVM for high EVM compatibility
• Account abstraction built-in
• Hyperscalability through recursive proofs
• Native token bridging
• Custom native gas token supported
• Elastic Chain Architecture for scalable, interconnected ZK rollups

ZKsync Elastic Chain

The Elastic Chain Architecture is ZK Stack's approach to creating a scalable network of interconnected ZK rollups. It consists of three main components:

• ZK Router: Smart contracts on Ethereum that manage the overall network state and shared liquidity.
• ZK Gateway: Middleware that facilitates interoperability between ZK Chains and optimizes interactions with Ethereum.
• ZK Chains: Customizable, autonomous rollups that operate independently while remaining interconnected through the ZK Gateway and Ethereum contracts.

This architecture aims to prevent liquidity fragmentation and enable seamless scaling across multiple ZK rollups, all while leveraging the security and efficiency of zero-knowledge proofs.

Architecture:

• Consensus Layer / Transaction Sequencing: Different options (Centralized sequencer, decentralized sequencer, priority queue, or an external protocol)
• Data Availability: Onchain data posting to Ethereum (with other options)
• Execution Layer: zkEVM environment
• Settlement Layer: Ethereum mainnet

ZK Stack Customization - Source

Arbitrum Orbit

Arbitrum Orbit, developed by Offchain Labs, is a framework for creating customizable Layer 2 (L2s) and Layer 3 (L3s) chains built on top of Arbitrum's Layer 2 technology.

Key Features:

• Built on Arbitrum's optimistic rollup technology
• Customizable models (AnyTrust or Rollup)
• Flexible data availability options
• Custom native gas token supported
• Stylus that Allows developers to write smart contracts in popular programming languages like Rust, C, C++, and any language that compiles to WASM.

Arbitrum Orbit - Stylus (Image source)

Architecture:

• Consensus Layer / Transaction Sequencing: Customizable (single sequencer or decentralized)
• Data Availability: Onchain data posting to Ethereum or using Arbitrum's AnyTrust protocol
• Execution Layer: Arbitrum Nitro for EVM compatibility and Stylus for WASM-based programming languages.
• Settlement Layer: Arbitrum (Layer 2) or Ethereum (Layer 1)

Polygon CDK

Polygon Chain Development Kit (CDK) is a modular framework for building and launching ZK-powered L2 chains or appchains on Ethereum.

Key Features:

• Supports ZK rollup models
• Customizable data availability solutions
• Native gas token support
• AggLayer for interoperability between CDK-built chains

AggLayer

The AggLayer is Polygon's developing interoperability protocol designed to enable seamless communication between chains built with Polygon CDK. It facilitates trustless token transfers and message-passing between different chains. While initially focused on CDK-built chains, the AggLayer aims to eventually support a wide range of blockchain architectures, including L2s, appchains, and non-EVM chains.

Architecture:

• Consensus Layer / Transaction Sequencing: Flexible (single sequencer or decentralized)
• Data Availability: Customizable (onchain, offchain, or hybrid)
• Execution Layer: zkEVM environment
• Settlement Layer: Ethereum mainnet or other supported networks

Polygon CDK Customization - Source

Comparison of Rollup Frameworks

Feature	OP Stack	ZK Stack	Arbitrum Orbit	Polygon CDK
Rollup Type	Optimistic	ZK	Optimistic	ZK
EVM Compatibility	EVM-equivalent	High (zkEVM)	EVM-equivalent	EVM-equivalent
Proof System	Fault proofs	ZK Proofs	Fault proofs	ZK Proofs
Interoperability	Superchain	Elastic Chain Architecture	Arbitrum Orbit	AggLayer
Data Availability	Ethereum, Various DA Layers	Ethereum, Various DA Options	Ethereum, Data Availability Committees (DAC), Celestia, Avail	Ethereum, Data Availability Committees (DAC)
Virtual Machine	EVM	zkEVM	EVM + WASM (Stylus)	Polygon zkEVM
Finality	~7 days	Minutes/Hours	~7 days	Minutes/Hours
Transaction Sequencing	Single sequencer, Multiple sequencer	Centralized sequencer, Decentralized sequencer, Priority queue, External protocol	Centralized sequencer, Decentralized sequencer	Centralized sequencer, Decentralized sequencer
Rollup Maturity Stage [See note below]	Stage 0	Stage 0	Stage 1	Stage 0
Custom Gas Token	Supported	Supported	Supported	Supported
Computation Required	Moderate	High	Moderate	High
Programming Language Support	Solidity	Solidity, Vyper	Solidity, Rust, C, C++, etc.	Solidity, Vyper
TPS (Transaction Per Second) [See note below]	140 TPS	180 TPS	Unknown	5 TPS
Network Layer Flexibility	Supports L2 & L3	Supports L2 & L3	Supports L2 & L3	Supports L2

Note for Rollup Maturity Stage

These maturity stages are obtained from L2Beat and they reflect the specific chains built on these frameworks (e.g., ZKsync Era, Arbitrum One) and may not apply to every rollup created with the framework itself. The level of decentralization and maturity can vary significantly based on how a rollup is customized and implemented.

For details, check here

Note for TPS: AMM TPS Test

TPS data is obtained from an AMM test to measure throughput using token swap transactions on a Uniswap V2-style AMM pool.

It is important to note that these results are specific to ZKsync, OP Mainnet, and Polygon zkEVM, and the maximum TPS of rollup frameworks may vary based on different configurations, network conditions, and optimizations.

Additionally, this test does not include Arbitrum Orbit.

For more details, check out the full study here.

Choosing the Right Framework for Your Rollup

Selecting the appropriate rollup framework depends on various factors specific to your project's needs. Here are some considerations to help guide your decision:

Compatibility Requirements:

• If full EVM compatibility is crucial, OP Stack or Arbitrum Orbit might be preferable.
• For projects willing to adapt to slight differences, ZK Stack offers high EVM compatibility with zkEVM.

Performance and Scalability Needs:

• For the highest theoretical throughput, ZK-based solutions (ZK Stack or Polygon CDK) might be advantageous.
• If low-latency finality is critical, ZK solutions offer faster settlement times.

Security Model Preferences:

• Projects prioritizing simplicity and easier fraud-proof verification might prefer Optimistic rollups (OP Stack or Arbitrum Orbit).
• For enhanced privacy and faster finality, ZK-based solutions are advantageous.

Developer Experience and Existing Skills:

• Teams with strong Ethereum development experience might find OP Stack or Arbitrum Orbit easier to adopt.
• Projects willing to invest in learning new concepts might benefit from the advanced features of ZK Stack or the flexibility of Polygon CDK.

Ecosystem and Community Support:

• Consider the size and activity of each framework's developer community.
• Evaluate the availability of grants, educational resources, and third-party tools.

Future-Proofing and Interoperability:

• Consider each framework's roadmap and plans for future upgrades.
• Evaluate how each solution approaches cross-chain interoperability.

Regulatory Compliance:

• If your project has specific regulatory requirements, consider how each framework's approach to data availability and decentralization aligns with these needs.

Conclusion

The rollup ecosystem is rapidly evolving, with each framework offering unique advantages and trade-offs.

If you're unsure about which framework best suits your needs or if you need assistance in implementing your chosen solution, don't hesitate to contact QuickNode for expert guidance. Our experts can provide tailored advice based on your specific requirements and help you leverage our Rollup-as-a-Service solution to streamline your deployment process.

We ❤️ Feedback!

Let us know if you have any feedback or requests for new topics. We'd love to hear from you.