Field guide 04 · Records and evidence
“On the blockchain” does not mean someone will host it forever
A blockchain can help you check whether data matches a committed record. It does not follow that every node will keep every byte, or that a linked image will remain available. Long-term access needs people or services that retain the underlying data.
A lasting reference needs an available record
01
Keeping, finding and checking are three different jobs
Imagine a receipt stored in a file, with a cryptographic commitment recorded elsewhere. A commitment binds to particular data so that a suitable check can detect a mismatch. It is not a compressed backup from which the original file can be recovered.
Three jobs have to succeed. Someone must retain the bytes. You need a way to find and retrieve them. Then you need enough information to verify what they are. A system can be strong at verification and weak at retrieval.
This helps explain a common frustration: an identifier still exists, but the page or file behind it does not load. The identifier has not necessarily become invalid. The service that supplied the content may have stopped retaining it or stopped serving your request.
Source notes: Ethereum Improvement Proposals · 4844 / IPFS Docs · ipfs
02
Data available for validation is not a permanent archive
Ethereum can carry batches of data for other systems to read and check. Those batches are called blobs. They are especially useful to rollups: systems that process transactions outside Ethereum’s main execution environment while relying on Ethereum for parts of their data and settlement design. Blob data travels separately from ordinary transaction data, and commitments connect it to the chain.
The EIP-4844 design specifies a bounded period during which the separate blob data must be served. That means “the network made this data available” and “I can ask any node for it years later” are different statements. A rollup or archive service may retain copies beyond the required window.
Avoid treating an old retention number in an article as a permanent guarantee. Network rules, client versions and service policies can change. For a real preservation task, record the applicable rule and the archive’s stated coverage on the day you check.
Source notes: Ethereum Improvement Proposals · 4844
03
Old transactions and old account state are different records
History pruning concerns whether a node retains or serves older records such as block bodies and receipts. EIP-4444 discusses bounding execution history and obtaining older data through other distribution paths. The retrieved document is a draft proposal; it does not establish what every live client currently stores.
Historical state is another requirement. An old transaction can tell you that an action was recorded, while a question such as “what was this account’s balance at that block?” needs suitable historical state data or a saved proof for that state. A provider that supplies one kind of history may not supply the other.
When requesting an archive service, describe the actual query you need. “Full history” is too vague to establish whether it includes receipts, historical balances, contract storage, blob data or application files.
Source notes: Ethereum Improvement Proposals · 4444 / Ethereum Improvement Proposals · 1186
04
A content address identifies a file; a pin keeps a copy
IPFS retrieves content using identifiers tied to content rather than relying only on a familiar web location. That is useful for checking that you received the intended object. Someone still needs to make the object available.
Pinning tells an IPFS node to retain content instead of removing it during routine storage cleanup. A remote pinning service performs that storage job for you under its own operating arrangements. Neither a content identifier nor an unpaid, unmonitored promise of pinning establishes perpetual availability.
For material you need to preserve, retain a copy you control and test retrieval from the other copies you depend on. Include associated files: the descriptive file linked to a non-fungible token (NFT) might point to an image stored elsewhere. That descriptive file is called metadata. Preserving only one may leave the other missing.
Source notes: IPFS Docs · ipfs
05
Build a record that another person can understand
A useful preservation packet contains the original data, its identifier or checksum—a fingerprint computed from the data—the relevant network and block references, and a plain-language description of what it establishes. Include retrieval time and source, so a later reader can distinguish a historical observation from a current one.
If the claim relies on a cryptographic proof, keep the proof and the trusted reference it is checked against. A hash by itself establishes much less than a complete verification procedure. If the claim relies on an invoice or an agreement outside the chain, preserve that context too, with access limited to the people who need it.
Then rehearse retrieval on another device. Can you open the file, identify the network and reproduce the check? This is a more useful preservation test than seeing a green availability badge once. Keep sensitive material private; publishing a preservation packet is a separate decision from keeping one.
Source notes: Ethereum Improvement Proposals · 4844 / Ethereum Improvement Proposals · 4444 / Ethereum Improvement Proposals · 1186 / IPFS Docs · ipfs
Worked example · fictional
The artwork survives; the caption does not
A fictional collector saves an artwork file but only bookmarks the token’s metadata page. Two years later the bookmarked service is unavailable. The collector still has the image, but cannot recover the exact description that was displayed when it was acquired.
A fuller packet would have included the image, metadata bytes, relevant content identifiers, token contract and token ID, network, and dated transaction references. Even then, the packet would preserve evidence of the recorded material, not automatically prove copyright ownership.
The lesson is to list each dependent object before choosing storage. A single visible page can depend on several separately hosted files.
| Record | What to retain | What to check |
|---|---|---|
| Blob-backed application data | The data and its verification context | Which archive has the required period? |
| Historical account claim | Block reference and suitable state proof or data | Can the proof be checked against a trusted root? |
| IPFS-linked media | Content and dependent objects | Are independent copies still retrievable? |
| Business meaning | Invoice, agreement or explanatory note | What does the chain record actually establish? |
Use what you learned
What to check
- List the bytes you need, including linked files and supporting records.
- Separate transaction history, historical state and application media.
- Keep copies under your control and record their checksums and provenance.
- Periodically test retrieval and verification, not only account billing.
Why this may matter for years
Cheaper blockchain data, rollups and tokenized records make retention an increasingly useful question. Readers need to distinguish verifiable records from an ongoing storage service.
This is an editorial judgment about lasting usefulness, not measured search demand or a forecast of adoption.
Evidence and scope
These primary sources were retrieved and saved with content hashes. Specifications describe mechanisms; provider documentation describes a particular implementation. Neither is a certification of a product. The examples and checklists apply those mechanisms to fictional situations and practical questions.
Primary-source comparison completed by a separate automated reviewer on 2026-10-02. This is AI-authored content with automated verification; no human or expert approval is claimed.
- EIP-4844: Shard Blob Transactions ↗
Ethereum Improvement Proposals · Parameters; Consensus layer validation; Rationale
Blob data and commitments have distinct roles; the original retention parameter is not a current universal service guarantee.
Retrieval details
2026-10-02T21:37:36.402734+00:00 · HTTP 200
SHA-256 d1c1eb7c505919bb326f493d163b9200b72ed0de2416deae37db6d75cc07baa5
- Pin files ↗
IPFS Docs · Pin files using IPFS; Three kinds of pins; Local versus remote pinning
Content addressing and responsibility for retaining copies; does not promise perpetual hosting.
Retrieval details
2026-10-02T21:37:36.595200+00:00 · HTTP 200
SHA-256 3fd4a0313f1c5af3309da80188b6ea14f3ea178d73f769a35b97d72d06690b76
- EIP-4444: Bound Historical Data in Execution Clients ↗
Ethereum Improvement Proposals · Specification; Rationale; History availability
A proposal about old execution history, not evidence that every client has implemented it.
Retrieval details
2026-10-02T21:37:36.541546+00:00 · HTTP 200
SHA-256 0fa0db4982dbcc447e0bcc49cb6ff80a97b70e5417bb9bc902351431cb4a5c90
- EIP-1186: RPC-Method to get Merkle Proofs - eth_getProof ↗
Ethereum Improvement Proposals · Abstract; eth_getProof; Returns
Account and storage proofs relative to a state root. Proposal status is distinct from method support in a client.
Retrieval details
2026-10-02T21:37:36.700685+00:00 · HTTP 200
SHA-256 bcd9a26e1825e07d795da6b103c5178cc9e560a3b4d8b92214b23a1e4680931e