My progress
Menu

Blockchain and Trust Infrastructure Engineer · Focus area 1: Cryptography fundamentals

BC1: Hashes: fingerprints for data

Goal: understand what a cryptographic hash is and what it promises, use hash chains to make changes to old records visible, prove that one record belongs to a large set with a Merkle tree, hide a value until later with a commitment, and choose and use hash functions correctly.

You'll need: Module 21 (Arrays and Objects), Module 23 (Functions and Scope), Module 77 (Encryption and Secrets), and the SakhiKosh practice kit (README.md, docs/FORMATS.md).

Where this is used: every blockchain links its blocks with hashes; software downloads, Git commits, backup checks, certificate transparency logs and document timestamping services all rely on them.

How it differs: in an ordinary app, a record is trusted because the company's database says so. In a shared record, there's no single company to trust, so the record has to show for itself whether it has been changed. Hashes are the first tool for that.

Time: reading about 2½ hours · practice (the Try it tasks) about 2 hours · assignment about 3 hours.

Lessons

  1. 1What a hash is, and what it promisesReading 15–25 minutes, plus practice✓
  2. 2Hash chains: making changes to old records visibleReading 15–25 minutes, plus practice✓
  3. 3Merkle trees: proving one record is in a big setReading 15–25 minutes, plus practice✓
  4. 4Commitments and salts: hiding a value until laterReading 15–25 minutes, plus practice✓
  5. 5Using hashes wellReading 15–25 minutes, plus practice✓

🛠️Assignment: A tamper-evident record for SakhiKosh

  1. Write a small Node.js script that hashes the group's five opening deposits from data/members.json into a hash chain, and prints the latest hash.
  2. Build a Merkle root of the same five records and an inclusion proof for M03's record.
  3. Write a commit-reveal plan for a members' vote, with salts.
  4. Write half a page on what your hash chain proves and what it doesn't.

Self-check before you finish:

✅Module check

Explain in a few sentences, in your own words:

How do hashes help people trust a record without trusting the person who keeps it?

Show a good answer

A good answer mentions: a fixed-length fingerprint that changes completely with any change and can't be reversed; hash chains that make changes to old entries visible to anyone holding a later hash; Merkle trees for short proofs that one record is included; salted commitments for values that must stay hidden until later; and choosing a standard function, agreeing the exact bytes, and remembering that hashes show integrity, not who made the data.

📚Official references

Official documentation and guidance for this module's topics, chosen on 2 November 2026. Tools, laws and standards change, so check the current version before you rely on a detail. If a link has moved, search the same site.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. A school publishes a results PDF and its SHA-256 digest. A parent's copy gives a different digest. What does that show?

Why each option is right or wrong

  • “The parent's computer calculates hashes differently from the school's computer” (Incorrect): SHA-256 gives the same result everywhere for the same bytes.
  • “The school's digest has expired, since digests are only valid for a few days” (Incorrect): Digests don't expire.
  • “The PDF is encrypted, and the digest can only be checked with a password” (Incorrect): Hashing doesn't need a password.
  • “The parent's file isn't byte-for-byte the same as the one the school published” is correct.

    Any change, even one character, gives a different digest.

    • Then: get the file from the school directly.

📖 Revise: Lesson 1: What a hash is, and what it promises

Question ID sp-blockchain-01-q1 · Report a mistake in this question
2. A team still checks downloads with MD5. What's the main concern?

Why each option is right or wrong

  • “MD5 digests are too long to compare easily by eye on a screen” (Incorrect): MD5 digests are shorter than SHA-256.
  • “MD5 can only hash text files, not programs” (Incorrect): It hashes any bytes.
  • “MD5 hashes take hours to compute for a large file on a normal laptop” (Incorrect): It's fast; that isn't the problem.
  • “Collisions can be made for MD5, so a changed file can share a digest” is correct.

    Use SHA-256 or newer for security checks.

    • Same for: SHA-1.

📖 Revise: Lesson 1: What a hash is, and what it promises

Question ID sp-blockchain-01-q2 · Report a mistake in this question
3. A treasurer keeps a hash chain of entries but is the only person holding the latest hash. What's the weakness?

Why each option is right or wrong

  • “Hash chains can only hold up to 100 entries before they become slow” (Incorrect): There's no such limit.
  • “The latest hash is too short to check the whole history properly” (Incorrect): One hash covers the whole chain.
  • “Entries can't be added any more once the chain has a latest hash” (Incorrect): New entries extend the chain.
  • “They can rewrite every entry and every hash, and nobody can compare” is correct.

    Changes show only to someone holding an earlier copy.

    • Fix: share or publish the latest hash.

📖 Revise: Lesson 2: Hash chains: making changes to old records visible

Question ID sp-blockchain-01-q3 · Report a mistake in this question
4. Why does each block include the hash of the block before it?

