Data availability (DA) refers to the guarantee that the transaction data included in a blockchain block is fully accessible and retrievable by any network participant who needs to verify it. In a decentralized system, data availability ensures that when a block producer publishes a new block, the underlying data, every transaction and every state change, is actually made available to the network rather than being withheld. Without this guarantee, validators and users cannot independently verify the correctness of the blockchain’s state, which undermines the trustless nature of the system.
The data availability problem becomes particularly critical in the context of modular blockchain architectures and layer-2 scaling solutions such as rollups. In an optimistic rollup, for example, a sequencer posts a compressed batch of transactions to the layer-1 chain. If the underlying transaction data is not available, fraud provers cannot reconstruct the state to challenge invalid state transitions. Similarly, in zero-knowledge rollups, while the ZK proof mathematically guarantees computational correctness, users still need access to the transaction data to reconstruct their account balances and generate their own proofs for withdrawals.
Data availability is fundamentally distinct from data storage. Data storage concerns the permanent retention of historical data, while data availability only requires that data be accessible for a sufficient window of time for verification purposes. This distinction has driven the development of dedicated data availability layers: specialized blockchains optimized solely for temporarily hosting data that other chains need for verification. Projects like Celestia, EigenDA, Avail, and Near DA represent this category of blockchain infrastructure. Ethereum itself introduced a native data availability mechanism through EIP-4844 (Proto-Danksharding), which created a new transaction type called “blobs” that provides temporary, low-cost data availability for rollups, and later expanded that capacity significantly through the Fusaka upgrade.
Origin & History
2018: The data availability problem is formally articulated by Mustafa Al-Bassam, Alberto Sonnino, and Vitalik Buterin in the research paper “Fraud and Data Availability Proofs: Maximising Light Client Security and Scaling Blockchains without Honest Majority Assumptions.” This paper introduces the concept of Data Availability Sampling (DAS), where light clients can probabilistically verify that data is available without downloading the entire dataset.
2019: LazyLedger is proposed by Mustafa Al-Bassam as a dedicated data availability blockchain, the first formal design for a chain optimized solely for ordering and making transaction data available rather than executing transactions. LazyLedger would later evolve into Celestia.
2020: Ethereum researchers including Dankrad Feist advance the concept of Danksharding, a data availability centric sharding design for Ethereum intended to let the network handle large amounts of rollup data. This represents a philosophical shift in Ethereum’s scaling roadmap from execution sharding toward data availability sharding.
2021 (October): Celestia Labs (formerly LazyLedger Labs) launches the Celestia project publicly, positioning it as the first modular data availability layer. The vision is to decouple data availability from execution and consensus, allowing rollups to post their data to Celestia rather than expensive Ethereum calldata.
2022: The “modular blockchain thesis” gains widespread attention, built around the idea that future blockchains would separate into specialized layers for execution, data availability, consensus, and settlement. Polygon Avail (later spun off as the independent project Avail) announces its dedicated DA layer.
2023: The Ethereum Foundation runs the KZG trusted setup ceremony for EIP-4844 from January to August, ultimately drawing over 141,000 contributions and becoming one of the largest cryptographic ceremonies of its kind. Throughout the year, EIP-4844 (Proto-Danksharding) is tested extensively across public devnets in preparation for mainnet activation. In October, Celestia’s mainnet launches, becoming the first live dedicated data availability layer; rollups can now post transaction data to Celestia at a fraction of the cost of Ethereum calldata.
2024 (March): Ethereum’s Dencun upgrade activates EIP-4844 on mainnet on March 13, introducing blob transactions. Rollup data posting costs on Ethereum drop sharply and almost immediately, as L2s like Arbitrum, Optimism, Base, and zkSync transition from calldata to blobs for data posting.
2024 to 2025: EigenDA launches as a data availability layer secured by restaked ETH through EigenLayer. Near Protocol introduces Near DA, using its sharded architecture for low-cost data availability. The DA market becomes increasingly competitive, with differentiated security models and pricing across Celestia, EigenDA, Avail, and Near DA.
2025 (December): Ethereum’s Fusaka upgrade activates on mainnet on December 3, headlined by PeerDAS (EIP-7594), which brings genuine Data Availability Sampling to Ethereum’s blob system for the first time. Fusaka also introduces Blob Parameter Only (BPO) forks, a mechanism that lets Ethereum raise blob capacity through lightweight, config-only updates rather than full coordinated hard forks.
2026 (January): Two BPO forks raise Ethereum’s per-block blob target from the original 6 (max 9) to 10 (max 15), and then to 14 (max 21), roughly a 2.3x increase in data capacity within a month. PeerDAS reduces the bandwidth a typical node needs to custody blob data by around 87.5%, since nodes now sample portions of the data rather than downloading every blob in full.
“Data availability is the most important and least understood problem in blockchain scaling. You can have the fastest execution engine in the world, but if the data isn’t available, the system has no security.” Vitalik Buterin, Endgame post, 2021.
In Simple Terms
Data availability is like a public bulletin board in a town square. When the mayor posts a new law, everyone needs to be able to read it to verify it is legitimate and follow it. If the mayor posts the law but then covers the bulletin board with a tarp, people cannot verify the law even though it technically “exists.” Data availability ensures the tarp is never placed: the data is always readable.
Imagine a teacher who grades exams but refuses to show students their graded papers. The teacher claims everyone passed, but without seeing the actual answers and marks, students cannot verify their scores. Data availability is the requirement that the teacher must make the graded papers accessible for review, even if only temporarily.
Think of a restaurant health inspection. The inspector visits, writes a report, and posts the grade in the restaurant window for a period of time. Customers do not need the report to stay there forever; they just need it to be available long enough for anyone who cares to check. Data availability works the same way: data must be accessible for a verification window, not necessarily stored permanently.
It is like a courtroom where all evidence must be made available to both sides before a trial. If the prosecution has evidence but refuses to share it, the defense cannot do its job and the trial is unfair. In blockchain terms, if a block producer has transaction data but refuses to share it, validators cannot do their job and the chain’s security guarantees break down.
Picture an open-book exam versus a closed-book exam. Data availability means the exam is open-book: everyone has access to the source material needed to verify answers. Without data availability, it becomes a closed-book system where you have to trust that the person who wrote the answers did so correctly.
Important: Data availability is not the same as data storage. A system can guarantee data availability (the data is accessible when needed for verification) without guaranteeing permanent storage (the data exists forever). Most DA solutions prune data after a specified window. Ethereum blobs are pruned after approximately 18 days, and Celestia similarly prunes after its own availability window. Historical data archiving is a separate concern handled by full nodes, indexers, and dedicated storage solutions like Filecoin or Arweave.
Key Technical Features
Data Availability Sampling (DAS)
- DAS allows light clients to verify that block data is available without downloading the entire block
- Each light client randomly samples a small number of data chunks from the block
- If all sampled chunks are retrievable, the client gains probabilistic confidence that the full data is available
- With enough independent light clients each sampling different random chunks, the collective network achieves very high confidence in availability
- DAS is the key innovation that makes large-block DA layers practical, since nodes do not need enormous bandwidth to verify data
- On Ethereum, DAS arrived in production through PeerDAS as part of the December 2025 Fusaka upgrade, letting regular nodes sample and custody only a fraction of blob data rather than downloading it all
Erasure Coding
- Block data is encoded using Reed-Solomon style erasure coding before being distributed to the network
- The original data is expanded, typically doubled, with redundancy, so that the full dataset can be reconstructed from a subset of the encoded data
- This means an adversarial block producer would need to withhold a large majority of the encoded data to successfully hide any portion of the original data
- Combined with DAS, erasure coding ensures that even a small number of random samples can detect data withholding with overwhelming probability
- Celestia, Ethereum’s blob system, and Avail all use erasure coding as a foundational primitive
How Data Availability Works in Rollups
- A rollup sequencer collects user transactions and arranges them into an ordered batch
- The sequencer compresses the batch and posts it as data to the DA layer (Ethereum blobs, Celestia, EigenDA, and so on)
- The DA layer ensures the data is distributed across its node network and made available for retrieval
- For optimistic rollups, fraud provers download the data from the DA layer, re-execute the transactions, and challenge any invalid state roots within the challenge period
- For ZK rollups, while the ZK proof guarantees computation correctness, users need the DA data to reconstruct their own state and generate withdrawal proofs
- After the DA window expires (for example, around 18 days for Ethereum blobs), the data may be pruned from the DA layer but can remain archived by full nodes and indexers
- The rollup’s security depends on the DA guarantee; if data is withheld, the rollup’s security model degrades
KZG Commitments (Kate-Zaverucha-Goldberg)
- EIP-4844 uses KZG polynomial commitments to cryptographically commit to blob data
- A KZG commitment is a compact cryptographic proof that binds to the entire blob contents, allowing efficient verification
- Validators can verify that a blob corresponds to its commitment without downloading the full blob data
- KZG commitments support efficient DAS by allowing point evaluations on the committed polynomial
- The KZG trusted setup ceremony for Ethereum ran from January to August 2023 and drew over 141,000 participants, making it one of the largest such ceremonies in cryptographic history
EIP-4844 Proto-Danksharding (Ethereum Blobs)
- Introduced a new transaction type that carries large data “blobs” (128 KB each)
- At launch in March 2024, Ethereum targeted 3 blobs per block with a maximum of 6
- Blobs exist in a separate fee market from regular Ethereum transactions, with their own base fee mechanism
- Blob data is temporarily stored by consensus layer clients and pruned after approximately 18 days
- Proto-Danksharding reduced L2 data posting costs dramatically, dropping typical L2 transaction fees from dollars to cents
- The Fusaka upgrade (December 2025) and its subsequent Blob Parameter Only forks raised Ethereum’s blob target to 14 and maximum to 21 by January 2026, roughly 2.3 times the original capacity, with further increases expected as the network monitors performance
Dedicated DA Layers vs. Ethereum DA
- Celestia: Purpose-built DA layer with native DAS support, erasure coding, and its own PoS consensus. Offers low DA costs but relies on its own validator set for security rather than Ethereum’s
- EigenDA: DA layer secured by restaked ETH through EigenLayer, inheriting economic security from Ethereum. Offers high throughput DA without requiring rollups to post data on Ethereum directly
- Avail: Standalone DA chain using KZG commitments and DAS with application-specific validity proofs, aiming to be a universal DA layer for rollups across ecosystems
- Near DA: Leverages Near Protocol’s sharded architecture to provide low-cost DA, benefiting from Near’s existing shard capacity and validator network
- Ethereum blobs: Native DA embedded in Ethereum’s consensus, offering the strongest security guarantees, backed by Ethereum’s full validator set, and now supported by production DAS through PeerDAS, though still at a higher cost per byte than some dedicated DA layers
Advantages & Disadvantages
| Advantages | Disadvantages |
|---|---|
| Rollup Security Foundation: Data availability is the critical security guarantee that allows rollups to inherit the security of their DA layer, enabling trustless scaling without compromising verifiability | Cost-Security Tradeoff: Cheaper DA layers (Celestia, EigenDA) offer lower costs but different security guarantees than posting data directly to Ethereum, creating a spectrum of security versus affordability |
| Modular Scalability: Separating DA from execution allows each layer to scale independently, letting execution layers optimize for speed while DA layers optimize for throughput | Complexity for Developers: Understanding and implementing DA correctly adds significant complexity to rollup design, requiring expertise in erasure coding, commitment schemes, and sampling protocols |
| Dramatic Cost Reduction: EIP-4844 and the subsequent Fusaka blob expansion reduced L2 data costs substantially, making sub-cent transactions possible on many rollups | Data Pruning Risk: Since DA layers only guarantee temporary availability, not permanent storage, there is a risk that historical data may become inaccessible if no one archives it after the DA window expires |
| Light Client Verification: DAS enables resource-constrained devices to verify data availability without downloading entire blocks, supporting decentralization by lowering node requirements | Fragmentation Risk: The proliferation of competing DA layers (Celestia, EigenDA, Avail, Near DA, Ethereum blobs) fragments the ecosystem and creates interoperability challenges |
| Censorship Resistance: Guaranteed data availability means no party can selectively withhold information to manipulate rollup state or prevent users from proving their account balances | Trusted Setup Requirements: KZG commitments used in EIP-4844 require a one-time trusted setup ceremony, introducing a cryptographic assumption that the ceremony was conducted honestly |
| Permissionless Verification: Anyone can independently verify the chain state by accessing the available data, maintaining the trustless nature of blockchain even in a modular architecture | Nascent Technology: Several DA solutions and features are still early in deployment, with less battle-testing than established monolithic blockchain designs |
| Future-Proof Design: The modular DA approach is designed to scale with future hardware improvements, as DA throughput scales with the number of DAS-participating light clients | Network Effects and Bootstrapping: New DA layers must build sufficient validator and node networks to provide meaningful security guarantees, creating a cold-start problem |
| Flexible Security Models: Rollups can choose their DA layer based on their specific security-cost requirements; high-value DeFi protocols may use Ethereum DA while gaming dApps may prefer cheaper alternatives | Liveness Dependencies: If a DA layer experiences downtime or liveness failures, all rollups depending on it cannot post new batches, creating a single point of failure for the rollup stack that relies on it |
Risk Management
Data Withholding Attacks:
- A malicious block producer could publish a block header and commitment but withhold the actual data, preventing others from verifying state transitions
- Mitigation: Data Availability Sampling by a sufficient number of light clients ensures that data withholding is detectable with overwhelming probability
- Rollups should implement fallback mechanisms that halt state updates if DA cannot be confirmed within the expected timeframe
DA Layer Liveness Failures:
- If the underlying DA layer goes offline, rollups cannot post new transaction batches and effectively stall
- Mitigation: design rollups with escape hatch mechanisms that allow users to withdraw funds directly from L1 even if the DA layer is unavailable
- Consider multi-DA strategies where critical data can be posted to multiple DA layers for redundancy
Security Assumption Differences:
- Different DA layers have fundamentally different security models. Ethereum DA is secured by the full Ethereum validator set, with tens of billions of dollars staked, while newer DA layers may have much smaller economic security
- Mitigation: understand and clearly communicate the security assumptions of your chosen DA layer; high-value applications should prefer DA layers with stronger economic security
- Monitor the staked value and validator decentralization of dedicated DA layers, as these metrics directly impact security guarantees
Data Reconstruction and Archival Risk:
- After the DA window expires (for example, around 18 days for Ethereum blobs), data is no longer guaranteed to be available from the DA layer
- Mitigation: ensure rollup operators and community members run full archival nodes that store historical data beyond the DA window
- Integrate with decentralized storage networks such as Filecoin or Arweave for permanent archival of critical historical data
Regulatory and Compliance Risk:
- Temporary data availability, with pruning, may conflict with regulatory requirements for data retention in financial applications
- Mitigation: implement archival strategies that maintain compliance with relevant data retention regulations independently of the DA layer’s pruning schedule
- Clearly document data lifecycle policies and ensure institutional users understand the distinction between DA and permanent storage
Cultural Relevance
The concept of data availability has gone through a remarkable transformation in blockchain culture, moving from an obscure academic concern to one of the most discussed topics in the scaling debate. The phrase “where does the data go?” became a rallying cry for critics of layer-2 solutions who worried that off-chain data posting could compromise security. This question pushed the industry to confront the data availability problem directly, leading to the modular blockchain thesis that now shapes much of the scaling conversation.
Celestia’s launch in October 2023 marked a cultural milestone, validating the idea that blockchains could be purpose-built for a single function (data availability) rather than trying to do everything. The “modular versus monolithic” debate became one of the defining narratives of the 2023 to 2024 cycle, with strong advocates on both sides. Monolithic chain supporters, particularly in the Solana community, argued that separating DA adds unnecessary complexity, while modular advocates in the Ethereum and Celestia ecosystems argued it is the clearest path to internet-scale throughput.
“The future of blockchain is modular. Just as the internet separated networking, transport, and application layers, blockchains will separate execution, settlement, and data availability.” Mustafa Al-Bassam, founder of Celestia, 2022.
EIP-4844’s activation in March 2024 was celebrated as one of the most impactful Ethereum upgrades since the Merge, since rollup fees dropped sharply almost overnight and demonstrated that data availability optimization could have immediate, tangible impact on end-user costs. The Fusaka upgrade in December 2025 extended that narrative further, bringing genuine Data Availability Sampling to Ethereum for the first time and reframing the conversation from “will Ethereum get DAS” to “how quickly can Ethereum scale blob capacity now that it has DAS.”
Real-World Examples
Ethereum EIP-4844 Rollup Cost Reduction
Scenario: A large Ethereum L2 was spending a substantial amount per day on Ethereum calldata costs for posting transaction batches prior to the Dencun upgrade.
Implementation: After EIP-4844 activated in March 2024, the rollup transitioned from posting transaction data as calldata (permanent, expensive) to blob transactions (temporary, cheap). The blob fee market’s separate pricing mechanism meant the rollup’s data costs were decoupled from Ethereum’s execution gas market.
Outcome: The rollup’s data posting costs dropped sharply, and that reduction was passed through to users in the form of much lower per-transaction fees. Similar cost reductions were observed across other major L2s, including Optimism, Base, and zkSync.
Celestia as a DA Layer for a Solana Virtual Machine Rollup
Scenario: A Solana Virtual Machine (SVM) rollup settling on Ethereum needed a high-throughput DA layer to support a high target transaction rate while maintaining verifiability.
Implementation: The rollup chose Celestia as its data availability layer, posting compressed transaction batches to Celestia’s DA network. Celestia’s erasure coding and DAS protocol ensured the rollup’s data was available for verification without requiring validators to download the full dataset. State roots were posted to Ethereum for settlement finality.
Outcome: The rollup achieved DA costs far below Ethereum calldata pricing, enabling high-throughput DeFi and gaming applications at low data costs while maintaining Ethereum-level settlement security.
EigenDA for High-Throughput Rollup Applications
Scenario: A high-frequency DeFi protocol building on an L2 needed data availability throughput beyond what Ethereum’s blob capacity could provide at the time.
Implementation: The protocol deployed on a rollup using EigenDA as its data availability layer. EigenDA’s higher throughput easily accommodated the protocol’s data needs, and its security was backed by restaked ETH through EigenLayer, providing significant economic security without requiring Ethereum-native blob space.
Outcome: The rollup achieved substantially higher data throughput than was possible with Ethereum blobs alone at the time, enabling order-book-style DEX operations with fast order updates. The restaked ETH security model offered a middle ground between Celestia’s independent security and Ethereum’s native DA.
Data Availability Sampling by Celestia Light Nodes
Scenario: A mobile wallet application wanted to verify that Celestia blocks (used by its rollup for DA) contained valid, available data without running a full Celestia node, which would require significant bandwidth and storage.
Implementation: The wallet integrated Celestia’s light node protocol, which performs Data Availability Sampling by randomly requesting small data chunks from the network and verifying them against the block’s erasure-coded commitment.
Outcome: The mobile light node verified data availability with very high confidence while downloading a small fraction of each block’s data, making it practical to run on mobile devices and giving users trustless DA verification without relying on any centralized RPC provider.
Comparison Table
| Feature | Ethereum Blobs (EIP-4844) | Celestia | EigenDA | Avail |
|---|---|---|---|---|
| Security Model | Full Ethereum PoS validator set | Independent PoS with TIA staking | Restaked ETH via EigenLayer | Independent PoS with AVAIL staking |
| Data Throughput (as of early 2026) | Target 14 blobs per block, max 21 (roughly 149 to 224 KB/s), up from a target of 3 and max of 6 at launch | Roughly 0.17 MB/s | Roughly 10 MB/s, with a roadmap toward much higher throughput | Roughly 1.4 MB/s |
| Data Retention | About 18 days, then pruned | Configurable, commonly around 30 days | Configurable per rollup | About 30 days |
| DAS Support | Yes, via PeerDAS (activated with the Fusaka upgrade, December 2025) | Yes (native, production) | Partial (dispersal based) | Yes (native, production) |
| Commitment Scheme | KZG polynomial commitments | Namespaced Merkle Trees plus erasure coding | KZG commitments | KZG commitments |
| Ecosystem Adoption | All major Ethereum L2s (Arbitrum, Optimism, Base, zkSync) | Eclipse, Manta Network, various rollup-as-a-service providers | Mantle, Celo, and various L2s | Validium-style rollups |
Note: throughput and cost figures for DA layers change quickly as networks upgrade; treat them as directional rather than exact.
Related Terms
- Rollup: A layer-2 scaling solution that executes transactions off-chain but posts transaction data to a DA layer for verification, the primary consumer of data availability services
- Proto-Danksharding (EIP-4844): The Ethereum upgrade that introduced blob-carrying transactions, providing a dedicated, lower-cost data availability mechanism for rollups on Ethereum
- Danksharding: The fuller sharding design for Ethereum, of which PeerDAS and the Fusaka blob capacity increases are an important step, aimed at further expanding blob capacity and native Data Availability Sampling
- Erasure Coding: A data encoding technique that adds redundancy to data so the original can be reconstructed from a subset, the mathematical foundation enabling Data Availability Sampling
- Modular Blockchain: An architectural model where execution, settlement, consensus, and data availability are handled by separate specialized chains rather than a single monolithic blockchain
- Validium: A scaling solution similar to a ZK rollup but with data availability provided off-chain rather than on Ethereum, trading some security for lower costs
- Calldata: The data field of an Ethereum transaction, historically used by rollups for data posting before blobs were introduced, permanently stored but comparatively expensive
- KZG Commitment: A cryptographic polynomial commitment scheme used in EIP-4844 to efficiently commit to and verify blob data without requiring a full data download
- Light Client: A blockchain client that verifies block validity and data availability without downloading and storing the full chain state, enabled by DAS
- Fraud Proof: A mechanism used by optimistic rollups where any party can challenge an invalid state transition by re-executing the disputed transactions, which requires the underlying data to be available
- Blob: A large data object (128 KB) attached to Ethereum transactions under EIP-4844, designed specifically for rollup data posting with temporary storage and a separate fee market
- Celestia: The first dedicated modular data availability layer, using DAS and erasure coding to provide high-throughput, lower-cost DA for rollups across multiple ecosystems
FAQ
Q: What is data availability and why does it matter for blockchain scaling? Data availability is the guarantee that the data in a blockchain block is actually accessible to anyone who needs to verify it. It matters for scaling because layer-2 rollups depend on being able to verify their state by accessing the underlying transaction data. If a rollup posts a state claim but the data is unavailable, no one can challenge incorrect claims (in optimistic rollups) or reconstruct their own state (in ZK rollups). Data availability is essentially the security foundation of the entire rollup scaling ecosystem.
Q: What is the difference between data availability and data storage? Data availability means data is accessible when needed for verification during a defined window of time. Data storage means data is permanently retained. Most DA solutions only guarantee temporary availability. Ethereum blobs are pruned after about 18 days, and Celestia has a similar window. After pruning, the data may still exist on archival nodes, indexers, or permanent storage networks, but the DA layer no longer guarantees it. Think of DA as a library’s reading room, where you can access books during operating hours, versus a vault, where books are stored permanently.
Q: How does Data Availability Sampling (DAS) work? DAS allows a light client to verify that a block’s data is available by randomly sampling a small number of data chunks rather than downloading the entire block. The data is first erasure-coded, adding redundancy so a subset can reconstruct the whole. Each light client requests a few random chunks. If all chunks come back, the client gains high confidence that the data is available. With many independent light clients sampling, the probability that unavailable data goes undetected becomes extremely small, even though no single client downloaded the full block. Ethereum brought this capability into production for its own blobs through PeerDAS in the December 2025 Fusaka upgrade.
Q: How much did EIP-4844 reduce rollup costs, and has that changed since? Before EIP-4844, rollups posted data as Ethereum calldata, which is permanently stored and priced within Ethereum’s single gas fee market. EIP-4844 introduced blobs: large data objects with their own separate fee market and temporary storage (pruned after roughly 18 days). Because blobs do not compete with regular Ethereum transactions for gas and only need temporary storage, the cost per byte dropped dramatically at launch in March 2024. Since then, the Fusaka upgrade and its Blob Parameter Only forks have more than doubled Ethereum’s blob capacity, which has generally kept blob-related costs low or pushed them lower as capacity has grown faster than demand.
Q: Should a rollup use Ethereum blobs or a dedicated DA layer like Celestia? This depends on the rollup’s priorities. Ethereum blobs offer a very strong security guarantee because they are validated by Ethereum’s full validator set, and now benefit from production DAS through PeerDAS, though they can still carry higher costs and, at least historically, lower throughput than some dedicated layers. Celestia and other dedicated DA layers offer high throughput and lower costs but rely on their own, smaller validator sets for security. High-value DeFi rollups typically prefer Ethereum DA for maximum security, while gaming and social rollups that prioritize low costs may choose Celestia or EigenDA. Some rollups use a hybrid approach, posting critical data to Ethereum and less critical data to a dedicated DA layer.
Q: What happens if data becomes unavailable after the DA window expires? After the DA window (for example, around 18 days for Ethereum blobs), the DA layer prunes the data and no longer guarantees its availability. However, the data typically still exists on archival full nodes, block explorers, and dedicated indexing services. The key security assumption is that during the DA window, all necessary verification occurred: fraud proofs were submitted, ZK proofs were verified, and users reconstructed their state. After that window, the chain’s state has effectively been finalized through these verification mechanisms, so the raw data is needed mainly for historical analysis rather than ongoing security.
Q: What is the relationship between data availability and MEV? Data availability and MEV intersect in several ways. DA layers that use batch posting, such as rollup sequencers posting to Ethereum, create MEV opportunities around the ordering of batches. If DA is delayed or withheld, it can create information asymmetry that sophisticated actors exploit. DA layer design also affects how transparent pending transactions are; some designs expose pending data to validators before finalization, potentially enabling MEV extraction at the DA layer itself. This remains an active area of research and protocol design.
Sources
- Mustafa Al-Bassam, Alberto Sonnino, and Vitalik Buterin, “Fraud and Data Availability Proofs”
- EIP-4844: Shard Blob Transactions: https://www.eip4844.com/
- Celestia Documentation: https://docs.celestia.org/
- Ethereum Roadmap, Danksharding and Fusaka: https://ethereum.org/en/roadmap/
- EigenDA Documentation
- Avail Project Documentation: https://docs.availproject.org/
- Dankrad Feist, KZG Polynomial Commitments
- Ethereum Foundation, Data Availability
- Ethereum Foundation Blog, “Wrapping up the KZG Ceremony”
- Ethereum Foundation Blog, “Fusaka Mainnet Announcement”
