CrowdProve: Community Proving for ZK Rollups

Antonio Locascio; Benjamin Livshits; John Stephan; Matej Pavlovic

REVIEW 4 major objections 6 minor 8 references

CrowdProve: Community Proving for ZK Rollups

T0 review · 4 major / 6 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read CrowdProve claims 3,000 community CPUs can prove a ZKsync batch about 4x faster than its datacenter.

desk verdict A credible small-scale orchestration design for community ZK proving, but the headline 4x speedup is an ideal-parallelization extrapolation that ignores a JD-side verification bottleneck. read the letter →

arxiv 2501.03126 v1 pith:F3E4STOL submitted 2025-01-06 cs.DC

John Stephan , Matej Pavlovic , Antonio Locascio , Benjamin Livshits This is my paper · ORCID

classification cs.DC

keywords ZKrollupsvalidityproofscommunityprovingjobdistributorBoojumPLONKparallelproofgenerationByzantineresilience

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

A ZK rollup proves each batch of transactions with a validity proof that is recursively assembled from thousands of independent sub-proofs. The paper's claim is that those sub-proofs can be outsourced to a community of untrusted commodity machines without losing correctness or speed. CrowdProve's orchestration layer, built around a Job Distributor, hands each sub-proof to a polling prover, checks every returned proof, and reassigns jobs whose first prover is slow or dishonest. Measured per-job times on ordinary hardware, extrapolated to a real 17,188-job batch, give a batch time under 10 minutes with 3,000 eight-core CPU provers, about 4x faster than ZKsync's centralized pool, with breakeven at 723 CPU, 359 MacBook, or 107 GPU provers. A 5-to-20-machine run on 100 jobs shows near-linear throughput growth, and if that extrapolation holds, rollup operators can trade datacenter cost for community incentives while preserving correctness through per-proof verification.

What carries the argument

The load-bearing mechanism is the Job Distributor (JD), a coordinator the rollup operator places between the core prover database and a permissionless pool of community provers. The JD fetches the next unassigned witness, hands it to whichever prover polls for work, marks it running, tracks multiple outstanding copies of the same job with request IDs, verifies each returned proof, pays only the first valid submission, and re-queues uncompleted jobs through a Least-Recently-Processed (LRP) queue so that slow or malicious provers do not stall the batch. It works because the underlying Boojum/PLONK proof is a tree of thousands of independent, compact sub-proofs, with a job around 470 KB and a proof around 742 KB, making the work embarrassingly parallel and cheap to verify, roughly tens of milliseconds per proof on a single core.

What would settle it

Take the 17,188-job batch the paper uses, run it through CrowdProve with 723 and then 3,000 eight-core CPU provers, and compare the measured batch times to the paper's predicted 38.7 minutes and under-10 minutes; if the measured time grows with prover count faster than the linear formula predicts, the core scalability premise is wrong.

Watch

Extended reading notes

Core claim

The paper's central claim is that the hardest computation in a ZK rollup, producing the validity proof for a transaction batch, can be turned into a stream of independent jobs executed by untrusted community hardware. In Boojum, the PLONK-based prover used by ZKsync, a batch proof is recursively composed of thousands of small sub-proofs that are computed independently and verified cheaply. CrowdProve treats each sub-proof as a job: the Job Distributor fetches witnesses from the rollup's job database, assigns them to community provers that poll for work, keeps multiple copies of a job alive by tracking request IDs, verifies each submitted proof, pays only the first valid submission, and uses a Least-Recently-Processed queue to reassign jobs before the core system's 10-minute timeout would fire. The evaluation extrapolates per-job times, 97.6 s for an 8-core CPU, 67.7 s for a 16-core CPU, 48.5 s for an Apple M3 Max, and 14.4 s for an L4 GPU, to the 17,188 jobs of ZKsync batch 491452 and reports that 723 CPU, 502 16-core CPU, 359 MacBook, or 107 GPU provers respectively match the centralized 38.70-minute batch time, while 3,000 8-core CPUs bring a batch under 10 minutes. The authors are explicit that this is partial decentralization, because the rollup operator still runs the Job Distributor and the core system.

