Chain Table: Protecting Table-Level Data Integrity by Digital Ledger Technology

Feng Yu; Ryan Laird

REVIEW 3 major objections 5 minor 6 references

Chain Table: Protecting Table-Level Data Integrity by Digital Ledger Technology

T0 review · 3 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

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

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

arxiv 2507.13932 v1 pith:HLDVV56S submitted 2025-07-18 cs.CR cs.DB

Feng Yu , Ryan Laird This is my paper · ORCID

classification cs.CRcs.DB

keywords chaintabledataintegritydigitalledgertechnologyblockchaindatabasesecuritytable-levelappend-onlytamperdetection

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

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

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.

Reading between the lines

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

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.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Desk Editor's Note

read the 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.

What'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.

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

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

Referee Report

3 major / 5 minor

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.

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 (3)

[§3.2, §3.3, §5, §5.1.1] 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.
[§4.2, §4.3, §5] 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.
[§5] 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.

minor comments (5)

[Eq. (1)] Equation (1) is missing a closing parenthesis; it should read hash = SHA(SHA(lid, update, prevHash)).
[Throughout] The terms 'temper,' 'tempering,' and 'tempered' should be 'tamper,' 'tampering,' and 'tampered' throughout the manuscript.
[§1, §5, §6] 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.
[§5.1.1] 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.
[§4.1] 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.

Circularity Check

2 steps flagged · score 6.0 of 10

The TDI guarantee reduces to the assumption that the chain table is immutable and authoritative; verification defines tampering as divergence from the chain table, so an adversary who can append is undetectable by construction.

self definitional [Section 5.1.1 (Verification and Data Reconstruction)]
"At any one time when a data integrity check is needed, the system can read the updates from the chain table to construct a verification table. If at any chain record, the verification table and the data table are not consistent, a data tempering is detected."

The integrity check is defined as equality between the data table and a table reconstructed from the chain table's update column. Therefore 'data tempering' is defined only as divergence from the chain table. An adversary who appends a fraudulent update to the chain table (which the append-only principles permit) and the corresponding record to the data table leaves the two tables consistent, so no tampering is detected. The claimed guarantee that any unauthorized modification will be detected reduces by construction to the weaker statement that any modification not recorded in the chain table will be detected. The chain table's own authenticity is taken as input rather than established.
other [Section 4.3 (Principles of Write Operations) and Section 5 attack scenarios]
"the only allowed write operation on a chain table is appending data. Each batch of data table updates will be appended at the end of the chain table. This eliminates the possibility that someone, even the high privilege adversaries, can directly manipulate the chain records."

This 'eliminates the possibility' is load-bearing for the Section 5 proof, but it is only a policy statement, not an enforced mechanism. The paper's own threat model in Section 3.3 includes adversaries who 'steal the administrative authorities' or 'take control' of the database; such an adversary can invoke the normal append path. The attack scenarios in Section 5 only consider in-place modification of existing chain records, which forces downstream hash recomputation; they never consider appending an unauthorized update, which preserves every existing hash and satisfies the writing principles. The proof therefore assumes the very property it claims to establish: that the adversary cannot write valid-appearing records to the chain table.

full rationale

The paper contains no self-citation chain, and the hash-inclusion construction is self-contained: it genuinely detects in-place modification of historical chain records because such modification forces recomputation of downstream hashes. However, the central table-level data integrity (TDI) guarantee does not follow from the provided derivation. Verification in Section 5.1.1 makes the chain table's update column the ground truth, so the guarantee is conditional on the chain table being immutable and containing only authorized writes. The paper recommends storing the chain table on independent trusted storage (Section 4.2), but the threat model (Section 3.3) includes a database administrator or an intruder with stolen administrative authority, and nothing in the writing principles prevents such an actor from appending a fraudulent update. The attack scenarios in Section 5 cover only modifications that rewrite existing chain records; appends are never analyzed. Consequently, the claimed proof reduces to the assumption that the chain table is trustworthy, and detected 'tampering' is by definition only divergence from that assumed truth. This is a partial, construction-level circularity of the central claim, even though the hash-chain primitive itself is not circular.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The central guarantee rests on the chain table's own immutability, which is assumed via trusted external storage rather than derived. The only free parameters are design choices such as the use of double SHA-256, with no fitted values. No new physical entities are introduced; the chain table is a schema design.

assumptions (4)

domain assumption The chain table is stored on independent trusted storage that adversaries cannot directly access, making it immutable.
Section 4.2 states this recommendation; the integrity proof in Section 5 depends on the chain table being unmodifiable.
standard math SHA-256 (double-hashed) is collision-resistant and one-way, so hash codes cannot be forged or inverted.
Equation (1) and the security argument rely on this cryptographic property.
domain assumption The append-only and one-record-at-a-time write principles are strictly enforced by the database system and cannot be bypassed even by high-privilege administrators.
Section 4.3 states the principles; the proof that attacks are 'detected and aborted' assumes an adversary cannot perform in-place updates or multi-record writes to the chain table.
domain assumption Every data-table update is correctly and completely logged into the chain table's update column.
Verification and reconstruction in Section 5.1.1 require the update column to be a complete, ordered history of all data-table changes.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Chain Table: Protecting Table-Level Data Integrity by Digital Ledger Technology." pith.science (2026). https://pith.science/paper/HLDVV56S

