Does blockchain logging mean writing every log line to a blockchain?

No, and any design that does is impractical and expensive. The normal pattern is to hash-chain the log locally and periodically write only the current head hash to a public chain. That fixes every prior entry with one transaction per period, and no log contents are ever published.

Does it stop someone tampering with logs?

It makes tampering detectable rather than impossible. Anyone can still edit the underlying store; what they cannot do is make the recomputed chain match the value already published on the ledger. Detectability by an outsider is the property that matters, since prevention is not achievable against an administrator.

What about entries written since the last anchor?

They are unprotected until the next anchor is published, so the anchoring interval is your exposure window. Shortening it costs one more transaction per period, which is the whole trade-off — hourly anchoring costs roughly twenty-four times daily anchoring and leaves a much smaller gap.

Blockchain Logging Explained

Audit logs have a structural weakness: they are usually written, stored and administered by the same organisation whose behaviour they record. Blockchain logging is one answer to that, and it is narrower and cheaper than the name suggests.

The problem

An audit log is meant to answer "what happened, and when". It works right up until someone with database access has a reason to change it.

The standard mitigations help and do not close the gap. Write-once storage still has an administrator. Shipping logs to a third party moves the trust rather than removing it. Cryptographic chaining — each entry hashing the previous one — makes tampering detectable within the log, but someone who can rewrite the log can recompute the chain.

What is missing is an anchor: a value published somewhere the log's owner cannot reach.

What blockchain logging actually is

Not, in any sensible design, writing every log line to a blockchain. That would be absurdly expensive and would publish data you almost certainly do not want public.

The practical pattern:

Logs are written normally, with each entry hashing the previous one.
On a schedule — hourly, daily — the current head hash is written to a public blockchain.
That transaction is a commitment: every entry before it is now fixed.

Altering an entry after its anchor is published requires changing every subsequent hash, which no longer matches the value on the chain. The tampering becomes visible to anyone who checks, including people outside the organisation.

The cost is one transaction per period, not per entry.

What it does and does not give you

	Provided
Detect alteration of past entries	Yes, after their anchor
Detect deletion of past entries	Yes
Prevent alteration	No — it makes it detectable
Protect entries since the last anchor	No — that window is unanchored
Prove the entries were true	No — only that they have not changed
Keep log contents private	Yes — only hashes are published
Verifiable by an outsider	Yes

Two limits deserve emphasis. Everything since the last anchor is unprotected, so the anchoring interval is your exposure window. And an anchor says nothing about whether an entry was accurate when written — only that it has not changed since.

When it is worth it

Worth it where the log may need to be believed by someone with a reason to doubt you: regulated record-keeping, evidence preservation, chain-of-custody records, safety-critical systems, multi-party arrangements where each side keeps its own log.

Not worth it for ordinary operational logging. Debugging output does not need tamper evidence, and adding ceremony to it helps nobody.

The test is whether an outsider will ever have to trust the log. If the answer is no, cryptographic chaining alone is plenty.

Doing it without a blockchain team

The mechanism is simple enough that it does not need to be a project. Compute the head hash on your schedule, timestamp that single value, and keep the certificate alongside the log archive. That is one file per period, and it is the same operation as timestamping any other document — the only difference is what you point it at.

The same approach covers related cases: a nightly database export, a build manifest, a signed release, a config snapshot. Anywhere you want to be able to say "this was in exactly this state at this time" and have an outsider check it.

See how to timestamp a software release for the version of this aimed at build artefacts, and chain of custody for digital files for the evidentiary framing.