ZK Rollups Explained: A Comprehensive Guide and Technical Comparison
Why ZK Rollups Exist, How They Work, and Why They Matter
Ethereum was never designed to support millions of users simultaneously interacting with complex applications.
That limitation is not a failure — it is a design choice. Ethereum prioritised decentralisation and security, accepting that scalability would need to be solved elsewhere.
ZK rollups are one of the most serious attempts to solve that problem.
They are not an optimisation. They are not a shortcut. They are a fundamental re-architecture of how computation happens on Ethereum.
This article explains ZK rollups from first principles, compares the leading implementations, and separates technical reality from marketing narratives.
The Ethereum Scaling Problem (Revisited Properly)
Ethereum’s base layer processes transactions sequentially. Every node re-executes every transaction. This provides extremely strong security guarantees — but it is computationally expensive.
As usage increased, several problems became unavoidable:
-
High transaction fees during demand spikes
-
Limited throughput
-
Poor user experience for everyday interactions
Importantly, Ethereum cannot simply “increase block size” without compromising decentralisation. Larger blocks mean fewer people can run nodes, which centralises the network.
This is the core tension:
-
Security and decentralisation live at Layer 1
-
Scalability and performance must live elsewhere
That “elsewhere” is Layer 2.
What a Rollup Actually Is
A rollup is a Layer 2 system that:
-
Executes transactions off-chain
-
Compresses the results
-
Submits a summary back to Ethereum
-
Uses Ethereum as the final judge of correctness
Ethereum does not re-run every transaction. Instead, it verifies that the result is valid according to predefined rules.
This drastically reduces computation and cost while inheriting Ethereum’s security.
Two Families of Rollups
All modern rollups fall into one of two categories:
Optimistic Rollups
-
Assume transactions are valid by default
-
Allow challenges during a dispute window
-
Rely on fraud proofs
ZK Rollups
-
Prove transactions are valid upfront
-
Use cryptographic validity proofs
-
Require no dispute window
Both approaches work. But they make very different trade-offs.
Why ZK Rollups Are Fundamentally Different
ZK rollups do not rely on economic game theory to detect fraud.
Instead, they rely on mathematical proof.
Each batch of transactions comes with a cryptographic proof that says:
“Given the previous state, these transactions were executed correctly, and this is the new state.”
Ethereum verifies the proof, not the computation itself.
If the proof is valid, the state update is accepted. If not, it is rejected automatically.
There is no waiting period. There is no challenge process. There is no assumption of honesty.
What “Zero-Knowledge” Actually Means Here
Despite the name, ZK rollups are not primarily about privacy.
“Zero-knowledge” refers to a class of cryptographic proofs where one party can prove a statement is true without revealing how it was computed.
In ZK rollups:
-
The prover executes transactions off-chain
-
A succinct proof is generated
-
Ethereum verifies the proof
Ethereum learns only that the computation was correct — not the intermediate steps.
This allows massive compression of computation.
Validity Proofs vs Fraud Proofs
This distinction is central to understanding ZK rollups.
Fraud Proof Model (Optimistic)
-
Transactions are posted
-
Anyone can challenge incorrect execution
-
Security depends on watchers being online
-
Finality is delayed
Validity Proof Model (ZK)
-
Transactions are proven correct immediately
-
Ethereum enforces correctness
-
Finality is fast
-
No honest-watcher assumption
ZK rollups trade complexity in proof generation for stronger security guarantees.
Why ZK Rollups Were Not Possible Earlier
ZK rollups are not new in theory — but they were computationally infeasible until recently.
Key constraints included:
-
Proving was extremely slow
-
Hardware requirements were prohibitive
-
Circuits were hard to design
-
Tooling was immature
Only in the last few years have:
-
Recursive proofs
-
GPU acceleration
-
Improved proving systems
-
Better compilers
Made ZK rollups viable at scale.
This is why they are emerging now — not in 2017 or 2018.
The ZK Rollup Execution Flow (High-Level)
A simplified flow looks like this:
-
Users submit transactions to a ZK rollup
-
Transactions are executed off-chain
-
State transitions are recorded
-
A cryptographic proof is generated
-
The proof + compressed data is posted to Ethereum
-
Ethereum verifies the proof
-
State is finalised
The heavy work happens off-chain, but correctness is enforced on-chain.
Why Proving Is the Hard Part
Generating proofs is orders of magnitude more expensive than verifying them.
This asymmetry is intentional:
-
Provers do the heavy lifting
-
Ethereum does lightweight verification
But it introduces real challenges:
-
Prover performance becomes a bottleneck
-
Hardware requirements are high
-
Prover centralisation risk emerges
Much of ZK rollup innovation focuses on making proving faster and cheaper.
Sequencers, Provers, and the ZK Rollup Stack
A ZK rollup is not a single system —it is a stack.
Key components include:
-
Sequencer – orders transactions
-
Execution engine – runs transactions
-
Prover – generates validity proofs
-
Verifier contract – lives on Ethereum
-
Data availability layer – stores transaction data
Each layer introduces trade-offs in performance, decentralisation, and security.
We will return to this stack in detail in Part Two.
ZK Rollups Are Infrastructure, Not Products
This is a critical framing.
ZK rollups are not consumer-facing apps. They are execution environments.
Most users will never know which ZK rollup they are using — and that is the goal.
If ZK rollups succeed, they disappear into the background.
Why ZK Rollups Are Considered the “Endgame”
Many Ethereum researchers describe ZK rollups as the long-term scaling path because they:
-
Preserve Ethereum’s security model
-
Reduce on-chain computation
-
Enable near-instant finality
-
Scale with hardware improvements
They do not require social coordination or subjective judgement to remain secure.
That makes them unusually robust.
But ZK Rollups Are Not All the Same
This is where most articles fail.
Not all ZK rollups:
-
Use the same proof systems
-
Support the EVM equally
-
Make the same decentralisation trade-offs
-
Optimise for the same use cases
Some prioritise:
-
Developer compatibility
-
Performance
-
Security minimalism
-
Ecosystem integration
Understanding these differences is essential.
Introducing the Major ZK Rollup Projects
The rest of this guide will deeply compare the leading ZK rollup implementations, including:
-
zkSync
-
Starknet
-
Scroll
-
Polygon zkEVM
-
Linea
Each takes a different approach to ZK scaling.
None is “objectively best”.
All represent different points in the design space.
ZK-EVM Compatibility, Proof Systems, and How the Leading Projects Really Differ
If ZK rollups were easy, there would already be one clear winner.
The reason there isn’t comes down to a single, deceptively simple question:
How closely should a ZK rollup replicate Ethereum itself?
Almost every major design decision in ZK rollups flows from how that question is answered.
The ZK-EVM Problem (This Is the Core Challenge)
Ethereum applications are written for the Ethereum Virtual Machine (EVM).
The EVM was never designed to be proven inside zero-knowledge circuits. It relies on:
-
Complex state transitions
-
Dynamic memory access
-
Opcodes that are cheap to execute but expensive to prove
Running EVM logic inside a ZK proof is orders of magnitude harder than running it normally.
So ZK rollups face a trade-off:
-
Recreate Ethereum faithfully (hard, slow, expensive)
-
Modify Ethereum semantics (faster, but less compatible)
This trade-off defines every ZK rollup today.
EVM Compatibility vs EVM Equivalence (Not the Same Thing)
These terms are often used interchangeably. They should not be.
EVM-Compatible
-
Supports Solidity contracts with some changes
-
May require recompilation
-
Certain opcodes behave differently
-
Easier to optimise for ZK proving
EVM-Equivalent
-
Behaves exactly like Ethereum
-
Same opcodes, same gas rules
-
No contract changes required
-
Much harder to prove
EVM equivalence is the gold standard — and one of the hardest goals in blockchain engineering.
Why Full EVM Equivalence Is So Hard
To be EVM-equivalent, a ZK rollup must:
-
Prove every opcode exactly
-
Preserve Ethereum’s gas semantics
-
Match execution edge cases
-
Remain compatible with future Ethereum upgrades
This dramatically increases:
-
Circuit complexity
-
Proof generation time
-
Hardware requirements
Some projects accept this cost. Others deliberately don’t.
The ZK Rollup Stack (In Practice)
Before comparing projects, it helps to understand the core components every ZK rollup must implement:
-
Sequencer
Orders transactions and creates batches -
Execution Engine
Runs transactions and computes state changes -
Prover
Generates cryptographic validity proofs -
Verifier Contract
Lives on Ethereum and checks proofs -
Data Availability Layer
Ensures transaction data is retrievable
Every project makes different trade-offs at each layer.
Project Comparison: Design Philosophies First
Rather than ranking projects, it’s more useful to understand what each is optimising for.
zkSync
Design goal: Developer experience + mass adoption
zkSync focuses on:
-
High-level EVM compatibility
-
Fast onboarding for existing developers
-
Abstracting ZK complexity away
It uses a custom VM designed to feel like Ethereum, even if it isn’t strictly equivalent under the hood.
Trade-off:
Slight deviations from Ethereum semantics in exchange for usability and speed.
Starknet
Design goal: Maximum ZK efficiency and scalability
Starknet takes the boldest approach:
-
It does not run the EVM directly
-
Uses its own VM and language
-
Optimised for ZK proofs from the ground up
This allows:
-
Extremely efficient proving
-
Advanced features like recursion
Trade-off:
Higher learning curve and reduced immediate compatibility with Ethereum tooling.
Scroll
Design goal: Faithful Ethereum replication
Scroll aims for:
-
Deep EVM equivalence
-
Minimal behavioural differences
-
Long-term Ethereum alignment
This approach prioritises correctness over short-term performance.
Trade-off:
Slower proving and higher complexity in exchange for maximal compatibility.
Polygon zkEVM
Design goal: Enterprise-grade EVM compatibility
Polygon zkEVM focuses on:
-
EVM equivalence
-
Integration with existing Ethereum ecosystems
-
Leveraging Polygon’s broader infrastructure
It positions itself as a “drop-in” Ethereum extension.
Trade-off:
Complex circuits and higher prover demands.
Linea
Design goal: Infrastructure reliability and tooling maturity
Linea prioritises:
-
Stability
-
Familiar developer workflows
-
Gradual decentralisation
Rather than pushing theoretical limits, it focuses on operational reliability.
Trade-off:
Less radical innovation, more incremental progress.
Proof Systems: Not All ZK Proofs Are Equal
Under the hood, ZK rollups rely on different proving systems, each with unique characteristics:
-
Proof size
-
Verification cost
-
Proving time
-
Hardware requirements
Some systems optimise for:
-
Faster proving
-
Smaller proofs
-
Recursive composition
These choices directly affect:
-
Transaction latency
-
Cost structure
-
Centralisation pressure
This is one reason comparing rollups purely by TPS is misleading.
Sequencers: The Centralisation Question
Today, most ZK rollups use centralised sequencers.
This allows:
-
Faster execution
-
Simpler architecture
-
Better UX
But it introduces risks:
-
Transaction censorship
-
MEV extraction
-
Single points of failure
Decentralising sequencers is an active area of research — but doing so without harming performance is non-trivial.
Prover Centralisation (The Bigger Issue)
Even if sequencers decentralise, provers may not.
Why?
-
Proving requires specialised hardware
-
Capital costs are high
-
Performance differences matter
This means:
-
Proving may remain concentrated
-
Rollups may rely on a small number of professional operators
This is not fatal — but it is a reality that must be acknowledged.
Data Availability: The Hidden Constraint
ZK rollups still need to post transaction data somewhere.
Today, most rely on Ethereum for data availability.
This ensures:
-
Trust minimisation
-
Security inheritance
But it also:
-
Limits throughput
-
Ties costs to Ethereum gas prices
Future upgrades aim to dramatically expand data availability — a key enabler for ZK rollups at scale.
Developer Reality: Why Adoption Is Slower Than Expected
Despite technical promise, ZK rollups face practical challenges:
-
Tooling maturity
-
Debugging difficulty
-
Long compile times
-
Complex failure modes
These issues are improving, but they explain why:
-
Optimistic rollups saw faster early adoption
-
ZK rollups are a longer-term play
Infrastructure maturity takes time.
Where ZK Rollups Excel Today
ZK rollups are particularly strong for:
-
High-value financial applications
-
Use cases requiring fast finality
-
Systems where correctness matters more than throughput
They are less ideal for:
-
Extremely low-margin microtransactions
-
Rapid prototyping environments
Again, trade-offs — not absolutes.
Why There Is No “Winning” Architecture Yet
Each major ZK rollup answers the same questions differently:
-
How close to Ethereum should we be?
-
How much complexity is acceptable?
-
How fast should we move vs how correct should we be?
These answers reflect different visions of Ethereum’s future.
Real-World Adoption, Risks, and the Long-Term ZK Rollup Landscape
By this point, it should be clear that ZK rollups are not a single technology or philosophy.
They are a family of approaches built around the same cryptographic idea, each making different trade-offs between correctness, performance, compatibility, and decentralisation.
This final section directly compares the leading projects, examines how ZK rollups are actually being used today, and looks ahead to what success realistically looks like over the next several years.
Side-by-Side: How the Major ZK Rollups Compare
Rather than ranking projects, it’s more useful to compare them across dimensions that actually matter.
zkSync
-
Philosophy: Accessibility and mass adoption
-
EVM approach: High-level compatibility via a custom VM
-
Strengths: Developer onboarding, UX focus, fast iteration
-
Trade-offs: Not fully EVM-equivalent, additional abstraction layers
zkSync prioritises growth and usability, betting that most developers value speed and familiarity over perfect equivalence.
Starknet
-
Philosophy: ZK-native scalability
-
EVM approach: Non-EVM, purpose-built VM
-
Strengths: Extremely efficient proving, long-term scalability
-
Trade-offs: Steep learning curve, different tooling
Starknet is the most technically ambitious approach, optimising for what ZK can do best, not what Ethereum already does.
Scroll
-
Philosophy: Ethereum faithfulness
-
EVM approach: Deep EVM equivalence
-
Strengths: Correctness, long-term compatibility
-
Trade-offs: Higher proving costs, slower iteration
Scroll treats Ethereum as a specification to be reproduced as precisely as possible, even if that makes engineering harder.
Polygon zkEVM
-
Philosophy: Drop-in Ethereum scaling
-
EVM approach: EVM-equivalent
-
Strengths: Ecosystem integration, familiarity
-
Trade-offs: Circuit complexity, prover demands
Polygon zkEVM focuses on minimising friction for existing Ethereum users and developers.
Linea
-
Philosophy: Stability and infrastructure reliability
-
EVM approach: EVM-compatible
-
Strengths: Operational maturity, conservative design
-
Trade-offs: Less aggressive innovation
Linea prioritises predictable behaviour and production-grade tooling over pushing technical boundaries.
Adoption Reality: Where ZK Rollups Are Actually Being Used
Despite the attention ZK rollups receive, real-world adoption is still uneven.
Strongest Early Use Cases
-
DeFi protocols that value fast finality and correctness
-
High-value transactions where security guarantees matter
-
Infrastructure-heavy applications that can tolerate complexity
Slower Adoption Areas
-
Casual consumer apps
-
Rapid experimentation environments
-
Extremely low-margin transaction use cases
This is not a failure — it reflects the fact that ZK rollups currently favour correctness over convenience.
Why Optimistic Rollups Got There First
Optimistic rollups reached adoption earlier because:
-
They were easier to build
-
They reused existing Ethereum tooling
-
They didn’t require complex proving systems
ZK rollups are the second phase, not a replacement.
Many teams expect a gradual migration from optimistic to ZK-based systems as tooling improves and costs fall.
The Real Risks Facing ZK Rollups
ZK rollups are powerful — but not risk-free.
Prover Centralisation
-
Proving is expensive and hardware-intensive
-
This may concentrate power among a few operators
-
Long-term decentralisation depends on proving cost reductions
Sequencer Control
-
Centralised sequencers can censor or reorder transactions
-
Decentralised sequencing is still an open problem
Complexity Risk
-
ZK systems are hard to reason about
-
Bugs can be subtle and catastrophic
-
Auditing costs are high
These risks are not hypothetical. They are the trade-offs that come with pushing cryptography to its limits.
Why These Risks Are Still Acceptable
Despite these challenges, ZK rollups have a key advantage:
They reduce the need for social trust.
Instead of relying on:
-
Honest watchers
-
Timely challenges
-
Economic assumptions
They rely on mathematics.
That makes them particularly well-suited for:
-
Financial infrastructure
-
Long-lived systems
-
Applications where failure is unacceptable
ZK Rollups and Ethereum’s Roadmap
Ethereum’s future upgrades are closely aligned with ZK rollups.
Expanded data availability will:
-
Lower rollup costs
-
Increase throughput
-
Reduce congestion
As this happens, ZK rollups benefit directly — without changing their security model.
This alignment is one reason many researchers view ZK rollups as structural infrastructure, not a passing scaling experiment.
The Likely End State: ZK Rollups Become Invisible
If ZK rollups succeed, most users will never:
-
Choose a rollup explicitly
-
Understand proof systems
-
Care about EVM equivalence
They will simply:
-
Use applications that are fast
-
Pay low fees
-
Receive quick finality
The technology fades into the background — which is exactly what good infrastructure does.
Why There Will Be Multiple Winners
There is no reason to expect a single dominant ZK rollup.
Different use cases reward different properties:
-
Financial apps may favour strict equivalence
-
Consumer apps may favour UX
-
Experimental systems may favour flexibility
This diversity is a strength, not a weakness.
A Calm, Long-Term View
ZK rollups are:
-
Hard to build
-
Slow to mature
-
Expensive to maintain
But they offer something rare in crypto: a scaling path that does not compromise core principles.
They allow Ethereum to scale without:
-
Trusting intermediaries
-
Weakening decentralisation
-
Introducing subjective dispute resolution
That makes them uniquely valuable.
Final Verdict
ZK rollups are not a silver bullet.
They are infrastructure — complex, imperfect, and evolving.
But they represent one of the most serious attempts yet to reconcile:
-
Security
-
Decentralisation
-
Scalability
If crypto is going to support real-world financial systems, global applications, and long-term digital economies, ZK rollups — in one form or another — will almost certainly be part of that future
Deep FAQs
What Is a ZK Rollup?
A ZK rollup is a Layer 2 scaling system that executes transactions off-chain and submits cryptographic proofs of validity to Ethereum. These proofs mathematically guarantee that transactions were executed correctly without requiring Ethereum to re-run them.
How Do ZK Rollups Differ From Optimistic Rollups?
ZK rollups use validity proofs to prove correctness immediately, while optimistic rollups assume transactions are valid unless challenged. This allows ZK rollups to achieve faster finality and avoid dispute windows, at the cost of higher computational complexity.
What Does “Zero Knowledge” Mean in ZK Rollups?
In this context, zero-knowledge refers to cryptographic proofs that allow one party to demonstrate that a computation was performed correctly without revealing its internal steps. ZK rollups use this property for scalability, not primarily for privacy.
Are ZK Rollups Private by Default?
No. Most ZK rollups do not hide transaction data. They use zero-knowledge proofs for correctness, not anonymity. Privacy features must be explicitly designed and are separate from the rollup model itself.
What Is a ZK-EVM?
A ZK-EVM is a virtual machine that allows Ethereum smart contracts to run inside a zero-knowledge proof system. Different projects interpret “ZK-EVM” differently, ranging from full EVM equivalence to partial compatibility.
What Is the Difference Between EVM-Compatible and EVM-Equivalent?
EVM-compatible systems support Solidity and Ethereum tooling but may behave differently under the hood. EVM-equivalent systems aim to replicate Ethereum’s execution semantics exactly, making them harder to build but easier to migrate to.
Why Is EVM Equivalence So Difficult in ZK Rollups?
The Ethereum Virtual Machine was not designed for zero-knowledge proofs. Proving its behaviour requires extremely complex circuits, significantly increasing proving time, hardware requirements, and engineering difficulty.
Are ZK Rollups More Secure Than Optimistic Rollups?
ZK rollups rely on mathematical proofs rather than economic incentives and monitoring assumptions. This removes the need for challenge periods and reduces reliance on honest third parties, but introduces complexity risk in proof systems.
What Are Provers and Why Do They Matter?
Provers generate cryptographic proofs for transaction batches. Proving is computationally expensive, which can lead to centralisation if only a few operators can afford the required hardware.
Do ZK Rollups Have Centralisation Risks?
Yes. Most ZK rollups currently rely on centralised sequencers and limited prover sets. Decentralising these components is an active area of research, but performance trade-offs remain.
How Do ZK Rollups Handle Data Availability?
Most ZK rollups publish transaction data to Ethereum so that anyone can reconstruct the state. This preserves security but ties rollup costs to Ethereum’s data pricing.
Are ZK Rollups Ready for Mass Adoption?
ZK rollups are production-ready but still maturing. Tooling, debugging, and proving costs are improving, but developer experience and operational complexity remain barriers compared to optimistic rollups.
Which ZK Rollup Is “The Best”?
There is no single best ZK rollup. Different projects optimise for different goals such as EVM equivalence, developer experience, performance, or long-term scalability.
Will ZK Rollups Replace Optimistic Rollups?
More likely, ZK rollups will gradually complement and eventually replace optimistic rollups as tooling improves and costs fall. Both models may coexist for some time.
Why Are ZK Rollups Considered Ethereum’s Long-Term Scaling Path?
ZK rollups preserve Ethereum’s security model while allowing computation to scale off-chain. They align with Ethereum’s roadmap and benefit directly from future data-availability upgrades.
Will Users Need to Understand ZK Rollups?
No. If ZK rollups succeed, they will become invisible infrastructure. Users will simply experience faster transactions and lower fees without needing to understand how proofs work.
Final Takeaway
ZK rollups are not hype technology. They are difficult, expensive, and slow to mature — which is precisely why they matter. As infrastructure, they prioritise correctness and security over speed, making them one of the most credible long-term scaling solutions in the blockchain ecosystem.