@misc{pith2026250713932,
  author       = {Pith},
  title        = {Pith review of: Chain Table: Protecting Table-Level Data Integrity by Digital Ledger Technology},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/HLDVV56S}},
  note         = {Machine review of arXiv:2507.13932}
}

read the original abstract

The rise of blockchain and Digital Ledger Technology (DLT) has gained wide traction. Instead of relying on a traditional centralized data authority, a blockchain system consists of digitally entangled block data shared across a distributed network. The specially designed chain data structure and its consensus mechanism protect blockchain data from being tampered by unauthorized adversaries. However, implementing a full-fledged blockchain system to protect a database can be technically cumbersome. In this work, we introduce an in-database design, named chain table, to protect data integrity without the need for a blockchain system. It features a succinct design without significant technology barriers or storage overhead. To realize rigorous data security, we also propose a set of data writing principles for the chain table. We prove that the chain table, together with the data writing principles, will guarantee flexible data integrity, named table-level data integrity (TDI).

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

6 extracted references · 5 canonical work pages

[1]

Different from a traditional centralized data storage model, a blockchain employs a decentralized storage model without relying on a trusted central authority

in 2008, the rise of Blockchain has been widely witnessed. Different from a traditional centralized data storage model, a blockchain employs a decentralized storage model without relying on a trusted central authority. Inside a blockchain system, the data is serialized in structure units named blocks. Each block is chained with the previous block by inclu...

work page 2008
[4]

Blockchain consensus algorithms: A survey,

M. S. Ferdous, M. J. M. Chowdhury, M. A. Hoque, and A. Colman, “Blockchain consensus algorithms: A survey,” arXiv preprint arXiv:2001.07091,

arXiv 2001
[5]

vChain: a blockchain system ensuring query integrity,

H. Wang, C. Xu, C. Zhang, and J. Xu, “vChain: a blockchain system ensuring query integrity,” in Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data, 2020, pp. 2693–2696

work page 2020
[9]

Reasoning about the future in blockchain databases,

S. Cohen, A. Rosenthal, and A. Zohar, “Reasoning about the future in blockchain databases,” in 2020 IEEE 36th International Conference on Data Engineering (ICDE), IEEE, 2020, pp. 1930–1933

work page 2020
[11]

Smart contracts: security patterns in the ethereum ecosystem and solidity,

M. Wohrer and U. Zdun, “Smart contracts: security patterns in the ethereum ecosystem and solidity,” in 2018 International Workshop on Blockchain Oriented Software Engineering (IWBOSE), IEEE, 2018, pp. 2–8

work page 2018
[14]

SQL Ledger: Cryptographically Verifiable Data in Azure SQL Database,

P. Antonopoulos et al., “SQL Ledger: Cryptographically Verifiable Data in Azure SQL Database,” in Proceedings of the 2021 International Conference on Management of Data, 2021, pp. 2437–2449

work page 2021

Pith tools

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

[1] [1]

Different from a traditional centralized data storage model, a blockchain employs a decentralized storage model without relying on a trusted central authority

in 2008, the rise of Blockchain has been widely witnessed. Different from a traditional centralized data storage model, a blockchain employs a decentralized storage model without relying on a trusted central authority. Inside a blockchain system, the data is serialized in structure units named blocks. Each block is chained with the previous block by inclu...

work page 2008

[2] [4]

Blockchain consensus algorithms: A survey,

M. S. Ferdous, M. J. M. Chowdhury, M. A. Hoque, and A. Colman, “Blockchain consensus algorithms: A survey,” arXiv preprint arXiv:2001.07091,

arXiv 2001

[3] [5]

vChain: a blockchain system ensuring query integrity,

H. Wang, C. Xu, C. Zhang, and J. Xu, “vChain: a blockchain system ensuring query integrity,” in Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data, 2020, pp. 2693–2696

work page 2020

[4] [9]

Reasoning about the future in blockchain databases,

S. Cohen, A. Rosenthal, and A. Zohar, “Reasoning about the future in blockchain databases,” in 2020 IEEE 36th International Conference on Data Engineering (ICDE), IEEE, 2020, pp. 1930–1933

work page 2020

[5] [11]

Smart contracts: security patterns in the ethereum ecosystem and solidity,

M. Wohrer and U. Zdun, “Smart contracts: security patterns in the ethereum ecosystem and solidity,” in 2018 International Workshop on Blockchain Oriented Software Engineering (IWBOSE), IEEE, 2018, pp. 2–8

work page 2018

[6] [14]

SQL Ledger: Cryptographically Verifiable Data in Azure SQL Database,

P. Antonopoulos et al., “SQL Ledger: Cryptographically Verifiable Data in Azure SQL Database,” in Proceedings of the 2021 International Conference on Management of Data, 2021, pp. 2437–2449

work page 2021