How Blockchain Works | Digital Fingerprints

Alicia and Tricia receive the astronomy club’s equipment list. Both files are called “equipment-list.pdf”. Both show a telescope and a box of eyepieces. Both seem to have the same first page. Are they the same file?

A filename cannot settle that question. Someone can give two different files the same name. The first page cannot settle it either; a change might sit on page nine or in information the reader does not see.

A hash offers another way to compare. We choose a particular algorithm, apply it to the bytes of each file and compare the results.

Its first job in our fictional story is helping us check whether data matches a reference. That is narrower than deciding whether the list is accurate, whether the sender is honest or whether the telescope exists.

We will use the imaginary club alongside small pieces of text whose hashes can be checked exactly. There are no investments, accounts or private keys to use.

Begin with one useful question: am I looking at the same data that the reference describes?

Contents · Next chapter

A hash function takes input data and computes an output according to a defined procedure. The output is often called a hash value or message digest.

For the algorithms discussed here, the result has a fixed length. A short note and a large document can produce digests of the same length. That does not mean the documents have become identical; their comparison values share an output format.

SHA-256 is one example of a cryptographic hash algorithm. Its digest has 256 bits and is commonly displayed as 64 hexadecimal characters. We will use it for small worked examples, without claiming that every blockchain uses this algorithm for every purpose.

The important ingredients are the algorithm and the exact input. “I hashed it” leaves out information needed to repeat the check.

Think of following a recipe. Two people can reproduce a calculation when they follow the same procedure on the same data.

The digest is not a person’s judgment about the document. It is a calculation result. Keeping those roles separate helps us avoid giving it powers it does not have.

Contents · Previous chapter · Next chapter

A fingerprint is a familiar way to talk about distinguishing things. “Digital fingerprint” borrows that feeling of recognition.

Alicia keeps a reference digest for the equipment list. Tricia calculates a digest for the copy she received. Comparing them helps answer whether the copy matches the reference data.

The analogy works at that level. It should not become a promise that a hash is an absolutely unique name for every possible file.

There are more possible inputs than fixed-length outputs. Different inputs can therefore share a digest. For suitable cryptographic algorithms, finding such a matching pair is intended to be computationally difficult.

Nor is the digest a complete description of the file. Looking at it does not tell Alicia how many telescopes the list contains or whether a lens is damaged.

The useful picture is a compact comparison value that can be calculated again.

When the analogy becomes confusing, return to the procedure: specify the algorithm, identify the exact data, calculate the result and state the limited conclusion supported by the comparison.

Contents · Previous chapter · Next chapter

Alicia writes “cat”. Tricia writes “Cat”. A person understands both as referring to the same animal. The computer receives different bytes.

Under a specified encoding, uppercase and lowercase letters have different representations. Hashing works on those representations, rather than deciding what the writer meant.

Two document exports can look alike while differing in metadata or layout information. Two text files can display the same sentence while using different line endings.

A file hash normally checks the complete sequence of bytes supplied to the algorithm. It does not automatically compare the meaning of the visible paragraphs.

Some systems first transform data into a standard representation and then hash that representation. That is an additional rule that needs to be specified.

For our worked examples, the input is exactly the text stated, encoded as UTF-8, with no added spaces or line breaks unless explicitly included.

Being precise is how we make the result reproducible. A second person should be able to identify the same input instead of guessing what the first person’s tool did.

Contents · Previous chapter · Next chapter

Take the three lowercase letters cat. Encode them as UTF-8 and add nothing before or after them.

The SHA-256 result is 77af778b51abd4a3c51c5ddd97204a9c3ae614ebccb75a606c3b6865aed6744e.

Another person can calculate SHA-256 over those same three bytes and compare the result.

Now use Cat, with an uppercase C. Its result is 48735c4fae42d1501164976afec76730b9e5fe467f680bdd8daff4bb77674045.

We changed one letter’s case. The digest values are very different.

These results were calculated for this article using Python’s standard hashing library. They are complete worked examples, not shortened labels invented to resemble cryptography.

You do not need to memorise either string. The lesson is that an exact data comparison can notice a difference that a reader might treat as a small stylistic change.

If you repeat the calculation, inspect the input. Some tools add a line break when you enter text. The algorithm would then be receiving different data.

Contents · Previous chapter · Next chapter

