A rollup can process transactions away from Ethereum’s main network and bundle them together before publishing an update. But there is a catch: what happens if other participants cannot access the information needed to check that update?
A record stating that a batch has been accepted is not enough on its own. Users and independent operators may still need the underlying transaction data to reconstruct balances, verify state changes or challenge an incorrect result.
This is the problem that blockchain data availability addresses. It concerns whether the information required to verify a block has been published and can be retrieved when needed.
The distinction matters because processing more transactions is only part of the scaling problem. Networks also need ways to make the relevant data available without requiring every participant to download and process everything. Different approaches to that task can increase capacity and reduce costs, but they do not all provide the same security guarantees.
Why does a rollup need more than a transaction summary?
Rollups are networks that execute transactions outside a main blockchain, then submit batches of information to another layer for settlement and security. By combining many operations into fewer submissions, they spread certain costs across a larger number of transactions.
However, the main network still needs enough information for independent participants to check what the rollup has done.
Imagine a rollup reporting that several account balances have changed. A cryptographic commitment can identify a particular dataset, making it possible to check whether the data later supplied matches what was committed to. But the commitment does not reveal the dataset itself.
Without access to the relevant transaction data, independent participants may be unable to reproduce the state changes or establish whether the proposed result is legitimate.
This is particularly important for optimistic rollups. These systems generally allow a period during which participants can challenge a proposed state transition. If an operator submits an incorrect update, producing a fraud proof may depend on being able to inspect the underlying transaction data.
Zero-knowledge rollups approach verification differently. They use cryptographic proofs to demonstrate that a computation satisfies specified rules. Yet a proof of correct execution does not, by itself, give users all the data they need to reconstruct the rollup’s state or continue interacting with it.
Both approaches therefore have to address data availability, even though their methods for verifying state transitions differ.
Availability and validity answer separate questions: can participants obtain the relevant information, and does the resulting state follow the network’s rules? A blockchain needs adequate answers to both.
What changes when data is separated from execution?
On a conventional blockchain, participants compete for limited block space. Transactions, smart-contract operations and the information associated with them consume resources. When demand exceeds the available capacity, fees can rise.
Rollups reduce some of this pressure by executing transactions elsewhere and publishing them in batches. Yet the data submitted to the main network still consumes resources and contributes to the cost of running the rollup.
This is where a separate data availability layer can change the architecture.
Instead of requiring one blockchain to handle execution, settlement and data publication in the same way, a modular system separates these responsibilities. One layer processes transactions, another may establish their settlement, and a dedicated data availability network provides the information needed for verification.
The result can be more room for applications to grow without making the main network carry every part of the workload. A specialised layer may also offer additional data capacity at a lower price than publishing the same information through a more expensive mechanism.
But cheaper data does not automatically translate into cheaper transactions for users. A rollup’s total costs can include execution, settlement, data publication and other infrastructure. Its fees also depend on demand, available capacity and how those costs are distributed.
Moving data away from the main execution layer can therefore improve scalability, but it changes the system’s dependencies as well. If the application relies on a separate network to make its data available, that network’s guarantees become part of the overall design.
Ethereum, Celestia and EigenDA take different routes
Not every data availability solution works in the same way. Ethereum provides a mechanism within its own ecosystem, while Celestia and EigenDA offer alternative approaches to publishing and verifying data.
Ethereum blobs
Ethereum introduced blobs through EIP-4844, creating a separate fee market for a type of data payload designed to support rollups.
Blobs allow rollups to publish transaction data without placing it all in Ethereum’s traditional execution data. This can reduce publication costs when blob space is cheaper than the alternatives.
The trade-off is that blobs are temporary data, rather than a permanent storage mechanism. Ethereum’s protocol-level availability guarantee for blobs lasts roughly 18 days under the current rules. Historical preservation requires other participants or services to retain copies.
Celestia and data availability sampling
Celestia was designed specifically to provide data availability for other blockchain applications.
Its approach includes data availability sampling (DAS). Rather than requiring every light node to download an entire block, the system allows nodes to request randomly selected portions of the data and verify the responses.
This works alongside erasure coding, a technique that adds redundant information so missing portions can be reconstructed if necessary. Successful sampling gives a node strong probabilistic confidence that the full dataset has been published and is available.
The practical advantage is that lightweight participants can check availability without bearing the cost of downloading every byte of every block. Execution and settlement can take place on other layers.
EigenDA and its operator network
EigenDA is a data availability service built on EigenLayer. It distributes data across operators, which provide attestations supporting the claim that the information is available.
Rather than relying on exactly the same mechanism as Ethereum’s blob system or Celestia’s sampling approach, EigenDA uses a security model based on operator participation, stake and quorum requirements.
These distinctions matter. A solution’s performance and price are only part of the decision; its integration requirements and the assumptions underpinning its availability guarantees also affect the security of the applications that depend on it.
The three approaches address a similar problem, but they are not interchangeable simply because they aim to make data available more efficiently.
Cheaper data is not the same as permanent storage
There is another distinction worth understanding: data availability is not the same as long-term data storage.
Availability concerns whether the information associated with a block has been published and can be obtained for verification. Historical retrievability concerns whether that information can still be accessed long after the original availability window has passed.
Ethereum’s blobs illustrate the difference. Once the protocol-level retention period expires, the data is not guaranteed to remain available indefinitely through Ethereum itself.
Archive nodes and other services may preserve copies, but that is a separate responsibility.
This does not necessarily mean the blockchain’s current state stops functioning. A network can continue processing transactions while older data is held by a smaller group of historical data providers.
The distinction becomes important when users need to reconstruct an application from earlier records, investigate an old transaction or recover information independently. Block explorers and indexers can help, but their ability to display historical records is not the same as a protocol-level guarantee that the original data remains available.
The same question applies to specialised data availability networks: what data do they retain, under which conditions can it be retrieved, and what happens when a participant requests information that is no longer within the normal availability window?
These are separate design questions, not minor details.
Scaling still depends on who can verify the network
Blockchain data availability helps networks scale by making it possible to publish transaction data more efficiently, reducing the burden on the main execution layer and allowing specialised infrastructure to take on part of the workload.
But the relevant measure of success is not simply how much data a network can publish or how cheaply it can do so. The design must also allow the participants who need to verify the system to obtain the information required for that task.
When evaluating a data availability approach, it is worth asking what information is published, how availability is checked, which parties are responsible for providing the data and how long the guarantees last.
The answers reveal more about the system’s practical security than a headline throughput figure or a low publication fee alone.
The central trade-off is straightforward: a blockchain can become more efficient without making every participant process everything, but it cannot dispense with the information that makes independent verification possible.
The challenge is to reduce the cost of providing that information while keeping its availability guarantees strong enough for the applications built on top.