How zkSync Era Actually Works: Architecture from Deposit to Proof

This article covers the internal architecture of zkSync Era, a Layer 2 network built on Ethereum. Specifically, it explains how transactions enter the system, get processed, get mathematically proved correct, and settle back on Ethereum. Understanding this architecture matters because it determines what security guarantees you actually get when you use zkSync — and where the remaining trust assumptions live.

zkSync Era is a ZK rollup — a separate blockchain that inherits Ethereum's security by posting compressed transaction data and mathematical proofs back to Ethereum. The core idea: instead of making Ethereum re-execute every transaction to verify it (expensive), zkSync executes transactions off-chain and then generates a validity proof (a cryptographic certificate that the execution was correct). Ethereum only needs to check this proof, which is cheap.

• zkSync Era runs an EVM-compatible execution environment, meaning it can run smart contracts written in Solidity (Ethereum's primary programming language), though they must be recompiled with zkSync's own compiler
• It uses STARK proofs wrapped inside a SNARK proof — STARKs are fast to generate but large, SNARKs are small and cheap to verify on-chain, so combining them gets both benefits
• The network posts both the proof and compressed state diffs (a summary of what changed in the system's data, not the full transaction data) to Ethereum L1
• This is a genuine ZK rollup: security comes from math, not from fraud-dispute games like optimistic rollups use

What this means practically: When you use zkSync Era, your transaction's correctness is eventually guaranteed by a proof that Ethereum itself verifies — no committee, no honest-majority assumption.

Every transaction on zkSync Era starts at the sequencer, a server (currently operated solely by Matter Labs, the company behind zkSync) that receives transactions, orders them, and executes them. This is where most explanations go wrong — they describe the sequencer as just a relay. It's not. It's the entity that decides transaction ordering and produces new blocks.

• The sequencer accepts transactions from users, validates basic properties (correct nonce, sufficient balance, valid signature), and places them into blocks
• It executes transactions against the current state — the complete snapshot of every account balance, smart contract storage value, and nonce on zkSync Era
• The sequencer produces L2 blocks roughly every few seconds, giving users fast soft confirmations
• Because it's currently a single operator, the sequencer can censor or reorder transactions — this is the main centralization tradeoff that exists today
• Users have a fallback: they can force-include transactions through Ethereum L1 directly via the zkSync diamond proxy contract, bypassing the sequencer entirely

What this means practically: Your transaction gets a fast response from the sequencer within seconds, but that's a promise, not a proof. Full security comes later.

zkSync Era has two distinct units of work that get confused constantly. L2 blocks are what users see — they contain transactions and get produced quickly. Batches are what the prover and Ethereum care about — they bundle many L2 blocks together for efficient proving and settlement.

• A single batch can contain dozens to hundreds of L2 blocks
• Each batch goes through three stages on Ethereum: committed (data posted), proved (validity proof verified), and executed (state root finalized and withdrawals unlocked)
• The sequencer constructs a batch, computes the state diff — only the net changes to storage, not every intermediate step — and posts it to Ethereum as calldata or blobs
• The state diff approach is more data-efficient than posting full transaction data, but it means you cannot reconstruct the full transaction history from L1 data alone without zkSync's help

What this means practically: Your transaction is included in an L2 block quickly, but it only reaches full Ethereum-grade finality once the batch it belongs to passes through all three stages — which currently takes hours.

The prover is the most computationally expensive part of the system. Its job: take everything the sequencer did in a batch and generate a cryptographic proof that all of it was done correctly. This proof is what makes the "zero-knowledge" part real.

• zkSync Era uses a custom proof system called Boojum, which generates STARK proofs using the Goldilocks field (a specific mathematical structure chosen because it's efficient on consumer-grade hardware)
• The prover breaks each batch into circuits — specialized mathematical representations of specific operations like storage writes, hash computations, and signature checks
• These individual circuit proofs get aggregated and then wrapped in a final SNARK proof (using FFLONK or similar schemes) that's small and cheap enough to verify in a single Ethereum transaction
• Proof generation is parallelized across many machines — a single batch may require thousands of CPU-hours, but spread across a GPU cluster it completes in minutes to low hours
• The proof confirms two things: every transaction in the batch was executed correctly according to EVM rules, and the resulting state root is accurate

What this means practically: The prover is why you don't need to trust the sequencer long-term. Even if the sequencer tried to forge a balance or steal funds, it could not produce a valid proof for that lie.

zkSync Era's L1 footprint is a set of smart contracts on Ethereum, organized using the diamond proxy pattern — a contract architecture where a single address delegates calls to multiple smaller contracts (called facets) that each handle different functions. This design allows upgrades to individual components without replacing the whole system.

• The Executor facet handles batch commitment, proof verification, and batch execution (finalization)
• The Getters facet exposes read-only data: batch status, state roots, protocol version
• The Mailbox facet manages L1 ↔ L2 messaging — deposits into zkSync, forced transaction inclusion, and withdrawal finalization
• The Admin facet controls upgrades, which currently go through a Security Council multisig and a timelock delay
• A critical nuance: the system is upgradeable, meaning the contract logic can be changed. This is a trust assumption — you're trusting the governance process not to deploy malicious upgrades

What this means practically: The diamond proxy is your actual trust anchor on Ethereum. Its upgrade policy determines how much you're trusting code versus trusting people.

Here's the complete lifecycle, from the moment you hit "send" to the moment Ethereum itself guarantees your transaction:

1. Submit transaction to the sequencer — your wallet sends a signed transaction to zkSync's RPC endpoint. The sequencer validates and queues it. This must happen first because the sequencer controls ordering.

2. Sequencer executes and includes in an L2 block — the transaction runs against the current state, and the result (balance changes, contract storage updates) gets recorded. This gives you a soft confirmation within seconds.

3. Sequencer seals a batch — once enough L2 blocks accumulate (or enough time passes), the sequencer groups them into a batch and computes the aggregate state diff.

4. Batch data committed to Ethereum — the sequencer posts the batch's state diffs and metadata to the diamond proxy's Executor facet. The batch status becomes "committed." This ensures the data is available even if zkSync goes offline.

5. Prover generates and submits validity proof — the prover processes the committed batch, generates a STARK proof, compresses it into a SNARK, and submits it to Ethereum. The L1 contract verifies the proof on-chain. Status becomes "proved."

6. Batch executed on Ethereum — after the proof verifies, the batch is finalized. The new state root is accepted, and any pending withdrawals from that batch become claimable on L1.

What this means practically: Steps 1–2 take seconds. Steps 3–6 currently take roughly 1–24 hours depending on network load. Your funds are fully secured only after step 6.

• zkSync Era executes transactions on its own chain, then proves correctness to Ethereum using validity proofs — security comes from math, not trust in validators
• The sequencer provides speed but is currently centralized; the prover provides security and is the real architectural innovation
• Transactions pass through five distinct stages (submitted → included → committed → proved → executed), and only the final stage gives Ethereum-equivalent finality
• The system is upgradeable via a diamond proxy contract on L1 — this is useful for improvements but means you're partially trusting governance, not just code