Tamper-evident ledger (hash chain)

What it is

A hash chain links records in order. Entry n stores hash_n = sha256(hash_(n-1) + contents_n). Change one byte in an old entry and its hash no longer matches; every later hash, which depends on it, stops matching too. That property is called tamper-evident: it does not stop anyone editing the data, but it makes an edit visible to anyone who checks.

Why it matters

An agent audit log is only useful as evidence if nobody can quietly rewrite it, including the operator who runs it. A plain database table can be edited without trace. A hash chain lets an auditor recompute the hashes and confirm the record is the one that was written.

How it works

1. Fix the exact list of fields that are hashed, in order. Adding a field later changes every hash, so the list must be explicit.
2. Start from a known genesis value, such as 32 zero bytes.
3. Hash each new entry together with the previous hash.
4. Anchor the chain: periodically write the latest hash (the head) somewhere the ledger's operator cannot silently rewrite, so the whole chain cannot be recomputed after an edit.
5. Verify by recomputing from any anchored point.

Certificate Transparency (RFC 6962) uses Merkle trees for the same goal on public logs: if a log shows different histories to different people, comparing tree heads exposes it.

Example

Rows 1 to 1,000 are chained and yesterday's head was sealed. Someone edits row 400 to hide a refund. Recomputing gives a different hash at row 400 and at every row after it, and today's head no longer matches the chain that leads to yesterday's seal.

Common pitfalls

• Overclaiming. A hash chain cannot prevent tampering; it makes tampering detectable. Call it tamper-evident.
• No anchor. If the operator holds the only copy of the head, they can rewrite the chain end to end. External witnesses or published seals close that gap.
• Hashing fields that change (status updated later, timestamps rewritten) produces false alarms.
• Undocumented gaps. Auditors stop trusting a chain whose gaps they discover themselves.

How actionlake handles it

The actionlake ledger has one row per run. Each row's hash is sha256(prev_hash + row) over a fixed field list, per tenant. To keep the request path fast, a single chainer hashes new rows about once a second; that window, in which a new row exists unchained, is documented rather than hidden. Once a day the chain head is sealed to object storage. Any run can be verified on its page in the console. What is not yet true: there is no external witness, and no export of the whole chain; the console's CSV carries the table, not the hashes. The full statement is on the trust page.