Load-bearing premise

The entire speedup argument rests on the assumption that doubling the number of provers halves the time to prove a batch, with no coordination, verification, or straggler overhead, since the large-batch numbers in Table 2 are extrapolated under 'ideal job distribution.'

Editorial extensions

If this is right

A ZK rollup operator can replace part or all of its cloud prover fleet with community hardware and still meet or beat current batch latency: 723 eight-core CPUs, 359 MacBooks, or 107 GPUs match the centralized 38.70-minute baseline, and 3,000 CPUs bring a batch under 10 minutes.
Proving cost can fall even while performance improves: at 0.06 cents per verified proof with 360 MacBook provers, the paper estimates matching current proving time while halving cost.
Correctness does not depend on trusting provers: every submitted proof is verified, duplicate assignments are tracked by request ID, and only the first valid proof is compensated.
Slow, failing, or malicious provers cannot stall a batch, because the LRP queue reassigns pending jobs without waiting for the core system's 10-minute timeout.
The system remains partially centralized: the Job Distributor is a single point of control, so full decentralization would require moving orchestration onto a replicated or blockchain-based coordinator.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

If the linear-scaling assumption is tested at the thousand-prover scale, the measured batch time may diverge from the per-job-time-times-jobs-divided-by-provers formula; the Job Distributor's tracking, verification, and reassignment could become bottlenecks well before 3,000 provers, so the real breakeven counts could be higher.
The same 'split the recursive batch proof into verified micro-jobs' recipe should transfer to other recursive proving systems, such as folding-based SNARKs, with per-job sizes and verification costs determining whether community proving remains economical.
The fixed-rate compensation model creates an incentive mismatch: high-end GPU provers are paid the same as slow CPUs, so time-based or auction-based pricing could allocate work more efficiently at the cost of more complex incentive engineering.
Because the experiments assume honest provers, a direct Byzantine stress test, with a fraction of provers hoarding jobs or submitting invalid proofs, would quantify how much LRP reassignment actually costs in latency and duplicated work.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

The paper is worth a serious look: it builds an orchestration layer for outsourcing Boojum proving jobs to community machines and reports real per-job measurements on four hardware classes. The 5-to-20 machine, 100-job deployment showing near-linear speedup is genuine evidence that the basic pipeline works at small scale, and the paper is honest that orchestration remains centralized. The specific combination of a work-queue JD with LRP reassignment for ZK proving is modestly novel; the individual pieces are standard, but applying them to Boojum's recursive proof structure is useful.

The soft spots are real and load-bearing. The headline 4x speedup and the breakeven numbers come from Table 2, which divides job count times per-job time by prover count under 'ideal job distribution.' That ignores the JD's per-proof verification, which the paper itself says takes tens of milliseconds. At 3,000 provers and 17,188 jobs, 50 ms per proof is 14.3 minutes of serial verification, already above the claimed 9.32-minute batch time; even 20 ms is 5.7 minutes. The 20-machine experiment with 100 jobs cannot detect this because verification there is only seconds. So the central stress-test concern lands: the paper has not ruled out a JD bottleneck at the claimed scale.

The Byzantine-resilience contribution is also untested. Section 4.1 explicitly assumes honest provers, so the latency impact of LRP under failures or malicious hoarding is not measured. The cost-savings conclusion depends on Matter Labs' internal baseline (0.0012 USD/job) and an assumed community payout of 0.06 cents, making the half-cost claim conditional on those numbers. The conclusion contains an unfinished placeholder ('XXX...'), and no code or data are shipped, so the measurements cannot be independently checked.

Still, none of this kills the core idea. The per-job times are concrete, the small-scale scaling experiment is real, and the feasibility direction—community hardware can prove Boojum jobs at reasonable speed—holds up. What does not hold up is the specific claim of matching or beating the centralized deployment. If the JD can verify in parallel or batch proofs, the bottleneck may be solvable, but this paper has not shown it.

