VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

How Blockchain Works | Content Addressing and File Retrieval

Three students in school uniforms work through open books at a classroom table, with textbooks and stationery nearby and study notes on the whiteboard behind them.

Content addressing identifies data using a representation tied to its content, rather than only the location of a server. It can help verify that retrieved data matches an identifier. It does not, by itself, keep a copy online, certify the data’s truth or grant permission to use it.

Part of How Blockchain Works — the beginner series. Read for understanding technology, not for cryptocurrency investment advice.

The classes, libraries, museums, equipment services and numerical examples in this guide are fictional teaching examples. Platform-specific behaviour is identified rather than assumed to apply to every blockchain.

Technical companion: continue into the technical article library.

Chapter index

Separate identity from location · Chapters 1–3
Understand files and content identifiers · Chapters 4–7
Follow retrieval and verification · Chapters 8–11
Plan for persistence and limits · Chapters 12–15
Practise an evidence trail · Chapters 16–18

CHAPTER 1 OF 18 · Separate identity from location

1. A shelf location is not a book’s identity

Back to chapter index

Imagine a fictional museum sharing a digital catalogue. One label says “the file on server A at this path”. Another label identifies a particular content-addressed representation.

The first label tells a reader where to ask. The second helps specify what data should be obtained.

A server can replace the file at a familiar path. That may be intentional, but the path alone does not promise unchanged contents.

Content addressing provides a different anchor for identity. It can let a recipient check retrieved data against an expected identifier under the relevant scheme.

The museum analogy is not perfect: real systems identify blocks and structured representations, not always one simple file digest. That distinction will matter as the guide develops.

Contents · Next chapter

CHAPTER 2 OF 18 · Separate identity from location

2. Location addressing has a useful job

Back to chapter index

A location-based address is not a mistake. It provides a convenient route to a service, and the service can update what it serves.

The museum’s website may intentionally publish the current opening-hours document at a stable URL. Visitors want the newest version, not a permanently fixed copy.

A historical researcher has a different need: the exact catalogue representation used in an earlier exhibit. For that task, an identity tied to the expected content can be useful.

Do not ask which addressing style is universally superior. Ask whether the application needs a changing service location, a specific immutable target or a combination. Different questions deserve different identifiers and evidence.

Contents · Previous chapter · Next chapter

CHAPTER 3 OF 18 · Separate identity from location

3. A hash can help check a candidate

Back to chapter index

A cryptographic hash maps an input to a digest. With an appropriate algorithm and assumptions, comparing a candidate’s computed digest with an expected value can help detect an unexpected substitution.

The expected value must come from somewhere the reader has reason to trust or verify. An untrusted download accompanied by an equally untrusted expected digest does not independently establish that it is the museum’s intended catalogue.

The computation also needs the correct input. Hashing raw file bytes and hashing a structured representation are not automatically the same operation.

The beginner habit is to identify both the candidate data and the source and meaning of the expected identifier. A successful comparison is useful because its target was defined, not because hashes know which museum is legitimate.

Contents · Previous chapter · Next chapter

CHAPTER 4 OF 18 · Understand files and content identifiers

4. A content identifier can describe more than a bare digest

Back to chapter index

IPFS uses content identifiers, commonly called CIDs. A CID includes information needed to interpret its content-addressing structure; it should not be casually reduced to “the file’s ordinary checksum”.

The precise format and version matter. Different textual representations can also need appropriate decoding rather than character-by-character guesswork.

For the museum analogy, a catalogue identifier can include a scheme label as well as a fingerprint. The scheme tells the checker how to understand the rest.

A beginner need not memorise the binary layout. The important lesson is to use software and documentation that understand the identifier, rather than stripping pieces off an unfamiliar string and assuming the remaining characters are interchangeable with any other digest.

Contents · Previous chapter · Next chapter

CHAPTER 5 OF 18 · Understand files and content identifiers

5. One file can become several blocks

Back to chapter index

Large data can be divided into blocks and represented as a linked structure. A root identifier then refers to a structure from which the file can be reconstructed.

The museum’s catalogue may therefore require more than one retrieved block. Obtaining the root alone does not necessarily provide the whole readable document.

Think of a contents page that points to several chapters. The contents page is part of the book’s structure, but it is not all the chapters.

This analogy explains why a content identifier can remain known while reconstruction fails because some required data is missing. Identity, possession of one piece and availability of the complete object are three separate facts.

Contents · Previous chapter · Next chapter

CHAPTER 6 OF 18 · Understand files and content identifiers

6. Representation settings affect identifiers

Back to chapter index

The same raw file can be imported using different structural settings. Those choices can produce different content-addressed representations and therefore different identifiers.

IPFS documentation explicitly explains that identical files can have different CIDs when their structure or import settings differ.

That means “different identifier” does not always imply “different human-readable document”. The comparison must specify whether it concerns raw file bytes, encoded blocks, a directory or a root structure.

For the museum, two packaging methods might reconstruct the same PDF while producing different package identifiers.

