Rollups and Data Availability (1): Understanding the Trade-offs
Note to readers: This article is an English adaptation of my original Chinese piece on Rollups and Data Availability written in 2022. I've translated, restructured, and expanded the content to make these complex technical concepts more accessible to a broader audience while preserving the technical accuracy of the original work. The core insights about the trade-offs between security, cost, and trust in Layer 2 scaling solutions remain the foundation of both versions.
TL;DR
Rollups solve blockchain scaling by processing transactions off-chain while posting data on-chain for security. Different Rollup technologies (ZK and Optimistic) offer various trade-offs between data availability and cost. Solutions like Validium and Volition provide flexibility but introduce different trust assumptions that users must understand before committing their assets.
This article explores the relationship between data availability and Rollups, examining how these Layer 2 (L2) scaling solutions can strategically balance data availability against transaction costs while maintaining acceptable security.
Before diving in: Readers should understand the basics of Rollups (L2 solutions that process transactions off the main blockchain) and Data Availability (the guarantee that transaction data remains accessible to network participants).
The Evolution of Scaling Solutions
To understand Rollups, it helps to view them as part of an evolutionary path of blockchain scaling solutions. Each evolution addresses specific problems encountered in previous approaches.
Sidechain: The Centralized Approach
A Sidechain operates under a centralized entity (the operator) through a straightforward process:
Users transfer funds on the main chain (Layer 1 or L1) to the operator
The operator mints corresponding tokens for users on the Sidechain
Users enjoy high-speed, low-cost transactions on the Sidechain
When finished, users transfer tokens back to the operator (on the Sidechain)
The operator unlocks the corresponding funds for users on L1
Primary Disadvantage: The operator has complete control over all funds. If they act dishonestly and refuse to return funds to users on L1, users have no recourse or protection.
Plasma: Adding Smart Contract Protection
Plasma improves upon Sidechains by replacing the operator's absolute power with smart contracts. Users can prove their ownership of funds directly to the smart contract to exit the Plasma chain without requiring the operator's permission.
How Fund Ownership Works: Users provide a Merkle Proof confirming their assets (e.g., proving they have 100 tokens in the State Merkle Tree of the chain). This constitutes objective evidence that doesn't require judgment from any centralized entity.
Key Operational Detail: The Plasma operator periodically submits block headers (but not full block content) to L1. The actual transaction data remains with the operator, and network participants must request this data from the operator as needed.
Primary Disadvantage: While the operator cannot directly steal users' funds, they can hide transaction data. This prevents others from validating transactions and verifying the correctness of the resulting state. When users discover the operator is hiding data (a situation called "Data Unavailable"), they can provide proof to the L1 Plasma contract to exit the chain.
Rollup: Ensuring Data Availability
Rollups solve the Plasma problem with a straightforward approach: they upload all transaction data directly to L1. This ensures:
All network participants can see all transactions (achieving "Data Availability")
Anyone can independently calculate the latest state (e.g., Alice has 100 tokens, Bob has 50 tokens)
Key Innovation: Rollups solve the data availability problem, eliminating the concern that users can only exit when operators misbehave. They minimize trust requirements for centralized entities.
Trade-off: This security comes at a cost—the expense of uploading and storing data on L1. This represents the main cost component for Rollups.
Understanding Data Availability
Data availability refers to the guarantee that all transaction data is accessible to network participants who need to verify the blockchain state. This concept becomes particularly important in scaling solutions where not all nodes store all data.
Key Data Availability Challenges:
When your node doesn't maintain complete chain data (as in Plasma or Sharding), data availability becomes a critical concern
There's an unavoidable trade-off between data availability and storage costs:
Storing all data yourself ensures data availability, minimizes trust, and enhances security, but increases storage costs
Delegating data storage to third parties reduces costs but sacrifices security and introduces trust requirements
This fundamental trade-off leads to the central question of this article: how can Rollups balance data availability and cost?
Rollups and the Data Availability Dilemma
Rollups must upload transaction data to L1 to solve the data availability problem, incurring significant storage costs. This raises an important question: can Rollups make strategic concessions in data availability to reduce these costs while maintaining acceptable security?
The answer depends on the type of Rollup technology being used.
Sacrificing data availability comes at a cost—you must trust a third party to store and provide your data when needed.
ZK Rollups and Data Availability Options
Zero-Knowledge (ZK) Rollups are particularly well-suited for making data availability trade-offs because of their inherent security model.
Why ZK Rollups Can Be Flexible with Data
The security of ZK Rollups is guaranteed by cryptographic zero-knowledge proofs. These mathematical proofs verify the correctness of state transitions without revealing the underlying data. This means whether or not all transaction data is uploaded to L1 doesn't affect the correctness of the state.
The Hidden Cost of Not Uploading Data
If ZK Rollups have this advantage, why do most still upload data to L1? The answer reveals an important trade-off: sacrificing data availability introduces a new trust requirement—you must trust a third party to store and provide your data when needed.
If the third party storing ZK Rollup data disappears or withholds data, users face a significant problem. While their assets remain safe and the state remains correct (thanks to zero-knowledge proofs), users cannot derive the latest state and generate the Merkle proofs needed to demonstrate their ownership to the L1 contract. This effectively means they cannot exit the Rollup and access their assets on L1.
This data availability trade-off has led to the development of specialized solutions in the ZK Rollup ecosystem.
Validium: Off-Chain Data Storage
Validium represents a variation on ZK Rollup architecture where all transaction data is stored off-chain. In this model:
Solutions that upload data to L1 are called "Rollups"
Solutions that entrust data to third parties are called "Validium"
In Starkware's StarkEx implementation, data is stored by a group of nodes called the Data Availability Committee (DAC), which is responsible for maintaining and providing data when needed.
Volition: User Choice for Data Storage
Taking flexibility a step further, Volition represents a hybrid approach that allows users to decide for each transaction whether their data should be:
Uploaded to L1 (higher security, higher cost)
Stored off-chain by a third party (lower security, lower cost)
This user-choice model provides flexibility based on individual security needs and cost considerations.
StarkEx has supported all three modes (Rollup/Validium/Volition) since version v4.5, allowing projects to implement the approach that best suits their specific needs.
zkSync's zkPorter: Another Hybrid Approach
zkPorter: a breakthrough in L2 scaling
zkSync's zkPorter design follows a similar hybrid model to Volition, supporting both full Rollup (on-chain data) and Validium-like (off-chain data) approaches within a single system.
Update: ZKsync has now taken the idea further and turn it into a network of chains - Elastic Chain.
Optimistic Rollups and Data Availability Challenges
Optimistic Rollups face a different set of constraints when considering data availability trade-offs.
Update: L2Beat has termed “Optimistic Rollup but publish data to somewhere else other than L1” as “Optimium”.
The Fundamental Challenge
Unlike ZK Rollups, Optimistic Rollups cannot easily make data availability concessions because their security model depends on a different mechanism. Optimistic Rollups rely on fraud proof challenge mechanisms to ensure correctness, and successful challenges require access to complete transaction data.
The Security Risk
When Optimistic Rollups choose not to upload all data to L1, they introduce a critical security vulnerability: If the third party storing data disappears or withholds data, no one can successfully initiate fraud proof challenges. This creates a scenario where:
Attacker (or basically anyone) could claim ownership of all funds on the Rollup
Without transaction data, no one can generate a fraud proof to challenge the false claim
After the challenge period expires, the attacker could withdraw all funds to L1
Despite these risks, several projects have experimented with modified Optimistic Rollup designs that make data availability trade-offs.
Case Studies in Data Availability Trade-offs in Optimistic Rollup
Case Study 1: MetisDAO
MetisDAO takes a straightforward approach by entrusting transaction data to a decentralized file storage system called MEMO.
Security Risk: If MEMO experiences an outage or data loss, MetisDAO would be vulnerable to the attack scenario described above. Without transaction data, no one could challenge fraudulent claims about the state.
For a detailed security analysis of MetisDAO, see: https://l2beat.com/projects/metis/
Case Study 2: Arbitrum AnyTrust
Arbitrum AnyTrust introduces a more sophisticated approach. Built on top of Arbitrum's standard Rollup, it adds a "trust mode" that:
Uses the "Honest Minority" trust assumption
Provides lower costs and eliminates challenge periods
Stores data with a Committee of N nodes
Uploads Committee member signatures to L1 instead of full transaction data
Requires signatures from at least N-1 Committee members
Security Model: AnyTrust operates on the "Honest Minority" assumption, requiring only 2 honest nodes among N nodes (not a majority). When L1 receives N-1 signatures, it guarantees at least one honest node has verified and signed off on the data, providing a minimal security guarantee.
User Experience Benefits:
Lower transaction costs by not uploading full data to L1
No challenge period, as the Committee's honest nodes are trusted to challenge any problematic states immediately
Fallback Mechanism: If honest nodes consistently refuse to sign (possibly because they cannot access or verify data), AnyTrust can switch to full Rollup mode, uploading all transaction data to L1.
Important Security Note: Despite the fallback capability, AnyTrust is not as secure as a standard Rollup—it introduces the Honest Minority trust assumption. If this assumption is violated, the security of the chain is compromised.
Arbitrum launched the AnyTrust implementation as "Arbitrum Nova" in 2022.
For a detailed security analysis of Nova, see: https://l2beat.com/projects/nova/
Case Study 3: Celestium
Celestium follows a similar model to Arbitrum AnyTrust but with a critical difference: transaction data is stored on the Celestia blockchain instead of with a committee, with data availability guaranteed by Celestia's validator nodes.
The DA Bridge contract verifies signatures from Celestia validators, similar to how Arbitrum AnyTrust verifies Committee signatures.
Key Differences from AnyTrust:
Celestium doesn't support fallback to Rollup mode
It doesn't implement the no-challenge-period feature
Conclusion: Navigating the Trade-offs
All approaches to scaling blockchains through Rollups involve trade-offs. When considering solutions that entrust data to third parties to reduce costs, users and developers must be aware of the inevitable compromises:
For ZK Rollup-based Solutions:
Key Benefit: State correctness remains guaranteed through cryptographic proofs
Primary Risk: If the third party storing data disappears, user assets remain safe and intact, but users cannot exit the Rollup to access their assets on L1
Best Use Case: Applications where lower transaction costs are essential, and users can accept some exit risk
For Optimistic Rollup-based Solutions:
Additional Risks: These solutions require significant security concessions, including:
Complete trust in third-party data providers (like MEMO)
Trust in a group of nodes with various trust assumptions:
Honest Minority assumption (Arbitrum AnyTrust)
Honest Majority assumption (Celestium)
Best Use Case: Applications willing to accept more security risk for better performance and lower costs
Key Takeaway
The blockchain scaling ecosystem is evolving toward more flexible models where users and developers can choose their own balance between security and cost.
Before using any of these solutions, users should carefully assess:
Their risk tolerance
The value of assets they'll commit to the system
Their need for guaranteed exit capabilities
How much they trust the entities maintaining data availability
As the technology matures, we'll likely see further innovations in balancing these trade-offs, potentially leading to solutions that provide both high security and low cost.