{"id":"8e0931e3-a362-480a-9ded-6a1eb3969721","arxiv_id":"2411.15031","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"high","formal_verification":"none","parameter_count":0,"one_line_summary":"A database system that uses PLONKish/Halo2 zero-knowledge circuits to prove SQL query results are correct without revealing the private database, with TPC-H experiments against ZKSQL and Libra.","lead":"PoneglyphDB builds zero-knowledge proof circuits for SQL query operators so a database owner can prove query answers are correct without revealing the underlying data. It claims to be the first non-interactive system for arbitrary SQL verification, reporting faster proof generation than prior methods on TPC-H queries.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Section 4.3's boundary constraints define b=1 for equal adjacent values, not for bin boundaries, so the GROUP BY / SUM gates used in every TPC-H query are unsound as written.","rationale":"I agree with the reader's weakest_assumption; it is the load-bearing point. The paper's central claim is that arbitrary SQL verification is sound and practical, and the reported TPC-H evaluation exercises GROUP BY-based aggregates. Equations 6–7 are the only mechanism for delimiting group-by bins, and the mechanism is inverted with respect to the start/end predicate described in the surrounding text. The rest of the gate-level exposition, such as the lookup-based range checks and sort permutation checks, has plausible textbook structure, but the compositional correctness argument in §4.6 assumes every constituent gate is correct; one inverted predicate breaks that induction. I credit the paper for being explicit about limitations such as differential privacy and query filtering, and for relying on Halo2's standard security properties, but none of that compensates for a concrete incorrect constraint in a gate used by all six evaluated queries. There is no released code or formal verification artifact that could independently rescue the implementation. The reader's REJECT verdict remains appropriate, and I would not adjust it; the issue is specific enough that a minimal gate-level test would settle it quickly.","tokens_in":25827,"tokens_out":8027,"duration_ms":83922,"concrete_test":"Instantiate the §4.3 group-by gate alone in Halo2 (or any PLONKish engine) on input D1=[1,1,2,2,3] with D2 values chosen so that each bin sum is distinctive, following Example 4.2 exactly: sort by D1, compute b from Equations 6–7, derive the S/E columns, and read the final O output. Check whether O equals the true per-group SUMs. A second analytic check is to enumerate all (b,p) satisfying Equations 6–7 for adjacent pairs (1,1) and (1,2); the first forces b=1 and the second forces b=0, so no satisfying assignment can mark the boundary row of the first bin.","verdict_should_be":"UNCHANGED","load_bearing_attack":"In §4.3, Equations (6) and (7) enforce b = 1 when v1 = v2 and b = 0 when v1 ≠ v2. Equation (6) gives b = 1 − (v1−v2)p, and Equation (7) forces b·(v1−v2) = 0, so in every satisfying assignment b is exactly the equality indicator of the adjacent pair, with 1 for \"equal\" and 0 for \"different\". The text, however, uses this bit to mark start/end records: a start should be 1 exactly when the previous adjacent value differs, and an end should be 1 exactly when the next adjacent value differs. Thus the constraint is inverted. Concretely, for a group-by column [1,1,2], the constraints mark the interior equal pair as boundary candidates and fail to mark the true final row of the first bin as its end; applying the E column as in Example 4.2 makes SUM copy the wrong per-bin terminal value. Because Q1, Q3, Q5, Q8, Q9, and Q18 all use GROUP BY and/or ORDER BY, the soundness of every reported TPC-H circuit depends on this gate. The flaw is localized and could be repaired, but as written the central evaluation rests on incorrect circuits.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"PoneglyphDB is a proposed database system that uses non-interactive zero-knowledge proofs to let a prover answer SQL queries over a private database while convincing clients of correct execution. The paper's contribution is a set of PLONKish/Halo2 gates for range checks, sorting, group-by, joins, and aggregation, which are combined into circuits for TPC-H queries, with experiments comparing proof generation time and memory against ZKSQL and Libra. The paper claims to be the first system to combine zero-knowledge, non-interactive operation, and support for arbitrary SQL queries, and it reports substantial speedups over Libra and competitive or better performance than ZKSQL on the selected workload.","tokens_in":26113,"tokens_out":14312,"duration_ms":131933,"significance":"If the gate designs were sound, the paper would be a meaningful advance: it would demonstrate that a non-interactive ZKP stack can express a substantial fragment of SQL with practical proof-generation times, and its use of lookup tables, recursive composition, and arithmetic PLONKish circuits is a reasonable engineering direction. The paper grounds its comparisons in the standard TPC-H benchmark and existing systems (ZKSQL and Libra), and it does not rely on fitted parameters or self-cited artifacts. However, two central gate constructions, the group-by boundary detector and the conditional range-check gate, are unsound as written, and because all six evaluated TPC-H queries depend on these gates, the experimental claims currently rest on incorrect circuits.","major_comments":[{"comment":"The constraints in Eqs. (6)-(7) implement an equality indicator, not a bin-boundary marker. For every satisfying assignment, b=1 when v1=v2 and b=0 when v1 differs from v2: Eq. (6) with p=0 gives b=1 for equal values, and for unequal values Eq. (7) forces p=1/(v1-v2), hence b=0. The text, however, states that b=1 marks a record as the start or end of a bin, which should occur exactly when the record's group-by value differs from the previous adjacent record (for a start) or from the next adjacent record (for an end). The paper's own correctness analysis in this subsection confirms the equality-indicator reading. Consequently, the S and E columns used in Example 4.2 and the SUM and aggregation gates built on them are inverted for runs of equal values; for a sorted group-by column [1,1,2], the interior equal pair is marked as a boundary and the true end of the first bin is not. Since Q1, Q3, Q5, Q8, Q9, and Q18 all use group-by and/or order-by, the soundness of every reported TPC-H circuit depends on this gate. The fix is localized, such as defining separate start and end flags with constraints tied to adjacent unequal values, but it must be made before the experimental results can be taken as evidence for the system's claims.","section":"Section 4.3, Eqs. (6)-(7)"},{"comment":"The conditional range-check gate does not constrain the prover-determined check column. Equation (4) only range-checks the value (x-t)+check*u; there is no constraint imposing that check lies in {0,1} and no constraint relating check to the sign of x-t. Because u is invertible in the finite field, a prover can, for any x-t, choose a field element check that makes this expression an element of [0,u); for example, with x-t=100 and u=10, taking check=-10 gives 0. Thus the gate accepts witnesses in which check is neither 0 nor 1 and does not encode whether x<t. The paper's Correctness paragraph argues that setting the binary variable check correctly is sufficient, but soundness requires that incorrect assignments be rejected by the constraints, not merely that a correct assignment exists. This unsoundness propagates to the sort gate, which uses Eq. (4) to enforce R_i <= R_{i+1}, and to all filtering and join predicates built on range checks. The gate needs explicit constraints, for instance check*(check-1)=0 together with a constraint that links check to the difference x-t, such as a sign-carrying decomposition.","section":"Section 4.1, Design D and Eq. (4)"},{"comment":"The disjointness argument for the join gate is under-specified in a load-bearing way. The text first says that a sorted table S is created to store the unique values in T1'_non-p and T2'_non-p, then later says that S is a permutation of T1_de union T2_de and satisfies S_i < S_{i+1}. If union is interpreted as set union of deduplicated values, strict increasingness of S cannot detect a value appearing in both T1'_non-p and T2'_non-p, because the duplicate is removed before S is built. If union is intended as multiset union, then the earlier 'unique values' wording must be corrected and the proof should state explicitly that duplicates are preserved until the strict-inequality check. As written, the completeness and exclusivity claims in the join correctness proof do not follow from the described constraints.","section":"Section 4.4, Join gate"}],"minor_comments":[{"comment":"The section title 'Application Framework Disuccsion' contains a typo and should read 'Application Framework Discussion'.","section":"Section 3.3"},{"comment":"The affiliation of all three authors is spelled 'Unversity of California, Irvine'; this should be corrected to 'University'.","section":"Author affiliations"},{"comment":"The symbols '%' and '!' in Table 1 are not explained in the caption; please add a legend stating which symbol denotes support and which denotes lack of support.","section":"Table 1"}],"recommendation":"major_revision","confidential_remarks":"Given that the reported TPC-H numbers are produced by circuits whose central gates are unsound as written, I would not accept the paper in its current form. The errors appear repairable in principle, but the authors should re-derive the group-by boundary constraints and the conditional range-check gate, re-run the experiments on corrected circuits, and ideally release a code artifact or a machine-checkable constraint listing so that the gate definitions can be audited. I also note the absence of an artifact link, which would have made the gate-level review substantially easier."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Bottom line: this is a serious engineering effort, but the central soundness claim does not hold as written. The group-by boundary constraint in Section 4.3 is inverted, and since every evaluated TPC-H query uses group-by or order-by, the headline numbers rest on circuits that do not enforce what the text says they enforce.\n\nWhat is genuinely new here is the combination of PLONKish/Halo2 with Plookup-style lookups to build gates for range check, sort, group-by, join, and aggregation, and the demonstration that a non-interactive system can be competitive with ZKSQL on six TPC-H queries. The range-check and join gate descriptions are mostly readable, the complexity counts are useful, and the comparison table is honest about ZKSQL being interactive and about the limits of Fiat-Shamir for designated-verifier protocols.\n\nThe load-bearing flaw: Equation (6) sets b = 1 when v1 = v2 and b = 0 when v1 != v2 (with p chosen accordingly). That is an equality indicator, not a boundary indicator. A start or end row should be flagged when adjacent values differ. For a group column [1,1,2], the constraint marks the equal pair as the boundary and misses the actual end of the first bin. The SUM gate in Example 4.2 then copies the wrong per-bin terminal value. This is not a nitpick; Q1, Q3, Q5, Q8, Q9, and Q18 all depend on it. The flaw looks repairable—flip the sense of b or fix the row indexing—but as submitted the evaluation is unsound.\n\nSecond, Design D's conditional range check leaves `check` as a free witness with no explicit binary constraint like check*(1-check)=0. The text says wrong check values cause proof generation to fail, but soundness requires that no assignment of check can satisfy the constraints for a false statement. Since the lookup only constrains (x-t)+check*u to be in [0,u), a prover can pick arbitrary field elements for check and pass. If check must be boolean, that constraint is missing.\n\nMinor: the \"arbitrary SQL\" claim is broader than the implemented and evaluated subset, and no code or artifacts are provided, so the benchmarks are not externally reproducible.\n\nWho this is for: researchers in verifiable databases and ZKP circuit design. The gate taxonomy is useful even if the current circuits are buggy. It deserves a serious referee—the idea is significant and the flaw is localized—but the referee will need to check equations carefully. My recommendation: send to peer review with a request for major revision, specifically re-examining Eqs. (6)-(7) and the conditional range check.","headline":"Promising systems paper with a load-bearing flaw: the group-by boundary constraint is inverted, so the TPC-H evaluation rests on unsound circuits; still worth peer review for repair.","tokens_in":26614,"tokens_out":3772,"would_cite":false,"duration_ms":36326,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"PoneglyphDB claims the first non-interactive zero-knowledge proof system for arbitrary SQL queries, with proof times competitive with or better than prior interactive systems.","keywords":["zero-knowledge proofs","verifiable SQL queries","non-interactive proof systems","arithmetic circuit design","lookup tables","group-by and aggregation","database commitment","TPC-H benchmark"],"falsifier":"Take a two-row table whose grouping attribute has distinct values, supply the honest witness with the inverse of their difference, and inspect the constraint satisfaction: a correct boundary marker must set both rows as boundaries, while the equations as written would set neither. If the proving algorithm accepts a witness that places the end index of the first group at the second row's position, the group-by gate is not actually enforcing bin boundaries.","tokens_in":25614,"feed_emoji":"🔐","tokens_out":7901,"duration_ms":73273,"temperature":0.7,"pith_summary":"This paper tries to show that a database can answer arbitrary SQL queries with a cryptographic proof of correctness while keeping the raw data entirely at the server, and without requiring the server and client to interact during proof generation. Earlier zero-knowledge approaches to SQL either needed multiple rounds of communication or did not support ad-hoc queries. The paper's route is to express each core SQL operation—range checks, sorting, group-by, joins, aggregation—as a small arithmetic circuit gate with low-degree polynomial constraints, then chain the gates along the query plan. If the construction holds, a data owner could commit to a database once and let many clients independently verify each query answer later, which is exactly the setting for regulated or shared sensitive data.","feed_headline":"One database proves any SQL query in zero knowledge, offline","feed_subtitle":"Clients can verify any query answer later, without seeing raw data or waiting through interactive rounds.","key_machinery":"The load-bearing mechanism is a set of custom gates in a tabular arithmetic circuit: a rectangular matrix of values with fixed, advice, and instance columns, where each row must satisfy low-degree polynomial equations and cells can be linked by equality constraints. Range checks are done with lookup tables, so a value is shown to fall in a set by proving it appears in a permuted copy of that set rather than by factoring a high-degree polynomial. Sorting reduces to a permutation check plus adjacent orderedness checks; group-by sorts and then uses a binary marker to record where equal-valued runs start and end; joins use sorted, deduplicated columns to prove non-contributing records from one table cannot match the other. A cryptographic commitment to the whole database is produced once and reused, and recursive proof composition keeps each final proof small.","core_discovery":"On its own terms, the central discovery is that non-interactive zero-knowledge verification of arbitrary SQL is not inherently too expensive, provided the SQL operators are compiled into lookup-table-based arithmetic gates rather than boolean circuits. Each gate establishes one property: a range check proves every value lies in a set by a permutation argument; a sort gate proves the output is a permutation of the input and is ordered; a group-by gate sorts on the grouping attributes and marks the first and last row of each equal-valued run; a join gate splits each table into contributing and non-contributing rows and proves the non-contributing rows are disjoint from the other table. The paper also uses a one-time database commitment so every later proof is tied to the same private data, and recursive proof composition to keep proofs compact. The authors report that on six standard analytics queries the resulting proofs are generated faster than an interactive zero-knowledge SQL system and much faster than a non-interactive comparison system, while using less memory.","pith_inferences":["Editorial inference: the gate decomposition is portable: the same SQL gates could be compiled onto a future, faster proving system, so the architecture's value is likely to outlive the specific proving implementation used in the paper.","Editorial inference: the group-by boundary equations are the most fragile link; if they are corrected or replaced by a separate proof, the rest of the gate library would be unchanged, suggesting the design is modular rather than inherently flawed.","Editorial inference: a natural next test is queries with nested subqueries and HAVING clauses, since the demonstrated benchmark set exercises flat filters, joins, group-by, and aggregates but not nested query plans.","Editorial inference: combining the commitment-and-proof structure with differential privacy could make privacy budgets auditable, though the paper notes this would add circuit overhead."],"forward_implications":["Proofs become transferable: any client holding the verification key can check an answer at any later time, enabling caching and re-use of previously computed responses.","Committing to a database is a one-time cost, after which individual queries can be proven and verified independently against the same public commitment.","Because gates compose along the query plan, any SQL query expressible with the supported operators inherits a correctness proof from the correctness of its individual gates.","Proof generation time and memory grow roughly linearly with input size, since all enforced polynomial constraints have low degree.","The zero-knowledge guarantee limits verifier learning to the answer and its logical consequences, so raw rows, intermediate group boundaries, and sort orders stay hidden."],"supporting_citations":[{"why":"Supplies the interactive zero-knowledge SQL baseline and the six standard analytics query workloads used for the main performance comparison.","marker":"[30]"},{"why":"Provides the proving system that turns the paper's arithmetic circuits into non-interactive zero-knowledge proofs.","marker":"[44]"},{"why":"Supplies the lookup-table protocol that every range-check gate is built on.","marker":"[19]"},{"why":"Prior verifiable SQL system that handles arbitrary queries without zero-knowledge, used as the positioning baseline and as the logic source for the non-interactive comparison.","marker":"[47]"},{"why":"Prior verifiable SQL system, the other main baseline for the non-interactive and zero-knowledge property comparison.","marker":"[49]"},{"why":"Establishes recursive proof composition without a trusted setup, which the paper uses to keep proofs compact.","marker":"[9]"},{"why":"Gives the inner product argument used for database and polynomial commitments.","marker":"[8]"},{"why":"Non-interactive comparison baseline; its circuit structure is adapted to SQL operations for the proving-time comparison.","marker":"[40]"},{"why":"Provides the interactive delegation protocol on which the non-interactive comparison baseline is built.","marker":"[20]"}],"fun_headline_variants":["Prove any SQL query without leaking data","Non-interactive zero-knowledge for SQL queries","SQL verification in zero knowledge, offline","Prove any SQL query privately, no interactive rounds","PoneglyphDB: ZK proofs for arbitrary SQL"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"All the group-by, aggregation, order-by, and join proofs presume that the circuit equations for marking group-by boundaries identify the first and last row of each run of equal values; as written, those equations appear to flag equal neighboring rows instead of differing ones, so if that reading is correct, the boundary indices would not enforce the intended grouping.","fun_headline_variants_meta":{"raw":{"variants":["Prove any SQL query without leaking data","Non-interactive zero-knowledge for SQL queries","SQL verification in zero knowledge, offline","Prove any SQL query privately, no interactive rounds","PoneglyphDB: ZK proofs for arbitrary SQL"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000586,"raw_usage":{"total_tokens":2750,"prompt_tokens":941,"completion_tokens":1809,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":557,"completion_tokens_details":{"reasoning_tokens":1737}},"tokens_in":557,"tokens_out":1809,"duration_ms":12105,"temperature":1.0,"reasoning_tokens":1737,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T14:35:59.390773+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take a two-row table whose grouping attribute has distinct values, supply the honest witness with the inverse of their difference, and inspect the constraint satisfaction: a correct boundary marker must set both rows as boundaries, while the equations as written would set neither. If the proving algorithm accepts a witness that places the end index of the first group at the second row's position, the group-by gate is not actually enforcing bin boundaries.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the interactive zero-knowledge SQL baseline and the six standard analytics query workloads used for the main performance comparison."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the proving system that turns the paper's arithmetic circuits into non-interactive zero-knowledge proofs."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the lookup-table protocol that every range-check gate is built on."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Prior verifiable SQL system that handles arbitrary queries without zero-knowledge, used as the positioning baseline and as the logic source for the non-interactive comparison."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Prior verifiable SQL system, the other main baseline for the non-interactive and zero-knowledge property comparison."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Establishes recursive proof composition without a trusted setup, which the paper uses to keep proofs compact."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Gives the inner product argument used for database and polynomial commitments."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Non-interactive comparison baseline; its circuit structure is adapted to SQL operations for the proving-time comparison."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the interactive delegation protocol on which the non-interactive comparison baseline is built."}],"review_version":1}