How Blockchain Works | Data Availability and Missing Pieces

A fictional club sends a report cover saying, “All equipment counts have been checked.” The cover includes a digital fingerprint of the report. The pages themselves do not arrive.

A reader can keep the fingerprint as a reference, but cannot inspect the missing entries just by looking at it. The statement on the cover does not supply the work needed to evaluate the report.

This is the beginner’s entrance to data availability. Participants need a way to obtain the data required by their checking tasks. A compact summary and access to the underlying information are different things.

Our club story uses imaginary records and no live system. It will help us separate three questions: what data is identified, what result is claimed, and which participants can actually obtain the pieces needed to check or reconstruct it.

Contents · Next chapter

The Merkle-tree guide introduced a root that summarises a collection through a defined construction. A matching proof can connect a record to that root.

The root does not contain a readable copy of every record. Someone still has to provide the underlying data for tasks that need it.

In the fictional club, a fingerprint on the cover can help compare a report once the report is obtained. It cannot print the missing pages. A link pointing to those pages also fails to help if nobody serves them.

This is a useful distinction whenever an application says its data is anchored on a blockchain. Ask which bytes are on the chain and which bytes are elsewhere. The anchor may remain available while the document disappears. Identifying information and retrieving it are separate responsibilities in the design.

Contents · Previous chapter · Next chapter

Suppose a carefully defined proof establishes that a calculation on some inputs satisfies a rule. Another participant still needs certain data to reconstruct the application’s state or continue using it.

The proof and the data answer different questions. One concerns the validity of a defined result. The other concerns access to the information required for the participant’s task.

Our fictional equipment report might have a trustworthy total while the individual loan entries are unavailable to the next organiser. That organiser cannot simply manage tomorrow’s returns from a total alone.

Do not conclude that the proof is useless. Do not conclude that it solves every access problem either.

A clear explanation says what each component does. Which result is checked? Which data is published? Who needs that data, and for what purpose? Those questions make the missing responsibility visible.

Contents · Previous chapter · Next chapter

A full checker in our fictional club recomputes the equipment state from the initial count and all relevant handovers. To do that, it needs the handover data in the correct order and format.

If one required entry is absent, the checker cannot complete the same independent calculation. A reported final count does not substitute for the missing input.

Different blockchain participants perform different checks. A full node, a light client and an application user may have different data requirements. Avoid assuming that every participant downloads and executes everything in exactly the same way.

Start with the task rather than the role’s name. What does this participant need to establish? Which inputs make that possible? The answer determines why unavailable data matters. Missing a decorative image and missing an execution input are not the same failure.

Contents · Previous chapter · Next chapter

A service sends the club a file called report-final. The file contains pages, but it belongs to the previous week. The download succeeded; the checking task still lacks the required information.

Availability and integrity are related but distinct. Participants need accessible data that corresponds to the intended commitment, block or state. Receiving arbitrary bytes is not sufficient.

Our club compares the obtained report with the correct reference and verifies that its context matches the task. A successful connection to the wrong collection would not help.

When describing a system, include both questions: can the participant obtain the required bytes, and can the participant check that those bytes are the intended ones?

This keeps a common slogan from hiding two jobs. “The data is online” tells us little unless we know what is online, where it belongs and who can access it.

Contents · Previous chapter · Next chapter

The club makes several copies of its report. If one organiser’s device is unavailable, another copy may still serve readers. Replication can improve resilience.

The number of copies alone does not settle the question. Five copies locked in five inaccessible rooms do not help the reader who needs the report now.

A network’s data-sharing design therefore concerns distribution, access and participant behaviour, not merely storage count. Who can serve the data? What happens when a provider leaves? Can the required participants reach another source?

Our paper exercise can represent providers as different folders. Mark which reader can open each folder. This shows why “many copies exist” and “this checking task can obtain the data” are different statements.

The details of a real network’s guarantees depend on its protocol and assumptions. The club analogy introduces the access problem without pretending that every replication scheme solves it equally well.

Contents · Previous chapter · Next chapter

A club report takes a few minutes to arrive because a connection is slow. Another report never arrives because its provider has stopped serving it. Both are inconvenient, but they describe different situations.

