{"id":"0ae2300f-0a85-4d35-b9bb-fb537a050c3b","arxiv_id":"2507.13932","paper_version":1,"verdict":"REJECT","confidence":"HIGH","novelty_score":3.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A database table can be tamper-evident by maintaining an append-only hash chain of all updates, but only if that chain is stored somewhere the attacker cannot modify.","lead":"This paper introduces a 'chain table,' an append-only cryptographic hash log stored inside a database to detect unauthorized changes to a data table. It presents a simpler alternative to full blockchain systems, though its security guarantee depends on keeping the chain table itself on trusted storage.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Chain table authenticates appends but not their authorization; an adversary with write access can append a malicious update and still pass the paper's verification, so the TDI guarantee fails even under the paper's own threat model.","rationale":"I read the paper as claiming that retroactive tampering with previously recorded data can be detected and that the original data can be reconstructed. The chain-table construction supports tamper-evidence of an append-only history, but that is weaker than the claimed TDI. The load-bearing gap is that appending a new, authorized-looking update is a supported operation, and the chain table records it without any check on authorization. This is not a niche attack: §3.3 explicitly includes external users who take control via vulnerabilities and administrative-credential theft. The reader's weakest_assumption focuses on the immutability of chain-table storage; that is also a real requirement, but my concern survives even if the storage is perfectly trusted, because the adversary never rewrites the chain; the database appends to it as part of normal operation. I therefore mark agreement as partial: the reader identified a missing trust boundary, but the more fundamental issue is the missing authorization invariant. The paper provides no implementation, benchmarks, or machine-checked proof, so the informal Section 5 argument is the only support for the guarantee; that argument covers only in-place tampering and not append-based unauthorized updates. My concrete test would exhibit a direct counterexample to the central claim under the paper's own enabled operations and threat model. Since the claim is disproved as stated, I recommend no change to the reader's REJECT verdict.","tokens_in":7417,"tokens_out":5821,"duration_ms":69241,"concrete_test":"Run the Events/EventLedger example under an adversary who has UPDATE permission but no direct chain-table access. Have the adversary change record {2,t2,opt2} to {2,t5,opt5} by issuing an UPDATE through the standard database interface, so a new chain record {lid=4, prevHash=h3, update=[{2,t5,opt5}]} is appended. Then execute the verification procedure from §5.1.1: replay EventLedger to reconstruct the Events table and compare it with the current data table. If the two match, the chain table has failed to detect an unauthorized modification under the paper's own threat model, disproving the TDI guarantee. An analytic alternative: formalize the adversary capability 'append a valid chain record through the normal write path' and check whether any invariant in §5 remains violated; it will not.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim (Abstract, §5) is that the chain table plus the writing principles guarantee table-level data integrity. The principles in §4.3 regulate only the form of writes: append-only, one record at a time. They say nothing about who may authorize an update or whether the appended content is legitimate. §3.2 explicitly permits updates, and §3.3 includes adversaries who steal administrative authorities or take control of the database and make modifications. If such an adversary performs an UPDATE through the normal database interface, the data table gains a new row and the chain table gains a new valid record; no existing hash is recomputed and no writing principle is violated. The verification in §5.1.1 reconstructs the data table by replaying the chain table's update column and compares it with the current data table. Since the malicious append is itself in the chain table, the comparison succeeds and the tampering is undetected. The proof's attack scenarios 1 and 2 only cover in-place modification of existing chain records that forces recomputation of downstream hashes; they never consider appending a fraudulent update. This is an internal gap in the stated guarantee, not merely a disagreement with current consensus. Even granting the independent trusted-storage assumption of §4.2, the normal write path gives an adversary an append capability, so the chain table cannot distinguish authorized updates from unauthorized ones.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes an in-database 'chain table'—a ledger table storing linked double-SHA hashes of update batches—to protect a relational data table from unauthorized tampering. It defines append-only writing principles and claims, in the Abstract and Section 5, that the chain table together with these principles 'will guarantee' table-level data integrity (TDI). The proposed mechanism includes verification by replaying the ledger's update column and reconstruction of the data table from the ledger. The argument is presented as two informal attack scenarios rather than as a formal security proof.","tokens_in":7595,"tokens_out":5637,"duration_ms":64795,"significance":"If the guarantee held, the chain table would be a lightweight alternative to a full blockchain for detecting unauthorized modifications to a critical database table. The linked-hash construction is simple and does correctly make in-place modification of ledger history detectable, and the related-work discussion appropriately positions the proposal against QLDB, Oracle Blockchain Table, and SQL Ledger. However, the claimed TDI guarantee is not established: the proof is informal, the storage-boundary assumption is not incorporated into a theorem statement, and the paper's own threat model admits an adversary who can append a fraudulent but valid ledger record. The contribution is therefore a useful tamper-evident audit-log sketch rather than a validated integrity guarantee.","major_comments":[{"comment":"The central claim that the chain table 'will guarantee' TDI is falsified by an append attack that is within the paper's own threat model. Section 3.2 explicitly enables updates, and Section 3.3 includes adversaries who steal administrative authorities or take control of the database and make modifications. Such an adversary can append a new record to both the data table and the chain table through the normal write path. Because the chain table's hash is computed from the new update and the previous hash, the appended record verifies correctly, and the verification procedure in Section 5.1.1, which reconstructs the data table by replaying the chain table's update column, will report consistency. The two attack scenarios in Section 5 only consider in-place modification of existing chain records; they never consider a fraudulent but well-formed append. The writing principles in Section 4.3 regulate the form of writes, not their authorization, so they do not exclude this attack. This gap is internal to the stated guarantee, not a disagreement with external consensus.","section":"§3.2, §3.3, §5, §5.1.1"},{"comment":"The integrity argument assumes the chain table itself is immutable, but this assumption is neither stated as a formal hypothesis nor reconciled with the threat model. Section 4.2 says it is 'recommended' that the chain table be stored on independent trusted storage, and Section 4.3 states that 'the only allowed write operation on a chain table is appending data,' but these are policies rather than mechanisms that a powerful adversary—such as the database administrator in Section 3.3—cannot bypass. If an adversary can modify the chain table in place, he or she can change both the data table and the ledger entries and recompute all hashes from the modified point onward, exactly as Tables 5 and 7 illustrate for the defender's side. The claimed guarantee is therefore circular: the protection rests entirely on an unproven storage-boundary assumption, and that assumption conflicts with the paper's own threat model.","section":"§4.2, §4.3, §5"},{"comment":"The Abstract states that the paper 'prove[s]' table-level data integrity, but Section 5 contains no formal theorem, no precise threat-model definition with adversary capabilities, and no reduction. The argument consists of two illustrative attack scenarios and an informal verification description. Because the proof never formalizes what 'integrity' means relative to ground truth—as opposed to consistency between the data table and its own ledger—it cannot support the universal claim made in the Abstract. A formal statement would need to specify the trusted components, the adversary's read and write capabilities, and the exact sense in which tampering is detected.","section":"§5"}],"minor_comments":[{"comment":"Equation (1) is missing a closing parenthesis; it should read hash = SHA(SHA(lid, update, prevHash)).","section":"Eq. (1)"},{"comment":"The terms 'temper,' 'tempering,' and 'tempered' should be 'tamper,' 'tampering,' and 'tampered' throughout the manuscript.","section":"Throughout"},{"comment":"The Introduction says Section 5 is related work, but in the text related work appears as Section 6, and Section 5 contains an orphan subsection 5.1.1 with no preceding 5.1.","section":"§1, §5, §6"},{"comment":"The reconstruction description says to 'append all updates' from the chain table, but because updates modify existing rows by primary key, reconstruction must specify the replay semantics (apply insertions and updates in lid order) rather than a simple append.","section":"§5.1.1"},{"comment":"The 'double SHA' description is imprecise and the serialization of the tuple (lid, update, prevHash) is unspecified; for a reproducible integrity check, the exact hash algorithm and byte encoding should be stated.","section":"§4.1"}],"recommendation":"reject","confidential_remarks":"The manuscript needs substantial rework before it can be considered for publication. The append attack defeats the stated guarantee even under the paper's own threat model, and the immutability assumption is outsourced to an unmodeled trusted-storage boundary. I would not oppose a future resubmission if the authors reposition the contribution as a trusted append-only audit log with explicit assumptions and a formal security statement."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Honest take: the paper's central claim — that the chain table plus the writing principles \"guarantee\" table-level integrity — does not survive contact with its own threat model. An adversary with write access can append a fraudulent update to the data table and a matching record to the chain table; verification replays the chain table and sees a consistent history, so the tampering goes undetected. The proof only considers in-place modification of existing chain records, not a valid-looking append.\n\nWhat's genuinely there: a clean, minimal description of a hash-chained ledger table stored alongside a data table, with a four-column schema (lid, hash, prevHash, update) and two append-only writing principles. The authors describe the design clearly and cite the commercial systems they build on — SQL Ledger, Oracle Blockchain Table, QLDB — which is honest. If you assume the chain table lives on tamper-proof storage and every append to it is authorized, the scheme works as an append-only audit log. That's a real, if narrow, use case.\n\nThe soft spots are structural, not cosmetic. First, the writing principles in Section 4.3 regulate the form of writes, not their authorization. Nothing stops a DBA — who the threat model explicitly says can bypass policies — from appending a malicious update. The hash chain authenticates the history of what was written; it does not authenticate whether each entry was legitimate. Second, Section 4.2's trusted-storage assumption is not folded into the Section 5 theorem statement, and it sits in tension with the stated adversary. Third, the paper offers no implementation, benchmarks, or formal proof — the argument is scenario-based and misses the append attack entirely. Novelty is low: hash-chained logs are standard in the cited prior work.\n\nWho is this for? A reader who wants a very short introduction to the idea of an in-database ledger. But as a research contribution, the central guarantee fails as stated. I'd reject before peer review. If the authors narrow the claim to \"append-only tables with trusted storage and authorized writes,\" there might be a workshop-level paper, but this version doesn't support the advertised guarantee.","headline":"The chain table is a clear, minimal hash-chained log, but the claimed integrity guarantee fails because the design never authenticates the authorization of appends, so an adversary with write access can pass verification.","tokens_in":8155,"tokens_out":2425,"would_cite":false,"duration_ms":26630,"reading_group":"no","serious_thinker":"yes","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper claims that a small in-database chain table, combined with append-only write rules, guarantees detection of any unauthorized modification to a relational table and lets the original data be reconstructed.","keywords":["chain table","data integrity","digital ledger technology","blockchain","database security","table-level data integrity","append-only ledger","tamper detection"],"falsifier":"Grant a database administrator full SQL access to both the data table and the chain table on the same server, have them change a middle row's description and rewrite the affected chain-table hashes with UPDATE statements, then run the described verification procedure; if the verification passes, table-level data integrity does not hold under the stated threat model.","tokens_in":7156,"feed_emoji":"🔗","tokens_out":4266,"duration_ms":49390,"temperature":0.7,"pith_summary":"This paper aims to establish that a compact in-database ledger, called a chain table, can give a relational data table the same kind of tamper-evidence that a blockchain gives a distributed ledger, without deploying a blockchain system. The chain table records every batch of writes to the protected table, with each record's hash computed from the current update and the previous record's hash, so the entries form a chain. Working with two writing principles (append-only writes, one record at a time), the design is argued to guarantee table-level data integrity: unauthorized changes to the data table would require rewriting chain-table records, which the write rules forbid and which therefore get detected. If the argument holds, sensitive tables in ordinary databases can gain tamper detection and data reconstruction at low storage and technical overhead.","feed_headline":"One ledger table inside a database catches data tampering","feed_subtitle":"Every update is chained into an append-only hash ledger, so unauthorized edits break the chain and original rows can be rebuilt.","key_machinery":"The central object is the chain table (also called the ledger table), a four-column structure with schema (lid, hash, prevHash, update), where lid is an auto-incrementing identifier, update holds the data records of one write operation, prevHash is the hash of the previous ledger record, and hash is computed as $\\mathrm{hash} = \\mathrm{SHA}(\\mathrm{SHA}(lid, update, prevHash))$, using the double-SHA256 procedure. This hash chaining makes the ledger records tamper-evident, while the write principles (append-only, one record at a time) are what turn the structure into an integrity guarantee.","core_discovery":"The central claim is that a chain table, together with the data writing principles, will guarantee flexible data integrity, named table-level data integrity (TDI). The chain table stores, for each batch of writes, a ledger record containing an identifier, a hash, the previous hash, and the update payload. Because each hash depends on the previous hash, tampering with any historical update forces an adversary to modify the chain record containing that update and every subsequent record. The write principles prohibit modification and multi-record writes, so the attack is detected and aborted. The same update history also supports verification and reconstruction of the data table at any time.","pith_inferences":["The guarantee is only as strong as the separation between the data table and the chain table storage; the paper names this separation but does not prove it, so a realistic deployment needs an external trusted element such as a tamper-resistant appliance or periodic off-site snapshot.","The attack analysis is illustrative rather than a formal security reduction; a full proof would need to model exactly what operations the write principles can enforce inside a real DBMS, since SQL-level privileges may not honor a logical append-only rule.","The same chaining idea could be extended to protect the whole database by linking per-table chain tables into a global ledger, or adapted to NoSQL and semi-structured systems mentioned as future work.","A direct comparison of storage and update latency against alternative table-level integrity designs that maintain Merkle trees would quantify the claimed simplification."],"forward_implications":["A critical relational table can be protected by one adjacent chain table, with no distributed network, consensus algorithm, or external blockchain deployment.","Any attempt to tamper with an earlier record forces an adversary to rewrite that chain record and every later one, which violates the append-only writing principle and is detected.","The update history stored in the chain table lets an auditor reconstruct the data table at any time, so even a successful tampering or accidental corruption can be repaired.","Because hashing uses only the current update and the previous hash, per-write overhead and ledger size stay small relative to hashing the entire table."],"supporting_citations":[{"why":"Supplies the blockchain chaining concept (each block includes the previous block's hash) that the chain table emulates.","marker":"[1]"},{"why":"Provides the SHA hashing background for the double-SHA256 procedure used in chain-table hash generation.","marker":"[6]"},{"why":"Describes an existing in-database ledger solution (Amazon QLDB) that the chain table contrasts with by preserving relational table structure.","marker":"[12]"},{"why":"Describes Oracle's blockchain-table integration, which locks hash codes inside one database and is difficult to transfer between systems.","marker":"[13]"},{"why":"Describes SQL Ledger's table-level integrity design requiring three structures plus a Merkle tree, the baseline the chain table aims to simplify.","marker":"[14]"}],"fun_headline_variants":["In-database chain table blocks tampering without blockchain","Chain table: hash-linked batches catch data edits","Tamper-proof table inside DB via hash chain","Table-level integrity from a simple hash ledger","Chain table guards data with append-only hash log"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The argument rests on the assumption that the chain table lives on independent trusted storage that powerful adversaries, including the database administrators named in the threat model, cannot access; if they can modify both tables, they can recompute all hashes and defeat the guarantee.","fun_headline_variants_meta":{"raw":{"variants":["In-database chain table blocks tampering without blockchain","Chain table: hash-linked batches catch data edits","Tamper-proof table inside DB via hash chain","Table-level integrity from a simple hash ledger","Chain table guards data with append-only hash log"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000669,"raw_usage":{"total_tokens":2984,"prompt_tokens":812,"completion_tokens":2172,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":428,"completion_tokens_details":{"reasoning_tokens":2101}},"tokens_in":428,"tokens_out":2172,"duration_ms":16693,"temperature":1.0,"reasoning_tokens":2101,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T16:12:42.697828+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Grant a database administrator full SQL access to both the data table and the chain table on the same server, have them change a middle row's description and rewrite the affected chain-table hashes with UPDATE statements, then run the described verification procedure; if the verification passes, table-level data integrity does not hold under the stated threat model.","supporting_citations":[{"cited_title":"Different from a traditional centralized data storage model, a blockchain employs a decentralized storage model without relying on a trusted central authority","cited_arxiv_id":null,"evidence_quote":"Supplies the blockchain chaining concept (each block includes the previous block's hash) that the chain table emulates."},{"cited_title":"SQL Ledger: Cryptographically Verifiable Data in Azure SQL Database,","cited_arxiv_id":null,"evidence_quote":"Describes SQL Ledger's table-level integrity design requiring three structures plus a Merkle tree, the baseline the chain table aims to simplify."}],"review_version":1}