Blockchain gets thrown around a lot. Sometimes it’s the answer. Sometimes it’s massive overkill. Let’s break it down simply — what it actually is, when it makes sense, when it doesn’t, and then show a real example of how we used it to make Moodle certificates tamper-proof.

Table of Contents

• What is Blockchain?
• How a Block Works
• Key Properties
• Blockchain : The Game (simplest explanation)
• When to Use Blockchain
• When NOT to Use Blockchain
• How We Used It : Tamper-Proof Moodle Certificates
• Verify It Yourself
• Ref

What is Blockchain?

A blockchain is a database — but one where records are grouped into blocks, chained together in order, and stored across many computers at once. No single person or company controls it.

Think of it like a shared notebook that thousands of people hold a copy of. When someone writes something new, everyone’s copy updates. And nobody can go back and erase a page — because everyone else’s copy would no longer match.

How a Block Works

Every block on the chain has three things:

• A header — metadata about the block (who created it, when, block number)
• Data — the actual transactions or records stored in this block
• A hash — a unique digital fingerprint of this block’s contents

The hash is the clever part. It’s computed from the block’s data plus the previous block’s hash. So every block is mathematically linked to the one before it — that’s the “chain.”

If someone tries to change data in block #500, its hash changes. That breaks block #501’s hash, which breaks #502, all the way to the current block. Every other node on the network sees the mismatch instantly and rejects it.

Result: past records are effectively permanent.

Key Properties

1 — Transparent

Every transaction and its value are visible to anyone with access to the system. On public chains like Ethereum, that means anyone in the world. You don’t need an account. Just go to etherscan.io and look.

2 — Pseudonymous

Each user has a 30+ character address like 0xf4c8F92715A76e80D0BB84287e53B11909264384. Transactions happen between addresses. Users can stay anonymous or prove their identity — their choice.

3 — Immutable

Once a transaction is recorded, it cannot be altered. The records are linked to every transaction that came before them. Various cryptographic algorithms enforce this — permanent, chronologically ordered, available to all nodes on the network.

4 — Decentralised

No single server. No single company. Thousands of nodes hold a copy. To attack the record you’d have to overpower more than half the network simultaneously — practically impossible on large chains.

Blockchain : The Game (simplest explanation)

Here’s a game that makes it click instantly. Try it at blockchaindemo.io.

1. You see a chain of blocks. Each block has a number, some data, and a hash.
2. Change the data in block #2. Watch its hash change.
3. Watch every block after it turn red — because their hashes were computed using the previous block’s hash. The whole chain is now invalid.
4. To “fix” it you’d have to re-mine every block from #2 onwards — faster than the rest of the network is adding new blocks. On Bitcoin or Ethereum, that’s computationally impossible.

That’s the entire security model, in a browser demo. Spend five minutes there and blockchain will make sense forever.

When to Use Blockchain

Blockchain solves a specific problem: how do you get multiple parties who don’t fully trust each other to agree on a shared record — without a central authority?

Use it when:

• Multiple untrusting parties need the same record — e.g. supply chain, financial settlements, cross-border records
• The record must survive any single party shutting down — e.g. certificates that must be verifiable in 10 years
• Tamper-evidence matters and must be independently provable — not just “we say we didn’t change it”
• The timestamp must be set by a neutral party — e.g. audit trails where backdating must be impossible
• Verification must be available to anyone without login or trust — public credentials, open records

When NOT to Use Blockchain

Honestly — most of the time, you don’t need it. A regular database is faster, cheaper, simpler, and easier to maintain.

Skip blockchain if:

• You only have one party writing to the database — just use a database
• You trust the central authority — a signed database backup is fine
• You need to delete or update records freely — blockchain is append-only by design
• Speed matters — blockchain is slow compared to a normal DB (seconds vs milliseconds)
• You want privacy — public chains are… public. Everything is visible.
• Your “blockchain solution” is just a database with the word blockchain in the pitch deck — this is unfortunately common

Quick test: replace “blockchain” with “shared database.” If it still works and nobody complains — you don’t need blockchain.

How We Used It : Tamper-Proof Moodle Certificates

Here’s our real use case. We built a Moodle plugin called local_blockchainbadge that anchors badge award hashes to the Ethereum Sepolia testnet.

The problem

Moodle issues badges for course completions. But the badge record lives in a database that the institution controls. An employer asking “is this certificate real?” has to trust the institution. If the institution shuts down, the verification portal disappears.

The solution

When Moodle awards a badge, the plugin:

1. Builds a canonical string from the award data — badge ID, award ID, issue timestamp
2. Computes a keccak256 hash of that string
3. Submits the hash to a smart contract on Ethereum Sepolia via a signed transaction
4. Stores the transaction hash in Moodle’s database

The canonical string looks like this:

blockchainbadge:v1|award_id:11|badge_id:4|badge_version:1726000000|issued_at:1726100000

No student name. No email. No PII — just integers. GDPR-friendly by design.

Verification

Anyone can visit:

https://yourmoodle.example.com/local/blockchainbadge/verify.php?awardid=11

No login. The page recomputes the hash from the current Moodle data and calls verifyAward() on the smart contract. If the hash matches and the award hasn’t been revoked — green panel, verified.

If someone edited the Moodle database after the award was made — the hash won’t match. Red panel, tampered.

Independent verification (no Moodle needed)

The real power: the verifier doesn’t have to trust the Moodle page either. They can go to Sepolia Etherscan, find the contract, call verifyAward() themselves, and check the block timestamp — all without any involvement from us.

The chain is the source of truth. Not us.

Why this makes sense here

• Third parties (employers, regulators) need to verify without trusting the issuer ✓
• Records must survive the institution changing systems or shutting down ✓
• Timestamp must be neutral and independent ✓
• No PII needs to be stored ✓
• Cost on testnet: free. On Polygon mainnet: fraction of a cent per certificate ✓

Verify It Yourself

The contract is live on Ethereum Sepolia testnet:

0x2C8d1c015c8Eda160C007037CC208C32bc196576

Go to Sepolia Etherscan, paste the address, click Read Contract, and call verifyAward(11, 0x0e359da19956de5af791f972863fa4bf0abe1bc6493734a0dc67847fb39b68fe).

It returns registered: true, hashMatch: true, revoked: false — directly from the chain, no Moodle involved.

Ref

• local_blockchainbadge on GitHub — full source, smart contract, setup guide
• blockchaindemo.io — best visual explanation of how blocks and hashing work
• sepolia.etherscan.io — Sepolia testnet block explorer
• remix.ethereum.org — deploy Solidity contracts in browser, no setup
• ethers.js v6 docs — the JS library we use for signing
• infura.io — free Ethereum RPC endpoint

Use blockchain when you genuinely need trustless, tamper-evident, multi-party records that must outlive any single system. For everything else — just use a database.