When it comes to Layer 2 scaling, zero-knowledge rollups (zkRollups) are the golden child.
They're fast, cheap, and promise near-L1 security.
But here’s the thing: while the math might be airtight, the implementation? That’s a whole other story.
This post breaks down how zkRollups and zkVMs should be secure in theory—and where things can (and have) gone wrong in practice.
Whether you’re building, auditing, or just aping in, here’s what you need to know.
The Cryptography That Makes zkRollups Tick
At the heart of every zkRollup is a validity proof—a cryptographic stamp of approval that says:
“These transactions were executed correctly. You don’t have to trust me, just verify the proof.”
These proofs are usually either zk-SNARKs (Succinct Non-Interactive Arguments of Knowledge) or zk-STARKs(Scalable Transparent ARguments of Knowledge). Both aim to do the same thing: compress a large batch of transactions into a tiny proof that can be verified on Ethereum without re-running all the computation.
In practice, this means Ethereum can trust an entire block of L2 activity just by verifying a small proof in a single on-chain transaction. It’s magic, but math.
Why Soundness is everything
There are two properties a zk proof system must have:
- Completeness: If the computation is valid, you can generate a valid proof.
- Soundness: If the computation is invalid, it should be impossible to generate a valid-looking proof.
It’s the soundness that really matters for security. If this breaks, attackers could submit proofs for completely fake states—like showing they own tokens they never deposited.
This isn’t just theory: in the early days of Zcash, a subtle bug in the proving system could’ve allowed someone to mint coins out of thin air. The bug was caught and patched silently, but it showed how fragile things can be when the math goes wrong.
Trusted Setup: The Ceremonial Weak Spot
Many SNARK-based systems (like Groth16 or early PlonK implementations) require a trusted setup—a one-time event where secret parameters are generated and (hopefully) destroyed. If someone retains this “toxic waste,” they could create valid-looking proofs for invalid computations.
Think of it like a key used to generate the rules of the game. If someone keeps a copy, they can rewrite the game entirely. That’s why modern SNARKs use multi-party ceremonies, where dozens (or even thousands) of participants contribute randomness. Unless every single one is compromised, the system remains safe.
On the other hand, STARKs ditch the trusted setup completely. Instead, they rely on public randomness and hash-based security, which makes them post-quantum secure (bonus!)—but they come with trade-offs: larger proof sizes and higher verification costs on-chain.
What “Zero-Knowledge” Actually Means Here?
Let’s clear up a common misconception: not every zkRollup is actually zero-knowledge in the privacy sense.
Many projects use zk-SNARKs or zk-STARKs just for validity, not confidentiality. They publish all transaction data on-chain for transparency, but use proofs to ensure that every state change is legitimate.
So technically, many zkRollups should be called validity rollups—not privacy rollups. The “zk” label stuck, but it’s often just shorthand for “succinct cryptographic proof.”
That said, some protocols do use full zero-knowledge to hide transaction data. Projects like Aztec focus on encrypted DeFi, where balances, recipients, and amounts are all private. That’s where the true zero-knowledge aspect comes into play.
Where Things Get Messy: Real-World Attack Surfaces
Circuit Bugs
zkVMs define state transitions using arithmetic circuits. If one constraint is off—say, it forgets to properly check a withdrawal balance—an attacker could generate a valid proof for an invalid state. That’s exactly what happened with zkSync Era in 2023. ChainLight discovered a critical soundness bug that could have let a malicious prover forge a withdrawal. Estimated damage? Up to $1.9B. Thankfully, caught in time.
Prover/Verifier Bugs
Even if your circuit is solid, the software that creates and verifies proofs might not be. StarkNet had a bug in 2024 that let a malformed transaction trigger an infinite loop in full nodes. No funds lost, but it shows how even implementation bugs can hit availability.
Trusted Setup and Governance Keys
If your setup isn’t secure—or your governance keys are compromised—game over. Early zkSync versions had upgrade keys that let the devs push changes directly to L2. That’s fine in an alpha phase, but long-term, time-locked upgrades and community governance are essential.
Bridges, Censorship, and Side Channels
Don’t forget the bridges! Bugs here are just as dangerous. Projects like Scroll have added rate limiters to mitigate damage in case of an exploit. And while zk proofs prevent unauthorized state changes, they don’t stop a sequencer from censoring transactions. Escape hatches and fallback mechanisms are crucial.
Also: theoretical attacks like side-channel leaks or economic DoS (e.g., flooding the prover with heavy computations) are still being studied.
How the Major Players Stack Up on Security
zkRollups might share similar cryptographic roots, but how each project implements, secures, and manages their systems varies widely.
Let’s zoom in on the real-world security posture of some of the biggest players in the zk space.
zkSync (by Matter Labs)
zkSync uses PlonK-based SNARKs that require a trusted setup. It’s one of the most active zkRollups and offers a general-purpose zkEVM via zkSync Era.
- In 2023, researchers uncovered a critical soundness bug in the proving circuit that could’ve allowed fake withdrawals. Fortunately, it was caught before exploitation, patched quickly, and earned the researcher a $50K bounty.
- That said, zkSync’s current setup is still centralized: Matter Labs holds upgrade keys and operates the sequencer/prover. They’re transparent about this being a phase and have a roadmap to decentralize these roles with safety mechanisms like upgrade delays.
StarkNet (by StarkWare)
StarkNet takes a different route with zk-STARKs, which don’t need a trusted setup and are post-quantum secure—meaning they’ll survive even if quantum computers become real tomorrow.
- Contracts are written in Cairo, a custom VM that’s been formally verified in parts. That’s a huge plus for security.
- In 2024, a bug in the Cairo bytecode parser caused a DoS on full nodes (an infinite loop), but it didn’t affect user funds or the sequencer.
- Like zkSync, StarkNet still has a centralized sequencer and direct upgradeability. But community governance and a prover marketplace are on the roadmap.
Scroll
Scroll is a Type-2 zkEVM, a L2 on Ethereum, meaning it mirrors the EVM closely so devs can deploy existing Solidity code without changes. It uses a Halo2-based SNARK system in collaboration with the Ethereum Foundation.
- Their security model is one of the most cautious in the space. No major vulnerabilities have been reported as of early 2025.
- They’ve built in extra protections like withdrawal rate limiters and upgrade safety checks. Also notable: they stayed on testnet for over a year, purely to stress-test everything.
Polygon zkEVM
Polygon’s zkEVM uses Plonky2, a recursive SNARK system that doesn’t require a trusted setup and is optimized for speed and scalability.
- They launched in 2023 with a Mainnet Beta tag, and wisely so — within months, two critical bugs were disclosed:
- A prover bypass vulnerability that could’ve let someone generate fake proofs.
- A storage overflow bug that could’ve misled the circuit about token balances.
- Both were fixed before any exploitation, and Polygon published full post-mortems and gave out bug bounties.
- They’ve since hardened the system, but still run a centralized prover and sequencer as they roll out decentralization in phases.
Linea (by ConsenSys)
Linea is ConsenSys’s zkEVM (formerly “zkEVM by ConsenSys”), designed to be 100% EVM bytecode compatible, using a SNARK-based system built with the gnark library.
- Security-wise, Linea partnered with Least Authority and ConsenSys Diligence for in-depth cryptographic and contract audits.
- They’ve taken a conservative launch path, with centralized controls during early mainnet phases and an active bug bounty program via Immunefi.
- No critical vulnerabilities have been publicly disclosed so far.
Aztec & Loopring
Two zkRollup OGs, but with very different philosophies.
Aztec:
- Focuses on privacy-first DeFi using encrypted transactions and zk-SNARKs.
- Ran a trusted setup ceremony (“Ignition”) and underwent multiple audits for its “Aztec Connect” bridge.
- In 2023, Aztec voluntarily sunset Aztec Connect to rebuild from scratch with a more decentralized, secure foundation. No hacks occurred.
Loopring:
- One of the oldest zkRollups focused on trading and payments, using Groth16 SNARKs initially, now upgraded.
- No critical rollup-level exploits in years.
- In 2023, a Guardian smart wallet feature was hacked (~$5M loss), but this was not a flaw in the rollup itself—just a vulnerable 2FA option.
Designing a Secure zkVM Is… Not Simple
Let’s get one thing straight: building a zkVM (zero-knowledge virtual machine) isn’t just hard — it’s next-level hard. You’re not just implementing a virtual machine like the EVM. You’re encoding it into math. Into arithmetic circuits. And any mistake in that math? It could mean proving — and accepting — an invalid state as valid.
Here’s why this stuff is so tricky:
Circuit Safety Is Everything
A zkVM works by converting all computation into a set of mathematical constraints (circuits). Each state transition — a transfer, a contract call, even a single opcode — has to be faithfully modeled.
If you forget even one constraint (say, checking that a balance doesn’t go negative), a malicious prover could sneak through a fake proof, and the L1 verifier would happily accept it.
And unlike traditional code, circuit bugs don’t always crash the app — they silently validate incorrect behavior. That’s what makes them dangerous.
Think of it like a house built with invisible cracks in the foundation. It looks fine until it collapses — and by then, it’s too late.
Proving Is Expensive (and Sometimes Painful)
Generating zk proofs isn’t cheap. Provers are constantly juggling performance, memory, and speed. This leads to pressure to optimize circuits, sometimes combining checks, reducing constraints, or skipping edge cases that are “unlikely.”
But the more optimized your circuits, the harder they are to audit. Sometimes the simplest, slowest circuit is also the safest — but that’s a tough sell when users want fast withdrawals and low fees.
The challenge is finding that sweet spot between performance and auditability — and erring on the side of caution when in doubt.
Type-1 vs Type-4 zkEVMs: The Compatibility Trade-Off
Vitalik famously categorized zkEVMs into Type-1 through Type-4, based on how closely they match Ethereum’s EVM:
- Type-1: Exact EVM bytecode compatibility. Great for devs. Nightmare to prove.
- Type-4: Brand new VM (e.g. Cairo) that’s designed to be proof-friendly. But you can’t deploy Solidity out of the box — and you now need to trust the compiler to faithfully translate your smart contracts into this new language.
So here’s the trade-off:
- More compatibility = less migration pain for devs, but way more circuit complexity (and attack surface).
- More divergence = easier to build secure circuits, but harder for apps to migrate or understand what they’re running on.
Either way, the attack surface doesn’t disappear. It just moves: from the circuit to the compiler, or from EVM bugs to language design flaws.
Proofs Mean Instant Finality — and Instant Consequences
In an optimistic rollup, there’s a challenge period — if someone posts a fake state, others can dispute it. But zkRollups skip that entirely. If a proof verifies, the state is final. No challenge window. No take-backs.
That’s great for UX — fast withdrawals, no waiting. But also terrifying: one bad proof, and it’s on-chain, set in stone.
This is why Vitalik proposed dual-proof systems or hybrid models: run two different zk systems in parallel or have an optimistic fallback, just in case one fails.
Until those safety nets are common, zkRollups walk a tightrope with no net.
Tooling and DevX Can Hide (or Reveal) Bugs
Even with perfect circuits, most developers interact with zkVMs through tooling: compilers, SDKs, test environments, deployment scripts.
If your dev tools behave differently from your prover or verifier — or skip edge cases in tests — you might deploy a smart contract that works in testing, but fails (or gets exploited) on-chain.
For example:
- A compiler bug might incorrectly transpile logic.
- A test RPC might behave slightly differently from the live zkVM.
- Debugging zkVM behavior can be harder due to opaque error traces.
DevX issues become security issues when developers don’t get accurate feedback or simulation from the tools they rely on.
zkProofs Are Only as Good as Their Implementation
Look, zkRollups should be more secure than optimistic rollups.
They don’t rely on fraud proofs, watchers, or week-long challenge games. But that guarantee only holds if every single layer of the system—from the circuits to the compilers to the bridge contracts—is watertight.
And that’s the catch: the math might be perfect, but the implementation is where things usually break.
So far, we’ve been lucky — a lot of near-misses, but not many disasters. That’s thanks to the teams treating security seriously: multiple audits, formal verification, aggressive bug bounties, and long testnets before going to mainnet.
But we’re not in the clear. Until we reach full decentralization, time-locked upgrades, redundant proof systems, and maybe even backup fallback verifiers, we’re still balancing on a high wire.
So what can you do?
Trust the math. Audit the code. And always verify before you bridge.
And if you’re building something serious, don’t skip the audit — get your smart contracts reviewed by a top firm like QuillAudits.
They’ve audited over a thousand projects and secured billions in assets across the most complex systems in Web3. In this space, a good audit isn’t a luxury — it’s your last line of defense.
