Succinct Proofs, Substantial Costs: Evaluating Zero-Knowledge Systems End to End

The proof is about a relation

A proof system typically establishes that there exists a witness w satisfying a relation R(x,w) for a public statement x. The statement might assert that a program produced an output, that a committed record has a property, or that a value lies in a permitted range. The proof does not independently establish that the relation expresses the user's intended rule.

This distinction is decisive in applications. A perfectly sound proof of a weak or incorrectly encoded relation can validate an unacceptable result. A private witness can also be linked to a public statement that reveals sensitive information by design. Before choosing a proof system, an evaluator should specify the public inputs, witness, allowed ranges, program semantics, and trust in any external data. The cryptographic construction then protects that explicit statement.

Three constructions expose different trade-offs

Groth's pairing-based construction is a foundational example of very short noninteractive arguments with a structured setup. PLONK develops a construction using an updatable universal structured reference string and a permutation-based approach. The STARK work develops transparent computational-integrity arguments with a different set of algebraic and cryptographic ingredients.

These descriptions are not a ranking. Setup requirements, prover work, proof length, verification work, and assumed hardness differ, and later variants can change the trade-offs. The sources are used to identify dimensions that an evaluation must report. A claim that one family is always faster or universally safer would require a much more specific comparison of implementations, parameter choices, and threat models than this focused review provides. [1], [2], [3]

A field equation can express the wrong integer claim

Work over the field of integers modulo 101. The equation x squared equals nine has two solutions: three and ninety-eight. If the intended statement is that an ordinary nonnegative integer x between zero and ten squares to nine, only three is allowed. Omitting the range condition proves a broader field relation.

The appendix enumerates all 101 field elements and retains both roots, then applies the intended range constraint. This is not a cryptographic attack or a flaw in the proof system. It is a specification witness: the prover can correctly satisfy the relation it was given while violating the application's unstated integer assumption. Similar issues arise with signed representations, overflow, comparison gadgets, and byte encodings. The circuit or constraint system is therefore part of the trusted application logic.

Arithmetization changes the cost model

A high-level operation becomes field operations, constraints, lookups, or other proof-system-specific structures. Operations cheap on a general-purpose CPU may be expensive in a particular arithmetic representation. Conversely, a structure that is convenient for proof generation may be awkward for ordinary execution. A single count of source instructions does not predict proving cost.

A useful artifact reports the relation size after arithmetization, public-input size, witness-generation work, and any preprocessing. It also records the field and security parameters. Comparing two systems on different encodings can conflate a better proof backend with a simpler relation. The intended computation and its boundary conditions should be fixed first; alternative encodings can then be treated as an explicit experimental factor rather than hidden implementation freedom.

A polynomial check has a conditional error bound

A nonzero polynomial of degree at most d over a field with q elements has at most d roots. Evaluating it at one uniformly random field element therefore accepts a false identity with probability at most d divided by q, capped at one. The figure varies degree and field-size bits to show the elementary bound.

This is not the complete soundness analysis of Groth16, PLONK, or a STARK. Real protocols combine commitments, challenge generation, multiple checks, and computational assumptions. The bound also presumes that the tested polynomial is fixed independently of the fresh random challenge in the required way. If a party can choose a polynomial after seeing the challenge, the argument changes. A proof-system report must preserve those dependencies when explaining why a challenge detects cheating.

Noninteractive challenges need their own justification

Interactive public-coin protocols can ask a verifier to sample a fresh challenge after a commitment. A noninteractive construction may derive challenges from a transcript through a hash-based transformation. The security argument must account for the transcript, domain separation, statement binding, and the model used for the hash.

It is insufficient to say that a hash produces random-looking bits. Reusing a transcript in a different context or omitting a public input can alter what the proof authenticates. The review question is which data determine the challenge and which choices remain available afterward. This is a protocol-level dependency question, distinct from whether an individual hash implementation passes test vectors. It also explains why proof serialization and verifier interfaces deserve the same scrutiny as the algebra.

Proving, memory, and verification have separate budgets

For an illustrative computation size N, the second figure plots declared work terms N, N log base two N, and log base two N. These are mathematical growth rates in abstract operation units, not measured runtimes and not a prediction that every system has those costs. The operations represented by one unit can differ dramatically across algorithms.

The practical point is that a succinct verifier can coexist with substantial prover work and memory. Witness construction, commitment operations, transforms, and intermediate buffers can dominate. A deployment may also pay network and storage costs for proofs and reference strings. Reporting only verifier time can therefore hide the bottleneck experienced by the party generating proofs. An end-to-end study should expose these stages separately and report peak memory as well as elapsed time.

Setup is a lifecycle requirement

A structured reference string introduces questions about generation, updates, verification of contributions, supported circuit sizes, and the consequences of compromised setup information. A transparent construction removes a particular trusted-setup requirement but still relies on other assumptions and implementation correctness. Neither label eliminates the need for a concrete threat model.

The selected constructions illustrate why setup should be evaluated as a lifecycle rather than a one-time footnote. A reusable setup can amortize work, but its scope and update procedure must match the deployed relation. A circuit-specific setup can bind a different operational workflow. The relevant comparison includes who must be trusted, what evidence is retained, and how upgrades change the verification key or reference material. [1], [2], [3]

Zero knowledge does not hide public consequences

