Why is data availability so important for Layer2?
TechFlow Selected TechFlow Selected
Why is data availability so important for Layer2?
What exactly is data availability? What data availability challenges do L2s face?
Navigating Web3 tides with focused insightsAuthor: Jian Shu
Ethereum Foundation researcher Dankrad Feist once stated in a tweet that if Ethereum is not used for data availability, it's not an L2. If we follow this definition, many chains would be excluded from the L2 category—such as Arbitrum Nova, Polygon, and Mantle.
So, what exactly is data availability? What data availability challenges do L2s face? And why is there so much controversy around data availability layers for L2s? This article focuses on these questions, aiming to demystify the concept of data availability.
What Is Data Availability
Simply put, data availability refers to the requirement that block producers publish all transaction data of a block onto the network so that validators can download it.
If a block producer publishes complete data and allows validators to download it, we say the data is available; if they withhold some data, making it impossible for validators to obtain the full dataset, we say the data is unavailable.
Difference Between Data Availability and Data Retrievability
We often confuse data availability with data retrievability, but they are fundamentally different.
Data availability pertains to the stage when a block has been produced but not yet finalized via consensus on the blockchain. Therefore, data availability is not about historical data, but rather whether newly published data can be verified through consensus.
Data retrievability, on the other hand, concerns data that has already passed consensus and is permanently stored on the blockchain—the ability to retrieve historical data. Nodes storing all historical data on Ethereum are known as archive nodes.
Thus, the co-founder of L2BEAT once noted in a long-form tweet that full nodes have no obligation to provide historical data; the reason we can access it is simply because full nodes are generous enough to do so.
He also suggested that the term "data availability" (Data Availability) may mislead people about its actual function and should instead be replaced with "data publishing." This view was supported by the founder of Celestia.
Data Availability Issues in L2
Although the concept of data availability originated from Ethereum, our current focus lies primarily on data availability at the L2 level.
In L2 systems, the sequencer acts as the block producer and must publish sufficient transaction data so that verifiers can validate transactions.
However, two key issues arise in this process: ensuring secure verification mechanisms and reducing the cost of data publication. We'll explore these in detail below.
Ensuring Secure Verification Mechanisms
We know that OP Rollups use fraud proofs to verify transaction validity, while ZK Rollups rely on validity proofs.
-
For OP Rollup: If the sequencer does not publish complete data required to reconstruct the block, challengers in the fraud proof system cannot launch valid disputes;
-
For ZK Rollup: Although validity proofs themselves don't require data availability, the ZK Rollup system as a whole still needs it. Without reconstructable block data, users won't be able to determine their balances and could risk losing assets.
To ensure secure validation, most current L2 sequencers publish both state and transaction data directly onto Ethereum—the highly secure base layer—and rely on Ethereum for settlement and data availability.
Therefore, the data availability layer is essentially where L2s publish their transaction data. Currently, mainstream L2s treat Ethereum as their data availability layer.
Reducing the Cost of Data Publication
Today’s L2s simply place both data availability and settlement functions on Ethereum. While this ensures high security, it comes at a significant cost. This is the second major challenge facing L2s: how to reduce the cost of publishing data.
The total gas paid by users on L2 consists mainly of two parts: gas consumed by executing transactions on L2, and gas spent when L2 submits data to L1. The former is negligible, while the latter constitutes the bulk of user fees. Among the data submitted to L1, transaction data published for data availability makes up the majority, whereas proof data for validating transactions accounts for only a small portion.
Therefore, to make L2s more affordable overall, we need to lower the cost of publishing data. How can this be achieved? There are two main approaches:
-
Reduce the cost of publishing data on L1—for example, through Ethereum's upcoming EIP-4844 upgrade.
-
Following the Rollup model of offloading execution from L1, data availability can also be separated from L1 to reduce costs—i.e., not using Ethereum as the data availability layer.
Controversy Around Data Availability Layers in L2
To understand the debate over data availability layers in L2, we must first discuss modular blockchains. Modular blockchains decouple various core functions of a monolithic blockchain into relatively independent components, combining specialized networks to scale performance.
While there's still some debate about how to categorize modular blockchains, the widely accepted framework divides them into four layers: Execution Layer, Settlement Layer, Consensus Layer, and Data Availability Layer. The functions of each module are illustrated below:
Modular blockchains resemble LEGO bricks—customizable combinations of best-in-class components allow us to build robust systems, helping alleviate the blockchain "impossible trinity" problem.
Currently, most L2s have only separated the execution layer from Ethereum, while the other three layers—settlement, consensus, and data availability—still operate on Ethereum. However, due to cost considerations, many L2s are now preparing to move their data availability layer off Ethereum, using Ethereum solely for settlement and consensus.
Interestingly, Ethereum seems reluctant to let L2s source data availability elsewhere. Ethereum Foundation researcher Dankrad Feist once tweeted that any chain not using Ethereum for data availability isn't a Rollup, and therefore not an L2.
Similarly, L2BEAT's latest definition of L2 states that scaling solutions that do not publish data on L1 are not considered L2s, because off-chain data availability solutions cannot guarantee that operators will provide the published data.
Of course, there's still no definitive conclusion on what exactly constitutes an L2. The stance held by Ethereum Foundation members and L2BEAT—that L2s must keep their data availability layer on Ethereum—appears to stem from security concerns. But is there also underlying anxiety about Ethereum's declining centrality?
Ethereum's vision is to become a supercomputer platform. To improve network performance, it had to embrace Rollups, allowing much of its ecosystem to migrate to cheaper L2s. Yet, since security remained anchored to Ethereum, its central position wasn't significantly threatened. However, if L2s also move their data availability layer off Ethereum, they fundamentally reduce reliance on Ethereum's security and gradually drift away from it—posing a real threat to Ethereum's dominance.
Nevertheless, this hasn't stopped the rapid growth of projects focused on data availability layers. In the next article on data availability, the author will dive into the major data availability solutions and related projects currently available—stay tuned.
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
@jianshubiji