Send it to peer review. It deserves referee time, but the authors should be pushed to either measure at larger scale, bound the JD overhead, or narrow the claims. A revised version that ships code and replaces the extrapolated speedup with measured end-to-end numbers would be a solid contribution to the rollup-proving literature.

Referee Report

4 major / 6 minor

Summary. The paper proposes CrowdProve, an orchestration layer that lets a central Job Distributor (JD) outsource individual ZK proof jobs from the ZKsync Boojum proving pipeline to community-run commodity hardware, with per-proof verification and a Least-Recently-Processed (LRP) reassignment mechanism to handle slow or faulty provers. The authors implement the system, measure per-job proving times on 8-core CPUs, 16-core CPUs, MacBooks, and GPUs (Table 1), extrapolate batch proving times for a real 17,188-job batch under ideal parallelization (Table 2), and run a small distributed deployment with 5-20 CPU machines over 100 jobs (Table 3). The headline claim is that 3,000 8-core CPU community provers can prove a real batch in under 10 minutes, roughly 4x faster than the current centralized ZKsync deployment, with breakeven at 723 CPU provers, and that community-based proving can be cost-effective under fixed compensation.

Significance. If the central claim holds, the paper would provide a concrete, implemented demonstration that community-sourced hardware can match or beat a centralized datacenter prover pool for ZK rollup proof generation, which is a practically relevant result for rollup decentralization and cost reduction. The paper has real strengths: a working implementation of the JD and community prover module, clearly specified per-job times for several hardware classes, a small end-to-end deployment with measured near-linear speedup (Table 3), and unusually explicit statements of the idealization assumptions used in the batch-time extrapolation. The contribution is incremental relative to prior distributed-proving systems (DIZK, Pianist) in that the proving tasks themselves are taken as black boxes, but the community-facing incentive and reliability angle is a useful addition. The significance is moderate and contingent on closing the scale-up gap between the 20-machine experiment and the 3,000-prover claim.

major comments (4)

[Section 4.2, Table 2] The 'approximately 4x faster' headline and all breakeven numbers rest on the assumption that total batch time equals (jobs × per-job time) / prover count with no JD-side serialization or capacity limit. The only empirical support is a 5-to-20-machine run over 100 jobs (Table 3), which cannot expose a single-point bottleneck at the JD. This assumption is load-bearing and unverified at the claimed scale of 3,000 provers; the paper should either add measurements of JD throughput, queueing, and verification rates at increasing prover counts, or scale back the headline claim to the range that the experiments actually cover.
[Section 3.4 and Section 4.2] The per-proof verification cost at the JD is a concrete serializing operation that the extrapolation ignores. The paper states that verification takes 'tens of milliseconds on a single-core machine' (Section 3.4); for a batch of 17,188 jobs, sequential verification at 50 ms per proof takes about 14.3 minutes, which alone exceeds the 9.32 minutes claimed for 3,000 8-core CPU provers, and at 20 ms it consumes over half the claimed batch time. The paper does not state whether verification is parallelized, batched, or offloaded, nor does it account for this cost in Table 2. Since the JD is the single coordinator, this is a potential bottleneck that must be measured or explicitly argued away before the performance claim can be accepted.
[Section 4.1 and Section 3.1.3] The Byzantine-resilience claims are untested. Section 4.1 states that the experiments 'assume honest provers,' so the LRP mechanism's ability to prevent delays under job hoarding, failures, or malicious submissions — a stated key contribution in Section 1.2 and Section 3.1.3 — is not validated empirically. The paper should either add experiments with injected failures and Byzantine behaviors (measuring tail latency and reassignment overhead) or explicitly reframe the contribution as a design for resilience rather than a demonstrated property.
[Section 4.2, Proving Cost Under Fixed Compensation] The cost-savings conclusion depends on the assumed community payout rate, which is a free parameter. The example sets the payout at 0.06 cents per proof, half of Matter Labs' internal per-job cost estimate of 0.0012 USD, and then concludes that costs are halved. This is a fair illustration of a fixed-rate model, but the paper does not justify that community provers would accept this rate, and the cost claim is therefore conditional on an unvalidated market assumption. The performance claim is independent of this, but the economic conclusion should be presented as a scenario, not as an empirical result.

