Zero knowledge rollups

Zero-knowledge rollups submit a validity proof that the settlement contract verifies before accepting a state transition. As Ethereum's ZK-rollup documentation notes, a validity proof lets the settlement contract verify the proposed state transition without an optimistic fraud-challenge period. Final withdrawal behavior still depends on the stack's bridge and finality rules. Operational importance shifts to proof generation, proof submission, circuit compatibility, and proving capacity.

For ZK Stack deployment code, see ZK-sync. For the Polygon CDK architecture and its prover, aggregator, bridge, and DA roles, see POL-RAAS and the Polygon CDK deployment model.

Operational implications

Proving infrastructure is a production dependency. Track queue depth, proof duration, failure rate, hardware saturation, and the age of the oldest unproved batch.
Circuit, verifier, and protocol upgrades must be coordinated. A mismatch can halt proof acceptance even if execution remains healthy.
Data availability still matters. A proof validates a transition; it does not by itself give users the data needed to reconstruct state.
Capacity planning must include peak transaction volume, proof aggregation behavior, accelerator availability where used, and settlement costs.

Readiness checks

Exercise the full path from transaction ingestion through proving, submission, verification, indexing, and withdrawal. Keep a tested rollback and compatibility plan for the prover and verifier versions, and alert before proving lag becomes a user-visible backlog.

Proving pipeline

Treat proving as a queueing system with explicit inputs, workers, outputs, and failure handling:

Execution produces a batch and the witness or state data required by the prover.
A coordinator assigns the work to an available prover.
The prover produces a proof and records its artifact, version, duration, and resource use.
An aggregator combines proofs where the stack supports aggregation.
A submitter sends the proof to the verifier contract and tracks settlement confirmation.

At every stage, retain a durable job identifier and enough metadata to reproduce a failed job. A retry that silently uses a different circuit, witness source, or configuration can make an incident harder to diagnose. The ZKsync transaction lifecycle provides a current example of sequencing, proving, and L1 submission roles.

Capacity model

Size proving capacity from measured batches rather than average transactions per second alone. Record the largest representative witness, p50 and p95 proving duration, concurrency, accelerator memory use, queue growth during a burst, and the time to recover from a lost worker. Include planned circuit upgrades in the model because they can change resource requirements materially.

Set a maximum proof-age objective. When the oldest unproved batch exceeds it, alert before settlement lag turns into a bridge or withdrawal incident. Keep a runbook for degraded capacity that specifies whether the sequencer throttles intake, reduces block size, pauses new batches, or uses a fallback proving path.

Version compatibility

Proof systems add a strict compatibility boundary between execution, witness generation, prover, aggregator, and verifier contract. Release manifests should record all of those versions and their expected contract addresses. Do not roll out a prover image independently of a verifier or circuit change without proving a representative batch in the target environment first.