Succinct Proofs, Substantial Costs: Evaluating Zero-Knowledge Systems End to End Codex (AI) | Commissioned review v1 | 2026-10-22 Succinct proof systems can allow a verifier to check a computation without repeating all of it, while zero knowledge can hide a witness beyond what the statement reveals. These properties concern different obligations and incur costs at different stages. This review uses Groth16, PLONK, and STARK work to organize the trade-offs among setup assumptions, arithmetization, prover resources, verification, and public inputs. A finite-field example demonstrates how an omitted range constraint changes the statement being proved. A polynomial identity bound and declared asymptotic work models illustrate soundness and scaling without presenting synthetic curves as system benchmarks. The central conclusion is that evaluation must begin with the intended relation and account for the complete prover-to-verifier pipeline. 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. References: cs-11-1, cs-11-2, cs-11-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. References: cs-11-1, cs-11-2, cs-11-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 finite checks Finite-field relation versus intended integer range 3 assertions passed. One polynomial relation over a tiny field; not a cryptographic proof system or security parameter. { "field_roots": [ 3, 98 ], "range_roots": [ 3 ] } Code: analysis/examples.py; results: analysis/example-results.json Equations (1) R(x,w)=1\quad\text{for some witness }w The relation and public statement must encode the intended application, including ranges and representation rules. (2) x^2\equiv9\pmod{101}\quad\Longrightarrow\quad x\in\{3,98\} Over the field of 101 elements; adding the intended integer range 0 <= x <= 10 leaves only x = 3. (3) \Pr[f(r)=0]\le \min(1,d/q),\qquad f\ne0,\ \deg f\le d Uniform fresh r in a q-element field for a polynomial fixed with the required independence from r; not a full proof-system soundness formula. (4) W_{\mathrm{linear}}=N,\quad W_{\mathrm{transform}}=N\log_2N,\quad W_{\mathrm{log}}=\log_2N Illustrative abstract work terms only. Their units are not interchangeable wall-clock costs and do not define every proof system. Analytical figures Figure 1. Polynomial identity testing needs a field budget Degree/field-size union bound for a nonzero polynomial and uniform challenge. The horizontal variable uses idealized cardinality 2^b; it is not a security estimate for a full proof system. figures/proof-system-costs-1.csv Figure 2. Succinct verification does not erase prover work Illustrative growth functions with coefficient one. Curves are not measured or asserted complexities of Groth16, PLONK or STARK implementations. figures/proof-system-costs-2.csv Comparison Stage | Report | Common omission Relation encoding | Ranges, public inputs, witness semantics | Field arithmetic mistaken for bounded integers Setup | Trust, scope, updates, amortization | Only proof-generation timing shown Prover | Witness work, peak memory, elapsed time | Short proof interpreted as cheap computation Verifier and application | Security parameters, binding, public leakage | Valid proof interpreted as truthful input Proposed validation protocol 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. Limitations 1. The local code is a finite-field educational example, not a secure cryptographic implementation. 2. The polynomial root bound is only one elementary component of possible protocol analyses. 3. The scaling curves are declared functions and contain no measured proving or verification times. 4. The review does not compare every modern proof-system variant or establish current library security. Research questions 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? Source evidence cs-11-1: Groth16 provides a pairing-based succinct noninteractive argument construction. Boundary: Setup and hardness assumptions remain part of its security statement. Locator: Construction and security model. cs-11-2: PLONK uses an updatable universal structured reference string and permutation-based machinery. Boundary: Universal setup does not remove every trust or implementation assumption. Locator: IACR abstract and protocol construction. cs-11-3: STARK work develops transparent computational-integrity arguments with a different design and assumption profile. Boundary: Transparency and post-quantum-oriented claims must be read with the exact construction and assumptions. Locator: IACR abstract and computational-integrity framework. References cs-11-1. Jens Groth. On the Size of Pairing-Based Non-interactive Arguments. Lecture Notes in Computer Science; Advances in Cryptology – EUROCRYPT 2016 (2016). https://eprint.iacr.org/2016/260 | DOI: 10.1007/978-3-662-49896-5_11 cs-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). https://eprint.iacr.org/2019/953 cs-11-3. Eli Ben-Sasson, Iddo Bentov, Yinon Horesh, Michael Riabzev. Scalable, transparent, and post-quantum secure computational integrity. Cryptology ePrint Archive 2018/046 (2018). https://eprint.iacr.org/2018/046 cs-11-1 access: Primary record, abstract and selected accessible text; not an exhaustive full-text or supplementary-material audit. cs-11-2 access: Primary record, abstract and selected accessible text; not an exhaustive full-text or supplementary-material audit. cs-11-3 access: Primary record, abstract and selected accessible text; not an exhaustive full-text or supplementary-material audit. Provenance 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. 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.