minor comments (6)

[Section 1, line 1] Typo: 'zero-knowkedge' should be 'zero-knowledge'.
[Section 7, Conclusion] The conclusion contains an unfinished placeholder text: 'our experiments demonstrate that XXX...' This must be completed before submission.
[References] References [2], [3], and [6] lack years and venue information; reference [7] has an access date of '24-09-2024' which should be standardized.
[Section 4.1] The statement that network delays 'averaged around 10 ms' is given without experimental details; a brief description of how this was measured would improve reproducibility.
[Section 3.4] The phrase 'tens of milliseconds' for proof verification is too coarse for a quantitative scale analysis; reporting a measured range and the hardware used would allow readers to assess the bottleneck concern directly.
[Table 2 and Figure 2] The caption of Table 2 notes the 'ideal job distribution' assumption, which is good, but Figure 2's logarithmic plot presentation should be described in the text to clarify which data points correspond to the extrapolated regime versus the measured regime.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the headline throughput numbers are transparent arithmetic extrapolations from measured per-job times against an external baseline; the main gaps are evidential, not circular.

full rationale

The claimed derivation chain is: measure per-job proving time on representative hardware (Table 1); extrapolate batch time for 17,188 jobs as N_jobs × t_job / P under an explicitly stated 'ideal job distribution' assumption (Table 2); compare to the external 38.70-minute ZKsync baseline; and run a small 5-to-20-machine / 100-job deployment (Table 3) to test the linear-scaling assumption. Each step is transparent, and the output is not defined in terms of the comparison baseline, nor is any fitted parameter renamed as a prediction. The cost-reduction example ('0.06 cents per proof' vs the '0.0012 USD' internal estimate) is arithmetic by construction, but it is presented as a conditional scenario, not as a measured result, so it does not make the central claim circular. There are no load-bearing self-citations: the only ZKsync citation [7] is an external system reference, and no prior work by the authors is invoked to justify the orchestration design. The notable weaknesses are evidential rather than circular: Section 4.1 explicitly assumes honest provers, so the Byzantine-resilience claim (Section 3.4) is not empirically validated; Table 3's 20-machine run does not rule out a JD-side verification bottleneck at 3,000 provers (Section 3.4 states verification takes 'tens of milliseconds' per proof, which at 17,188 proofs could consume minutes serially); and Section 7 contains an unfinished placeholder ('our experiments demonstrate that XXX...'). These affect confidence in the extrapolation, but none is a case where the paper's derivation reduces to its own inputs.

Assumptions & free parameters 1 free parameters · 4 assumptions · 2 invented entities

The central performance claim rests on three unpaid inputs: measured per-job times on four hardware types, an internal Matter Labs baseline for comparison, and an ideal-parallelization extrapolation that carries the headline results. The cost claim rests on a hand-chosen payout rate. The Byzantine-resilience claim rests on an untested algorithmic argument. Free parameters and assumptions are modest in count, but the largest one (linear scaling to thousands of provers) is load-bearing and unvalidated at scale.

free parameters (1)

Community payout rate = 0.06 cents (0.0006 USD) per proof
Chosen by the authors for the cost scenario; the 'cost reduced by half' conclusion is an arithmetic consequence of setting this rate to half the internal ZKsync estimate (Section 4.2).

assumptions (4)