A participant observing a timeout should not immediately claim to know its cause. The data may be unavailable from that source, the request may be wrong, or the service may be temporarily delayed.

Record the observation precisely: which data was requested, from which source and at what time? Then distinguish that observation from a conclusion about the whole system.

The same care applies when a blockchain-related website fails to show information. A missing display is not automatically evidence that every network participant lacks the data.

Data availability is a system-level question evaluated through the relevant design. A single unsuccessful request is an observation that needs context, not a complete diagnosis by itself.

Contents · Previous chapter · Next chapter

The fictional club grows into a large association. Asking every member to download every report may become burdensome. Some members want to perform narrower checks while using less bandwidth and storage.

Blockchain designs face analogous tradeoffs. Reducing what each participant downloads can support scalability, but it creates a need for other ways to obtain assurance about the required data.

This is where compact proofs and availability mechanisms become relevant. They should not be confused with a promise that data is unnecessary.

Our association must specify who retains and serves the full reports, what lighter readers check, and which assumptions connect those checks to the larger collection.

The scaling guide asks where work happens. This chapter adds a second question: where does the data go, and how do participants know it was made accessible? Moving work away from a participant does not remove that participant’s need for a trustworthy checking path.

Contents · Previous chapter · Next chapter

Imagine the association divides an appropriately prepared report into pieces. Instead of downloading the whole report, a checker requests randomly selected pieces according to a defined procedure.

Data availability sampling uses this general idea within a specialised construction. The confidence it provides depends on matters such as encoding, sample selection, successful responses and the assumed behaviour of providers.

It is not enough to open three convenient pages chosen by the report’s author. An author who knows the checks in advance could serve those pages while withholding others in our simple story.

The paper analogy explains why random selection matters, but it is not a complete protocol. Real schemes need mathematical analysis and carefully specified networking rules.

The useful beginner question is narrow: how does the sampling procedure provide evidence about the accessibility of the larger dataset, rather than merely the particular pieces it happened to receive?

Contents · Previous chapter · Next chapter

A specialised encoding can add redundant information to data. This is not simply making a second identical photocopy. The encoded pieces have mathematical relationships that can support reconstruction under defined conditions.

Such techniques can also help availability checks: withholding enough information to prevent reconstruction can require hiding a substantial portion of the encoded pieces. Random sampling then has a basis for detecting the problem with specified confidence.

The exact thresholds belong to the construction. Do not copy one scheme’s fraction into every other design.

For a beginner analogy, imagine a puzzle designed so multiple combinations of clues can recover its answer. This only illustrates redundancy. It does not establish a cryptographic guarantee.

Keep encoding and sampling together in the explanation. Sampling arbitrary unprepared data may not provide the same assurance. The useful property comes from the complete scheme, not from the word random alone.

Contents · Previous chapter · Next chapter

Another fictional association appoints several report keepers. They announce that the required data is available and promise to serve it when needed.

A data availability committee is a different kind of design from independent full downloading or a sampling scheme. Its guarantees depend on its membership, rules and assumptions about how many members behave as required.

A committee signature can be evidence that the committee made an attestation. It is not the same act as every reader successfully downloading the complete data.

Ask who belongs to the committee, what they attest to and what happens if they do not serve the data. Those questions make the trust boundary explicit.

Committees can have legitimate roles. The beginner mistake is treating a familiar security word as if it removed the people and operational responsibilities behind the assurance. A truthful explanation names those responsibilities.

Contents · Previous chapter · Next chapter

A fictional processing team computes equipment totals while another service stores the underlying handovers. The checking path now crosses two components.

Layered blockchain systems can likewise separate execution, settlement and data services in different ways. Some publish relevant data to a base chain; others rely on separate availability arrangements. The specific design matters.

Do not infer the data location from the word layer two or from a proof-system label. Ask which data is published where and what a participant can do if one service fails.

The report analogy helps identify the dependency: a result may be checked in one place while the information needed for reconstruction is obtained elsewhere.

Write the locations as separate sentences before evaluating the whole system. That makes it easier to understand which guarantee comes from which component, and where an unresolved assumption enters the route.

Contents · Previous chapter · Next chapter

