Pith. sign in

REVIEW 4 major objections 3 minor 49 references

SNARKChain: Proof-of-Useful-Work Blockchain Consensus with General-Purpose SNARK Marketplace

T0 review · 4 major / 3 minor · reviewed 2026-08-04 · deepseek-v4-flash

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

Pith's one-line read 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.

desk verdict 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. read the letter →

arxiv 2510.09729 v2 pith:HU3O7UA2 submitted 2025-10-10 cs.CR

Samuel Oleksak , Richard Gazdik , Martin Peresini , Ivan Homoliak This is my paper · ORCID
classification cs.CR
keywords proofofusefulworkzk-SNARKGroth16blockchainconsensusSNARKmarketplacewitnessobfuscationprivateinputslotteryprotocol
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

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.

What carries the argument

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,

What would settle it

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.

Watch

Extended reading notes

Core claim

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

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

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

  • 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.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 3 minor

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.

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 (4)
  1. [Appendix B (B.2-B.4), Eq. (4)-(5), Algorithm 2] 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.
  2. [Algorithm 2 vs. Eq. (1)] 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.
  3. [Section 6, "Puzzle Condition Analysis"] 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.
  4. [Section 5, Figure 5] 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.
minor comments (3)
  1. [Section 5 / Figure 11] 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.
  2. [Section 6, "Amortization-freeness"] 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.
  3. [Section 4.4 / Algorithm 2] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the PoUW lottery and marketplace claims are design proposals/novelty assertions, not derivations that reduce to their own inputs; the evaluation is an internal-consistency simulation, and the WOO concern is a correctness issue rather than a circular step.

full rationale

The paper's central derivation chain is not circular. The lottery rule P_win(i) = C_i/kappa is introduced as a design choice in Section 4.2, with C_i defined as the circuit's gate/constraint count; the paper does not claim to derive this relation from data or from an external first-principles result. The Groth16 linear proving-time assumption is supported by external benchmarking sources ([19], [20], zk-bench), not by values fitted in this paper. The Section 5 Petri-net simulation instantiates the proposed lottery equations directly, so the H1-H4 results are best read as internal-consistency checks of the design rather than independent empirical validation; however, no parameter is fitted to a subset of data and then presented as a prediction of a closely related quantity, and no result is identical by construction to its input. There are no load-bearing self-citations: the WOO technique is attributed to Nakamura et al. [37], and the paper explicitly acknowledges the trade-off of reduced circuit reusability. The Appendix B statement that 'the R1CS and masks are kept private' while 'only the proving key and obfuscated witness are sent to the worker' raises a genuine feasibility/security concern for Groth16, since a prover normally needs the R1CS to compute the witness and h(x); but that is a correctness/soundness issue, not a circularity in the claimed derivation chain, so it is not scored here. The strongest claim, being the first PoUW marketplace meeting all PoW properties, is a comparative novelty assertion rather than a derivation and does not reduce to the paper's own equations.

Assumptions & free parameters 3 free parameters · 8 assumptions · 1 invented entities

The protocol's behavior depends on several unstated parameters (difficulty, ψ, bucket count) and on assumptions that gate count equals real work, that miners sample transactions uniformly, and that a circuit-specific proving key does not reveal the circuit. The last assumption is contradicted by the properties of Groth16 and breaks the private-input extension.

free parameters (3)
  • block difficulty κ = periodically adjusted after fixed epochs
    Target threshold in the lottery (Eq. 1, Algorithm 2); controls expected block time, but no calibration formula or initial value is given, so protocol behavior depends on an unstated network parameter.
  • lottery chain-preference coefficient ψ = in [0,1]; tested over 0–0.5 in Figure 8
    Optional term in Eq. 2 to reduce wasted work; the paper experiments with it but does not propose a concrete value, leaving the waste-vs-centralization tradeoff unresolved.
  • number of buckets / hash-prefix length = dynamically adjusted based on pending transaction count
    Introduced in Section 4.2(E) and evaluated in Figure 9; no adjustment rule is specified, and it affects wasted work and the miner's valid inclusion set.
