Blockchain Really Is Just Git With Extra Steps

A vendor once pitched me a “blockchain-based audit trail” that turned out, once I stripped away the slide deck, to be a hash-linked list of records with a timestamp on each one. Saying so out loud in the meeting went down badly. But I’d spent the previous weekend elbow-deep in Git internals preparing a talk, and the parallel was impossible to unsee afterwards: both systems store history as a chain of objects, each identified by the hash of its own contents plus a pointer to whatever came before it. Tamper with an old entry and every hash after it changes, which is precisely the property both systems sell.

That resemblance is genuinely useful, because it tells you which parts of “blockchain” are novel engineering and which parts you already understand from a tool you probably use daily. Git solved content-addressed, tamper-evident history in 2005 for a comparatively small problem: letting thousands of kernel contributors disagree about the state of a codebase without losing anyone’s work. Bitcoin solved a much harder problem in 2008 — letting mutually distrusting strangers agree on the state of a shared ledger with no central authority — by reusing the same underlying trick. Once you see the shared skeleton, blockchain stops looking mysterious and starts looking like a specific, expensive answer to a specific, narrow question.

The skeleton they share

Ask Git what a commit actually is and strip away the porcelain: a commit object holds a pointer to a tree (the snapshot of your files), pointers to zero or more parent commits, some metadata, and the whole object is identified by the SHA of its own contents. Change one byte in that commit and its hash changes. Because the next commit stores the hash of its parent, that commit’s hash changes too, cascading down every descendant. Editing history three commits back leaves every subsequent hash visibly broken — that’s arithmetic, not a policy Git enforces.

A blockchain block reuses the same idea with the nouns swapped. A block header carries a pointer to the previous block’s hash, a Merkle root summarising the transactions inside it, a timestamp and, on proof-of-work chains, a nonce. Hash the header, and changing a transaction buried inside the block changes the Merkle root, which changes the header hash, which breaks every subsequent block’s “previous hash” pointer. Same arithmetic, same guarantee: the chain lets you detect tampering with certainty, because the hashes stop lining up.

You can build a toy version of this in about fifteen lines, which is a good way to confirm there’s no hidden magic:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

import hashlib, json

def block_hash(index, data, prev_hash):
    payload = json.dumps({"index": index, "data": data, "prev": prev_hash}, sort_keys=True)
    return hashlib.sha256(payload.encode()).hexdigest()

chain = [{"index": 0, "data": "genesis", "prev": "0" * 64}]
chain[0]["hash"] = block_hash(0, "genesis", "0" * 64)

for i, data in enumerate(["alice pays bob 5", "bob pays carol 2"], start=1):
    prev = chain[-1]["hash"]
    chain.append({"index": i, "data": data, "prev": prev, "hash": block_hash(i, data, prev)})

# tamper with block 1 and watch every downstream hash go stale
chain[1]["data"] = "alice pays bob 500"

Run that last line and every stored hash field from block 1 onward stops matching what block_hash() would recompute. That single check, repeated down the chain, is the entire tamper-evidence story for both Git and blockchain. Neither system prevents you from editing old data; both make it immediately, mathematically obvious the moment you have.

Where the resemblance runs out

The part Git never had to solve — because a single maintainer or a small trusted team decides what the next commit looks like — is exactly what blockchain exists for: getting a large number of parties who share no trust to agree on which block comes next, without a referee.

Git answers “who gets to write history” through a repository owner with push access, or in a distributed setup, whoever everyone else agrees to pull from. That’s a social and administrative arrangement, and it works fine because a codebase is rarely an asset that strangers are actively fighting over. Bitcoin’s answer is proof-of-work: miners burn real electricity racing to find a nonce that makes the block hash satisfy a difficulty target, and the chain carrying the most accumulated work becomes canonical. Hashing already supplied tamper-evidence for free — proof-of-work exists to make rewriting history so expensive that no rational attacker bothers, and to give a leaderless network an objective rule for resolving competing versions of events. Proof-of-stake chains swap the electricity burn for staked capital at risk, but the job stays the same: manufacture a real cost for proposing the next block so agreeing on one canonical chain never requires a trusted party.

That consensus mechanism is the expensive bit the sales decks skip past. Hashing is the easy 10% that happens to be the part everyone finds impressive on a slide; consensus among distrusting strangers is a genuinely hard distributed-systems problem. If your actual requirement is detecting whether a record was altered after the fact, and you already have a trusted party — your own organisation, a regulator, a counterparty under contract — you don’t need consensus at all. A hash chain and a signature cover most of that, which is most of what Git already gives you, plus a way to publish the latest hash somewhere append-only and outside your own control so you can later prove you didn’t rewrite the log.

Signed commits close the identity gap

A vanilla Git commit’s hash proves the content hasn’t changed since it was hashed, but says nothing about who made it — anyone with write access can create a commit claiming any author identity. Git closes that gap with GPG or SSH-signed commits, worth setting up wherever authorship genuinely matters — a firmware repo, a compliance-relevant configuration repo, anywhere “who approved this” is a real question rather than a formality:

1
2
3
4

git config --global user.signingkey <your-key-id>
git config --global commit.gpgsign true
git commit -S -m "sign every commit from here on"
git log --show-signature -1