Alicia copies cat. Tricia copies the same letters followed by a line break. Their screens can look almost identical.

For our example, that line break is a single LF character. The input has four bytes rather than three.

Its SHA-256 digest is 175cc6f362b2f75acd08a373e000144fdb8d14a833d4b70fd743f16a7039103f.

A trailing ordinary space creates another difference. The input cat followed by one space produces 0933316995d43e13027e2516d1c17b659764ffa50d35b89b77b794f8d2dbf651.

Two careful learners can obtain different results without either having used the wrong algorithm. Their inputs may differ.

Inspect the bytes, encoding and boundaries. Guessing which digest looks more convincing cannot settle the issue.

In a shared service, these details need agreed rules. If one organisation hashes a file and another hashes the visible text extracted from it, they are answering different questions.

Make the questions match before comparing their answers.

Contents · Previous chapter · Next chapter

A deterministic calculation gives the same result for the same input under the same algorithm.

This allows Alicia and Tricia to compare independently. They do not need their tools to interpret the equipment list’s meaning; they need the specified calculation applied to the specified data.

If repeated calculations produce different answers, investigate the input, algorithm, configuration and implementation. Something relevant is different or wrong.

The hash does not change because a person feels more confident about the document. Approval does not become an extra ingredient unless it changes the actual input.

Repeatability is useful. A person can retrieve a copy later, calculate again and compare with the reference.

Yet repeatability is not truth. A fictional equipment list gives a reproducible digest. A false sentence can do so too.

For a child, separate “can we repeat the calculation?” from “is the list correct?” The first concerns data and procedure. The second concerns evidence about equipment and custody.

Hashing helps with the first question. It does not remove the second.

Contents · Previous chapter · Next chapter

Alicia’s reference digest differs from the digest Tricia calculates, using the same algorithm. Their input bytes do not match.

That is a useful finding. They should investigate before treating the copy as identical.

The digest does not reveal the whole cause. A deliberate alteration, accidental edit, changed export or transmission error could produce changed bytes.

It does not locate the changed sentence either. The readers may need to compare the documents themselves.

Our equipment list might have changed from “one telescope” to “two telescopes”. Alternatively, its visible list could be unchanged while its export metadata differs.

Both situations involve different bytes. Their practical consequences differ.

A sound check reports the narrow finding first: this file does not match the reference data. The investigation then asks what changed and whether it was authorised, meaningful or harmless for this task.

Avoid jumping from a mismatch to an accusation of fraud. The calculation found a data difference. A claim about someone’s intention needs additional evidence.

Precision makes the result more useful because it leaves the right next question visible.

Contents · Previous chapter · Next chapter

With a suitable cryptographic hash and a reliable procedure, a matching digest can provide strong practical evidence that data matches the referenced input.

“Suitable” matters. A weak function may not provide the resistance an application needs. A tiny classroom checksum can be easy to defeat deliberately.

A matching digest is not a mathematical guarantee that no other input could ever share that result. A fixed-length output cannot provide universal uniqueness.

For an integrity check, the practical question is whether the algorithm and procedure provide adequate confidence against the relevant threats.

This article is not a recipe for selecting production cryptography. Our goal is understanding why the algorithm name and security assumptions cannot be omitted.

Alicia must also ask how she obtained the reference. A strong algorithm cannot repair a reference replaced by an attacker.

The result depends on the combination: appropriate algorithm, exact input handling, trustworthy reference and correct comparison.

That combination gives the hash evidential value. The long string’s appearance does not.

Contents · Previous chapter · Next chapter

Someone alters the equipment list and publishes a digest of the altered version beside it.

Tricia downloads both. Her calculation matches the displayed digest. The altered document passes that comparison.

The reference described the altered data. The check worked as instructed.

Obtaining a file and its digest from one compromised location may therefore leave an important attack unresolved: someone could replace both.

Alicia needs a reason to trust the reference. Perhaps the club signs a release manifest. Perhaps she obtains the digest through an independently authenticated route. The arrangement depends on the service.

For a child, imagine someone changing both an answer sheet and its marking guide. Comparing the sheet with the changed guide will not expose the original alteration.

A reference digest has a source and a history. We need to know who supplied it, which version it describes and why the source is acceptable.

“Does the digest match?” should be followed by “match which trusted reference?”

The second question is often where the practical reliability of the check is decided.

Contents · Previous chapter · Next chapter

