ZK Rollups: zkSync & StarkNet

1) How It Works

A ZK rollup is an L2 chain whose state transitions are proven correct to Ethereum with validity proofs. Rather than asking Ethereum to re-execute every transaction, the rollup posts a compact cryptographic proof that “this batch of transactions, when applied to the previous state, produces the new state.” If the proof verifies on L1, Ethereum accepts the update.

Users → L2 executes txs → proof system (SNARK/STARK) → proof + data posted to Ethereum
Ethereum verifies proof → accepts state update

The flow in practice.

• Sequencing & execution: An L2 sequencer orders your transactions and executes them in the L2 VM (EVM-like or alt-VM). The result is a new L2 state root.
• Proving: A prover takes the batch and generates a succinct proof that the transition is valid. Modern rollups often use recursion to aggregate many blocks into one proof.
• Data availability (DA): The rollup also publishes the data needed for anyone to reconstruct state (typically on Ethereum as calldata or blob-style data). With data available on L1, users can always verify and exit, even if L2 operators vanish.
• Verification on L1: An on-chain verifier contract checks the proof. If valid, it finalizes the new state commitment; messages and withdrawals can be processed.

Why withdrawals are faster. In optimistic rollups, you wait out a challenge window. In ZK rollups, the proof itself is the guarantee. Once verified, funds are withdrawable without a week-long delay (you still wait for the proof to be generated and included, but not for adversarial challenges).

SNARKs vs. STARKs. Both are zero-knowledge proof systems (you’ll also hear “validity proofs”). SNARKs are extremely concise and fast to verify, but many variants require a trusted setup. STARKs avoid trusted setup and rely on transparent assumptions, with excellent scalability and post-quantum properties, but proofs are larger and on-chain verification can be heavier. Many modern stacks use recursion, custom circuits, and hardware acceleration to keep user fees low and confirmations quick.

Rollup vs. validium (DA choice). In rollup mode, data is posted on Ethereum, so anyone can reconstruct state and exit trustlessly. In validium, data lives off-chain with committees/providers; proofs still ensure correctness, but if DA providers withhold data, users can be stuck until data reappears. Some ecosystems support volition, letting apps choose per-asset DA trade-offs.

2) EVM Compatibility

ZK rollups sit on a spectrum from “very close to EVM” to “purpose-built VM.” Closer to EVM means easier app portability; purpose-built VMs can be more proving-efficient.

• Near-EVM ZK-EVMs (Type 2/2.5 style): Strive to run most Solidity/Vyper code with minimal changes. You can generally redeploy popular frameworks and reuse tooling, with occasional caveats (gas semantics, precompiles, edge opcodes, or different system contracts).
• Alt-VMs: Use a different language/VM designed for proof efficiency (e.g., Cairo). Toolchains include their own compilers, debuggers, and libraries. Porting from Solidity usually requires rewriting or transpiling, but you can gain performance and new language features.

Developer considerations.

• Tooling: Does your target chain support the frameworks, debuggers, and test runners you rely on? Is there a mature explorer, RPC, and simulation?
• Account abstraction (AA): Many ZK L2s ship native AA: smart accounts, session keys, and paymasters (sponsor gas or pay in tokens). Great UX, but read the docs—AA flows differ across stacks.
• Bridging model: Prefer the canonical L1↔L2 bridge for moving core assets. Third-party bridges can be convenient but add extra trust and code paths.
• L1 interaction: Messaging (L1↔L2) and finality timing vary by chain. If your app depends on quick L1 responses, measure real timings.

3) zkSync & StarkNet

Below are high-level traits to understand each ecosystem’s vibe and trade-offs. These aren’t endorsements, use them to orient your own testing and due diligence.

• zkSync.
  • Focus: Smooth user UX, near-EVM developer experience, and fast confirmations. Generally SNARK-based with recursive proving and a strong emphasis on account abstraction and paymasters.
  • Dev experience: Solidity-first path for most apps; common frameworks and libraries typically work with minor adjustments. Native AA lets you explore gas sponsorship or non-ETH fee experiences depending on network rules.
  • Bridging & UX: Canonical bridges for ETH and major tokens; withdrawals finalize after proof verification. As with any L2, always confirm the official bridge and domain from docs—avoid lookalikes.
  • Operational notes: Pay attention to prover/sequencer decentralization roadmaps, upgrade procedures, and DA mode (rollup vs any validium options) when sizing deposits.
• StarkNet.
  • Focus: Throughput and scalability with STARK proofs. Uses the Cairo language and a purpose-built VM designed for proving efficiency.
  • Dev experience: Cairo requires learning a new toolchain (compiler, debugger, testing). The design encourages provable programs and offers unique patterns; Solidity-to-Cairo transpilers exist for some cases, but native Cairo often yields the best results.
  • AA & contracts: Account abstraction is native, so smart-account patterns (spending policies, social recovery, session keys) are first-class.
  • DA modes: Rollup and validium-style options exist in the ecosystem; choose per-app based on security vs. cost. As always, verify the exact mode a given deployment uses.

4) Risk Watchlist

ZK rollups inherit Ethereum’s security for what they prove and publish, but real-world risk also lives in operators, bridges, and upgrade processes. Use this list before moving serious funds.

• Prover decentralization & performance. A single prover or opaque cluster can be a bottleneck. If proofs stall, withdrawals and finality lag. Prefer systems with visible progress toward multiple provers, fallback routes, and transparent status dashboards.
• Sequencer centralization & censorship. If one sequencer orders all transactions, what are the escape hatches? Look for “force inclusion” or “forced withdrawals” that let you exit via L1 even if the sequencer is down or censoring.
• Bridges & upgrade keys. Who controls the canonical bridge and the verifier contract? Is there a security council, multisig, and timelock for non-emergency upgrades? Emergency powers should be explicit and narrow.
• Data availability choice. Rollup (on-chain DA) vs validium (off-chain DA). Validium lowers fees but adds availability/committee trust. If DA disappears, can you still exit? What are the guarantees?
• EVM differences. Near-EVM ≠ identical EVM. Edge opcodes, precompiles, or gas accounting differences can cause unexpected behavior. Test production paths on the actual L2.
• Asset origin confusion. “ETH on L2” and “USDC on L2” can exist in multiple forms (canonical vs third-party bridged). For serious funds, stick to the canonical bridge and verify token origins in the explorer.

Quick check

1. Why are ZK rollup withdrawals usually faster?
2. What’s a validium risk relative to a rollup?

Go deeper

• L2BEAT (ZK ecosystems & risks)
• zkSync
• StarkNet

Finally, let’s compare sidechains and state channels, different trust models.

Next: Sidechains & State Channels →