Blockchain transactions carry public-key signatures by design from block zero: every transaction proves who authorised it. That’s a real structural difference from stock Git, where signing is available but optional and most repositories skip it entirely.

Forks and reorgs: the branch you already understand

Git and blockchain even share their messiest failure mode. In Git, two people commit on top of the same parent and you get a fork — two valid histories tracing back to a common ancestor, resolved later by a merge or by agreeing which branch is main. Both histories sit safely in the object store until someone tidies up.

A blockchain fork looks structurally identical and carries very different consequences. Two miners solve a valid block at nearly the same height, the network briefly disagrees about which one is next, and for a few minutes two competing chains hang off the same parent block. The protocol’s tie-breaking rule — longest accumulated proof-of-work, in Bitcoin’s case — eventually picks a winner, and every transaction that only existed in the losing branch is orphaned: it disappears from the canonical ledger, and if it spent money, that money needs re-confirming in the winning chain. Exchanges wait for several confirmations before crediting a deposit for exactly this reason — the most recent block hasn’t yet been buried under enough subsequent work to make a reorg (a chain “reorganisation,” where the network swaps its view of the canonical tip) astronomically unlikely.

Git carries none of that anxiety, because it never needed a rule for which branch is objectively correct — it just holds every commit and lets a human decide. That works well when the stakes are a codebase and a bug fix. It would be a disaster if the stakes were a ledger of who owns what, which is exactly why blockchain had to invent a rule Git never needed.

The Merkle tree is doing more work than the toy example shows

A real block doesn’t hash its transactions as one flat blob — it builds a Merkle tree, pairing transaction hashes, hashing those pairs together, and repeating all the way up to a single root stored in the block header. Git does the same thing one level down: a tree object hashes the names and hashes of the blobs and sub-trees it contains, and a commit hashes the tree plus its parents. Both structures exist for the same reason: proving a single item belongs to a set without re-hashing the whole set.

That property — a Merkle proof — is why a lightweight Bitcoin client can verify a transaction is included in a block without downloading every transaction ever made: it only needs the sibling hashes on the path from its transaction up to the root, a handful of hashes instead of gigabytes of history. Git leans on the same trick when a shallow clone verifies the tip commit’s tree without materialising the full object graph. Merkle trees predate both systems by decades, but each leaned on the same idea for the same reason: proving membership cheaply matters more as the dataset grows.

Where teams actually reach for the hash-chain half without the coin

The pattern shows up constantly outside anything you’d call a cryptocurrency. Certificate Transparency logs — the mechanism browsers use to catch mis-issued TLS certificates — are append-only Merkle trees maintained by a small set of trusted operators, with no mining and no token anywhere in sight; the whole point is a publicly auditable, tamper-evident record, and a hash chain plus a published root delivers that without a consensus protocol. Package registries increasingly do the same thing for supply-chain integrity: Sigstore’s transparency log records every signed artefact in a Merkle tree so anyone can verify a package wasn’t quietly swapped after the fact, and again there’s no blockchain underneath it, just the same hashing discipline Git and Bitcoin both rely on. If you’ve set up container image signing with Sigstore and cosign you’ve already used the tamper-evidence half of blockchain’s toolkit without touching a single smart contract.

This is worth dwelling on because it’s the detail most “enterprise blockchain” proposals quietly omit: you can have an auditable, cryptographically verifiable, publicly checkable history without ever needing a network of mutually distrusting validators. The validators only earn their keep when nobody — including you — is allowed to be the sole authority over what counts as canonical. Most organisational audit trails have an obvious canonical authority already: the organisation itself, its auditor, or a regulator with subpoena power. Paying for Byzantine fault tolerance to protect a record that one party is already legally accountable for is solving a problem you don’t have.

Troubleshooting: does this project actually need a blockchain?

Working through evaluation requests over the years, the honest checklist looks like this:

• “We need an immutable audit log.” A hash-chained table in your existing database, with the latest hash republished somewhere outside your own control, gives you tamper-evidence without mining, staking or a token. This covers the majority of “blockchain for compliance” pitches I’ve sat through.
• “Multiple organisations need to agree on shared state, and none trusts the others to run the database.” This is the genuine blockchain use case, and it’s narrower than most vendors imply — real inter-company settlement problems, rarely a single company’s internal record-keeping.
• “We need it fast.” Public chains are slow and expensive by design; the friction is the security model. Throughput requirements point somewhere else entirely.
• “Our team already lives in Git.” Signed commits plus a public timestamp of your HEAD hash form a smaller, cheaper, better-understood system than standing up a private chain nobody on the team has operated before.

Is it worth reaching for

Understanding blockchain through Git doesn’t make blockchain useless — proof-of-work and proof-of-stake consensus are real engineering, solving a real problem Git was never built for: agreement among parties with no shared trust anchor. Most of the systems pitched to me as “blockchain” over the years never had that problem. They had a much smaller one — proving a record wasn’t altered after the fact — that a hash chain, a couple of signatures and a public timestamp solve for a fraction of the operational cost. Understand how Git internals work under the hood when you type git commit, or what it takes to self-host your own Git forge instead of trusting someone else’s, and you already understand the load-bearing half of blockchain. The other half — leaderless consensus among strangers who’d cheerfully double-spend given the chance — is the genuinely hard, genuinely novel part, worth paying for only when you actually have that problem.