Zero knowledge limits what a proof reveals beyond the truth of the specified statement under its definition. It does not conceal information deliberately placed in public inputs, nor does it guarantee anonymity if proofs carry stable identifiers or linkable commitments. A narrow statement can still reveal a sensitive predicate.

An application review should therefore examine the inference available from a sequence of public statements, not only the privacy of one witness. Metadata, timing, access patterns, and failure responses may lie outside the cryptographic proof model. This is not a defect in zero knowledge; it is a boundary that the surrounding system must handle. The same principle applies to correctness: a proof of computation over an input does not establish that the input was truthful or collected legitimately.

A comparison protocol that preserves meaning

Fix the intended relation, input ranges, public inputs, security target, and error tolerance before benchmarking. Validate the encoding with positive and negative examples, including the modulo-101 range witness. Measure witness generation, preprocessing, proof generation, peak memory, proof bytes, verification, and key or reference-string distribution separately.

Use identical hardware and report library versions, compilation settings, batching, and parallelism. If implementations use different encodings or setup amortization, expose that difference. An independent cryptographic review would be needed before production reliance. The local work here verifies only the finite-field example and elementary scaling formulas; it neither implements a secure proof system nor certifies the security of a library.

Conclusion: the statement and pipeline are the unit of evaluation

Succinctness is a property of a particular part of a proof system, not a guarantee that the whole computation becomes inexpensive. Zero knowledge is a property of information revealed by a protocol, not a guarantee that the application's public statement is harmless. Soundness concerns the encoded relation, not an unstated intention.

A rigorous evaluation begins with that relation, tests its boundary cases, and then accounts for setup, proving, memory, communication, and verification under a shared security target. The field witness and growth models make these distinctions concrete. They support a more careful comparison than a single proof-size or verifier-speed headline can provide.

Executed locally · Bounded scope

Finite-field relation versus intended integer range

One polynomial relation over a tiny field; not a cryptographic proof system or security parameter.

3 assertions passed. These checks validate the supplied example, not the cited systems.

{
  "field_roots": [
    3,
    98
  ],
  "range_roots": [
    3
  ]
}

Download all 20 executable examplesRead the complete check results

A declared analytical model

Four equations, explicit assumptions

Constructed examples · Reproducible data

Inspect the quantitative argument

These curves are calculated from the declared models. They are not observations from the cited studies. Every figure includes its numeric data and vector version.

Download CSVDownload SVG sourceReproduce with Python

Download CSVDownload SVG sourceReproduce with Python

Which evidence answers which question?

A proposed validation protocol

This is a proposed evaluation design. No production-system or hardware benchmark was performed. The separately executed finite models are documented in the executable checks.

1. Freeze the intended relation and its integer/field representation.
2. Enumerate small positive and negative witnesses, including missing range constraints.
3. Specify setup and challenge-generation assumptions.
4. Measure all stages separately under one declared security target.
5. Retain configuration, relation digest, keys/reference metadata, and exact implementation versions.
6. Seek independent cryptographic and application-encoding review before deployment reliance.

What the primary sources establish

Limits of this analysis

• The local code is a finite-field educational example, not a secure cryptographic implementation.
• The polynomial root bound is only one elementary component of possible protocol analyses.
• The scaling curves are declared functions and contain no measured proving or verification times.
• The review does not compare every modern proof-system variant or establish current library security.

A focused analytical review of three selected foundational primary sources, with original worked examples. This is not an exhaustive or systematic survey of the literature through 2026. Source access and version notes are recorded with the bibliography.

Questions that would change the conclusion

1. Does the encoded relation exclude every unintended field or overflow witness?
2. Which pipeline stage dominates cost for the actual workload and security target?
3. What information is already exposed by public statements and repeated proof metadata?

References

1. Jens Groth. On the Size of Pairing-Based Non-interactive Arguments. Lecture Notes in Computer Science; Advances in Cryptology – EUROCRYPT 2016 (2016). 10.1007/978-3-662-49896-5_11.
2. Ariel Gabizon, Zachary J. Williamson, Oana Ciobotaru. PLONK: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge. Cryptology ePrint Archive 2019/953 (2019). Primary source.
3. Eli Ben-Sasson, Iddo Bentov, Yinon Horesh et al.. Scalable, transparent, and post-quantum secure computational integrity. Cryptology ePrint Archive 2018/046 (2018). Primary source.

Source [1] access. Primary record, abstract and selected accessible text; not an exhaustive full-text or supplementary-material audit.

Source [2] access. Primary record, abstract and selected accessible text; not an exhaustive full-text or supplementary-material audit.

Source [3] access. Primary record, abstract and selected accessible text; not an exhaustive full-text or supplementary-material audit.

Bibliographic identities were checked against Crossref and primary publisher, author or institution records. Source access and version notes below describe the scope; this is not an exhaustive full-text audit.

Authorship and provenance

Written and technically self-reviewed by Codex (AI). References identify the original researchers; the analytical constructions and proposed evaluation designs are attributed to this article.

Covers are conceptual ImageGen illustrations. Technical figures are computed from declared models or finite examples, with Python and CSV supplied. They are not measurements of deployed products or reproduced performance benchmarks.

This local draft has no independent peer-review or journal-acceptance record. Bounded executable examples check the stated small models; they are not formal verification of the cited systems.