Conversely, a similar-looking title does not imply identical bytes. Keep the level of identity clear. A filename, a rendered appearance, a raw file and a structured package are different objects of comparison.

Contents · Previous chapter · Next chapter

CHAPTER 7 OF 18 · Understand files and content identifiers

7. Verification should follow the structure

Back to chapter index

When an object is built from linked blocks, a proper verification process checks the relevant blocks and relationships needed to reconstruct the intended object.

It should not accept a convenient substitute merely because the substitute has the right filename. Nor should it call a partially retrieved object complete.

In the paper analogy, the museum specifies a contents sheet and three numbered chapters. A complete reconstruction needs the required chapters, not merely the cover.

This guide does not implement an IPFS verifier. It teaches the evidence question: which data was checked against which expected identifiers, and was every required piece obtained? The answer should describe the actual reconstruction path rather than rely on a successful-looking download button.

Contents · Previous chapter · Next chapter

CHAPTER 8 OF 18 · Follow retrieval and verification

8. A verified match is not a truth certificate

Back to chapter index

Suppose the catalogue contains an incorrect date for an artefact. A successful content check can establish that the retrieved representation matches the expected one under the scheme.

It does not correct the date or prove the curator’s research.

This distinction is easy to lose when words such as verified appear in an interface. Verified against an identifier has a narrower meaning than verified as factually accurate.

The museum still needs provenance, editorial review and appropriate sources. A permanent reference to a mistaken catalogue is a permanent reference to that mistake.

Content addressing is valuable because it makes a defined comparison possible. Its value does not depend on pretending that identity checks also solve historical truth, authorship or institutional authority.

Contents · Previous chapter · Next chapter

CHAPTER 9 OF 18 · Follow retrieval and verification

9. Knowing an identifier does not supply the data

Back to chapter index

A researcher writes down the catalogue’s identifier and then loses every accessible copy of the underlying data.

The identifier remains useful for recognising a matching copy if one is found. It is not a compressed replacement from which the full catalogue can simply be read.

Retrieval requires somebody to retain and serve the necessary data, and a path through which the requester can obtain it.

The classroom analogy is knowing a book’s catalogue entry after all copies have disappeared. Identification survives; access does not.

When an application says “the file is on IPFS”, ask the operational follow-up: who retains the required blocks, how are they made reachable and what happens if those copies or services disappear?

Contents · Previous chapter · Next chapter

CHAPTER 10 OF 18 · Follow retrieval and verification

10. Pinning is a retention action

Back to chapter index

In IPFS workflows, pinning is used to retain content so it is not removed by the node’s ordinary garbage-collection behaviour under the relevant configuration.

That is an important operational step, not a supernatural permanence guarantee. The node, storage, operator and network access still need to remain available.

A museum can arrange more than one retained copy, but it must verify what each arrangement actually covers. A promise to retain one object may not mean every future revision is automatically retained.

Do not generalise a pinning service’s name into unlimited preservation.

The useful question is concrete: which content is retained by which responsible systems, and what evidence shows that the complete required object can still be retrieved?

Contents · Previous chapter · Next chapter

CHAPTER 11 OF 18 · Follow retrieval and verification

11. A gateway is an access route

Back to chapter index

Many readers access IPFS content through an HTTP gateway. This can make retrieval convenient in an ordinary browser.

The gateway is a service in the access path. Its availability is not the same thing as the availability of every underlying copy, and its displayed response is not automatically independent verification by the reader.

Different gateway modes and client arrangements can support different checking paths. Identify what the actual client verifies rather than assuming the URL alone supplies a guarantee.

In the museum analogy, a librarian can fetch a volume for a visitor. The librarian’s counter is useful, but the visitor still needs to know whether the requested edition was checked and whether the counter’s failure means the book is missing everywhere.

Contents · Previous chapter · Next chapter

CHAPTER 12 OF 18 · Plan for persistence and limits

12. A failed route is not universal disappearance

Back to chapter index

The museum’s preferred gateway stops responding. The website cannot display the catalogue.

That observation establishes a failure along that access path. It does not by itself establish that every retained copy has disappeared.

An alternative authorised retrieval path may help diagnose the distinction, provided it does not bypass an access restriction or permission boundary. A forbidden response should be respected, not treated as an invitation to evade controls.

For a beginner notebook, record the requested identifier, service response and time of observation. Say “this route could not retrieve it” when that is what the evidence shows.

Clear language prevents one endpoint’s outage from being reported as a failure of the entire storage system.

Contents · Previous chapter · Next chapter

CHAPTER 13 OF 18 · Plan for persistence and limits

13. A mutable reference can point to new content

Back to chapter index

A museum may want a stable public reference that directs readers to the latest catalogue. A separate naming or publication layer can update which content identifier it points to.

The content-addressed targets remain specific representations, while the reference selecting the current target can change.

These are different promises. A fixed old identifier should not silently become a different object under the same content-addressing scheme, but a mutable “latest catalogue” pointer can intentionally select a newer identifier.

