{"id":"91ba8bff-1b4a-469d-bc69-999bf1c86154","arxiv_id":"2510.09729","paper_version":2,"verdict":"REJECT","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"high","formal_verification":"none","parameter_count":3,"one_line_summary":"A proof-of-useful-work protocol where mining consists of generating client-outsourced zk-SNARK proofs, claimed to be the first consensus-layer general-purpose SNARK marketplace satisfying PoW properties.","lead":"This paper proposes a blockchain consensus protocol in which miners secure the network by computing client-outsourced zk-SNARK proofs, turning proof-of-work's wasted electricity into useful cryptographic work. It also sketches a consensus-layer marketplace for proof generation, claiming to be the first such system that satisfies all standard PoW properties.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"WOO private-input extension is not executable: Groth16 proving key alone doesn't let a worker compute a proof, and sharing the R1CS exposes the hardcoded mask.","rationale":"The reader's verdict is REJECT, and my stress-test supports that verdict. The single most load-bearing concern is the private-input extension (WOO) in Appendix B. The paper's strongest claim is that SNARKChain is the first PoUW consensus protocol that doubles as a general-purpose zk-SNARK marketplace while meeting all necessary PoW properties. The base protocol explicitly handles only public parameters (Section 4.5), so the zero-knowledge aspect of the marketplace rests entirely on the WOO extension. If WOO fails, the 'zk-SNARK marketplace' contribution collapses to a public-parameter SNARK marketplace, which is materially weaker than advertised.\n\nI agree with the reader that WOO is unsound, but I would phrase the mechanism somewhat differently. The reader says the mask is recoverable from the proving key itself because the proving key encodes the R1CS. In a concrete Groth16 implementation, the proving key is a list of group elements; extracting a field constant like r_in from those group elements would require solving a discrete logarithm, so 'recoverable' is not immediate in that form. The deeper, more robust flaw is that the worker cannot compute a Groth16 proof without knowing the R1CS to evaluate the circuit and compute intermediate values. Therefore the protocol must either reveal the R1CS to the worker—in which case the hardcoded r_in is plainly visible as a constraint constant and the mask provides no confidentiality—or withhold it, in which case the worker cannot generate the proof. Section 4.4's registry, which stores and serves the original source code, makes the first horn even more explicit. There is no middle ground.\n\nThe paper offers no formal verification and no released code for the extension; the only benchmark (Figure 11) measures obfuscated vs. raw proof time while assuming the WOO pipeline works, so it cannot detect this correctness failure. The PoW-properties analysis is also informal and the simulation encodes the protocol's own model, but the WOO flaw alone is sufficient to reject the paper as written. This is not an ad hominem or a disagreement with consensus; it is an internal inconsistency in the proposed construction. The base public-parameters idea may be salvageable, but the central claimed contribution is not established.","tokens_in":16070,"tokens_out":8655,"duration_ms":483542,"concrete_test":"Implement the Appendix B.3 WOO workflow in Circom/snarkjs for a small circuit (e.g., s1 + s2 = out). Compile the circuit with a hardcoded additive mask r_in, run a Groth16 trusted setup, and have a worker attempt to generate a valid proof given only the proving key and a masked input, with no access to the R1CS/source file. If the worker cannot produce a proof, the scheme is not executable as specified. If, to make proof generation succeed, the worker must use the R1CS/source, verify that r_in is directly readable from the constraint constants and that the original private input is recoverable from the masked input, demonstrating the privacy break.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim depends on the private-input extension (Appendix B, WOO) to make the SNARK marketplace a genuine zero-knowledge marketplace. That extension is internally inconsistent with the protocol's own circuit registry and with Groth16's prover requirements.\n\nSection 4.4 says the circuit registry stores and serves the original circuit source code, proving keys, and verification keys to miners. Appendix B.3 instead claims that in the WOO mode, 'the R1CS and masks are kept private' and only the proving key and obfuscated witness are sent to the worker. But a Groth16 prover cannot generate a proof from a proving key alone: it must know the R1CS to compute intermediate wire assignments and the h(x) polynomial. If the worker is given the R1CS or source to perform the computation, then r_in (hard-coded into the circuit as a constant in B.2) is directly visible, so the worker can compute s_in = \\hat{s_in} - r_in and the zero-knowledge property is lost. If the R1CS is withheld, the worker cannot compute the witness or the proof at all.\n\nThus there is no coherent mode in which a worker can both generate a valid Groth16 proof and remain ignorant of the private inputs. This breaks the advertised zk-SNARK marketplace, which is one of the two headline contributions. The base public-parameters protocol might still stand as a PoUW design, but the paper's strongest claim—'first solution that meets all necessary properties of PoW' in a general-purpose zk-SNARK marketplace—is not supported without the private-input extension.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes SNARKChain, a Proof-of-Useful-Work (PoUW) consensus protocol in which miners' puzzle work is the generation of Groth16 zk-SNARK proofs for client-outsourced circuits. Blocks contain both coin transactions and proof transactions; miners build a proof chain and, after each proof, run a lottery whose winning probability is claimed to be proportional to the circuit complexity (Eq. 1), optionally modified by accumulated work via the parameter ψ (Eq. 2). An integrity parameter is injected into each circuit to bind the proof to the in-progress block, and a circuit-registry subnetwork stores circuits and performs MPC-based trusted setup. Appendix B extends the scheme to private inputs through \"witness obfuscating outsourcing,\" in which the client additively masks private inputs and hard-codes the masks into the circuit. The paper evaluates fairness and wasted work using a stochastic Petri-net model and claims to be the first general-purpose zk-SNARK marketplace operating at the consensus layer while meeting all necessary properties of PoW.","tokens_in":16456,"tokens_out":7736,"duration_ms":79378,"significance":"If the design were sound, this would be a significant contribution: it targets a real gap in PoUW by coupling consensus security to a practically valuable computation, and it provides a concrete property checklist, algorithms, and reproducible simulation scaffolding. The paper's strengths include the clear articulation of the PoW requirements, the proof-chain binding idea in Section 4.3, the concrete pseudocode in Algorithm 2, and the use of Groth16's linear proving-time benchmarks from the literature. However, the central claims are not established: the private-input extension is internally inconsistent and cannot be executed as described, the pseudocode for the lottery threshold contradicts the stated winning probability, and the security properties are asserted rather than proven. As presented, the paper does not meet the bar for a serious journal publication.","major_comments":[{"comment":"The WOO private-input extension is unsound. B.3 claims that only the proving key and obfuscated witness are sent to the worker and that the R1CS and masks remain private. But a Groth16 prover cannot generate a proof from a proving key alone: it must evaluate the R1CS to assign all intermediate wires and compute the h(x) polynomial. The circuit registry, as specified in Section 4.4 and used in Algorithm 2's genProof, stores and serves the circuit source/R1CS; once the circuit is available, the client-specific mask r_in hard-coded into the circuit (B.2, Eq. (5)) is visible, and any worker can compute s_in = s_hat_in - r_in. If the R1CS is withheld instead, the worker cannot compute the proof at all. There is no coherent mode in which the worker can both generate a valid Groth16 proof and remain ignorant of the private inputs.","section":"Appendix B (B.2-B.4), Eq. (4)-(5), Algorithm 2"},{"comment":"The lottery check in Algorithm 2, `blkHash < κ * proofTx.complexity`, is inconsistent with Eq. (1), which defines Pwin(i) = Ci/κ. If the hash is normalized to [0,1), the winning condition should be proportional to Ci/κ, not κ*Ci. As written, increasing the difficulty parameter κ makes winning easier, and the implied winning probability is κ*Ci rather than Ci/κ. This is not a mere typo: it changes the meaning of the difficulty parameter and invalidates the block-time calibration and fairness arguments built on Eq. (1). The pseudocode and the formula must be reconciled and stated with an explicit hash-to-target mapping.","section":"Algorithm 2 vs. Eq. (1)"},{"comment":"The required PoW properties are asserted as bullet points rather than proven. There is no adversarial model, no theorem or lemma, no quantification of adversary hashrate, and no failure-probability analysis. The Unforgeability bullet, for example, only argues that proofs cannot be precomputed before the previous block hash is known; it does not address a miner registering a self-dealing circuit through the open registration procedure of Section 4.4, nor the effect of such circuits on the lottery and on the marketplace's usefulness. Similarly, the Freshness and Amortization-freeness arguments are one-sentence claims. Since the paper's headline claim is that the protocol \"meets all the necessary properties of PoW,\" this is a load-bearing gap.","section":"Section 6, \"Puzzle Condition Analysis\""},{"comment":"The Petri-net evaluation does not independently validate the fairness hypotheses. The model in Figure 5 encodes the protocol's own lottery probability Pwin as a transition probability and uses the same gate-count complexity measure as the design. Figures 6-8 therefore largely reproduce algebraic consequences of Eq. (1)-(2) rather than providing external evidence. The model also contains no adversarial miners, no network delays, and no miner misbehavior. Consequently, the experimental claims for H1-H4 do not support the protocol's security or fairness in an adversarial setting beyond what is already assumed by the formulas.","section":"Section 5, Figure 5"}],"minor_comments":[{"comment":"The STCPN experiments and the WOO benchmark lack details needed for reproducibility: no number of replications, no error bars or confidence intervals, and no description of the circuits used in Figure 11 beyond constraint counts. The claim that WOO overhead remains below 0.1 s should be substantiated with more complete experimental reporting.","section":"Section 5 / Figure 11"},{"comment":"The claim that no batching techniques exist for Groth16 proving is presented as a permanence statement. It would be more accurate to say that no practical batching method is known or used in the paper's setting; the argument should be framed as a current limitation rather than an intrinsic property.","section":"Section 6, \"Amortization-freeness\""},{"comment":"The circuit registry's `getCircuit` returns both `circuit` and `provingKey`, but the paper does not specify whether the returned circuit is source code, compiled R1CS, or a prover-ready object. This ambiguity is directly tied to the private-input flaw and should be clarified in any revision.","section":"Section 4.4 / Algorithm 2"}],"recommendation":"reject","confidential_remarks":"The private-input extension is not a minor fix; it is a central contribution and the described mechanism cannot work as stated with Groth16. The base public-parameter protocol is an interesting design idea, and the lottery/threshold inconsistency in Algorithm 2 is fixable in principle, but the paper's claimed security properties would still need a full formal treatment. Given the scope of the changes required, rejection is appropriate."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Hi [Colleague],\n\nShort version: this paper proposes a PoUW consensus where miners compute client-outsourced SNARK proofs as the puzzle, and it is the first to put a general-purpose proof-generation marketplace at the consensus layer. That is a real idea. But the advertised zero-knowledge marketplace falls apart: the WOO extension in Appendix B cannot work as described, and the security properties are asserted rather than demonstrated. I think the base protocol is worth a serious look, but not in its current form.\n\nWhat's new: The integrity parameter that hashes the block header into the circuit, the proof-chain binding, and the complexity-weighted lottery are a sensible combination that addresses freshness and progress-freeness in a PoUW setting. The paper also correctly identifies why prior PoUW schemes fail the freshness requirement. The related work survey is competent.\n\nWhere it gets shaky: The main claim that this is the first zk-SNARK marketplace at consensus layer rests on the private-input extension. Appendix B.3 says the worker gets only the proving key and obfuscated witness, while the R1CS and masks stay private. That is not how Groth16 works. A prover needs the R1CS to compute the full witness and the h(x) polynomial; the proving key alone doesn't contain circuit structure. If you hand over the R1CS (or the source, which Section 4.4 says the registry stores), then the hard-coded mask r_in is visible and the worker can recover s_in from the obfuscated witness. So there's no coherent mode where the worker can both generate a proof and stay ignorant of the private input. This is a load-bearing flaw: without WOO, the marketplace is for public-parameter SNARKs only, and the 'zk' in the title is not supported.\n\nThe security properties for the base protocol are also argued informally. The section-length analysis in Section 6 reads like a checklist, not a proof. Some of these properties (e.g., independence, amortization-freeness) are plausible, but they are not established. The Petri net simulation (Section 5) encodes the protocol's own lottery equations and gate-count complexity, so the results largely confirm the design assumptions rather than validate them against an independent ground truth. The benchmark data on Groth16 linear proving time is fine, but it doesn't test the actual consensus protocol.\n\nOne minor point: the paper claims 'to the best of our knowledge' first to meet all PoW properties, but without a formal treatment of unforgeability, that is overreaching.\n\nVerdict: This is a paper for blockchain and applied-crypto readers who are interested in PoUW. The base mechanism is a reasonable starting point, and the WOO flaw is identifiable and could be removed or reworked. If the authors revised the claims to public-parameter proof generation and added a proper security analysis, the core idea would be worth publishing. I'd send it to peer review rather than desk reject, but I'd expect major revisions.","headline":"The base PoUW design is genuinely novel, but the private-input extension is internally inconsistent and the security claims are asserted rather than proven; send to peer review with major revisions expected.","tokens_in":16896,"tokens_out":3734,"would_cite":false,"duration_ms":34083,"reading_group":"maybe","serious_thinker":"no","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"SNARKChain proposes a Proof-of-Useful-Work consensus in which mining consists of generating client-requested zk-SNARK proofs, and claims this is the first such protocol to meet all standard PoW security properties.","keywords":["proof of useful work","zk-SNARK","Groth16","blockchain consensus","SNARK marketplace","witness obfuscation","private inputs","lottery protocol"],"falsifier":"Compile a small circuit with a known hard-coded additive mask, generate its Groth16 proving key, and attempt to recover the mask from the key alone. If the mask is found, the WOO confidentiality claim is refuted; if it cannot be recovered, the claim survives this test.","tokens_in":15956,"feed_emoji":"⛏️","tokens_out":4396,"duration_ms":41601,"temperature":0.7,"pith_summary":"This paper tries to establish that blockchain consensus can be made useful without giving up the security properties of Proof of Work: instead of hashing random numbers, miners compute zk-SNARK proofs that clients have requested, and each completed proof acts as a lottery ticket for the right to publish the next block. The authors claim this is the first PoUW scheme to satisfy all the standard PoW properties—asymmetry, freshness, progress-freeness, unforgeability, and the rest—because every proof is bound to the block being built through an integrity parameter, forming a proof chain that prevents reuse or theft. The same mechanism doubles as a decentralized marketplace for outsourcing proof generation, where circuit complexity determines both the fee and the chance of winning the block. A private-input extension wraps masked witnesses in an obfuscating circuit so workers can produce proofs without learning the secret inputs, though this part rests on an assumption that the proving key reveals nothing about the mask.","feed_headline":"Miners earn blocks by computing client SNARK proofs","feed_subtitle":"A proposed blockchain turns outsourced proof requests into the mining puzzle, keeping PoW security while producing proofs clients want.","key_machinery":"The proof chain and the integrity parameter carry the protocol. Each circuit is modified to accept a public integrity value η derived from the current block header, the coin transactions, and the previous proofs in the block; altering η invalidates the proof, so a solution cannot be transplanted to another block. The lottery is drawn with probability C_i/κ for each completed proof, making circuit complexity the difficulty metric and giving progress-free, Poisson-like mining. For the private-input extension, the mechanism is witness obfuscating outsourcing (WOO): the client samples a random additive mask, publishes the masked witness, and compiles the circuit with a hard-coded unmasking step,","core_discovery":"The central claim is that zk-SNARK proof generation is a suitable PoW puzzle: it is asymmetric (mining hard, verification millisecond-fast), adjustable via circuit complexity and a target κ, amortization-free and independent because each proof differs by an integrity parameter, and progress-free because a lottery is held after every completed proof. The protocol binds proof transactions and coin transactions in one block; a block wins when the hash of the accumulated block falls below κ times the complexity of the latest proof. The paper further claims that its private-input extension, based on additive masking, lets clients outsource proofs over secret witnesses while preserving zero knowle","pith_inferences":["The paper leaves implicit that the lottery mechanism could, in principle, be repurposed for any computation with a fast verifier and a predictable cost metric, not only SNARKs.","A testable consequence of the private-input extension: if the additive mask is recoverable from the proving key, the confidentiality claim fails while the public-parameter marketplace would still stand.","One operational risk the paper does not fully address is circuit authenticity: clients cannot tell a correct proof from a proof for a subtly different circuit unless the registry is publicly auditable; staking reduces the incentive but does not eliminate the risk.","A direct way to stress-test the design is to simulate the lottery under adversarial transaction selection, checking whether the claimed Poisson fairness holds when miners can choose which proof requests to include."],"forward_implications":["If the protocol is sound, miners can secure a PoW-style chain while producing Groth16 proofs that clients would otherwise purchase on an external market; the electricity buys useful cryptographic output.","Because every proof embeds an integrity parameter derived from the block content, a mined proof cannot be replayed or transplanted to another block, addressing the freshness gap that has sunk earlier PoUW designs.","Circuit complexity acts as a deterministic difficulty metric, so block time can be calibrated by adjusting the target κ while preserving a fair link between mining power and block rewards.","Proof generation becomes a general-purpose consensus-layer marketplace: any registered arithmetic circuit with a trusted setup can produce work, unlike prior consensus-layer SNARK systems limited to a single fixed circuit.","The WOO private-input variant would let clients hide witnesses from the workers who compute their proofs, extending the marketplace to privacy-preserving applications while keeping proof verification unchanged on-chain."],"fun_headline_variants":["Mining becomes useful: blocks are won by computing SNARK proofs","PoUW reinvented: client SNARK proofs secure the chain and get mined","A marketplace for SNARK proofs at the consensus layer","Blockchain mining now produces zk-proofs clients actually want","Proof-of-Useful-Work: SNARK proofs as the new mining puzzle"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The private-input scheme assumes that handing a worker the proving key hides the secret mask baked into it, even though the proving key is generated from the circuit that contains that mask.","fun_headline_variants_meta":{"raw":{"variants":["Mining becomes useful: blocks are won by computing SNARK proofs","PoUW reinvented: client SNARK proofs secure the chain and get mined","A marketplace for SNARK proofs at the consensus layer","Blockchain mining now produces zk-proofs clients actually want","Proof-of-Useful-Work: SNARK proofs as the new mining puzzle"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000418,"raw_usage":{"total_tokens":1958,"prompt_tokens":681,"completion_tokens":1277,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":425,"completion_tokens_details":{"reasoning_tokens":1199}},"tokens_in":425,"tokens_out":1277,"duration_ms":8527,"temperature":1.0,"reasoning_tokens":1199,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T10:29:42.079471+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Compile a small circuit with a known hard-coded additive mask, generate its Groth16 proving key, and attempt to recover the mask from the key alone. If the mask is found, the WOO confidentiality claim is refuted; if it cannot be recovered, the claim survives this test.","supporting_citations":[],"review_version":1}