The Current State of the Data Availability Landscape: L1, L2, and Modularity Forming a Three-Way Balance
TechFlow Selected TechFlow Selected
The Current State of the Data Availability Landscape: L1, L2, and Modularity Forming a Three-Way Balance
Hope to see more outstanding startup teams exploring the field of data availability.
Navigating Web3 tides with focused insightsData availability primarily arises in the context of light client nodes relative to full nodes. Within the industry, there is already a consensus on addressing data availability for light clients—using erasure codes.
Not only do light clients face data availability issues, but narratives such as Layer1+Layer2 or modular blockchains also encounter similar challenges.
Currently, the industry has mainly developed three types of solutions for data availability:
1. Cost-Reduction Schemes for Storing Data on L1—EIP-4488 and EIP-4844
When Ethereum scales via Rollups, a transaction incurs three main types of costs: execution fees (costs for all nodes in the network to execute and verify the validity of transactions), storage/state fees (costs for updating new states), and data availability fees (costs for publishing data to L1).
Among these, data availability fees constitute the largest portion.
Currently, Rollups upload data to L1 in the form of calldata, which is very expensive. Hence, EIP-4488 was proposed to reduce the cost per non-zero calldata byte from 16 gas to 3 gas. However, this cost remains relatively high.
Then came the EIP-4844 proposal—Proto-Danksharding, introducing a new transaction format called Blob-carrying Transactions. Compared to standard transactions, this format includes an additional "blob" field specifically designed to store L2 data. Moreover, blob data is deleted by nodes after one month, significantly reducing long-term storage requirements.This blob transaction format provides cheaper data availability than calldata.
There are two primary reasons:
-
First, calldata resides within the Execution Payload, while blob data is stored separately in Prysm or Lighthouse nodes (not in Geth). Calldata requires more computational resources when being read by smart contracts;
-
Second, blob data is only stored temporarily and will be deleted by nodes after one month.
In summary, this can be seen as Ethereum’s approach to lowering data availability costs directly on the L1 chain.
Additionally, a complementary verification mechanism—Data Availability Sampling (DAS)—was introduced. With DAS, nodes can verify whether a block's data has been published by downloading only randomly selected portions of it. Since DAS enables parallelized validation of block data, even with a large number of future data shards, individual validator nodes won’t face increased burdens. On the contrary, this could encourage more validators to join, ensuring sufficient decentralization. To implement DAS, erasure coding technology is used; and to ensure correct encoding of erasure codes, KZG polynomial commitments are introduced.
With this suite of solutions, Ethereum nodes (or light clients) can verify full data availability by randomly downloading only a fraction of the data blocks.
2. Data Availability Solutions Proposed by Execution-Layer Rollups
Leading execution-layer Rollups have also developed their own data availability solutions, such as StarkEx, zkSync 2.0, Polygon zkEVM, among others.
StarkEx
StarkEx is a framework for building permissioned, application-specific scaling solutions. Projects including dYdX, Immutable, Sorare, DeversiFi, and Reddio currently use StarkEx.
StarkEx supports multiple data availability modes: Rollup, Validium, and Volition—all based on validity proofs.
-
In Rollup mode, all data is submitted on-chain;
-
In Validium mode, data stays off-chain, with only commitments to recent state and validity proofs posted on-chain;
-
Volition is a hybrid model where users can choose at the transaction level whether data storage occurs on-chain or off-chain.
Since Validium keeps data off-chain and only posts state commitments and proofs on-chain, it achieves lower transaction fees and higher TPS. However, the trade-off is that StarkEx Validium operators could potentially freeze user funds. To mitigate this, StarkEx introduced a permissioned Data Availability Committee (DAC), whose members must sign off via quorum approval on every state update to confirm they’ve received the corresponding data. Currently, the DAC consists of eight participants.
zkSync
zkSync 2.0 introduces a new holistic architecture combining zkRollup and zkPorter accounts. These two components are composable and interoperable: contracts and accounts on the zkRollup side can seamlessly interact with those on the zkPorter side, and vice versa. From a user perspective, the most noticeable difference is that zkPorter accounts cost about 100 times less in fees.
zkRollup ensures on-chain data availability, whereas zkPorter uses off-chain data availability. Specifically, zkRollup stores data availability on L1, while zkPorter handles it on L2. zkRollup transaction data is published to Ethereum via calldata—a conventional method. The innovative part lies in zkPorter’s data availability design.
zkPorter addresses data availability through a hybrid approach combining zkRollup and sharding concepts. It supports arbitrarily many shards, each with its own defined data availability strategy governed by its shard-specific smart contract. Shard selection is controlled at the individual account level, effectively delegating data availability responsibilities to individual shards, which can independently adopt different solutions.
zkPorter’s shards include: Shard 0, Guardians Shard, and Protocol X Shard.
Shard 0 is a simple zkRollup shard with full data availability and security guarantees provided by the underlying Ethereum L1. Thus, Shard 0 is the most expensive shard within zkPorter, costing approximately 1/100th of the mainnet transaction fee.
Other shards define their own data availability strategies via their respective smart contracts. By moving data availability off-chain, zkPorter reduces transaction costs by another 10–100x and increases TPS beyond base-layer sharding capabilities. zkPorter introduces an optional validator mechanism—zkPorter Guardians—that allows the protocol to invite stakeholders to serve as data availability guarantors across shards.
zkPorter’s data availability is secured by zkSync token holders (Guardians). They track the state of the zkPorter side by signing blocks, thereby confirming data availability for zkPorter accounts. Guardians participate in proof-of-stake (PoS) using zkSync tokens—this constitutes what is known as cryptographic-economic assurance of data availability.
Polygon zkEVM
Polygon zkEVM is a decentralized Ethereum Layer 2 scaling solution based on cryptographic proofs, offering fast finality and transaction verification. Like Polygon Avail, it is one of several scaling initiatives launched by Polygon, though with different focuses. Despite having released Polygon Avail as a general-purpose data availability solution, Polygon zkEVM still implements its own dedicated data availability scheme.
Polygon zkEVM adopts a hybrid data availability model, allowing either Validium or Volition modes. In Validium mode, data is stored off-chain, with only validity proofs published on-chain. In Volition mode, certain transactions keep both data and proofs on-chain, while others publish only proofs.
Scroll
Of course, some zkRollups have not yet designed their own data availability schemes—such as Scroll.
Its CTO, Ye Zhang, said in an interview with Chain Catcher: “Scroll currently does not have a dedicated data availability solution. We remain optimistic about Ethereum’s technical roadmap, whether it’s Danksharding or Proto-Danksharding.”
“Moreover, introducing additional data availability mechanisms may compromise overall system security. Therefore, we believe that in the long term, it’s best to rely on Ethereum itself as the native data availability layer.”
3. General-Purpose Data Availability Solutions
Beyond Ethereum L1 and Rollup L2 efforts to solve data availability and reduce associated costs, some projects are developing general-purpose data availability solutions.
These projects are expected to play a key role as data availability layers in future modular blockchain architectures. Currently, the two main players are Celestia and Polygon Avail.
Celestia
Celestia is a modular blockchain focused exclusively on the data availability layer. The Celestia DA layer features two core components: Data Availability Sampling (DAS) and Namespace Merkle Trees (NMT). DAS allows light nodes to verify data availability without downloading entire blocks; NMT enables execution and settlement layers on Celestia to download only transactions relevant to them.
For Celestia to function as an independent data availability layer, three key steps are required:
-
Rollups send all transaction data to Celestia;
-
Celestia publishes all this data across its network;
-
Ethereum verifies that Celestia has stored and published the data and that it remains accessible.
In short, Celestia realizes a general-purpose data availability solution through erasure coding + fraud proofs + economic constraints and incentive mechanisms.
Polygon Avail
Polygon is a highly resilient project with strong strategic planning and R&D capabilities. Having evolved through various scaling approaches—from state channels and Plasma to Optimistic Rollups and zk Rollups—the Polygon team continues exploring multiple directions, maintaining active development on solutions like Polygon Avail, Polygon Zero, Polygon Miden, and Polygon zkEVM. Polygon functions almost like a Layer 2 aggregator, consolidating diverse scaling technologies.
Polygon Avail is a project aimed at solving data availability challenges for Ethereum scaling. Officially, Polygon Avail is defined on its website as a modular blockchain serving the data availability layer.
Avail offers high assurance of data availability for any light client, although its documentation candidly admits it “does not provide higher DA guarantees for light clients than any other network.” Avail focuses on enabling light clients to efficiently and randomly sample small portions of data—proving block data availability without downloading entire blocks—by leveraging KZG polynomial commitments, erasure coding, and other techniques.
Like Celestia, Polygon Avail is a general-purpose data availability solution. The key difference is that Celestia uses fraud proofs to ensure correct erasure coding, while Polygon Avail relies on KZG commitments. Celestia is simpler to implement but requires higher communication bandwidth due to larger erasure code and sampling data sizes. Avail involves more complex cryptographic implementations, making it slightly harder to build, but offers advantages in smaller erasure code size, reduced sampling load for light nodes, and lower bandwidth requirements.
Summary
The above three categories of solutions all aim to address on-chain data availability—either by introducing new ways to store data on L1, adopting a modular blockchain perspective to build general-purpose DA layers, or designing low-cost off-chain data availability schemes for L2s.
I believe these solutions will coexist for a long time to come.
Under the Layer1+Layer2 architecture, “blobs” replace “calldata” to handle L2 data availability, while Validium, Volition, and zkPorter use economic incentives and constraints within limited trusted parties to ensure L2-level data availability.
Under the modular blockchain narrative, general-purpose data availability solutions like Polygon Avail and Celestia will take on DA layer responsibilities in a relatively more decentralized manner.
At the same time, I hope to see more outstanding entrepreneurial teams exploring the data availability space. Current solutions are pioneers, yet I still feel something exciting is missing.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@iobc_capital