domain assumption Ideal job distribution and perfect parallelization hold at scale
Table 2 computes total batch time as jobs times per-job time divided by prover count, with the caption noting 'ideal job distribution among the provers'; the 5-to-20 machine experiment does not validate this at hundreds or thousands of provers.
domain assumption All provers are honest in the experiments
Section 4.1 states experiments assume honest provers, so the Byzantine-resilience contribution (LRP reassignment) is never empirically exercised; its claimed benefits rest on informal argument.
domain assumption ZKsync baseline metrics are accurate
The 38.70-minute proving time for batch 491452 and the 0.0012 USD per-job cost are internal Matter Labs estimates cited only to 'the current ZKsync deployment', with no reproducible source.
domain assumption Job Distributor overhead is negligible at scale
The paper notes proof verification takes tens of milliseconds and network latency averages about 10 ms, and Table 2 ignores these; at 17,188 jobs and up to 3,000 provers, serialized verification and queue management could add minutes that the extrapolation omits.

invented entities (2)

Job Distributor (JD)
purpose: Central proxy that assigns proving jobs to community provers, tracks request_ids, verifies submitted proofs, and triggers LRP reassignment
Described in prose with no shipped code or public deployment; the paper's own experiments treat it as part of the testbed, so there is no falsifiable handle outside the paper.
Least-Recently-Processed (LRP) reassignment mechanism
purpose: Reassigns pending jobs to new provers to tolerate slow or malicious provers without waiting for core timeouts
The mechanism is specified algorithmically and could be reimplemented, but its claimed Byzantine-resilience benefit is not tested in the paper (experiments assume honest provers), so no independent evidence is provided.

how reviews work

0 comments

Cite this review

Pith. "Pith review of CrowdProve: Community Proving for ZK Rollups." pith.science (2026). https://pith.science/paper/F3E4STOL

@misc{pith2026250103126,
  author       = {Pith},
  title        = {Pith review of: CrowdProve: Community Proving for ZK Rollups},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/F3E4STOL}},
  note         = {Machine review of arXiv:2501.03126}
}

read the original abstract

Zero-Knowledge (ZK) rollups have become a popular solution for scaling blockchain systems, offering improved transaction throughput and reduced costs by aggregating Layer 2 transactions and submitting them as a single batch to a Layer 1 blockchain. However, the computational burden of generating validity proofs, a key feature of ZK rollups, presents significant challenges in terms of performance and decentralization. Current solutions rely on centralized infrastructure to handle the computational tasks, limiting the scalability and decentralization of rollup systems. This paper proposes CrowdProve, a prover orchestration layer for outsourcing computation to unreliable commodity hardware run by a broad community of small provers. We apply CrowdProve to proving transaction batches for a popular ZK rollup. Through our experimental evaluation, we demonstrate that community proving can achieve performance comparable to, and in some cases better than, existing centralized deployments. Our results show that even systems utilizing modest hardware configurations can match the performance of centralized solutions, making community-based proof generation a viable and cost-effective alternative. CrowdProve allows both the rollup operator and community participants to benefit: the operator reduces infrastructure costs by leveraging idle community hardware, while community provers are compensated for their contributions.

Figures

Figures reproduced from arXiv: 2501.03126 by the authors.

**Figure 1.** System Architecture of CrowdProve detailed overview of the architecture components in Sections 3.1.1 and 3.1.2, and explain the LRP mechanism in Section 3.1.3. 3.1.1 Community Prover Module. This module is a key component that enables public participation in the proving process. It consists of software that community members can download and run on their own machines, allowing them to contribute computational resou… view at source ↗

