[Paper] push0: Scalable and Fault-Tolerant Orchestration for Zero-Knowledge Proof Generation

Source: arXiv - 2602.16338v1

Overview

Zero‑knowledge (ZK) proof generation is a performance bottleneck for modern blockchain scaling solutions such as ZK‑rollups and Ethereum’s upcoming zkEVM. The paper “push0: Scalable and Fault‑Tolerant Orchestration for Zero‑Knowledge Proof Generation” introduces a cloud‑native orchestration layer that schedules proof‑generation jobs across many prover instances while guaranteeing strict block ordering, sub‑slot latency, and automatic recovery from failures. The authors demonstrate that push0 can keep the orchestration overhead to a few milliseconds—practically invisible compared with the 7‑second‑plus compute time of a typical proof—making real‑time, stateless validation on Ethereum feasible.

Key Contributions

• Event‑driven dispatcher‑collector architecture built on persistent priority queues that enforces head‑of‑chain ordering while exploiting parallelism inside a block.
• Prover‑agnostic scheduling primitives that let operators plug in any zkVM binary without rewriting orchestration logic.
• Fault‑tolerant task reassignment via durable message queues, enabling automatic recovery from node crashes or network hiccups.
• Production‑grade evaluation on a Kubernetes cluster and on the live Zircuit rollup (14 M+ blocks), showing sub‑10 ms median orchestration latency and near‑perfect scaling up to 32 dispatchers.
• Formalization of real‑time proving requirements derived from Ethereum’s 12‑second slot window and ZK‑rollup finality constraints.

Methodology

1. Requirement Formalization – The authors distilled four hard constraints from production rollup operators and the Ethereum zkEVM spec: (i) strict sequential ordering of blocks, (ii) proof completion within a sub‑slot deadline, (iii) resilient reassignment of failed tasks, and (iv) support for heterogeneous provers.
2. System Design – push0 separates the dispatcher (which pulls block‑level jobs from a priority queue and hands them to available provers) from the collector (which gathers completed proofs and acknowledges the queue). Both components are stateless services running in containers, communicating through a durable message broker (e.g., NATS JetStream or Kafka).
3. Scheduling Logic – Jobs are prioritized by block height; the dispatcher only releases a proof task when all earlier blocks have been marked complete, guaranteeing head‑of‑chain ordering. Within a block, the dispatcher can fan‑out multiple sub‑tasks (e.g., proving different shards) to exploit intra‑block parallelism.
4. Fault Tolerance – If a prover container crashes or a task times out, the message remains un‑acknowledged in the queue and is automatically re‑queued for another dispatcher.
5. Evaluation – Two experimental setups were used: (a) a controlled Docker environment to isolate network variance, and (b) a production‑scale Kubernetes cluster mirroring the Zircuit rollup’s workload. Metrics captured include median orchestration latency, scaling efficiency, and overhead as a percentage of total proof time.

Results & Findings

• Negligible Overhead: Even at peak load, orchestration adds less than one‑tenth of a percent to the total proof generation time.
• Linear Scaling: Adding dispatchers yields almost perfect linear speed‑up, confirming that the queue‑based design avoids contention.
• Robustness: Simulated node failures were recovered automatically without manual intervention, keeping the overall block‑finality deadline intact.
• Real‑World Validation: The system has processed over 14 million mainnet blocks on Zircuit, confirming that the lab results translate to production traffic.

Practical Implications

• For Rollup Operators: push0 offers a plug‑and‑play scheduler that can be dropped into existing proving pipelines, reducing the engineering effort needed to meet sub‑second finality targets.
• For zkEVM Deployments: By keeping orchestration latency under 10 ms, the system fits comfortably within Ethereum’s 12‑second slot, enabling stateless validation and potentially lowering gas costs for proof verification.
• Multi‑Prover Ecosystems: The prover‑agnostic API means operators can experiment with newer, faster zkVMs (e.g., PLONK‑based, Halo2) without rewriting orchestration code, fostering a more competitive prover market.
• Cloud‑Native Deployments: Because push0 runs as containerized micro‑services on Kubernetes, it can leverage auto‑scaling, observability, and security features already present in modern cloud stacks.
• Cost Savings: With orchestration overhead essentially zero, compute resources are fully dedicated to proof generation, improving hardware utilization and reducing operational expenses.

Limitations & Future Work

• Network‑Bound Scenarios: The study assumes a relatively stable intra‑cluster network; extreme latency or packet loss could affect queue consistency and task reassignment latency.
• Prover Heterogeneity Overheads: While the API is prover‑agnostic, the paper does not quantify the impact of mixing provers with vastly different runtime characteristics on overall throughput.
• Security Audits: The orchestration layer itself becomes a critical component; formal security analysis and hardened implementations are left for future work.
• Decentralized Governance: Extending push0 to support truly decentralized multi‑prover networks (e.g., with on‑chain incentive mechanisms) is an open research direction.

Authors

• Mohsen Ahmadvand
• Rok Pajnič
• Ching-Lun Chiu

Paper Information

• arXiv ID: 2602.16338v1
• Categories: cs.DC, cs.CR
• Published: February 18, 2026
• PDF: Download PDF