A historical researcher should record the resolved target and observation context, not only the moving pointer.

The analogy is a noticeboard that says which edition is current. The noticeboard changes; each identified edition still needs its own retained copy and provenance.

Contents · Previous chapter · Next chapter

CHAPTER 14 OF 18 · Plan for persistence and limits

14. Publishing a correction creates another evidence trail

Back to chapter index

The museum discovers an error and publishes a corrected catalogue. Under the relevant content-addressing representation, the corrected object has a new identity.

Readers need a clear explanation of the relationship: which version is superseded, what changed and which version should now be used.

Keeping the older version can be useful for historical transparency. It also means the museum should not claim that publishing a correction erases every earlier copy.

The update workflow therefore has several jobs: prepare the corrected content, retain it, publish its identity and update appropriate references.

Content addressing clarifies what changed. It does not automatically communicate that change to every reader or remove the old material from every place where it was stored.

Contents · Previous chapter · Next chapter

CHAPTER 15 OF 18 · Plan for persistence and limits

15. Integrity is not permission

Back to chapter index

A file can match its identifier perfectly while the reader lacks permission to redistribute it. A public technical route is not a copyright licence.

Likewise, identifying a catalogue does not necessarily establish who authored it or which institution endorses it. Those claims need their own evidence.

This guide is not legal advice. It simply keeps separate questions separate: what data is this; can it be obtained; who published it; and what uses are permitted?

The museum analogy makes the distinction natural. Recognising an exact edition of a photograph collection does not by itself grant commercial reproduction rights.

A responsible application should not label every content-addressed file “free to use” merely because its identity can be checked.

Contents · Previous chapter · Next chapter

CHAPTER 16 OF 18 · Practise an evidence trail

16. Encryption changes what is addressed

Back to chapter index

A service may encrypt data before storing it in a content-addressed system. The resulting identifier can concern the encrypted representation rather than the original readable file.

Retrieving the ciphertext does not supply the decryption key or guarantee access to the plaintext. Re-encrypting equivalent plaintext with different randomness can also produce different ciphertext.

The complete workflow must therefore explain which object is identified and which party holds the capability to read it.

Do not place private keys or recovery secrets in a public paper exercise or storage system. Content addressing does not make published secrets safe.

For beginners, think of a locked box whose exterior is identifiable. Recognising the correct box and opening it are distinct capabilities.

Contents · Previous chapter · Next chapter

CHAPTER 17 OF 18 · Practise an evidence trail

17. Build a paper retrieval checklist

Back to chapter index

Draw a root card for a fictional catalogue that requires three chapter cards. Label each required card with a distinct identifier.

Give one group all three chapters and another group only two. Both groups know the root label. Only the first group can complete the stipulated reconstruction.

Now give the second group a substitute chapter with the same title but a different identifier. It should remain an unverified substitute, not be accepted because its heading looks right.

Finally label two service desks as access routes to the same retained set. This demonstrates that two routes do not necessarily mean two independent stored copies.

The exercise illustrates dependencies and checking. It is not a cryptographic demonstration or a production storage design.

Contents · Previous chapter · Next chapter

CHAPTER 18 OF 18 · Practise an evidence trail

18. The simplest complete explanation

Back to chapter index

Content addressing helps identify and check a defined data representation. It can separate the identity of an object from the location of a particular service that supplies it.

Complete retrieval still needs all required data, retained copies and a working access path. A correct match establishes integrity relative to the expected identifier, not the truth, authorship or permitted uses of the contents.

A useful reading checklist has four questions: what exact representation does the identifier describe; who supplied the expected identifier; can every required part be retrieved and checked; and who is responsible for keeping it available?

Those questions make content-addressed files understandable without turning a powerful identification tool into a promise of permanent, universal or unrestricted access.

Contents · Previous chapter · Worked situations

Worked situations

SituationWhat it meansWhat to check next
A gateway fails to return a fileOne access path has failedRecord the response without claiming all copies are gone
A root is available but one required block is missingThe object may remain unreconstructableCheck completeness of the required block set
The same file produces different CIDsImport or representation settings may differCompare raw bytes and structural settings separately
The file matches its expected identifierAn integrity comparison has passedCheck provenance, factual claims and permissions separately
Fictional examples: identify the boundary before drawing a conclusion.

Check your understanding

  • How does content identity differ from server location?
  • Why is a CID not always a raw-file checksum?
  • What does pinning help with?
  • Why does a verified match not prove factual truth?
  • What should a researcher record when using a mutable latest pointer?

Answer guide: Identity describes the intended representation while location describes an access route. A CID can identify a structured block representation with relevant format information. Pinning supports retention but depends on the retaining system. Integrity is not editorial accuracy. Record the resolved content identifier and observation context, not only the moving pointer.

Continue learning

Technical companion · Structured learning guide · English–Chinese Blockchain hub

References and scope

Sources checked 16 October 2026. Specifications and implementations differ and can change. This is a conceptual beginner guide, not operational, security, legal or investment advice.

Return to chapter index · Begin with the simplest explanation