**Figure 2.** Proving time in minutes for 17,188 jobs when varying the number of provers under different hardware configurations. Left: linear scale, right: logarithmic scale for better clarity on lower values [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗

**Figure 3.** Total number of jobs executed per minute, when proving 100 jobs of Circuit ID 1 and Aggregation Round 0 across varying number of (8 CPU, 32 GB RAM)-provers. distributed system with 5, 10, 15, and 20 machines and measured the total proving time. For simplicity, we consider (8-core, 32 GB RAM) CPU machines, and a total of 100 proving jobs [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

8 extracted references · 7 canonical work pages

[1]

Wenqing Hu, Tianyi Liu, Ye Zhang, Yuncong Zhang, and Zhenfei Zhang

work page
[2]

Chongrong Li, Yun Li, Pengfei Zhu, Wenjie Qu, and Jiaheng Zhang. [n. d.]. HyperPianist: Pianist with Linear-Time Prover via Fully Dis- tributed HyperPlonk. ([n. d.])

work page
[3]

Tianyi Liu, Tiancheng Xie, Jiaheng Zhang, Dawn Song, and Yupeng Zhang. [n. d.]. Pianist: Scalable zkRollups via Fully Distributed Zero- Knowledge Proofs. ([n. d.])

work page
[4]

Wilson Nguyen, Trisha Datta, Binyi Chen, Nirvan Tyagi, and Dan Boneh. 2024. Mangrove: A Scalable Framework for Folding-based SNARKs

work page 2024
[5]

Yuyang Sang, Ning Luo, Samuel Judson, Ben Chaimberg, Timos Antonopoulos, Xiao Wang, Ruzica Piskac, and Zhong Shao. 2023. Ou: Automating the Parallelization of Zero-Knowledge Protocols. In Pro- ceedings of the 2023 ACM SIGSAC Conference on Computer and Com- munications Security. ACM, Copenhagen Denmark, 534–548. https: //doi.org/10.1145/3576915.3616621

arXiv 2023
[6]

Howard Wu, Wenting Zheng, Alessandro Chiesa, Raluca Ada Popa, and Ion Stoica. [n. d.]. DIZK: A Distributed Zero Knowledge Proof System. ([n. d.])

work page
[7]

ZKSync. [n. d.]. ZKSync: Scaling Ethereum with Zero-Knowledge Proofs. https://zksync.io/. Accessed: 24-09-2024. 13

work page 2024
[2024]

Parallel Zero-knowledge Virtual Machine

work page

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.

[1] [1]

Wenqing Hu, Tianyi Liu, Ye Zhang, Yuncong Zhang, and Zhenfei Zhang

work page

[2] [2]

Chongrong Li, Yun Li, Pengfei Zhu, Wenjie Qu, and Jiaheng Zhang. [n. d.]. HyperPianist: Pianist with Linear-Time Prover via Fully Dis- tributed HyperPlonk. ([n. d.])

work page

[3] [3]

Tianyi Liu, Tiancheng Xie, Jiaheng Zhang, Dawn Song, and Yupeng Zhang. [n. d.]. Pianist: Scalable zkRollups via Fully Distributed Zero- Knowledge Proofs. ([n. d.])

work page

[4] [4]

Wilson Nguyen, Trisha Datta, Binyi Chen, Nirvan Tyagi, and Dan Boneh. 2024. Mangrove: A Scalable Framework for Folding-based SNARKs

work page 2024

[5] [5]

Yuyang Sang, Ning Luo, Samuel Judson, Ben Chaimberg, Timos Antonopoulos, Xiao Wang, Ruzica Piskac, and Zhong Shao. 2023. Ou: Automating the Parallelization of Zero-Knowledge Protocols. In Pro- ceedings of the 2023 ACM SIGSAC Conference on Computer and Com- munications Security. ACM, Copenhagen Denmark, 534–548. https: //doi.org/10.1145/3576915.3616621

arXiv 2023

[6] [6]

Howard Wu, Wenting Zheng, Alessandro Chiesa, Raluca Ada Popa, and Ion Stoica. [n. d.]. DIZK: A Distributed Zero Knowledge Proof System. ([n. d.])

work page

[7] [7]

ZKSync. [n. d.]. ZKSync: Scaling Ethereum with Zero-Knowledge Proofs. https://zksync.io/. Accessed: 24-09-2024. 13

work page 2024

[8] [2024]

Parallel Zero-knowledge Virtual Machine

work page