Hashing and encryption can both produce outputs unlike ordinary prose. Their jobs differ.

Encryption protects readable information from people without the relevant decryption capability. Hashing computes a digest used in tasks such as integrity checking and commitments.

A digest is not a secret container normally opened with a key to recover the original file. Hashing a file also does not hide that file wherever it is stored.

If Alicia publishes a PDF and its hash, the PDF remains public. The digest does not restrict downloads.

If she removes the PDF but keeps its digest, the digest is not a backup from which she can reconstruct the document.

Give each job its own question. Encryption asks who can read protected content. Hash comparison asks whether supplied data matches a reference. Storage asks where the original data can be retrieved.

A working service may need all three.

Calling one of them “blockchain security” does not eliminate the others. Clear explanations make the relationship visible so that readers understand both the useful check and the remaining responsibilities.

Contents · Previous chapter · Next chapter

Someone hashes the answer to “Which club has TEL-01?” The possible answers are North, Central and South.

Another person can hash each candidate and compare the results with the published digest. There are only three possibilities.

The person need not reverse the function. They can test guesses.

A one-way calculation does not automatically make predictable information private. Short codes, familiar names and a small set of possible answers can create similar problems.

Surrounding information can narrow the possibilities further. A digest that looks mysterious may sit beside a clue that gives most of the answer away.

This is not a password-storage recipe. Password systems and privacy designs need specialised methods. The beginner’s insight is that “hashed” and “secret” are different claims.

In a classroom, publish a toy answer’s digest and provide three candidates. Ask how learners could test them. Then discuss why making more copies of the digest would not stop that method.

Explain the action someone could actually attempt. An impressive phrase about irreversibility is less useful than understanding the practical guessing problem.

Contents · Previous chapter · Next chapter

Let us invent a classroom rule: count the letters in a message. “cat” produces the code 3. So does “dog”.

This toy code notices some changes. Add a letter and the count changes. Replace one three-letter word with another and it misses the difference.

We could make a more elaborate classroom code by adding letter numbers. That might catch more changes, but learners could still find different messages with the same result.

These exercises explain why a compact check can be useful and why its strength matters. They do not reproduce the security of a cryptographic hash.

The important distinction is between noticing ordinary mistakes and resisting deliberate attempts to create misleading matches. A method suitable for the first job may be unsuitable for the second.

When teaching, label the toy honestly. “Our pretend page code” is fine. “This is how SHA-256 calculates” would be false.

A child can understand the problem without doing the internal mathematics. Ask them to defeat the letter-count check, then explain why real cryptographic algorithms are designed against much harder adversarial tests.

The analogy becomes stronger when its limits are visible.

Contents · Previous chapter · Next chapter

A collision occurs when different inputs produce the same hash result.

The letter-count activity gave us one immediately: “cat” and “dog” both produce 3. That toy function is easy to defeat.

A cryptographic function is designed so that finding collisions is difficult under its security assumptions. The difference is difficulty, not a claim that collisions are logically impossible.

Imagine many books assigned a shorter code from a fixed collection of codes. If there are enough possible books, some must share a code. Knowing this does not necessarily give you an efficient way to find the useful pair.

For a beginner, retain two sentences together. Different inputs can share a fixed-length digest. A suitable cryptographic function aims to make finding such pairs computationally infeasible.

Do not replace those sentences with “every file has a unique hash”. That phrase is convenient but hides the distinction.

The same care matters when someone advertises a blockchain as collision-free. Ask which algorithm, which purpose and which threat model they mean.

Security explanations should remain accurate even when simplified. The reader can understand an important limit without being asked to solve the entire mathematical problem.

Contents · Previous chapter · Next chapter

Consider two sentences: “North has the telescope” and “The telescope is at North”.

They can communicate similar information. Their bytes differ, so hashing them is not a way to recognise equivalent meanings.

Now consider one sentence written twice: “North has the telescope”. Its digest can match perfectly even if the telescope is actually at Central.

The hash calculation cannot distinguish truth from falsehood by reading the sentence’s meaning. It has no telescope, witness or inspection report.

This distinction is especially useful when discussing misinformation. A preserved claim can remain false. A cryptographic match can establish consistency with recorded data while leaving factual accuracy unresolved.

A separate evidence process might compare the claim with authorised acknowledgements, photographs, inspections and other sources. That process has its own standards.