The association’s report was accessible when its members checked the day’s result. Years later, the designated storage service no longer retains it.

Availability during the relevant checking process and long-term retrievability are different properties. A protocol can provide assurance that data was published without promising that every participant stores it forever.

This distinction matters for readers returning to old records. A root or recorded result may remain while the original data must be obtained from an archive or another retained copy.

Avoid describing every blockchain data mechanism as permanent storage. Retention rules vary by data type and system.

In our fictional design, write an explicit retention plan: what must remain accessible now, what should be preserved later and who is responsible for preserving it? The promise should match that plan rather than borrowing permanence from a general impression of blockchains.

Contents · Previous chapter · Next chapter

The club appoints an archivist to preserve old reports for later reference. This job is different from circulating the latest report for immediate checks.

An archive may help researchers or applications retrieve historical information. Its operation still involves storage, indexing, access and continuity. The fact that a record once passed a network’s checks does not make those archive duties disappear.

In a real system, historical data needs vary by task and node configuration. Do not assume that every participant keeps every old form of data.

Our teaching question is practical: if a reader returns after the routine retention window, where can the required information be found? What evidence links the retrieved copy to the accepted reference?

Preservation and verification work together. The archive supplies information; the checking method helps establish that it is the intended information. Neither role should be silently assigned to the other.

Contents · Previous chapter · Next chapter

The club’s web page still shows a report fingerprint, but the linked file returns an error. The fingerprint remains useful as a comparison reference if someone finds a copy.

It does not repair the broken link or recover the document by itself. This is the same boundary encountered with certificate anchors and token metadata.

When an application displays a file-related record, inspect the file’s location and preservation arrangements separately from the ledger entry. A durable pointer can point to unavailable content.

In our fictional evidence note, write: “The reference is present; the file was not retrieved from this source at this time.” That is more accurate than “the blockchain lost the file,” especially if the file was never stored there.

A good design explanation tells readers which component owns each responsibility. Persistence of a reference is one result; continued service of the referenced content is another.

Contents · Previous chapter · Next chapter

A club may need to protect personal details while allowing authorised checks of its equipment records. It should design the necessary disclosure and access rules deliberately.

Making essential checking inputs unavailable is not automatically a privacy solution. It may simply prevent the intended participants from validating or using the system.

Privacy mechanisms can change which data is required and which readers receive it. Their guarantees need to be explained alongside the checking procedure.

For example, a carefully designed proof may reduce the private information a verifier must see. That does not eliminate every data requirement elsewhere in the application.

Start with the task and the audience. Which information must be accessible for that task? Which information should remain protected from which observers? The two questions are compatible when the design answers them precisely, instead of treating all sharing as good or all secrecy as good.

Contents · Previous chapter · Next chapter

Create an imaginary report with eight numbered pages and a symbolic fingerprint on its cover. Give the full report to one fictional provider and only the cover to a reader.

Ask the reader to perform three tasks: identify the reference, inspect page three and recompute the complete total. Mark which tasks are possible with the information provided.

Next give the reader page three and a conceptual membership path. Discuss how that helps one check without supplying every page. Finally introduce an archive that retains a full copy after the ordinary provider stops serving it.

No real hashing or sampling is performed in this exercise. The labels show responsibilities rather than numerical guarantees.

The point is to separate commitment, targeted evidence, complete data access and later preservation. Once these roles are visible, broad claims about data being on blockchain become much easier to question constructively.

Contents · Previous chapter · Next chapter

A blockchain participant needs the data appropriate to its task. Compact references and proofs can help with checking, but they do not automatically deliver every input needed for reconstruction or continued use.

Availability mechanisms differ. Full downloading, specialised sampling and committee attestations have different procedures and assumptions. Their names are introductions, not complete explanations.

Carry three questions forward: what data is required, who can obtain it and during which period? Add a fourth when returning to historical information: who preserves it later?

The answer should identify the actual locations and responsibilities in the system. A root is not a reversible backup. A successful check at one time is not a universal archive promise.

You can now read data claims with a clearer boundary between an accepted summary and the information that makes a system usable. That boundary matters whenever a design splits work across layers or services.

Contents · Previous chapter · Worked situations