中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC049
A commitment can identify data without storing the data. A protocol can establish that data was available when a block was accepted without requiring every node to retain it forever. A later reader can therefore fail to retrieve old bytes without proving that the earlier availability check was false.
These distinctions matter whenever someone says that information is “onchain”, “available” or “permanent”. The statement needs an object, a time, a retrieval path and the particular guarantee being claimed.
This lesson follows one fictional data package through publication, a retention window and archival retrieval. A small sampling calculation then shows why checking a few authenticated pieces can provide limited evidence without becoming a permanent storage promise.
Choose your reading route
In this guide
- 1. Four questions hidden inside “available”
- 2. A commitment is a binding reference
- 3. Availability does not validate an application’s computation
- 4. The fictional publication at height 100
- 5. The inclusive boundary at 200
- 6. A later archive failure changes the present claim
- 7. Real documentation separates availability from historical retrieval
- 8. Why sampling enters the picture
- 9. The eight-share classroom model
- 10. Interpret the probability without inflating it
- 11. Repeated samples do not create new reconstruction pieces
- 12. Archival planning is an application responsibility
- 13. Two different meanings of a data availability statement
- 14. Exercise: classify six evidence cards
- 15. Frequently asked questions
- Sources and next reading
Start with the four separate questions: identity, publication, retrieval and retention. Follow package D through heights 100, 200, 201 and 300. Then work through the eight-share sampling model and classify the evidence cards.
The heights, retention policy, data shares and probability model are invented for teaching. They are not Ethereum or Celestia configuration values. No node settings are changed and no data is uploaded, deleted or purchased.
Primary sources were checked on 12 October 2026. Where a named proposal or implementation document discusses retention, we use its bounded-storage concept rather than treating an old parameter as a universal current rule.
Back to contents · Next section
1. Four questions hidden inside “available”
First, identity: which exact data object does a commitment or identifier refer to? Second, publication: what evidence shows the required data was made available under the protocol’s acceptance conditions? Third, retrieval: can this reader obtain it now? Fourth, retention: who is responsible for preserving and serving it over the intended period?
A positive answer to one question does not automatically answer the others. An authentic identifier may point to missing bytes. A successful download today may say little about the publisher’s original protocol compliance. A historical availability result may not include a promise of future service.
Write a time and a subject beside every claim. “Node A served package D at height150” is narrower and more testable than “the network stores everything”. It also tells an investigator where the evidence stops.
Our worksheet treats a retrieval failure as an observation to diagnose. It is not automatically evidence of censorship, malicious withholding, historical unavailability or universal loss.
Back to contents · Next section
2. A commitment is a binding reference
The fictional package D has commitment cD. The worksheet supplies a correct commitment scheme and an authenticated reference to cD in the relevant chain history. A reader who obtains candidate bytes can check whether they match that reference.
This helps detect substitution. If a provider returns Dwrong and its commitment differs from cD, those bytes are not the package named by the reference. The check is useful even when the provider is not trusted to choose the correct file.
But cD is not a backup of D. If no source supplies the bytes or enough properly encoded information to reconstruct them, the commitment alone does not restore the package.
EIP-4844, a Final proposal created on 25 February 2022, provides a concrete architectural example of blob data being separate from the commitment information available to execution. This lesson uses that separation, not its original throughput or fee parameters.
Back to contents · Next section
3. Availability does not validate an application’s computation
Suppose D contains an application batch. Obtaining the complete authenticated bytes establishes access to that object. Whether the batch obeys the application’s rules is a different check involving its inputs, authorisations and execution semantics.
A data-availability service can make a malformed or application-invalid message retrievable. The availability question is whether the relevant bytes are accessible under the specified model, not whether every application will accept their meaning.
Conversely, a valid computation proof does not necessarily deliver the data required by a reader. The previous lesson separated proof acceptance from reconstruction; here we ask which publication and storage responsibilities keep the reconstruction inputs accessible over time.
Settlement finality is also distinct. A commitment can be recorded in a finalised history while an archive containing its bytes later becomes unavailable. Finality preserves the relevant historical decision under its assumptions; it does not operate a storage server by itself.
Back to contents · Next section
4. The fictional publication at height 100
At height 100, a protocol records cD and accepts the relevant data publication under its specified rules. The exercise supplies authentic evidence that the required complete D was retrievable at that time. Node A obtains and verifies it.
The protocol’s fictional retention rule requires this participating node to retain and serve the relevant data through height 200 inclusive, assuming normal connectivity and correct operation. After 200, the rule permits pruning. It does not require pruning and does not promise that all other holders delete their copies.
Archive B separately obtains the complete package at 150, checks it against cD and records the necessary format and identity metadata. B plans to serve it beyond the protocol window. That is a separate archival arrangement, not an extension automatically created by the original commitment.
These assumptions give us a clear starting point. We are not inferring historical availability merely from the presence of cD; the publication evidence and successful verified retrieval are supplied independently.
Back to contents · Next section
5. The inclusive boundary at 200
At height 200, the fictional retention obligation still applies to A. If A is functioning and connected as assumed, it should still serve the required package under this policy. A claim that “the window ended at 200, so200 is outside it” misreads the inclusive boundary.
At 201, A prunes D in accordance with the supplied rule. A later query to A returns no data. That observation is consistent with allowed pruning; it does not, by itself, contradict publication at 100.
B still retains D at 201 and returns matching bytes. The reader verifies cD and can use the package. Retrieval has moved to a different holder, while the authenticated identity of the package remains the same.
Do not generalise the toy boundary to a live network. A real rule might use epochs, timestamps, slots or a rolling recency window, with implementation-specific serving behaviour. The exact unit and inclusion convention must be checked.
Back to contents · Next section
6. A later archive failure changes the present claim
At height 300, B is unavailable. The reader knows no other accessible source, and A no longer retains D. The correct conclusion is that the reader cannot retrieve D through the available paths at 300.
That is a serious operational problem for a reader who needs the package. It still does not prove that D was unavailable at 100, or that no copy exists anywhere. Those stronger claims would require different evidence.
If B later returns and supplies matching bytes, retrieval can recover without changing cD or rewriting the historical publication event. If all copies really are lost, the remaining commitment does not recreate them.
This distinction keeps incident reports useful. Record the missing object, attempted sources, time and required downstream task. A statement such as “reconstruction blocked by an archive outage” points to the actual dependency more clearly than “the blockchain failed”.
Back to contents · Next section
7. Real documentation separates availability from historical retrieval
The Celestia retrievability and pruning documentation explicitly distinguishes publication assurances from permanent historical storage. It describes archival holders and the responsibility of applications or rollups to preserve historical data they will need.
The page is marked updated 9 October 2026 and includes a version-specific sampling-window description. We do not turn that number into a universal rule for every node or network. The relevant lesson is the division of responsibility.
EIP-4844 similarly describes a bounded period for blob serving rather than requiring blobs to be retained as long as all execution history. A reader assessing a current deployment must inspect the applicable fork, specification and client configuration instead of assuming the original proposal’s parameters remain the whole story.
“Stored on a blockchain” is therefore too broad a retention statement. Identify the actual data type, protocol requirement, node role and archival provision before promising future access.
Back to contents · Next section
8. Why sampling enters the picture
Downloading all required data is one way a participant can establish direct possession. A lighter participant may use a protocol that samples authenticated pieces of correctly encoded data and obtains a probabilistic availability assurance under particular assumptions.
The Celestia data-availability explanation describes sampling with authenticated shares and an erasure-coding scheme. It also discusses why correct encoding and the network model matter. Our numerical example below is deliberately simpler and uses a different sampling rule.
A sample’s authentication can show that its bytes belong at a specified position under the accepted commitment. It does not mean that every other position was retrieved, that the whole application executed correctly or that the responding node will serve the bytes next year.
Keep three results separate: this piece is authentic; these observations support a probabilistic availability inference under a model; and enough distinct correct pieces have actually been collected to reconstruct the data.
Back to contents · Next section
9. The eight-share classroom model
Assume D has been correctly encoded into eight indexed shares, numbered 1 through 8. The supplied coding scheme permits reconstruction from any four distinct correct shares, while fewer than four are insufficient for guaranteed reconstruction of arbitrary D.
Five fixed positions are withheld from everyone in this toy experiment, leaving only three available positions. The withheld set does not adapt to queries. A query chooses one of the eight indices uniformly and independently, with replacement, and succeeds only when that share is available and authentic.
Because only three distinct shares are available, the reconstruction threshold cannot be reached from this available set. We ask a different question: what is the probability that three sample queries all succeed despite those five fixed missing positions?
Each query succeeds with probability 3/8. Independence with replacement gives (3/8)×(3/8)×(3/8)=27/512, approximately 5.27%. At least one query detects a missing response with probability 485/512, approximately 94.73%, under exactly these assumptions.
Back to contents · Next section
10. Interpret the probability without inflating it
The 27/512 result is a conditional sampling calculation: given this fixed withholding pattern and this query model, three queries can all hit the available set. It is not the probability that a real network is insecure, nor the probability that an observed success means the data is missing.
Those are different statistical questions. Turning the conditional result around would require additional assumptions about how often withholding occurs and what other explanations exist for responses or failures.
Sampling without replacement would give a different calculation. So would adaptive selective serving, correlated queries, an isolated client, different coding guarantees or a different number of missing positions. Our toy model intentionally excludes those conditions.
Celestia’s cited description samples unique coordinates; it is not the with-replacement process used here. The exercise teaches how assumptions control a number, not how to compute a deployed protocol’s security level from a small made-up example.
Back to contents · Next section
11. Repeated samples do not create new reconstruction pieces
Suppose a reader receives authenticated responses for indices 1, 2, 1. It has made three successful queries but possesses only two distinct shares. Under our coding assumption, it cannot yet reconstruct arbitrary D.
Receiving indices 1, 2, 3 still gives only three distinct pieces, below the required four. In a separate all-data-available case, obtaining 1, 2, 3, 4 supplies four distinct correct shares and meets the toy reconstruction threshold.
This is why counting successful requests is not the same as counting usable reconstruction information. The index, commitment binding and correctness of each piece belong in the evidence record.
Even successful reconstruction today says nothing automatic about tomorrow’s retention. Someone still needs to keep the reconstructed package or sufficient valid encoded pieces and make them retrievable when needed.
Back to contents · Next section
12. Archival planning is an application responsibility
An application that expects a new reader to recover old state needs a plan for the historical inputs or an appropriately authenticated alternative starting point. A snapshot may reduce the historical data required for a particular task, but it introduces its own identity, completeness and trust questions.
For D, an archival record should identify cD, the relevant chain and block, the format and decoding requirements, the intended retention period and the parties responsible for serving or handing over the data. A successful restore test supplies evidence beyond a statement that a backup job ran.
Multiple providers are not automatically independent. They may share an operator, storage backend or retrieval endpoint. The worksheet does not assign failure probabilities without that information.
No purchase or node configuration is needed for this learning exercise. The useful output is a responsibility map: which future task needs which object, who holds it, how the reader authenticates it and what happens when that route fails.
Back to contents · Next section
13. Two different meanings of a data availability statement
In research publishing, a data availability statement explains where supporting research data can be accessed and under what conditions. In blockchain protocols, data availability refers to a technical publication and verification problem under a particular network model.
The existing eduKate guide to writing a data availability statement addresses the research-writing task. Its repository, version and access-route questions are useful for documentation, but they are not a substitute for a blockchain protocol’s availability mechanism.
The distinction prevents a terminology collision. A well-written repository statement does not establish that a block satisfied a sampling protocol. Conversely, protocol availability does not settle research consent, redistribution rights or a repository’s long-term access arrangements.
For this lesson, the new job is technical evidence over time: what was committed, what was retrievable at validation, what a sample establishes, and who preserves the data afterwards.
Back to contents · Next section
14. Exercise: classify six evidence cards
Use the fictional heights and eight-share model already stated.
- At 201, A no longer serves D, but B supplies bytes matching cD. Has present retrieval failed for this reader?
- At300, B is offline and no other accessible source is known. Does that prove D was unavailable at 100?
- A provider returns Dwrong whose commitment differs from cD. What should the reader reject?
- Three with-replacement queries all succeed despite five fixed withheld positions. What was the probability of that event under the model?
- The successful indices are1,2,1. How many distinct pieces does the reader have, and can it reconstruct arbitrary D?
- A complete authenticated D is retrieved, but its application operation violates an authorisation rule. Does data availability make that operation valid?
Answers and reasoning
- No. Retrieval from A fails, but the reader can retrieve matching D from B. Identify the working source rather than equating one endpoint with the whole retrieval arrangement.
2. No. It establishes the current reader’s retrieval gap at 300, not historical unavailability at 100 or universal destruction of every copy.
3. Reject Dwrong as the object named by cD. A returned file is not sufficient without the identity check. The historical commitment remains a reference to the correct object.
4. 27/512, approximately 5.27%. This is the probability of three successes conditional on the specified fixed withholding and independent uniform with-replacement queries, not a production attack probability.
5. Two distinct pieces. That is below the four-distinct-share threshold. Repeated index 1 does not provide another independent reconstruction piece.
6. No. Availability supplies the data needed to inspect the operation; the application’s validity rules remain separate.
Back to contents · Next section
15. Frequently asked questions
Does a finalised commitment guarantee permanent downloads?
No. Finality and retention are different properties. Determine who stores and serves the bytes, for how long and under which assumptions.
Does one missing sample prove malicious withholding?
Not by itself. The observation is a failed retrieval under the sampling procedure. Network faults, an unavailable provider or other conditions may explain it; the protocol determines how such failure affects its decision.
Is more sampling the same as an archive?
No. Sampling supports a particular availability assessment. Long-term retention and later serving require a separate arrangement, even if samples were successful when the data was new.
Can an archive supply correct data without being trusted to invent the contents?
An authenticated commitment can help the reader verify the returned bytes. The reader still depends on someone actually providing those bytes and on the correctness of the commitment reference and decoding rules.
Back to contents · Next section
Sources and next reading
Primary sources checked on 12 October 2026, Singapore time:
- EIP-4844: Shard Blob Transactions, Final, created 25 February 2022: separation of blob data and execution-visible commitment information, plus bounded-retention design. Original parameter values are not presented as universal current deployment rules.
- Celestia data availability: authenticated sampling and coding concepts. The eight-share with-replacement exercise is explicitly different from its described unique-coordinate sampling.
- Celestia data retrievability and pruning, last updated 9 October 2026: publication versus historical storage and archival responsibility. No provider recommendation is made.
For the different research-writing meaning, see the linked eduKate data availability statement guide. For the blockchain sequence, the next lesson follows signed offchain channel states and the evidence needed when a channel closes or a dispute arises.