- ZK-Rollups process multiple transactions off-chain, submitting a single proof to the main Ethereum network, thereby increasing throughput.
- This approach significantly reduces transaction costs, making Ethereum more accessible and efficient for users.
- By preserving security and decentralization, ZK-Rollups offer a promising solution to Ethereum's scalability challenges.
Introduction
As CEO of Rather Labs and a blockchain technology enthusiast, I want to share my vision on a crucial topic for the future of Ethereum: scalability. In this article, we'll explore the challenges Ethereum faces in terms of scalability and delve into a promising solution: rollups based on ZK-proofs.
Ethereum's Vision and Current State
Ethereum has established itself as a leading platform for executing transactions, from simple payments to complex decentralized applications (dApps). Its goal is ambitious: to provide access to a global and decentralized platform to all of humanity. To achieve this, Ethereum must overcome the famous blockchain "trilemma": finding the perfect balance between decentralization, security, and scalability.
The core pillars of Ethereum are security, decentralization, and scalability. While Ethereum excels in security and decentralization, scalability remains a challenge. Currently, the network processes between 15 and 20 transactions per second, far from the goal of 100,000 TPS. This limitation has led to periods of extreme network congestion where transaction fees (gas) have exceeded $100 for simple transfers, making the network prohibitively expensive for many users.
A significant milestone in Ethereum's evolution was "The Merge" - the transition from Proof of Work to Proof of Stake in September 2022. While this upgrade primarily focused on reducing energy consumption and improving security, it laid the crucial groundwork for future scalability improvements by preparing the network for sharding and other scaling solutions.
Scalability Challenges
Increasing the number of transactions per second (TPS) is crucial, but it's not the only challenge. The cost associated with each transaction must also be kept under control. The "gas problem" has become particularly acute during periods of high network activity, such as during the DeFi summer of 2020 or the NFT boom of 2021, where users faced fees that made smaller transactions economically unfeasible.
Core Components of Rollup Architecture
Rollups operate on a Layer 2 built on top of the Ethereum mainchain. The rollup architecture involves several key components and smart contracts working together:
Core Components
1. The Bridge Contracts
- L1 Bridge Contract:
- Manages asset deposits and withdrawals between L1 and L2
- Locks assets when they're deposited to L2
- Releases assets when valid withdrawal proofs are submitted
- Maintains a mapping of L1-L2 asset pairs
- L2 Bridge Contract:
- Mirror of the L1 bridge that manages assets on L2
- Mints corresponding L2 tokens when deposits are processed
- Burns L2 tokens when withdrawals are initiated
2. The State Management System
- State Contract:
- Maintains the current state root of the L2 chain
- Stores the Merkle root of all L2 accounts and their states
- Updates state based on validated batch submissions
- Provides functions for state verification
- Merkle Storage:
- Efficient storage system for tracking state changes
- Uses incremental Merkle trees to manage state updates
- Optimizes gas costs for state updates
3. The Sequencer
The sequencer is responsible for:
- Accepting transactions from users
- Ordering transactions
- Creating rollup blocks
- Submitting transaction batches to L1
- Generating validity proofs (in ZK-Rollups)
4. The Verifier System
For ZK-Rollups:
- Verifier Contract:
- Validates ZK-proofs submitted with state updates
- Contains the verification key from trusted setup (for SNARKs)
- Implements proof verification logic
- Guards state updates based on proof validity
For Optimistic Rollups:
- Challenge Contract:
- Manages fraud proof submission and verification
- Implements challenge period logic
- Processes fraud proofs
- Handles dispute resolution
5. Data Availability Layer
- Call Data Publisher:
- Posts compressed transaction data to Ethereum
- Optimizes data formatting for minimal gas costs
- Ensures data availability for state reconstruction
- State Sync:
- Manages synchronization between L1 and L2 states
- Handles state updates and rollbacks
- Maintains consistency between layers
Security Considerations
The architecture implements several security mechanisms:
- Force Transaction Inclusion: Users can submit transactions directly to L1 if sequencer is unavailable
- Emergency Exit: Mechanism to withdraw assets if L2 becomes unavailable
- State Verification: Anyone can verify the L2 state using posted data
- Decentralization Options: Various approaches to sequencer decentralization:
- Rotating sequencer sets
- Proof-of-Stake based selection
- Auction-based sequencing rights
Types of Rollups
Rollups are Layer 2 scaling solutions that process transactions off-chain and post data or proofs to Ethereum Layer 1. They differ primarily in how they ensure transaction validity and where they store transaction data. Here are the main types:
ZK Rollups
These use cryptographic proofs to validate transaction correctness directly on Ethereum.
- Core Mechanism: Generate mathematical proof that all transactions in a batch are valid
- Security Model:
- Immediate finality once proof is verified
- Inherits Ethereum's security guarantees
- Trade-offs:
- Higher computational costs
- More complex implementation
- Faster finality (15-30 mins)
- Examples: StarkNet (STARK proofs), zkSync, Polygon zkEVM (EVM compatible)
Optimistic Rollups
These do NOT use zero-knowledge proofs. Instead, they assume transactions are valid by default and rely on a challenge system for security.
- Core Mechanism: Post transactions to L1, allow time window for fraud challenges
- Security Model:
- Relies on fraud proofs
- Requires at least one honest challenger
- Trade-offs:
- Simpler implementation
- Longer finality period (7 days)
- Lower operational costs
- Examples: Arbitrum, Optimism
Validium
A ZK Rollup variant that keeps transaction data off-chain for higher throughput.
- Core Mechanism: Use validity proofs but store data with trusted committee
- Security Model:
- Relies on data availability committee
- Maintains fast finality of ZK systems
- Trade-offs:
- Highest throughput and lowest costs
- Reduced security vs full rollups
- Best for specific use cases (gaming, trading)
- Examples: StarkEx, DeversiFi, Myria
Leading ZK Rollup Projects
The ZK rollup ecosystem has evolved rapidly, with several projects taking different approaches to achieve Ethereum scaling. While some projects prioritize maximum compatibility with existing Ethereum tools and languages, others have opted for custom implementations that prioritize performance. Each approach has its merits, and the diversity of solutions helps strengthen the overall ecosystem.
The main projects using ZK rollup technology represent different approaches to scaling Ethereum.
- StarkNet stands out for its high performance, using its own Cairo language and STARK proofs, being particularly popular in gaming and DeFi.
- zkSync Era has prioritized developer experience with native EVM compatibility and account abstraction support.
- Polygon zkEVM has achieved full bytecode-level compatibility, focusing on enterprise adoption.
- Scroll distinguishes itself with its native EVM implementation and focus on open-source development tools.
- Other notable projects include Linea, backed by ConsenSys and integrated with MetaMask, and Taiko, which focuses on full decentralization.
Each of these projects has made different trade-offs between performance, compatibility, and security, contributing to a diverse ecosystem of scaling solutions. Most are already running on mainnet, processing real transactions and demonstrating the viability of ZK rollups as a scaling solution for Ethereum.
Challenges and Considerations
Despite their promise, rollups face several significant hurdles. The core technical challenge lies in the complexity of proving systems, particularly for ZK rollups, which require substantial computational overhead and specialized knowledge to implement correctly. This complexity extends to cross-rollup communication, which remains a significant barrier to true ecosystem interoperability.
On the operational front, most rollups still rely on centralized sequencers, creating potential points of failure and trust assumptions. This is compounded by the challenge of liquidity fragmentation across different rollups, which can impact user experience and market efficiency. Additionally, while rollups aim to scale Ethereum, they introduce new UX complexities and learning curves for both developers and users, particularly around bridging assets and understanding different security models.
The Future of Scaling: Danksharding
Proto-Danksharding (EIP-4844)
- Introduced "blob" transactions for cheaper rollup data
- Implemented March 13, 2024 in the Dencun upgrade
- Reduced rollup costs by ~10x
Full Danksharding
Full danksharding represents the next major evolution in Ethereum's scalability roadmap. It builds on EIP-4844's foundations by introducing data sharding and integrating with Proposer-Builder Separation (PBS). This upgrade is expected in 2025-2026 and will further reduce costs while maintaining Ethereum's security guarantees.
Conclusion
Ethereum's scalability journey represents one of the most ambitious technological undertakings in the blockchain space. While challenges remain, the combination of rollups, ZK-proofs, and upcoming innovations like danksharding presents a clear path forward. The success of projects like StarkNet, zkSync, and others demonstrates the viability of these approaches.
As the ecosystem continues to mature, we can expect to see increased adoption of Layer 2 solutions, improved user experiences, and eventually, a truly scalable and accessible Ethereum network capable of serving billions of users. The key will be maintaining the delicate balance between scalability, security, and decentralization while these solutions evolve.