assumptions (8)
  • domain assumption Groth16 proving time grows linearly with constraint count.
    Section 6 relies on benchmark data [20,19] to equate gate count C_i with real work; this equivalence underpins the difficulty and lottery fairness. It is hardware- and implementation-dependent.
  • domain assumption Each completed proof yields an independent Bernoulli lottery chance Pwin = C_i/κ, and the process is Poisson/progress-free.
    Section 4.2 and Hypothesis H2; fairness and progress-freeness are outcomes of this modeling assumption, not proven from protocol rules.
  • standard math Hash functions behave as random oracles and cannot be optimized by miners.
    The integrity binding in Section 4.3 and the lottery rely on this; standard for blockchain papers.
  • domain assumption At least one circuit-registry node is honest during SMPC trusted setup.
    Section 4.4; the security of the proving and verification keys depends on this threshold, and the subnetwork has no specified consensus or availability mechanism.
  • domain assumption No meaningful amortization exists across proof generations for the same circuit.
    Section 6, Amortization-freeness; asserted from the absence of known batching for Groth16 proof generation, not from a proven lower bound.
  • ad hoc to paper A circuit-specific Groth16 proving key can be given to workers without revealing the circuit or mask constants.
    Appendix B.3 claims the R1CS and masks stay private while the proving key is sent to workers; with a circuit-specific setup the proving key encodes the constraint system, so this assumption is false and load-bearing for the privacy extension.
  • domain assumption Miners select proof transactions uniformly at random and clients cannot bias hash prefixes.
    Used for the bucket-overlap analysis in Eq. (3); real selection is fee-driven and Sybil clients can create many keys, so the uniform-random assumption is not guaranteed.
  • ad hoc to paper The dummy assert on the integrity parameter keeps it non-optimizable and cryptographically bound.
    Algorithm 1 adds assert(integrity != 0) to force use of the public input; this is an implementation hack whose security depends on compiler behavior, not a proof-system property.
invented entities (1)
  • Circuit registry subnetwork
    purpose: Stores circuits and proving/verification keys, runs SMPC trusted setup, and stakes/slashes registry nodes.
    A new subsystem introduced in Section 4.4; no consensus or availability mechanism is specified, so its liveness and security are assumed.

how reviews work

0 comments
Cite this review

Pith. "Pith review of SNARKChain: Proof-of-Useful-Work Blockchain Consensus with General-Purpose SNARK Marketplace." pith.science (2026). https://pith.science/paper/HU3O7UA2

@misc{pith2026251009729,
  author       = {Pith},
  title        = {Pith review of: SNARKChain: Proof-of-Useful-Work Blockchain Consensus with General-Purpose SNARK Marketplace},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/HU3O7UA2}},
  note         = {Machine review of arXiv:2510.09729}
}
read the original abstract

Proof of Work (PoW) is widely regarded as the most secure permissionless blockchain consensus protocol. However, its reliance on computationally intensive yet externally useless puzzles results in excessive electric energy wasting. To alleviate this, Proof of Useful Work (PoUW) has been explored as an alternative to secure blockchain platforms while also producing real-world value. Despite this promise, existing PoUW proposals often fail to embed the integrity of the chain and the identity of the miner into the puzzle solutions, not meeting the necessary requirements for PoW and thus rendering them vulnerable. In this work, we propose a PoUW consensus protocol that computes client-outsourced SNARK proofs as a byproduct, which are simultaneously used to secure the consensus protocol. We further leverage this mechanism to design a decentralized marketplace for outsourcing SNARK proof generation, which is, to the best of our knowledge, the first such marketplace operating at the consensus layer while meeting all necessary properties of PoW.

Figures

Figures reproduced from arXiv: 2510.09729 by the authors.

