Below is an engineering-oriented overview. Production numbers cited below are drawn from publicly reported ranges through mid-2024 (L2BEAT, growthepie, project explorers); they should be cross-checked against current dashboards before being used in any official analysis. # ZK rollups vs optimistic rollups: an architectural overview
Rollups all do the same high-level trick: execute transactions off Ethereum, but keep Ethereum as the settlement layer. The two dominant families differ in how Ethereum is convinced the offchain execution was correct.
That difference propagates into everything else: latency, withdrawal UX, prover economics, compatibility, and decentralization strategy.
At a high level:
Optimistic rollup:
L2 posts tx data + new state commitment to L1
L1 accepts "optimistically"
Anyone may challenge during dispute window
Finality delayed by challenge period
ZK rollup:
L2 posts tx data + new state commitment + validity proof
L1 verifies proof
Finality follows proof acceptance on L1
No challenge window for correctness
The key engineering distinction is the cost model:
So optimistic systems externalize correctness cost into a dispute game; ZK systems internalize it into continuous proving.
Most production rollups today, including zkSync Era, Linea, and Polygon zkEVM, have historically used a single sequencer/operator path for ordering transactions. That means:
Typical components:
User -> Sequencer -> Executor -> Batcher -> DA publisher -> Prover -> L1 Verifier
Roles:
The important nuance is that sequencing and proving are orthogonal. A rollup can have:
In practice, production ZK rollups have usually decentralized the verification first, not the sequencing.
A system is a rollup in the strict sense only if the data needed to reconstruct state is available on Ethereum.
That means the L2 must publish either:
If data is kept offchain by a committee, the system is closer to a validium or volition mode.
For the three systems here:
Post-4844, the architectural story changed materially: batch cost is now dominated less by calldata pricing and more by blob inclusion strategy, proof cadence, and compression efficiency.
Optimistic rollups and ZK rollups both inherit Ethereum security for settlement, but they expose different latency surfaces.
Operational path:
1. Sequencer executes txs and gives user an L2 receipt
2. Batcher posts tx data and state commitment to L1
3. State is "pending" economically
4. Challenge window passes (commonly ~7 days)
5. Withdrawal finalizes
Implications:
Operational path:
1. Sequencer executes txs and gives user an L2 receipt
2. Batcher posts DA payload to L1
3. Prover generates validity proof
4. Verifier contract accepts proof
5. State becomes finalized on L1
Implications:
This is why application teams often pick ZK for:
But optimistic rollups still have advantages where:
zkSync Era is architecturally distinctive because it is not just “EVM inside a proof.” It uses EraVM and a custom compilation/bootloader model, which improves ZK-friendliness but introduces semantic differences versus Ethereum.
Core traits:
Boojum is Matter Labs’ proving stack for Era. The important architectural point is not the brand name but the design goal:
Because Era is not strict L1 bytecode equivalence, Boojum benefits from a VM that is more tractable to prove than raw Ethereum semantics.
Linea takes the opposite posture: it aims to feel very close to Ethereum for developers. ConsenSys positioned it around high compatibility with existing Solidity tooling and MetaMask-native distribution.
Core traits:
Terminology around Linea’s proving internals can vary by document: some materials describe the proof stack via circuit frameworks, others via arithmetization/recursion layers. The important engineering takeaway is that Linea’s prover is designed around high EVM fidelity, which generally means:
Polygon zkEVM sits between Ethereum equivalence ambition and Polygon’s broader proving research stack.
Core traits:
You asked specifically for Plonky3. The right engineering caveat is:
That matters because researchers often blur:
Vitalik’s type taxonomy is still a useful shorthand, though real systems often land “between” categories.
Type 1: Ethereum-equivalent
Proves Ethereum blocks almost exactly as-is
Type 2: Fully EVM-equivalent
Very high compatibility, minor implementation differences
Type 3: Almost EVM-equivalent
Small semantic/tooling differences
Type 4: High-level-language compatible
Solidity/Vyper friendly, but not bytecode equivalent
Linea is best understood as a Type 2-ish design:
Polygon zkEVM has generally been positioned near Type 2, but in practice many zkEVMs have enough edge-case differences to look Type 2.5 / Type 3 operationally:
zkSync Era is the least “literal Ethereum” of the three:
Higher equivalence gives:
Lower equivalence gives:
For app teams, this is not abstract. If you rely on:
then Type 2-ish systems are much less risky.
If you mainly deploy conventional Solidity applications and care more about fee efficiency and future throughput, a more custom VM may be acceptable.
+---------------------+
Users/Builders ->| Sequencer |-- soft confirmation -->
+----------+----------+
|
v
+---------------------+
| Executor / VM |
| tx execution |
| state transitions |
+----------+----------+
|
v
+---------------------+
| Batcher |
| compress txs/diffs |
| build L1 payload |
+-----+----------+----+
| |
DA to L1 | | witness / traces
v v
+----------------+ +-------------------+
| Ethereum DA | | Prover |
| calldata/blobs | | circuit generation|
+--------+-------+ | recursion/agg |
| +---------+---------+
| |
+--------------------+
|
v
+-----------------------+
| L1 Verifier Contract |
| verify validity proof |
| accept new state root |
+-----------+-----------+
|
v
Finalized L2 state
The real latency is the sum of:
Users often conflate “my tx was included quickly” with “it is finalized on Ethereum.” They are different.
Users -> Sequencer -> Execution -> Batcher -> L1 assertion/data post
|
v
Challenge / dispute window
|
no valid fraud proof?
|
v
Finalization
The crucial difference is that optimistic systems replace continuous proving with a dispute game. This is why they can be operationally simpler but have much worse native withdrawal latency.
Engineering emphasis:
Best for:
Engineering emphasis:
Best for:
Engineering emphasis:
Best interpreted as:
For researchers, the main observation is this: the three systems are not merely swapping proof libraries; they represent different positions on the spectrum of equivalence vs proof efficiency.
Again, these are not 2026-verified values. They are the best non-marketing production ranges visible on public dashboards through my knowledge cutoff.
Using growthepie, L2BEAT, and chain explorers through mid-2024:
These are real-world observed usage ranges, not vendor TPS claims. They also reveal an important truth: actual bottlenecks in 2024 were usually ecosystem demand, proving cadence, and fee economics, not raw theoretical VM throughput.
What matters operationally is not “TPS max” but:
By contrast, optimistic rollups commonly had:
After blobs, fee economics improved for all rollups using Ethereum DA:
This especially benefits high-volume systems because fixed proving overhead amortizes better across larger batches.
A major recent shift is the recognition that “single sequencer now, decentralize later” creates persistent problems:
A shared sequencer is a sequencing layer used by multiple rollups. The hoped-for benefits are:
But it also introduces:
Espresso has been developing a shared sequencing / confirmation approach meant to give rollups:
The conceptual value for ZK rollups is strong: sequencing can be decentralized independently of proving. A rollup could still settle with validity proofs but outsource ordering.
Astria pushes a more modular sequencing architecture:
As of the latest public architecture I can responsibly describe, these three are still best understood as individually operated rollups, not as fully shared-sequenced systems in production default mode.
For researchers, the interesting trend is:
Today:
per-rollup sequencer + per-rollup prover + Ethereum settlement
Emerging:
shared sequencer + per-rollup execution/proving + Ethereum settlement
If that model sticks, future differentiation among ZK rollups may shift away from ordering and toward:
Developers pay for:
Implications by design:
Ask three separate questions:
For many consumer apps, soft confirmations are enough.
For exchanges, bridges, lending protocols, and intent systems, proof finality matters.
This is where ZK rollups clearly outperform optimistic rollups natively.
Bridges can hide this with fast liquidity exits, but then the app depends on:
If your app needs trust-minimized exits, the difference is decisive.
Type-2-ish systems reduce risk for:
Custom-VM systems may still be excellent, but the engineering burden shifts left:
zkSync Era
Best read as: ZK-efficiency-forward
Strengths: strong scaling posture, busy ecosystem, custom-proof-friendly VM
Tradeoff: less exact EVM equivalence
Linea
Best read as: compatibility-forward zkEVM
Strengths: high dev portability, Ethereum-like behavior
Tradeoff: proving high-fidelity EVM is expensive/complex
Polygon zkEVM
Best read as: compatibility-focused zkEVM tied to strong proving research lineage
Strengths: good portability, deep Polygon research bench
Tradeoff: smaller production footprint than Era in 2024; proving stack nomenclature is easy to oversimplify
Start
|
|-- Do you need trust-minimized native withdrawals faster than ~7 days?
| |
| |-- Yes -> Prefer ZK rollup
| |
| |-- No -> Optimistic rollup remains viable
|
|-- Is bytecode-level / near-exact EVM behavior critical?
| |
| |-- Yes -> Favor Linea or Polygon zkEVM
| |
| |-- No -> zkSync Era becomes more attractive
|
|-- Do you depend on obscure EVM edge cases, custom tooling, or low-level gas assumptions?
| |
| |-- Yes -> Favor Type-2-ish zkEVMs first
| |
| |-- No -> Custom-VM designs are acceptable
|
|-- Is current ecosystem liquidity / usage a top priority?
| |
| |-- Yes -> Prefer the chain with the strongest observed production demand
| | (through mid-2024, that was generally zkSync Era among these three)
| |
| |-- No -> Optimize for technical fit instead
|
|-- Is sequencing decentralization a hard requirement today?
| |
| |-- Yes -> Be cautious: most production rollups still rely on centralized sequencing
| | and shared sequencing is still an active transition area
| |
| |-- No -> Current production rollups are usable with known trust tradeoffs
|
|-- Recommended bias
|
|-- Want highest compatibility, lowest migration friction -> Linea
|
|-- Want compatibility plus Polygon ecosystem/proving roadmap -> Polygon zkEVM
|
|-- Want aggressive ZK-oriented architecture and can handle VM differences -> zkSync Era
For protocol researchers, the most important framing is this: the real competition is not “which proof system has the coolest name,” but which layer of the stack absorbs complexity.
Among the three compared here:
For app teams, the selection rule is simple:
Thanks for reading this far. If “zkEVM rollup architecture” connected with where you are, three concrete next steps:
The full Midnight ZK Cookbook index has 17 tutorials across Midnight, Aleo, Aztec, Noir, and risc0 plus 4 Chinese translations. Adjacent tutorials are listed by ecosystem on that page.
Bounty Radar tracks open ZK bounties across Algora, GitHub labels, Drips Wave, Code4rena, and Bountycaster. Browse the live ZK bounty radar or any per-ecosystem widget at https://battam1111.github.io/bounty-radar-data/widget.html?ecosystem=<aleo|aztec|cairo|midnight|noir|risc0>. The free tier is poll-based; the $19/mo Hobbyist tier pushes one filter to your Telegram in real time.
zk-pipeline-doctor is the free MIT-licensed CLI that scores any ZK project on tests, CI, docs, security, reproducibility, and language toolchain (supports Compact, Leo, Noir, Cairo, and 7 Rust zkVMs). Drop it into a GitHub Action with zk-doctor-action for diff-aware PR comments. The $15/mo Pro tier adds four cross-ecosystem deep detectors (circuit complexity, proving-system pitfalls, verifier soundness, multi-file consistency).
Drafted with AI assistance and reviewed by the author before publishing. See DISCLOSURE for the full process.
Three ways to support this work, pick whichever matches your situation:
Free alternative: Sponsor on GitHub · Star the repo · Share with one ZK developer who'd benefit