{"id":"875a6811-4c37-4db5-934c-0378c24577d6","arxiv_id":"2501.03126","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"CrowdProve is a job-orchestration layer that lets ZK rollup proving be outsourced to untrusted community hardware, and the paper reports time and cost performance comparable to centralized proving, with some extrapolated speedups.","lead":"This paper presents CrowdProve, an orchestration layer that lets ZK rollup operators outsource proof-generation jobs to a community of untrusted consumer-grade machines. The authors report that community proving can match or beat the current centralized ZKsync deployment in time and cost, but the headline numbers are extrapolated from small-scale tests.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 4x speedup claim rests on an ideal-linear-scaling extrapolation from 20 machines; no evidence rules out a Job Distributor verification bottleneck at 3,000 provers.","rationale":"CrowdProve is a plausible orchestration design, and the small-scale measurements—per-job times on four hardware classes and near-linear speedup from 5 to 20 machines—are genuine evidence that the basic parallelization mechanism works. The paper's central claim, however, is not just that speedup exists on 20 machines; it is that a real 17,188-job batch can be proven in under 10 minutes by 3,000 community CPU provers, roughly 4x faster than ZKsync's centralized deployment. For that claim to hold, total batch time must equal jobs × per_job_time / prover_count with no significant serial bottleneck at the Job Distributor. Section 3.4 itself acknowledges that the JD verifies every proof and that verification takes tens of milliseconds; at 17,188 jobs this is a serial cost of order minutes, comparable to the entire claimed batch time. The 100-job, 20-machine experiment cannot detect this because it generates only 100 verifications and does not stress the JD with thousands of concurrent provers. The Byzantine-resilience claim is also untested, since Section 4.1 states the experiments assume honest provers, so LRP reassignment costs are absent from the measurements. These are not internal inconsistencies; they are extrapolation gaps in a paper that otherwise makes a credible feasibility case. A conditional verdict remains appropriate: the direction is plausible, but the headline outperformance claim needs either a scale test that exercises the JD at the claimed prover count or a narrowed claim about what is actually demonstrated. The reader's weakest-assumption diagnosis identifies the same load-bearing premise, and our analysis sharpens it with a concrete verification-bottleneck mechanism.","tokens_in":15388,"tokens_out":2719,"duration_ms":27506,"concrete_test":"Run the Job Distributor against 17,188 real Round-0 jobs with 3,000 simulated or real community provers, while measuring end-to-end batch proving time, JD CPU utilization, per-proof verification latency, queue lengths, and reassignment counts. If the measured batch time exceeds jobs × per_job_time / prover_count by more than a small margin, or if JD verification/queueing time is a non-negligible fraction of the 9.32-minute budget, the Table 2 extrapolation fails. A cheaper analytical check: multiply 17,188 by the measured single-core verification latency (including tail latencies) to see whether the verification budget alone fits under 9.32 minutes; if not, sequential verification is already a demonstrated bottleneck.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 4.2's headline result (17,188 jobs in under 10 minutes with 3,000 8-core CPUs, with a 723-prover breakeven) is computed as jobs_per_batch × per_job_time / prover_count under 'ideal job distribution' (Table 2). The only empirical validation is a 5-to-20-machine run over 100 jobs (Table 3), which is far too small to expose serializing costs at the Job Distributor. One concrete such cost is the per-proof verification the JD must perform for every submitted job (Section 3.2, step 5). The paper states verification takes 'tens of milliseconds on a single-core machine' (Section 3.4). Sequential verification of 17,188 proofs at even 50 ms is about 14.3 minutes, already above the 9.32 minutes claimed for 3,000 CPU provers; at 20 ms it is about 5.7 minutes, a large fraction of the claimed batch time. The JD's queue and hashmap operations, network I/O, and LRP reassignments add further serial work that the 20-machine experiment cannot detect. In addition, the Byzantine-resilience contribution is untested: Section 4.1 explicitly assumes honest provers, so the latency impact of LRP under failures or malicious job hoarding is not measured. The load-bearing premise—that total batch time equals per-job time divided by prover count with no JD-side bottleneck—is therefore not established at the claimed scale.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":15621,"tokens_out":2748,"duration_ms":26671,"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":[{"comment":"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":"Section 4.2, Table 2"},{"comment":"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":"Section 3.4 and Section 4.2"},{"comment":"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":"Section 4.1 and Section 3.1.3"},{"comment":"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.","section":"Section 4.2, Proving Cost Under Fixed Compensation"}],"minor_comments":[{"comment":"Typo: 'zero-knowkedge' should be 'zero-knowledge'.","section":"Section 1, line 1"},{"comment":"The conclusion contains an unfinished placeholder text: 'our experiments demonstrate that XXX...' This must be completed before submission.","section":"Section 7, Conclusion"},{"comment":"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":"References"},{"comment":"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":"Section 4.1"},{"comment":"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.","section":"Section 3.4"},{"comment":"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.","section":"Table 2 and Figure 2"}],"recommendation":"major_revision","confidential_remarks":"The paper's authors are affiliated with Matter Labs, and the baseline performance and cost figures (38.70-minute batch, 0.0012 USD per job) are internal Matter Labs data. This does not by itself invalidate the comparison, but the lack of independent baseline verification, combined with the reliance on ideal-linear-scaling extrapolation, raises a novelty and credibility risk that the authors should address head-on in the revision. The paper may also be on the applied edge for a theory-oriented venue; its contribution is primarily a systems evaluation with a partial decentralization narrative."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","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.\n\nThe 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.\n\nThe 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.\n\nStill, 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.\n\nSend 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.","headline":"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.","tokens_in":16238,"tokens_out":2137,"would_cite":true,"duration_ms":22406,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"CrowdProve claims 3,000 community CPUs can prove a ZKsync batch about 4x faster than its datacenter.","keywords":["ZK rollups","validity proofs","community proving","job distributor","Boojum","PLONK","parallel proof generation","Byzantine resilience"],"falsifier":"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.","tokens_in":15109,"feed_emoji":"🖥️","tokens_out":10088,"duration_ms":83796,"temperature":0.7,"pith_summary":"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.","feed_headline":"CrowdProve: 3,000 community CPUs beat a ZK datacenter by 4x","feed_subtitle":"A real 17,188-job batch is proved in under 10 minutes on ordinary 8-core machines, not a centralized prover pool.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Defines the baseline system (ZKsync/Boojum prover), its 38.70-minute proving time for the 17,188-job batch, and the per-job cost estimate that CrowdProve is compared against.","marker":"[7]"},{"why":"Pianist is cited as prior work showing PLONK-based zkRollup proofs can be split across many machines with minimal inter-machine communication; CrowdProve treats such per-machine tasks as the black-box jobs it distributes.","marker":"[3]"},{"why":"DIZK is cited as the pioneering distributed ZK proof system whose parallel job-splitting approach CrowdProve adapts from trusted clusters to untrusted community hardware.","marker":"[6]"}],"fun_headline_variants":["3,000 8-core CPUs prove ZK batch in 10 min","Community hardware matches ZK datacenter, 4x cheaper","CrowdProve: Turn idle PCs into ZK prover pool","ZK rollup validity proofs from untrusted home CPUs"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.'","fun_headline_variants_meta":{"raw":{"variants":["3,000 8-core CPUs prove ZK batch in 10 min","Community hardware matches ZK datacenter, 4x cheaper","CrowdProve: Turn idle PCs into ZK prover pool","ZK rollup validity proofs from untrusted home CPUs"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000204,"raw_usage":{"total_tokens":1466,"prompt_tokens":1097,"completion_tokens":369,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":713,"completion_tokens_details":{"reasoning_tokens":293}},"tokens_in":713,"tokens_out":369,"duration_ms":4105,"temperature":1.0,"reasoning_tokens":293,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T21:53:12.750500+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines the baseline system (ZKsync/Boojum prover), its 38.70-minute proving time for the 17,188-job batch, and the per-job cost estimate that CrowdProve is compared against."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Pianist is cited as prior work showing PLONK-based zkRollup proofs can be split across many machines with minimal inter-machine communication; CrowdProve treats such per-machine tasks as the black-box jobs it distributes."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"DIZK is cited as the pioneering distributed ZK proof system whose parallel job-splitting approach CrowdProve adapts from trusted clusters to untrusted community hardware."}],"review_version":1}