Our beginner should be able to complete two sentences: “The digest comparison tells us about …” and “To know where the telescope is, we also need …”

The first answer concerns data. The second concerns evidence about the world.

A useful system may combine both. Calling the combination “verified” should not hide which checks were actually performed.

Contents · Previous chapter · Next chapter

Alicia now wants to know who approved the equipment-list reference. A bare digest does not answer that.

Digital signatures can be used in arrangements that let readers check whether a particular key authorised a particular message. Hashes are often part of how signature schemes process messages, but hashing and signing remain different jobs.

The service must also connect the key with an acceptable authority. A valid signature from an unknown key does not establish that the astronomy club issued the list.

Nor does a club signature prove that every listed item was inspected correctly. It establishes an authorisation claim under the relevant key and system assumptions.

For our fictional example, the club publishes a signed manifest stating the file version, algorithm and digest. A reader checks the signature using the accepted club key, then hashes the supplied file and compares it with the manifest.

This combines two checks: the authority of the reference and the integrity of the supplied data.

The wider journey appears in A Record’s Journey.

Keep the questions distinct: which data matches, which key authorised the reference and why that key represents an authority the reader accepts?

Contents · Previous chapter · Next chapter

Now we can return to blockchain.

A later block can contain a cryptographic reference to its parent. If the referenced earlier data changes, its calculated identifier changes. The later reference no longer matches.

Picture a row of record pages. Each page names the exact previous page it expects. Change the earlier page and the expected relationship breaks.

The real mechanism uses precisely defined data structures and hash calculations. Our pages are an analogy, not a literal description of every chain.

The dependency is useful because a proposed history can be checked for consistency. A reader can detect that one page no longer matches the reference carried by the next.

However, the chain of references is only part of the system. We still need the rules for accepting blocks and deciding which history participants follow.

Without those rules, someone could propose a new sequence of pages and calculate new links for it.

The Ethereum blocks documentation gives a platform-specific example of parent references and block structure.

Learn the general relationship first, then consult the particular system’s specification instead of assuming every chain’s fields and calculations are identical.

Contents · Previous chapter · Next chapter

Tricia asks a sensible question: “If changing a page changes its hash, why can’t someone calculate all the later hashes again?”

They can calculate hashes for altered data. Hashing is a public computation, not a permission system.

The remaining problem is making the altered history acceptable under the network’s rules. A real blockchain can impose conditions on block production, agreement and accepted history that go far beyond computing references.

Those conditions differ across systems. We should not tell a beginner that every chain requires the same mining work, the same votes or the same membership permissions.

A clear explanation separates two parts. Hash links help establish the relationships between data. The protocol determines which candidate history participants accept under its assumptions.

Imagine someone printing a convincing replacement club logbook. Page numbers alone would not authorise it. The club still needs rules about who can produce and approve an official replacement.

That is a limited analogy for authority, not a cryptographic security proof.

The useful conclusion is that the chain’s resistance to rewriting comes from the combined design. It cannot be explained by saying only “the hash changes”.

Contents · Previous chapter · Next chapter

The club records the digest of its equipment list on a shared ledger. Later, Alicia wants to read the list.

The digest cannot supply the document’s missing pages. She still needs access to the original data through an archive, server or other storage arrangement.

Once she has a candidate file, the digest can help her compare it with the recorded reference. Retrieval and checking are separate jobs.

A service can therefore preserve a digest while losing the material it refers to. That is a serious practical limitation if nobody can obtain the document.

Our fictional club keeps versioned documents in managed storage and records enough information to find the intended version. It also plans what happens if a storage operator stops providing service.

A blockchain record may be one part of that arrangement. It does not automatically make every linked file permanently available.

For the learner, imagine keeping a library catalogue entry after the only copy of the book has disappeared. The entry is useful evidence that a particular book was catalogued. It does not become the book.

Ask both questions: what lets us check the file, and what lets us retrieve it?

Contents · Previous chapter · Next chapter

Suppose the club’s document digest appears in an accepted ledger record. What does that tell us about when the document existed?

The answer depends on the commitment’s construction, the network’s timestamp rules and the evidence a reader can verify. The recorded time is not automatically a perfectly accurate account of the outside-world event.

A club member might create a document on Monday and submit a reference on Wednesday. The ledger record does not move the document’s creation to Wednesday or independently establish every event described inside it.