Figure 1
Figure 1. Diagram illustrating the lifecycle of a single block, including the different [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 2
Figure 2. The lottery mechanism during block mining (as described in Section 4.2). [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. The overlap probability Poverlap(m, t) of two randomly selected transac￾tion sets of size t from the mempool of size m. the constant ψ ∈ [0; 1]: Pwin(i) = Ci κ + ψ · X j<i Cj κ . (2) Shortcomings. Intuitively, this alteration provides a disproportionate advan￾tage to the stronger miners that are able to produce stronger chains within a single block window, thereby increasing centralization (see H3 in Section 5). (D)… view at source ↗
Figures from the paper (8 more)
Figure 4
Figure 4. Figure 4: Sycomore ledger creates a split in the block DAG in times of high traffic. [PITH_FULL_IMAGE:figures/full_fig_p009_4.png]
Figure 5
Figure 5. Figure 5: Stochastic Time Colored Petri Net (STCPN) modeling the consensus [PITH_FULL_IMAGE:figures/full_fig_p011_5.png]
Figure 6
Figure 6. Figure 6: Simulation results for H1 run with 2 miners, where the relative compu￾tational power of a stronger miner was increasing as indicated on the x-axis. 2 4 6 8 10 Stronger vs. weaker miner average selected proof size ratio 0.00 0.25 0.50 0.75 1.00 1.25 1.50 1.75 2.00 Ratio…
Figure 7
Figure 7. Figure 7: Results of experiments for hypothesis H2 regarding the preference of proof complexity. Simulation was run with two miners of the same computational power, but with a different preference of proof size (as indicated by the x-axis). trend would make the reward system unf…
Figure 8
Figure 8. Figure 8: The experimental results of ψ parameter addition (H3) with 5 miners with different computational power. 2 4 6 8 10 12 14 16 Number of buckets 0 20 40 60 80 100 Wasted work (%) Influence of bucketing on wasted work 4 total miners 8 total miners 16 total miners [PITH_FU…
Figure 9
Figure 9. Figure 9: Results from simulation of H4. a high number of buckets is beneficial; however, their number is constrained by the number of proofs that are available in the mempool. 6 Discussion In this section, we examine specific aspects of our proposed solution, focusing especiall…
Figure 10
Figure 10. Figure 10: Structure of the transformed circuit Fˆ, where encrypted input sˆin passes through the input decryption function Din, and the output sˆout is later decrypted using Dout. Adapted from [37]. obfuscated witness is included in the proof request, allowing the worker to gen…
Figure 11
Figure 11. Figure 11: Proof time comparison for raw vs. obfuscated Circom circuits. The green [PITH_FULL_IMAGE:figures/full_fig_p024_11.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

49 extracted references · 5 canonical work pages

  1. [1]

    0KIMS Association: Circom: A high-level language for zk-snark circuits (2021), https://github.com/iden3/circom, accessed: 2025-01-08

    2021

  2. [2]

    ACM Comput

    Ali, I.M., Caprolu, M., Pietro, R.D.: Foundations, properties, and security ap- plications of puzzles: A survey. ACM Comput. Surv.53(4) (Aug 2020).https: //doi.org/10.1145/3396374,https://doi.org/10.1145/3396374

    work page doi:10.1145/3396374 2020

  3. [3]

    In: 2018 IEEE 17th International Symposium on Network Computing and Applications (NCA)

    Anceaume, E., Guellier, A., Ludinard, R., Sericola, B.: Sycomore: A permissionless distributed ledger that self-adapts to transactions demand. In: 2018 IEEE 17th International Symposium on Network Computing and Applications (NCA). pp. 1– 8 (2018).https://doi.org/10.1109/NCA.2018.8548053

    arXiv 2018

  4. [4]

    Entropy21(8) (2019).https://doi.org/10

    Baldominos, A., Saez, Y.: Coin.ai: A proof-of-useful-work scheme for blockchain- based distributed deep learning. Entropy21(8) (2019).https://doi.org/10. 3390/e21080723,https://www.mdpi.com/1099-4300/21/8/723

    2019

  5. [5]

    Cryptology ePrint Archive, Paper 2017/203 (03 2017),https://eprint.iacr.org/2017/203

    Ball, M., Rosen, A., Sabin, M., Vasudevan, P.N.: Proofs of useful work. Cryptology ePrint Archive, Paper 2017/203 (03 2017),https://eprint.iacr.org/2017/203

    2017

  6. [6]

    In: Proceedings of the 23rd USENIX Conference on Security Symposium

    Ben-Sasson, E., Chiesa, A., Tromer, E., Virza, M.: Succinct non-interactive zero knowledge for a von neumann architecture. In: Proceedings of the 23rd USENIX Conference on Security Symposium. p. 781–796. SEC’14, USENIX Association, USA (2014)

    2014

  7. [7]

    Cryptology ePrint Archive, Paper 2010/040 (2010),https: //eprint.iacr.org/2010/040

    Blazy, O., Fuchsbauer, G., Izabachène, M., Jambert, A., Sibert, H., Vergnaud, D.: Batch groth-sahai. Cryptology ePrint Archive, Paper 2010/040 (2010),https: //eprint.iacr.org/2010/040

    2010

  8. [8]

    Bonneau, J., Meckler, I., Rao, V., Shapiro, E.: Mina: Decentralized cryptocurrency at scale. Tech. rep., O(1) Labs (2020),https://minaprotocol.com/wp-content/ uploads/technicalWhitepaper.pdf Zk-SNARK Marketplace with Proof of Useful Work 17

    2020

Show all 49 references
  1. [9]

    In: 2023 IEEE 22nd International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom)

    Chatterjee, D., Banerjee, P., Mazumdar, S.: Chrisimos: A useful proof-of-work for finding minimal dominating set of a graph. In: 2023 IEEE 22nd International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom). pp. 1332–1339 (2023).https://doi....

    2023

  2. [10]

    In: 2021 IEEE In- ternational Conference on Blockchain (Blockchain)

    Chaurasia, Y., Subramanian, V., Gujar, S.: Pupow: A framework for designing blockchains with practically-useful-proof-of-work & vanitycoin. In: 2021 IEEE In- ternational Conference on Blockchain (Blockchain). pp. 122–129 (2021).https: //doi.org/10.1109/Blockchain53845.2021.00026

    2021

  3. [11]

    In: Proceedings of the 7th Asia- Pacific Workshop on Networking

    Chen, C., Cheng, Z., Qu, S., Fang, Z.: Crowdsourcing work as mining: A de- centralized computation and storage paradigm. In: Proceedings of the 7th Asia- Pacific Workshop on Networking. p. 174–175. APNet ’23, Association for Comput- ing Machinery, New York, NY, USA (2023).http...

    2023

  4. [12]

    arXivabs/2101.11134(2021),https://arxiv.org/ abs/2101.11134, accessed: 2025-03-09

    Chiesa,A.,Koutsou,E.,Williams,D.:zk-rollups:Scalableprivacy-preservinglayer- 2 solutions for blockchain. arXivabs/2101.11134(2021),https://arxiv.org/ abs/2101.11134, accessed: 2025-03-09

    2021 arXiv

  5. [13]

    Costan, V., Devadas, S.: Intel SGX explained. Tech. Rep. 2016/086, IACR Cryp- tology ePrint Archive (2016),https://eprint.iacr.org/2016/086

    2016

  6. [14]

    In: 2022 Fourth International Conference on Blockchain Computing and Ap- plications (BCCA)

    Davidović, T., Todorović, M., Ramljak, D., Krüger, T.J., Matijević, L., Jovanović, D., Urošević, D.: Cocp: Blockchain proof-of-useful-work leveraging real-life applica- tions. In: 2022 Fourth International Conference on Blockchain Computing and Ap- plications (BCCA). pp. 107–1...

    2022

  7. [15]

    Domenech, A.A., Heiss, J., Tai, S.: Servicifying zk-snarks execution for verifiable off-chain computations (2024),https://arxiv.org/abs/2404.16915

    2024 arXiv

  8. [16]

    Dong, Z., Lee, Y.C., Zomaya, A.Y.: Proofware: Proof of useful work blockchain consensus protocol for decentralized applications (2019),https://arxiv.org/abs/ 1903.09276

    2019 arXiv

  9. [17]

    Dotan, M., Tochner, S.: Proofs of useless work – positive and negative results for wasteless mining systems (2021),https://arxiv.org/abs/2007.01046

    2021 arXiv

  10. [18]

    In: 2024 IEEE International Conference on Blockchain (Blockchain)

    Ebrahimi, E., Sober, M., Hoang, A.T., Ileri, C.U., Sanders, W., Schulte, S.: Blockchain-based federated learning utilizing zero-knowledge proofs for verifiable training and aggregation. In: 2024 IEEE International Conference on Blockchain (Blockchain). pp. 54–63 (2024).https:/...

    2024

  11. [19]

    Information 15(8) (2024).https://doi.org/10.3390/info15080463,https://www.mdpi.com/ 2078-2489/15/8/463

    El-Hajj, M., Oude Roelink, B.: Evaluating the efficiency of zk-snark, zk- stark, and bulletproof in real-world scenarios: A benchmark study. Information 15(8) (2024).https://doi.org/10.3390/info15080463,https://www.mdpi.com/ 2078-2489/15/8/463

    2024 doi

  12. [20]

    Cryptology ePrint Archive, Paper 2023/1503 (2023),https://eprint.iacr.org/2023/1503

    Ernstberger, J., Chaliasos, S., Kadianakis, G., Steinhorst, S., Jovanovic, P., Ger- vais, A., Livshits, B., Orrù, M.: zk-bench: A toolset for comparative evaluation and performance benchmarking of SNARKs. Cryptology ePrint Archive, Paper 2023/1503 (2023),https://eprint.iacr.or...

    2023

  13. [21]

    Birkhäuser Basel (2013),https://books.google.ca/books?id=LIP1BwAAQBAJ

    Falk, M., Hüsler, J., Reiss, R.: Laws of Small Numbers: Extremes and Rare Events. Birkhäuser Basel (2013),https://books.google.ca/books?id=LIP1BwAAQBAJ

    2013

  14. [22]

    In: Dodis, Y., Shrimpton, T

    Fitzi, M., Kiayias, A., Panagiotakos, G., Russell, A.: Ofelimos: Combinatorial op- timization via proof-of-useful-work. In: Dodis, Y., Shrimpton, T. (eds.) Advances in Cryptology – CRYPTO 2022. pp. 339–369. Springer Nature Switzerland, Cham (2022) 18 S. Oleksak et al

    2022

  15. [23]

    Dissertation, Stanford Uni- versity (2009),https://crypto.stanford.edu/craig/craig-thesis.pdf

    Gentry, C.: A Fully Homomorphic Encryption Scheme. Dissertation, Stanford Uni- versity (2009),https://crypto.stanford.edu/craig/craig-thesis.pdf

    2009

  16. [24]

    SIAM Journal on Computing18(6), 186–208 (1985)

    Goldwasser, S., Micali, S., Rackoff, C.: Knowledge complexity of interactive proof- systems. SIAM Journal on Computing18(6), 186–208 (1985)

    1985

  17. [25]

    In: Fischlin, M., Coron, J.S

    Groth, J.: On the size of pairing-based non-interactive arguments. In: Fischlin, M., Coron, J.S. (eds.) Advances in Cryptology – EUROCRYPT 2016. pp. 305–326. Springer Berlin Heidelberg, Berlin, Heidelberg (2016)

    2016

  18. [26]

    In: Advances in Cryptology – EUROCRYPT 2016

    Groth, J.: On the size of pairing-based non-interactive arguments. In: Advances in Cryptology – EUROCRYPT 2016. pp. 305–326. Springer Berlin Heidelberg, Berlin, Heidelberg (2016).https://doi.org/10.1007/978-3-662-49896-5_11,https:// doi.org/10.1007/978-3-662-49896-5_11

    2016 doi

  19. [27]

    In: Jacobson, M., Lo- casto, M., Mohassel, P., Safavi-Naini, R

    Henry, R., Goldberg, I.: Batch proofs of partial knowledge. In: Jacobson, M., Lo- casto, M., Mohassel, P., Safavi-Naini, R. (eds.) Applied Cryptography and Network Security. pp. 502–517. Springer Berlin Heidelberg, Berlin, Heidelberg (2013)

    2013

  20. [28]

    Hess, Z., Malahov, Y., Pettersson, J.: Æternity blockchain. Tech. rep. (2017),https://blockchainlab.com/pdf/%91ternity-blockchain-whitepaper. pdf, version 0.1

    2017

  21. [29]

    CoRR abs/1602.03031(2016),http://arxiv.org/abs/1602.03031

    Ileri, A.M., Ozercan, H.I., Gundogdu, A., Senol, A.K., Özkaya, M.Y., Alkan, C.: Coinami: A cryptocurrency with DNA sequence alignment as proof-of-work. CoRR abs/1602.03031(2016),http://arxiv.org/abs/1602.03031

    2016 arXiv

  22. [30]

    Jin, Y., Wang, T., Yang, Q., Shi, L., Zhang, S.: Zero-knowledge federated learning: A new trustworthy and privacy-preserving distributed learning paradigm (2025), https://arxiv.org/abs/2503.15550

    2025

  23. [31]

    Cryptology ePrint Archive, Paper 2020/190 (2020),https: //eprint.iacr.org/2020/190

    Kattis, A., Bonneau, J.: Proof of necessary work: Succinct state verification with fairness guarantees. Cryptology ePrint Archive, Paper 2020/190 (2020),https: //eprint.iacr.org/2020/190

    2020

  24. [32]

    King, S.: Primecoin: Cryptocurrency with prime number proof-of-work.https: //primecoin.io/primecoin-paper.pdf(2013)

    2013

  25. [33]

    Komargodski, I., Schen, I., Weinstein, O.: Proofs of useful work from arbitrary matrix multiplication (2025),https://arxiv.org/abs/2504.09971

    2025

  26. [34]

    Komarov, M.: =nil; proof market.https://nil.foundation/blog/post/ proof-market(Jan 2023), accessed: 2025-07-18

    2023

  27. [35]

    Mina Foundation: What are snark workers and the snarketplace?https: //minaprotocol.com/blog/what-are-snark-workers-and-the-snarketplace (Aug 2021), accessed: 2025-07-18

    2021

  28. [36]

    bitcoin.org/bitcoin.pdf

    Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system (2008),http://www. bitcoin.org/bitcoin.pdf

    2008

  29. [37]

    Journal of Information Processing 30, 151–154 (02 2022).https://doi.org/10.2197/ipsjjip.30.151

    Nakamura, M., Miyamae, T., Morinaga, M.: A privacy-preserving outsourcing scheme for zero-knowledge proof generation. Journal of Information Processing 30, 151–154 (02 2022).https://doi.org/10.2197/ipsjjip.30.151

    2022 doi

  30. [38]

    Orlicki, J.I.: Pogo: A scalable proof of useful work via quantized gradient descent and merkle proofs (2025),https://arxiv.org/abs/2504.07540

    2025 arXiv

  31. [39]

    In: Proceedings of the 2009 BSDCan Conference (May 2009),https://www.tarsnap

    Percival, C.: Stronger key derivation via sequential memory-hard functions. In: Proceedings of the 2009 BSDCan Conference (May 2009),https://www.tarsnap. com/scrypt/scrypt.pdf

    2009

  32. [40]

    RISC Zero: Bonsai network blockchain litepaper.https://dev.risczero.com/ litepaper, accessed: 2025-07-18

    2025

  33. [41]

    Communications of the ACM22(11), 612–613 (1979).https://doi.org/10.1145/359168.359176,https://doi.org/10.1145/ 359168.359176 Zk-SNARK Marketplace with Proof of Useful Work 19

    Shamir, A.: How to share a secret. Communications of the ACM22(11), 612–613 (1979).https://doi.org/10.1145/359168.359176,https://doi.org/10.1145/ 359168.359176 Zk-SNARK Marketplace with Proof of Useful Work 19

    1979

  34. [42]

    Symmetry14(9) (2022).https://doi.org/ 10.3390/sym14091831,https://www.mdpi.com/2073-8994/14/9/1831

    Todorović, M., Matijević, L., Ramljak, D., Davidović, T., Urošević, D., Jakšić Krüger, T., Jovanović, D.: Proof-of-useful-work: Blockchain mining by solv- ing real-life optimization problems. Symmetry14(9) (2022).https://doi.org/ 10.3390/sym14091831,https://www.mdpi.com/2073-8...

    2022 doi

  35. [43]

    com/tornadocash/tornado-core, accessed: 2025-03-09

    TornadoCash:Tornadocash:Aprivacytoolforethereum(2021),https://github. com/tornadocash/tornado-core, accessed: 2025-03-09

    2021

  36. [44]

    de Vries, A., Gallersdörfer, U., Klaaßen, L., Stoll, C.: Revisiting bitcoin’s carbon footprint (02 2022).https://doi.org/10.1016/j.joule.2022.02.005

    2022 doi

  37. [45]

    In: IEEE Security & Privacy on the Blockchain (IEEE S&B

    Westerkamp, M., Eberhardt, J.: zkrelay: Facilitating sidechains using zksnark- based chain-relays. In: IEEE Security & Privacy on the Blockchain (IEEE S&B

  38. [46]

    In: Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Secu- rity (CCS)

    Xie, T., Zhang, J., Cheng, Z., Zhang, F., Zhang, Y., Jia, Y., Boneh, D., Song, D.: zkbridge: Trustless cross-chain bridges made practical. In: Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Secu- rity (CCS). pp. 3003–3017 (2022).https://doi.org/10...

    2022

  39. [47]

    In: 27th Annual Symposium on Foundations of Computer Science (FOCS ’86)

    Yao, A.C.: How to generate and exchange secrets. In: 27th Annual Symposium on Foundations of Computer Science (FOCS ’86). pp. 162–167. IEEE Computer Society, Washington, DC, USA (1986).https://doi.org/10.1109/SFCS.1986.25, https://doi.org/10.1109/SFCS.1986.25

    1986 doi

  40. [48]

    Oleksak et al

    ZoKrates Team: ZoKrates: A toolbox for zkSNARKs on Ethereum (11 2023), https://zokrates.github.io/, accessed: 2024-05-08, version 0.8.8 20 S. Oleksak et al. A Block Production and Verification Pseudocode Algorithm 2 shows pseudocode of the most important functions for block ge...

    2023

  41. [2020]

    (2020),https://eprint.iacr.org/2020/433

    2020

Pith tools

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