At 09:24 UTC on 5 January 2026, the transaction executor of Starknet, a ZK rollup on Ethereum, got a reverted call wrong: it kept a state change that should have been thrown away. Blocks kept coming for 18 minutes. Then the network stopped, the 18 minutes of activity were dropped, and Starknet stayed down until 14:17 UTC, according to StarkWare’s incident report. The bad state never reached Ethereum. The report says the incorrect execution “never saw L1 finality thanks to Starknet’s proving layer”. That is what a ZK rollup is built for: Ethereum accepts nothing it cannot check.
The same report has a second lesson in it. The people who caught the error also decided to halt the chain, roll it back and restart it. On 12 November 2026, ETHBEAT (formerly L2BEAT) still lists Starknet’s sequencer as five permissioned nodes run by StarkWare, and its contracts can be upgraded at once by a 9-of-12 Security Council. StarkWare’s own staking documentation is just as plain: “While Starknet is currently still centralized”, it says, the network is moving step by step towards validators.
It builds on our lesson on optimistic rollups, which compares the two families in a table and explains why Arbitrum or OP Mainnet make you wait about a week. The rollup pipeline itself (sequencer, batches, state root, bridge) and ETHBEAT’s stages 0, 1 and 2 are in our layer 2 explainer. The rest goes deeper on the ZK side: what exactly gets proven, who proves it and at what cost, how long an exit really takes, and what went wrong on ZKsync, Starknet, Scroll, Linea and Polygon zkEVM.
ZK rollups explained: Ethereum checks a receipt instead of waiting
A rollup runs transactions away from Ethereum and posts the result back. An optimistic rollup posts its claimed new state and gives anyone several days to dispute it. A ZK rollup posts its claimed new state together with a cryptographic proof that the claim is right, and a contract on Ethereum checks that proof before it accepts anything. No dispute window is needed, because there is nothing left to dispute.
The proof is a zero-knowledge proof: a prover convinces a verifier that a statement is true without the verifier redoing the work. The name is a little misleading here. Most ZK rollups publish all their data, so nothing is hidden; what they use is the other property of these proofs, succinctness. Checking a proof of a batch of thousands of transactions costs Ethereum one contract call, far less than re-executing them.
ETHBEAT gives the same definition on every ZK project page: each update of the system’s state must come with a proof that the new state was obtained by correctly applying valid user transactions to the previous one, and a smart contract on Ethereum verifies those proofs. ethereum.org calls such a proof a succinct commitment to the correctness of the batch. In practice that is the “validity proof” you will see in rollup documentation.
Four roles: sequencer, prover, proposer, verifier
The sequencer orders transactions and produces the rollup’s blocks, just as on an optimistic rollup. The prover is a separate machine, or a fleet of GPUs, that takes a batch of blocks and computes the proof; it is the expensive part. The proposer posts the new state root and the proof to Ethereum. The verifier is a contract on Ethereum (Linea’s is called PlonkVerifierFull on ETHBEAT, Scroll’s PlonkVerifierOpenVMv2) that accepts or rejects the proof. If the proof fails, the state root is refused.
What is proven is the state transition function: the rules that turn the old state plus a list of transactions into the new state. On Starknet that program is the Starknet OS, written in Cairo, and since 19 October 2025 the proofs come from StarkWare’s Stwo prover, per ETHBEAT’s milestones. On the EVM-based rollups the program is an implementation of the Ethereum Virtual Machine.
What is not proven matters as much. The proof does not show that the sequencer included your transaction; a censoring operator produces perfectly valid proofs. It does not show that the people holding the upgrade keys will behave. And it does not show that the data behind the state is available to you, which is the difference between a rollup and a validium, covered below. A proof is only as good as the program it checks: a bug in the circuit or the verifier can make a wrong state look right.
Recursion: many proofs folded into one
Proving a whole day of activity in one go would be slow, so provers split the work and then prove the proofs. Linea makes inner proofs and aggregates them into one final PLONK proof that Ethereum checks, according to ETHBEAT’s description of its proof system. StarkWare goes further with SHARP, a shared prover that bundles work from several chains into a single proof. The catch is shared too: ETHBEAT notes that the SHARP verifier can be changed by a 2-of-4 multisig with an 8-day delay, “affecting all rollups like Starknet that are sharing it”.
State diffs or transactions: what goes to Ethereum
Because the proof already vouches for the computation, a ZK rollup does not have to post every transaction. Starknet, ZKsync Era and Lighter post state diffs, the final changes to balances and storage, which take less space when the same accounts trade many times. Linea is an exception: ETHBEAT points out that, unlike most ZK rollups, it posts transaction data. Either way the data lands in Ethereum’s blobs, the subject of the next lesson of this path, on blobs and EIP-4844.
SNARKs and STARKs: two ways to build the proof
Two families of proof systems run almost every ZK rollup. SNARKs came first in production. The best known, Groth16, was published by Jens Groth in 2016; in his paper “On the Size of Pairing-based Non-interactive Arguments” a proof is only three group elements, a few hundred bytes, and verification is a single pairing equation. That is cheap on Ethereum. The price is a trusted setup: a ceremony creates secret parameters for each circuit, and if someone kept them, that person could forge proofs.
PLONK, published in 2019 by Ariel Gabizon, Zachary Williamson and Oana Ciobotaru (IACR ePrint 2019/953), keeps small proofs but uses a universal, updatable setup: one ceremony serves every circuit up to a size, and it stays safe if a single participant was honest. Linea’s final proof is a PLONK proof.
STARKs come from a 2018 paper by Eli Ben-Sasson, Iddo Bentov, Yinon Horesh and Michael Riabzev titled “Scalable, transparent, and post-quantum secure computational integrity”. Transparent means set up “with no reliance on any trusted party”: no ceremony at all. STARKs rely on hash functions instead of elliptic curves. Their proofs are much larger, which makes them more expensive to verify on Ethereum.
| SNARK (Groth16, PLONK) | STARK | |
|---|---|---|
| Setup | Trusted setup, per circuit (Groth16) or universal (PLONK) | Transparent, no trusted setup |
| Proof size | Tiny: Groth16 is three group elements | Much larger |
| Verification on Ethereum | Cheap, a pairing check | Costlier, so often wrapped in a SNARK |
| Cryptography | Elliptic curves and pairings | Hash functions |
| Large quantum computer | Would break the curves | Considered post-quantum |
| Used by (ETHBEAT, 12 Nov 2026) | Linea, Lighter; final wrapper of ZKsync Era, Scroll, Mantle | Starknet, verified on Ethereum without a wrapper |
Most projects now combine the two. They prove the heavy work with a STARK-style system, then prove the verification of that STARK inside a small SNARK, and only the SNARK goes to Ethereum. ETHBEAT’s risk notes for ZKsync Era, Scroll and Mantle say exactly that, and add the trade-off: the outer SNARK brings a trusted setup back. Starknet is the main exception. Its STARK proofs are verified on Ethereum as they are.
The quantum angle
A large quantum computer running Shor’s algorithm would break the elliptic-curve assumptions behind SNARKs. Hash-based STARKs are considered safe against it. StarkWare uses that argument, but it also concedes, as we reported in our story on Starknet’s post-quantum vote, that the network’s full quantum safety depends on Ethereum’s own transition. On 22 October 2026 a non-binding Starknet poll gave 93.52% support to researching a post-quantum layer 1. It is research, and no move has been decided.
zkEVM types: Vitalik Buterin’s 2022 scale
Proving the EVM is hard because the EVM was never designed for it: its hash function and its state tree are expensive to express in a circuit. In August 2022 Vitalik Buterin sorted the attempts into types in “The different types of ZK-EVMs”. Type 1, he wrote, strives “to be fully and uncompromisingly Ethereum-equivalent”: it changes nothing, so it can prove real Ethereum blocks, but proving is slow.
Type 2 is exactly equivalent to the EVM but changes some parts of Ethereum around it, such as the state tree, to speed up proving. Type 2.5 also changes gas costs. Type 3 is almost EVM-equivalent and drops a few features that are too hard to prove. Type 4 does not prove the EVM at all: it compiles Solidity or Vyper source code into a language built for proofs. In 2022 he placed Scroll and Polygon at Type 3, both expected to improve compatibility over time, ZKSync at Type 4, and Nethermind’s Warp, a compiler from Solidity to Cairo for StarkNet, at Type 4 too.
Treat those labels as a 2022 photograph. Scroll has since replaced its whole prover, and every team has moved its own way. Starknet never aimed for the EVM: ETHBEAT gives it the virtual machine badge “CairoVM” where the others show “EVM”, so contracts are written in Cairo rather than Solidity. For a user the question is simpler than the type number: does my wallet work, and do the contracts behave as on Ethereum? For a developer, small differences in gas or precompiles can still break code that works on Ethereum.
Why withdrawals take hours, not a week
ethereum.org puts it bluntly: “There are no delays when moving funds from a ZK-rollup to Ethereum”, because the exit is executed as soon as the contract has verified the proof. True in principle. In practice your withdrawal waits for three things: the next batch that contains it, the proof of that batch, and any delay the operator has added on top. On some native bridges a last step remains, a claim transaction you send yourself on Ethereum and pay for in gas.
| Chain | What sets the wait | Source, date read |
|---|---|---|
| Linea | Median hard finality about 2 hours; “should never exceed 16 hours” in normal conditions; target under 30 minutes | Linea docs, page updated 5 Nov 2026 |
| ZKsync Era | Proving, then an execution delay of at least 24 hours since 7 Oct 2026 (3 hours before) | Matter Labs (ZKsync forum); ETHBEAT, 12 Nov 2026 |
| Starknet | Proving cadence; no extra finalization delay once the state update reaches Ethereum | ETHBEAT, 12 Nov 2026 |
| Scroll | Proving cadence; no execution delay | ETHBEAT, 12 Nov 2026 |
| Taiko Alethia | Proofs targeted every 4 hours; no execution delay | ETHBEAT, 12 Nov 2026 |
| Arbitrum One (optimistic, for scale) | Challenge period of about 6.4 days | Arbitrum docs |
Linea’s transaction finality page is the most precise public statement among the big four: a median of about two hours, a ceiling of 16 hours under normal operating conditions, and a plan to bring it under 30 minutes. It also says hard finality is what cross-layer withdrawals need. Those figures are the ones on the page as last updated on 5 November 2026; a median is not a promise for your own withdrawal.
ZKsync is the case where a deliberate delay dominates. Its validator timelock holds batches on Ethereum for a set time before they execute, so that responders can step in if something looks wrong. An earlier governance vote had cut that delay from 21 hours to 3 hours. In September 2026 Matter Labs proposed ZIP-17, which lets each EraVM chain raise its own delay to 24 hours. Its stated reason: AI-assisted tools may shorten the gap between finding a vulnerability and exploiting it. After the token holders’ vote, Matter Labs announced that ZKsync Era would switch to 24 hours on 7 October 2026 at 13:00 UTC; ETHBEAT recorded the change the next day and shows a 1-day execution delay as of 12 November 2026. Withdrawals from Era now take at least 24 hours to finalize on Ethereum, and Matter Labs stresses that this is a minimum. Other ZK Stack chains keep the 3-hour default unless they choose otherwise.
Starknet has no execution delay once a valid state update reaches Ethereum, per ETHBEAT. It has a different brake: every StarkGate bridge escrow can switch on a withdrawal throttle of 5% of the locked funds per 24 hours. A multisig can enable it; a 3-of-12 minority of the Security Council can lift it on the main ETH and STRK escrows. It is a defence against a drain, and it would slow honest exits too.
Faster exits exist through third-party bridges and intent protocols, which pay you on Ethereum right away and wait for the rollup themselves, for a fee. That swaps the rollup’s guarantee for the bridge’s, a trade explained in our guide to bridges and intents.
Proving costs, and who runs the provers
Every large ZK rollup is proven by a small, permissioned set of machines. Starknet’s proofs come from StarkWare’s SHARP. ZKsync Era and Linea accept state roots only from whitelisted proposers; if Linea’s stop, ETHBEAT’s verdict is blunt: users cannot withdraw, and the operator role opens to anyone only after six months without a finalized block. Taiko Alethia has two whitelisted provers. Scroll is the exception among the well-known names: if its proposer fails, ETHBEAT says users can run the source-available prover and submit proofs themselves.
The proving software has changed fast. General-purpose zkVMs prove any program compiled to a simple instruction set, often RISC-V, rather than a hand-built EVM circuit: Succinct’s SP1, RISC Zero, OpenVM (which Scroll adopted in its Euclid upgrade of 16 and 22 April 2025, and moved to version 2.0.0 on 28 September 2026), StarkWare’s Stwo, and ZKsync’s Boojum. Taiko shows where this leads. Since its Unzen upgrade of 3 August 2026, every proven range needs two proofs out of four systems (two Intel SGX setups, SP1 and RISC Zero), and at least one must be an SP1 or RISC Zero validity proof.
zkVMs have bugs too. In October 2026 Succinct disclosed a flaw that let invalid proofs pass SP1’s native Rust verifier, while on-chain verifiers were not affected, as we reported in our story on the SP1 bug. Using two different proof systems, as Taiko does, is an answer to exactly that risk.
The Ethereum Foundation wants to bring the cost down far enough to prove Ethereum itself. In a 10 July 2025 post it defined “realtime proving” as proving 99% of mainnet blocks in 10 seconds or less, on hardware costing at most $100,000 and drawing at most 10 kW, with 128-bit security and proofs under 300 KiB without trusted setups. The aim is that validators could check a proof instead of re-executing every block.
Users do not see proving costs as a separate line. On 11 November 2026 (full UTC day), growthepie data show a median transaction fee of $0.0031 on Starknet across 76,363 transactions, $0.0016 on Scroll and $0.0153 on Linea, against $0.0253 on Ethereum. The four rollups’ users paid less than $2,100 in fees that day all together. ZK rollups are cheap to use and still small in activity: Base alone processed about 7.7 million transactions the same day.
The main ZK rollups on 12 November 2026
ETHBEAT counted 80 active layer 2s securing about $35.9 billion on 12 November 2026, of which 14 in its “ZK Rollup” category. The surprise is at the top. By value secured, the two largest are not the names in this lesson’s title.
| Project (ETHBEAT, 12 Nov 2026) | Stage | Value secured | Proofs | If the proposer stops |
|---|---|---|---|---|
| Mantle (OP Stack with ZK proofs) | 0 | $1,162M | STARK wrapped in SNARK | Cannot withdraw |
| Lighter (exchange chain) | 0 | $1,031M | SNARK | Escape hatch |
| Starknet | 1 | $314M | STARK | Security Council minority |
| Linea | 0 | $297M | SNARK (PLONK) | Cannot withdraw |
| ZKsync Era | 0 | $211M | STARK wrapped in SNARK | Governance replaces proposer |
| Scroll | 0 | $34M | STARK wrapped in SNARK | Users can propose |
| Taiko Alethia | 0 | $11.5M | 2 of 4 systems | Cannot withdraw |
Mantle runs the OP Stack but proves its blocks with Succinct’s ZK proofs, so ETHBEAT files it as a ZK rollup. Lighter is a single application, a funding payment between longs and shorts, settled every few hours, keeps the contract price close to the spot or index price.">perpetual futures exchange, and it has the most user-friendly exit of the list: if the operator disappears, users can leave by submitting “a zero knowledge proof of funds”, in ETHBEAT’s words. Every chain in the table shares one weakness. ETHBEAT gives them all an exit window of “None”: their contracts can be upgraded instantly, before users could leave.
Starknet: the only one at Stage 1
Starknet, built by StarkWare, is the only sizeable ZK rollup at Stage 1, details on our Starknet project page. Normal upgrades go through a 2-of-6 StarkWare multisig with an 8-day timelock; the 9-of-12 Security Council can act at once. Its sequencing runs on a Tendermint setup where three of five StarkWare-run nodes must agree on a block, which ETHBEAT labels “Centralized 5-node Tendermint”. STRK holders can stake: the protocol is in the second of four phases, where validators attest to blocks, with a minimum of 20,000 STRK to run a validator and wrapped bitcoin counted at a weight of 0.25, per the Starknet staking docs. Unstaked tokens stay locked for 7 days on mainnet. Block proposing by validators is planned only for a later phase.
ZKsync Era and the Elastic Network
ZKsync Era, by Matter Labs, is the hub of a family of chains built with the ZK Stack, which ETHBEAT tags “Part of the Elastic Chain”: Abstract, Sophon, Lens and ADI Chain are ZK rollups of the same family, while Cronos zkEVM and GRVT keep their data elsewhere. Era is Stage 0. Code upgrades wait 5 to 9 days on the normal path, and none at all when the EmergencyUpgradeBoard acts.
Linea, Scroll and Taiko
Linea is Consensys’ rollup. Its proof system has covered 100% of the zkEVM since 9 June 2024, per ETHBEAT, but its sequencer has no fallback: if it stops, there is no mechanism to force a transaction through. Scroll had an independent 9-of-12 Security Council until 1 June 2026, when ETHBEAT recorded its replacement by a 3-of-4 team multisig and moved Scroll down to Stage 0. Taiko Alethia, run by Taiko Labs, is the multi-proof chain described above, also at Stage 0.
Polygon zkEVM: a ZK rollup wound down
Polygon zkEVM is the cautionary tale. On 11 June 2025 Polygon announced its sunset on the Polygon forum, citing late support for EIP-4844, “ZK counters” that made some DeFi transactions impractical, and too little difference from other chains. “The zkEVM sequencer will run for the next 12 months,” the post said, with forced transactions kept on so users could leave. On 3 December 2025 ETHBEAT recorded that the chain stopped proving its full state and moved to “pessimistic proofs” that only account for the bridge. ETHBEAT now files it under “Others” with no state validation and about $8.5 million still counted.
Validiums: the same proof, the data elsewhere
A validium proves its state exactly like a ZK rollup but keeps its transaction data off Ethereum, often with a data availability committee (DAC) of a few named members. It is cheaper. It also changes what the proof protects. ethereum.org’s validium page warns that “validium users can have their funds frozen and withdrawals restricted” if the data holders withhold it: without the data you cannot build the Merkle proof the exit needs. A volition lets each user choose, per transaction, between rollup mode and validium mode.
ETHBEAT keeps the line sharp. On 12 November 2026 its API listed 14 projects as “ZK Rollup”, 9 as “Optimistic Rollup”, one as “Optimium” and 66 as “Others”. Validium-style chains with real money sit among the Others: Cronos zkEVM ($22.8 million), Paradex with its data availability committee ($21.6 million) and Immutable zkEVM ($20.9 million).
zkLink Nova shows what that label means. The layer 3 built on Linea, which L2BEAT classified as a validium, was drained of about $779,000 on 28 October 2026 by an attacker who forged a batch root, as we reported in our story on the zkLink Nova exploit. The weakness sat in the bridge and its checks, not in the mathematics of a proof Ethereum verified.
Incidents: the proofs held, the people intervened
Look at the record of the last two years and a pattern appears. The proof systems mostly did their job, sometimes because their operators switched them off in time. The losses and outages came from keys, sequencers and bridges.
| Date | Chain | What happened |
|---|---|---|
| 15 Apr 2025 | ZKsync | Compromised admin key of three airdrop contracts mints about 111 million unclaimed ZK, about $5 million |
| 30 Jul 2025 | ZKsync Era | Proof system paused by hand over a vulnerability; partial liveness failure |
| 10 Sep 2025 | Linea | Chain halts for about one hour |
| 5 Jan 2026 | Starknet | 18 minutes dropped, network down 09:42-14:17 UTC, nothing wrong final on Ethereum |
| 23 Feb 2026 | Scroll | Emergency verifier replacement after a bug in the guest prover program |
| 1 Jun 2026 | Scroll | Security Council replaced by a team multisig, back to Stage 0 |
| 28 Oct 2026 | zkLink Nova (validium) | About $779,000 drained with a forged batch root |
The ZKsync token incident of April 2025 is often misread. ZKsync called it “an isolated incident caused by a compromised key”: the admin account of three airdrop distribution contracts, which the attacker used to call a sweep function and mint about 111 million unclaimed ZK. The ZKsync protocol and the ZK token contract were not affected, the team said in its incident thread. Scroll’s February 2026 episode is the opposite case: a flaw inside the proving stack, which ETHBEAT’s incident log records as an emergency verifier replacement due to a bug in the guest prover program. That fix needed instant upgrade power, the same power ETHBEAT counts against the chain.
Is a ZK rollup safer than an optimistic rollup?
On the narrow question of whether a wrong state can be accepted, a working validity proof is the stronger guarantee: it does not rely on someone watching and challenging in time. Starknet’s January incident is the proof of concept. An optimistic rollup with a broken or silent challenger could have finalized that bad state after its window.
Everything else depends on the chain, not on the family. On 12 November 2026 ETHBEAT rates Starknet at Stage 1 and every other ZK rollup with real value at Stage 0, while Arbitrum One and Base, both optimistic or hybrid, sit at Stage 1. Circuits are complex code, and a bug can turn the strongest guarantee into the weakest point, which is why upgrade keys stay in place. For a given chain, ETHBEAT’s stage and its “if the proposer stops” column say more about your risk than the letters ZK in its name.
For readers in the United States and the United Kingdom, the tokens of these networks (ZK, STRK, LINEA) reached many holders through airdrops. How the IRS treats airdropped tokens and their later sale is covered in our US crypto tax guide. None of this is a reason to buy or sell them: governance tokens give votes, not a share of the rollup.
The next lesson of this path, on blobs and EIP-4844, follows the data these rollups post: what a blob is and why it cut layer 2 fees after March 2024. The one after it compares sidechains with rollups: chains that do not prove anything to Ethereum at all. For the wider question of why Ethereum needs any of this, go back to why blockchains need scaling.