Nor does displaying an old-looking timestamp on a screenshot establish when a reference was accepted. The screenshot itself needs a checking route.

For our beginner, distinguish document creation, submission, inclusion and the timestamp displayed by an application. They are different points in a story.

A stronger claim needs an explicit argument connecting its evidence to those points. A vague phrase such as “blockchain timestamped” leaves too much unsaid.

You do not need to master timestamp engineering to spot the gap. Ask what event the time describes, which system supplied it and what that system guarantees.

The digest checks data relationships. The time claim requires additional context.

Contents · Previous chapter · Next chapter

Earlier, Alicia and Tricia hashed different exports of the same visible list. Their digests differed because their files differed.

Sometimes a system wants to check agreed data fields rather than every byte in a particular file export. It can define a standard representation of those fields before hashing.

For example, our fictional clubs might agree on a specific order for equipment identifiers and a specified encoding. Every participant must follow the same complete rule.

This is often called canonicalisation. It is an additional step, not something a hash function automatically does.

The step must be designed carefully. Removing all spaces may accidentally merge different meanings. Ignoring a field may leave an important change outside the check.

If a standard representation excludes the inspection report, a matching digest cannot establish that the inspection report matches.

Our example is not a production canonicalisation specification. Its lesson is about scope: exactly which data is included, which transformations occur and which differences the resulting check deliberately ignores.

A comparison becomes intelligible when these choices are stated.

Before celebrating a match, ask whether the calculation covered the part of the record on which the decision depends.

Contents · Previous chapter · Next chapter

The equipment list changes as the club purchases another eyepiece. Keeping the old digest does not mean the new list must be forbidden.

The club can publish a new version with a new digest. Readers then need a way to identify which version is relevant to their question.

Alicia reviewing last month’s inventory may need version 1. Tricia preparing this weekend’s session may need version 2.

Both documents can be genuine. They describe different positions in the history.

A useful release record connects the version label, date or event context, algorithm, digest and authority. A file called “latest.pdf” alone is a weak guide when people need to investigate earlier decisions.

The hash assists with exact identification; the version arrangement assists with interpretation.

This also helps explain corrections. An old record can remain available while an authorised later version fixes a mistaken quantity. Readers should be able to see why the newer version supersedes the older one for a particular purpose.

The goal is a readable history, not a pile of unexplained strings.

Ask which version applies before treating a difference between two genuine documents as a contradiction.

Contents · Previous chapter · Next chapter

Start with two invented equipment lists. One says “TEL-01: one telescope”. The other says “TEL-01: two telescopes”. Ask learners to identify the visible difference.

Next, demonstrate the exact SHA-256 examples from this article using a trusted local tool if one is available. Use only the public toy text. No personal information or real keys are needed.

Show lowercase cat, uppercase Cat, a trailing LF and a trailing space. Explain each input before calculating.

Then run a reference-replacement round. Give one learner a changed list and the changed list’s correct digest. Ask why the comparison passes and what additional evidence would establish which reference is authorised.

Finally, give everyone the same false sentence and its matching digest. Ask whether agreement about the bytes proves the sentence true.

The expected answer is no.

If a real hashing tool is unavailable, use the letter-count activity instead, labelled as a toy checksum. Do not present invented short codes as SHA-256.

The activity succeeds when learners can explain the scope of each result, rather than merely copying the digest into a worksheet.

Contents · Previous chapter · Next chapter

A child-friendly explanation can be short: a hash is a calculation that gives data a compact comparison value. We can calculate it again to check a copy against a reference. We still need to trust the reference and check whether the story inside the data is true.

For an adult, add the details that keep the explanation accurate: exact bytes, a specified algorithm, practical collision resistance and a reliable comparison procedure.

In blockchain, cryptographic references help connect records and expose inconsistent alterations. The network’s acceptance rules are also necessary. A chain of hashes alone does not decide which history people should follow.

A hash is useful because its job is precise. It need not understand a document, protect every secret or store a lost file to help with a data-integrity check.

Return to Simplest Explanation for the beginner map. Continue to A Record’s Journey to see the check inside a complete request.

For technical depth, follow Master Blockchain’s structured learning guide.

The question to carry forward is wonderfully practical: what exactly does this match establish, and what remains to be checked?

Contents · Previous chapter · Continue reading