Why each option is right or wrong

  • “So blocks can be stored in any order on the disk without getting mixed up” (Incorrect): Storage order isn't the purpose.
  • “So each block's transactions are encrypted with the previous hash as a key” (Incorrect): Hashes link blocks; they don't encrypt them.
  • “So the network knows how many blocks there are in total” (Incorrect): Block numbers do that.
  • “So changing an earlier block changes every later link, and the change shows” is correct.

    The chain of hashes ties each block to all earlier ones.

    • Also: copies held by many nodes make rewriting hard.

📖 Revise: Lesson 2: Hash chains: making changes to old records visible

Question ID sp-blockchain-01-q4 · Report a mistake in this question
5. A scheme publishes one Merkle root for 80,000 approved students. What does a student need to prove they're on the list?

Why each option is right or wrong

  • “The whole list of 80,000 names, so the college can search through it” (Incorrect): That's what the tree avoids.
  • “A password from the scheme that unlocks the root for that student” (Incorrect): Merkle proofs don't use passwords.
  • “Nothing, since a Merkle root lists every student's name inside it” (Incorrect): A root is one hash; it lists nothing.
  • “Their record and about 17 sibling hashes, one per level up to the root” is correct.

    The college hashes up the path and compares with the root.

    • Because: 2 to the power 17 is over 130,000.

📖 Revise: Lesson 3: Merkle trees: proving one record is in a big set

Question ID sp-blockchain-01-q5 · Report a mistake in this question
6. Two offices build Merkle roots from the same 500 records and get different roots. What's the most likely cause?

Why each option is right or wrong

  • “One office's computer has a faster processor than the other's” (Incorrect): Speed doesn't change hashes.
  • “Merkle trees give a random root each time they're built” (Incorrect): They're deterministic.
  • “Merkle roots depend on the time of day at which the tree is built” (Incorrect): Time isn't part of the tree.
  • “They sorted or encoded the records differently” is correct.

    Order and exact bytes must be agreed first.

    • Write down: the sort order and the rule for an odd count.

📖 Revise: Lesson 3: Merkle trees: proving one record is in a big set

Question ID sp-blockchain-01-q6 · Report a mistake in this question
7. An app stores SHA-256 hashes of phone numbers to "anonymise" them. What's the problem?

Why each option is right or wrong

  • “SHA-256 digests are too long to store in an ordinary database column” (Incorrect): They fit easily.
  • “Phone numbers can't be hashed, because they're numbers rather than text” (Incorrect): Any bytes can be hashed.
  • “Hashes of phone numbers can't be compared, so the data becomes useless” (Incorrect): They can be compared.
  • “There are few enough numbers to hash them all and match the records” is correct.

    Hashing doesn't hide small sets of values.

    • Fix: a secret salt, or don't keep the numbers.

📖 Revise: Lesson 4: Commitments and salts: hiding a value until later

Question ID sp-blockchain-01-q7 · Report a mistake in this question
8. In a commit-reveal vote, what does each member publish first?

Why each option is right or wrong

  • “Their vote in plain text, with their name beside it on the shared page” (Incorrect): Others would see it before voting.
  • “Their private key, so others can check the vote later on” (Incorrect): A private key stays with its owner.
  • “A hash of the word "vote", which is the same for everyone in the group” (Incorrect): That says nothing about the choice.
  • “A hash of a random salt plus their vote” is correct.

    Nobody can read it, and it can't be changed later.

    • Then: reveal salt and vote to be counted.

📖 Revise: Lesson 4: Commitments and salts: hiding a value until later

Question ID sp-blockchain-01-q8 · Report a mistake in this question
9. A forger changes a contract PDF and publishes a matching SHA-256 next to it. What would show it's a forgery?

Why each option is right or wrong

  • “Hashing the forged PDF again, since a second hash of a forgery comes out different” (Incorrect): It comes out the same each time.
  • “Checking that the digest is 64 characters long” (Incorrect): Any SHA-256 digest is.
  • “Looking at the file size, since forged files are larger than the originals” (Incorrect): Sizes can match.
  • “Checking a signature from the real author over the original document's hash” is correct.

    A hash shows integrity; a signature shows who.

    • Next: BC2 on signatures.

📖 Revise: Lesson 5: Using hashes well

Question ID sp-blockchain-01-q9 · Report a mistake in this question
10. Two systems hash "0.50" and "0.5" for the same deposit and disagree. What should the team do?

Why each option is right or wrong

  • “Use a different hash function that treats both of them the same way” (Incorrect): No good hash function does that.
  • “Compare only the first eight characters of each digest” (Incorrect): They differ there too.
  • “Stop hashing amounts at all, since amounts can't be hashed reliably” (Incorrect): They can, with an agreed format.
  • “Agree the exact format (for example amounts in wei as whole numbers) before hashing” is correct.

    The same bytes then give the same digest.

    • On Ethereum: ABI-encoded fields.

📖 Revise: Lesson 5: Using hashes well

Question ID sp-blockchain-01-q10 · Report a mistake in this question

ProLearners Assist