![\"\"](\"https:\/\/uplatz.com\/blog\/wp-content\/uploads\/2025\/10\/Verifiable-Scaling-A-Technical-Analysis-of-Data-Availability-Sampling-in-Decentralized-Networks-1024x576.jpg\")
<\/p>\n
bundle-multi-3-in-1—sap-fico By Uplatz<\/a><\/h3>\n1.1. The Verifier’s Dilemma: Beyond “Don’t Trust, Verify”<\/b><\/h3>\n
At its core, the Data Availability problem is the challenge of ensuring that when a block producer proposes a new block, they publish not only the block header but also the complete set of transaction data contained within that block.<\/span>3<\/span> The block header serves as a compact summary, containing cryptographic commitments (like a Merkle root) to the transactions. While this header is small and easily distributed, it is the underlying transaction data that is necessary for full nodes to execute the transactions and independently verify that the state transition is valid according to the protocol’s rules.<\/span>1<\/span><\/p>\nThe verifier’s dilemma arises when a malicious block producer engages in a <\/span>data withholding attack<\/b>. In this scenario, the producer broadcasts a valid-looking block header but deliberately withholds some or all of the corresponding transaction data.<\/span>4<\/span> Without this data, full nodes cannot re-execute the transactions to check for invalid state changes, such as the creation of currency out of thin air or the illegitimate transfer of assets.<\/span>7<\/span> Consequently, they are unable to generate fraud proofs to alert the rest of the network of the malicious activity.<\/span>3<\/span> The “don’t trust, verify” principle breaks down because verification is rendered impossible. Such an attack can have severe consequences, ranging from halting the chain to enabling the theft of funds, with the severity depending on the specific blockchain architecture.<\/span>4<\/span><\/p>\nThis dilemma creates a stark divide between the security guarantees available to different types of network participants. <\/span>Full nodes<\/b>, by definition, download and verify every transaction in every block. They possess an inherent guarantee of data availability; if they cannot download a block’s data, they simply reject the block and do not add it to their local view of the chain.<\/span>4<\/span> This resource-intensive process makes them the ultimate arbiters of network validity.<\/span><\/p>\nIn contrast, <\/span>light clients<\/b> (or light nodes) are designed for resource-constrained environments. They download only block headers, which are significantly smaller than full blocks, and rely on indirect methods to ascertain the chain’s validity.<\/span>8<\/span> Traditionally, this has meant operating under an “honest majority assumption”\u2014trusting that the consensus of block producers, who created the chain of headers, would not approve a block containing invalid transactions.<\/span>7<\/span> This assumption creates a significant security vulnerability. If a majority of block producers were to collude, they could create a block with invalid transactions, and traditional light clients would blindly accept the corresponding header as valid, as they lack the data to check for themselves.<\/span>7<\/span> This establishes the critical need for a new mechanism that can empower light clients with stronger, trust-minimized security guarantees, allowing them to verify data availability without shouldering the prohibitive costs of running a full node.<\/span>8<\/span><\/p>\n <\/p>\n
1.2. Scaling Bottlenecks in Monolithic and Modular Architectures<\/b><\/h3>\n
<\/p>\n
The Data Availability problem is inextricably linked to the <\/span>scalability trilemma<\/b>, which posits that it is difficult for a blockchain to simultaneously achieve decentralization, security, and scalability. In a traditional monolithic blockchain architecture, like that of Bitcoin or early Ethereum, all core functions\u2014execution, consensus, and data availability\u2014are handled by a single layer of nodes.<\/span>11<\/span> The most straightforward way to increase scalability (i.e., transaction throughput) in such a system is to increase the block size. However, this directly increases the hardware, storage, and bandwidth requirements for running a full node.<\/span>1<\/span> As these requirements rise, fewer participants can afford to run full nodes, leading to a centralization of network validation and a potential compromise of security and decentralization.<\/span>3<\/span> This trade-off places a practical limit on the data throughput of monolithic chains.<\/span><\/p>\nThe nature of the Data Availability problem fundamentally transforms when moving from monolithic to modular architectures. What begins as a challenge of storage and bandwidth evolves into a critical security and liveness vulnerability. In a simple monolithic chain, the consequence of data unavailability is straightforward: a node that cannot download the block data rejects it.<\/span>4<\/span> The problem appears to be primarily one of economic and performance costs associated with bandwidth and storage.<\/span>1<\/span><\/p>\nHowever, the advent of <\/span>Layer 2 (L2) rollups<\/b> as a primary scaling solution has placed the DA problem at the forefront. Rollups function by executing transactions off-chain and then posting batches of transaction data to a Layer 1 (L1) chain for security and settlement.<\/span>2<\/span> This makes the L1 a “bulletin board” for rollup data, and the availability of this data is paramount.<\/span>5<\/span><\/p>\n\n- For <\/span>Optimistic Rollups<\/b>, the security model relies on a challenge period during which any observer can submit a fraud proof if they detect an invalid state transition in the rollup’s batch.<\/span>15<\/span> Generating this fraud proof requires access to the transaction data posted to the L1. If a malicious rollup sequencer posts a fraudulent state commitment but withholds the corresponding transaction data, the challenge mechanism becomes inert. No one can prove the fraud, allowing the sequencer to potentially steal user funds.<\/span>2<\/span> This is not merely a verification failure; it is a catastrophic security failure.<\/span><\/li>\n
- For <\/span>Zero-Knowledge (ZK) Rollups<\/b>, which use validity proofs to guarantee the correctness of off-chain execution, data availability is still crucial for liveness and user self-sovereignty.<\/span>2<\/span> While the validity proof ensures the state transition is correct, users still need the underlying transaction data to reconstruct the rollup’s state and prove ownership of their assets. Without data availability, users cannot independently generate the Merkle proofs needed to withdraw their funds, effectively trapping them in the L2 system and reintroducing a dependency on the centralized sequencer.<\/span>15<\/span><\/li>\n<\/ul>\n
The critical importance of DA for rollups is reflected in its cost; data-posting fees on the L1 constitute the vast majority\u2014often cited as over 95%\u2014of a rollup’s operational expenses.<\/span>18<\/span> This high cost has driven an architectural paradigm shift towards <\/span>modular blockchains<\/b>. This approach unbundles the core functions of a blockchain, creating specialized layers for execution, settlement, and data availability.<\/span>11<\/span> This has led to the emergence of dedicated <\/span>Data Availability Layers (DALs)<\/b>, such as Celestia, which are designed specifically to provide a highly scalable and cost-effective solution for rollups to publish their transaction data.<\/span>1<\/span><\/p>\nThis unbundling represents a significant evolution in blockchain architecture, creating a new, competitive market for what can be termed “verifiable bandwidth.” Initially, rollups were forced to use expensive and inefficient mechanisms like Ethereum’s CALLDATA for data availability, treating the L1 as a monolithic provider of all services.<\/span>2<\/span> The prohibitive cost created a market opportunity for specialized solutions.<\/span>5<\/span> Projects like Celestia, and Ethereum’s own future with Danksharding, are not merely offering cheaper storage; they are offering a new commodity: data throughput with a cryptographic guarantee of <\/span>verifiability<\/span><\/i> by light clients. This decouples the security of data availability from a specific execution environment, fostering a modular stack where a rollup can choose its execution layer, settlement layer, and data availability layer independently. This fosters competition based on cost, security, and performance, but also introduces new complexities in cross-layer security assumptions.<\/span>20<\/span> The core product is no longer just “blockspace,” but “secure, verifiable data space.”<\/span><\/p>\nThe same principles apply to <\/span>sharded blockchains<\/b>. In a sharded architecture, the blockchain is split into multiple parallel chains (shards) to increase throughput.<\/span>3<\/span> No single node is expected to validate all shards; instead, nodes typically run a full node for one or a few shards and act as light clients for the others. The security of this system depends on the ability of any node to challenge an invalid block on any shard by generating a fraud proof. This, once again, is entirely contingent on the guaranteed availability of every shard’s data.<\/span>3<\/span><\/p>\n <\/p>\n
Part II: Core Mechanics of Data Availability Sampling<\/b><\/h2>\n
<\/p>\n
To solve the Data Availability problem for light clients without forcing them to download entire blocks, a novel technique known as Data Availability Sampling (DAS) was developed. DAS leverages a combination of data redundancy through erasure coding and probabilistic verification through random sampling. This approach fundamentally alters the security model, enabling resource-constrained nodes to achieve extremely high confidence in a block’s data availability by downloading only a few kilobytes of data.<\/span><\/p>\n <\/p>\n
2.1. The Principle of Probabilistic Verification<\/b><\/h3>\n
<\/p>\n
Data Availability Sampling is a mechanism that allows light clients to verify that all data for a block has been published to the network with a high degree of probability, without downloading the entire dataset.<\/span>4<\/span> The core process is straightforward: a light node conducts multiple rounds of random sampling, requesting small, randomly selected portions of the block’s data from the network.<\/span>4<\/span><\/p>\nEach time a requested sample is successfully retrieved and verified, the light node’s confidence that the complete dataset is available increases.<\/span>4<\/span> The logic behind this is statistical. As will be detailed, erasure coding forces a malicious block producer to withhold a large fraction of the block’s data (e.g., over 50%) to make it unrecoverable. Withholding such a large portion of the data makes it statistically very likely that at least one of a small number of random sample requests will fail.<\/span>22<\/span><\/p>\nIf a light node successfully completes a predetermined number of sampling queries\u2014for example, 30\u2014it can reach a statistical confidence level (e.g., 99.9999999%) that the data is available.<\/span>15<\/span> At this point, it considers the block’s data to be available and accepts the corresponding header.<\/span>4<\/span> This statistical leverage is the foundation of DAS, providing a scalable and secure verification method for clients that cannot afford to download and process every transaction.<\/span>10<\/span><\/p>\nThe combination of erasure coding and random sampling creates a powerful asymmetric security model that heavily favors the defender (the light client) over the attacker (the malicious block producer). To achieve their goal of making data unrecoverable, an attacker using a standard 1-to-2 erasure code must withhold more than 50% of the encoded data chunks.<\/span>15<\/span> The defender’s goal is simply to detect this withholding. The probability of any single random sample request landing in the available portion of the data (less than 50%) is less than 0.5. For s independent samples, the probability of the attacker successfully fooling the defender\u2014meaning all s samples are successfully retrieved\u2014is less than $0.5^s$. This probability decreases exponentially with each additional sample.<\/span>15<\/span> For just 15 samples, the chance of being fooled is less than 1 in 32,000. For 30 samples, it is less than one in a billion. This means the attacker must expend a massive effort (withholding more than half of a potentially multi-megabyte block), which is probabilistically trivial to detect with a minuscule effort from the light client (downloading a few tiny, kilobyte-sized samples). This asymmetry renders data withholding attacks economically and practically infeasible, provided a sufficient number of light clients are actively sampling the network.<\/span><\/p>\n <\/p>\n
2.2. Erasure Coding for Data Redundancy: Reed-Solomon Codes<\/b><\/h3>\n
<\/p>\n
The statistical power of DAS is entirely dependent on the properties of <\/span>erasure coding<\/b>, a technique used to add redundancy to data so that it can be recovered even if parts of it are lost.<\/span>14<\/span> The most common type of erasure code used in this context is the <\/span>Reed-Solomon (RS) code<\/b>.<\/span><\/p>\nThe mathematical foundation of RS codes lies in the properties of polynomials. The process begins by taking the original block data and splitting it into $k$ chunks. These $k$ chunks are then used to define a unique polynomial, $P(x)$, of degree less than $k$. This can be done by treating the data chunks as the coefficients of the polynomial or, more commonly, by treating them as evaluations of the polynomial at specific points (e.g., $P(0) = \\text{chunk}_0, P(1) = \\text{chunk}_1, \\dots, P(k-1) = \\text{chunk}_{k-1}$).<\/span>14<\/span><\/p>\nThe <\/span>encoding<\/b> process involves extending this data by evaluating the polynomial $P(x)$ at additional points. For example, the polynomial can be evaluated at $n$ distinct points, where $n > k$, to create an extended set of $n$ data chunks. A common configuration is to set $n = 2k$, effectively doubling the size of the original data.<\/span>22<\/span> These additional chunks are often referred to as “parity data”.<\/span>22<\/span><\/p>\nThe critical property of polynomials that underpins RS codes is that a unique polynomial of degree < k can be fully reconstructed from any $k$ of its evaluation points.<\/span>23<\/span> This means that to recover the original $k$ data chunks, a node only needs to successfully download <\/span>any<\/span><\/i> $k$ chunks from the extended set of $n$ chunks.<\/span><\/p>\nThis has a profound security implication for DAS. To launch a successful data withholding attack and make the original data unrecoverable, a malicious actor must prevent honest nodes from gathering at least $k$ chunks. This requires the attacker to withhold more than $n-k$ chunks. In the common $n=2k$ scenario, the attacker must withhold more than $k$ chunks\u2014that is, more than 50% of the extended data.<\/span>15<\/span> This dramatically raises the difficulty of an attack compared to a non-erasure-coded system, where withholding even a single chunk would make the data incomplete.<\/span><\/p>\n <\/p>\n
2.3. The 2D Reed-Solomon Encoding Scheme<\/b><\/h3>\n
<\/p>\n
While a one-dimensional (1D) RS code provides the necessary redundancy for DAS, a more sophisticated construction known as the <\/span>2D Reed-Solomon encoding scheme<\/b> offers significant advantages, particularly for the generation of fraud proofs. This scheme, notably implemented by Celestia, organizes the data in a two-dimensional matrix.<\/span>25<\/span><\/p>\nThe construction process is as follows:<\/span><\/p>\n\n- The original $k^2$ data chunks are arranged into a $k \\times k$ matrix.<\/span><\/li>\n
- 1D RS encoding is applied to each of the $k$ rows, extending them to $2k$ chunks each. This results in a $k \\times 2k$ matrix.<\/span><\/li>\n
- 1D RS encoding is then applied to each of the $2k$ columns of this intermediate matrix, extending them to $2k$ chunks each.<\/span><\/li>\n
- The final result is a $2k \\times 2k$ extended matrix containing the original data and the newly generated parity data.<\/span>25<\/span><\/li>\n<\/ol>\n
To commit to this data structure in the block header, a cryptographic commitment scheme is used. Specifically, a separate Merkle root is computed for the data in each of the $2k$ rows and each of the $2k$ columns. The final block data commitment, included in the block header, is the Merkle root of these $4k$ individual row and column roots.<\/span>25<\/span><\/p>\nThe primary motivation for this more complex 2D scheme is the generation of <\/span>efficient fraud proofs for incorrect encoding<\/b>. A DAS system must defend against not only data withholding but also against a malicious producer who correctly publishes all data chunks but has generated the parity data incorrectly. An honest node that downloads enough chunks could detect this, but it needs a way to prove the fraud to light clients.<\/span><\/p>\nThe choice of a 2D encoding scheme is not a minor optimization but a critical design decision that directly enables the practical viability of a fraud-proof-based DAS system by managing the size of these proofs. A DAS system requires a mechanism to handle maliciously <\/span>encoded<\/span><\/i> data, not just withheld data, and this is accomplished via fraud proofs.<\/span>25<\/span> Light clients are, by definition, resource-constrained. A fraud proof that is as large as the original data block itself would defeat the purpose of being a light client, as they would be forced to download a massive proof.<\/span><\/p>\nIn a 1D RS scheme applied to $k^2$ data chunks, proving that the encoding was done incorrectly would require providing all $k^2$ original data chunks so that a verifier could re-compute the encoding and spot the error. This results in a fraud proof of size $O(k^2)$.<\/span>25<\/span> In contrast, with the 2D scheme, an incorrectly encoded row or column can be proven fraudulent by providing only the $k$ original data chunks for that <\/span>single<\/span><\/i> row or column. The verifier can then re-encode just that one dimension and show that the resulting parity data does not match what was published. This reduces the fraud proof size to $O(k)$, a quadratic improvement.<\/span>25<\/span> For a block with original data arranged in a 128×128 matrix, this is the difference between a proof of roughly 2 MB and one of only 16 KB. Without the 2D scheme, a security model based on fraud proofs for incorrect encoding would be impractical for the very clients it is designed to protect, revealing a deep causal link between the abstract mathematical structure of the erasure code and the concrete economic feasibility of the light client security model.<\/span><\/p>\n <\/p>\n
Part III: Security and Verification Frameworks<\/b><\/h2>\n
<\/p>\n
While erasure coding and random sampling form the mechanical core of DAS, they are insufficient on their own. A complete and secure system requires additional cryptographic and protocol-level frameworks to enforce the rules and ensure the integrity of the entire process. These frameworks primarily consist of fraud proofs, which act as the enforcement layer to penalize malicious behavior, and polynomial commitment schemes, which provide a robust method for verifying the authenticity of individual data samples. The interplay between these components defines the overall security model of a given DAS implementation.<\/span><\/p>\n <\/p>\n
3.1. Fraud Proofs: The Enforcement Layer<\/b><\/h3>\n
<\/p>\n
Fraud proofs are a necessary complement to any data availability system that relies on optimistic assumptions.<\/span>7<\/span> DAS provides a powerful probabilistic guarantee that the data required for verification is <\/span>available<\/span><\/i> to be downloaded by full nodes. However, DAS itself does not say anything about the <\/span>validity<\/span><\/i> of the transactions within that data. Fraud proofs are the mechanism by which full nodes, after downloading and executing the available data, can alert light clients to any invalidity they discover.<\/span>7<\/span> This combination allows the system to eliminate the honest-majority assumption for block validity, replacing it with a much weaker assumption that at least one honest full node is online to monitor the chain and generate proofs when necessary.<\/span>7<\/span><\/p>\nThere are two primary types of fraud proofs relevant to DAS systems:<\/span><\/p>\n\n- Invalid State Transition Proofs<\/b>: This is the traditional form of fraud proof, particularly relevant for Optimistic Rollups. A full node executes the batch of transactions published by the rollup sequencer and finds that the resulting state root differs from the one committed by the sequencer. The proof demonstrates this discrepancy, allowing the invalid batch to be reverted on the L1.<\/span>15<\/span> The generation of this proof is entirely dependent on the availability of the transaction data.<\/span><\/li>\n
- Incorrect Erasure Coding Proofs (Codec Fraud Proofs)<\/b>: This type of proof is specific to the integrity of the DAS process itself. It does not concern the validity of the transactions but rather proves that the block producer incorrectly generated the extended parity data from the original data. As enabled by the 2D Reed-Solomon encoding scheme, this proof is exceptionally efficient.<\/span>25<\/span> A light client that receives a valid codec fraud proof can immediately reject the block as fraudulent without needing to download or understand the transactions themselves, as it proves a clear violation of the protocol rules.<\/span>26<\/span><\/li>\n<\/ol>\n
The lifecycle of a codec fraud proof provides a clear example of this enforcement mechanism in action. The process, based on the scheme detailed by Al-Bassam et al., unfolds as follows <\/span>26<\/span>:<\/span><\/p>\n\n- Detection<\/b>: A full node downloads a sufficient number of shares from the extended $2k \\times 2k$ matrix to reconstruct a full row or column. It then computes the Merkle root of this reconstructed data and discovers that it does not match the corresponding row or column root that was committed to in the block header’s main dataRoot.<\/span><\/li>\n
- Generation<\/b>: The full node constructs the fraud proof. This proof is a data package containing several key components: the hash of the block in question, the incorrect row\/column root from the header, a Merkle proof showing that this incorrect root is part of the overall dataRoot, and at least $k$ original shares from that row\/column, each with its own Merkle proof verifying its position in the overall data matrix.<\/span>26<\/span><\/li>\n
- Verification<\/b>: A light client receives this proof and performs a series of checks. It first verifies that the block hash corresponds to a header it knows. It then validates all the Merkle proofs to ensure the provided shares and the incorrect row\/column root are authentic parts of the block’s commitment. Finally, it performs the crucial step: it uses the $k$ provided shares to reconstruct the entire row or column, computes the Merkle root of this locally reconstructed data, and verifies that this new root <\/span>does not match<\/b> the root that was committed to in the block header. This mismatch is an irrefutable, self-contained proof of malicious behavior by the block producer, prompting the light client to permanently reject the block.<\/span>26<\/span><\/li>\n<\/ol>\n
<\/p>\n
3.2. Polynomial Commitments: Ensuring Sample Integrity<\/b><\/h3>\n
<\/p>\n
When a light client performs a random sample, it receives a small chunk of data and a proof (e.g., a Merkle proof) that this chunk belongs to the block. While Merkle proofs are effective, a more powerful cryptographic primitive known as a <\/span>polynomial commitment scheme (PCS)<\/b> can offer stronger guarantees and a more integrated security model. The most prominent PCS in this context is the <\/span>Kate-Zaverucha-Goldberg (KZG) commitment scheme<\/b>
The verifier’s dilemma arises when a malicious block producer engages in a <\/span>data withholding attack<\/b>. In this scenario, the producer broadcasts a valid-looking block header but deliberately withholds some or all of the corresponding transaction data.<\/span>4<\/span> Without this data, full nodes cannot re-execute the transactions to check for invalid state changes, such as the creation of currency out of thin air or the illegitimate transfer of assets.<\/span>7<\/span> Consequently, they are unable to generate fraud proofs to alert the rest of the network of the malicious activity.<\/span>3<\/span> The “don’t trust, verify” principle breaks down because verification is rendered impossible. Such an attack can have severe consequences, ranging from halting the chain to enabling the theft of funds, with the severity depending on the specific blockchain architecture.<\/span>4<\/span><\/p>\n This dilemma creates a stark divide between the security guarantees available to different types of network participants. <\/span>Full nodes<\/b>, by definition, download and verify every transaction in every block. They possess an inherent guarantee of data availability; if they cannot download a block’s data, they simply reject the block and do not add it to their local view of the chain.<\/span>4<\/span> This resource-intensive process makes them the ultimate arbiters of network validity.<\/span><\/p>\n In contrast, <\/span>light clients<\/b> (or light nodes) are designed for resource-constrained environments. They download only block headers, which are significantly smaller than full blocks, and rely on indirect methods to ascertain the chain’s validity.<\/span>8<\/span> Traditionally, this has meant operating under an “honest majority assumption”\u2014trusting that the consensus of block producers, who created the chain of headers, would not approve a block containing invalid transactions.<\/span>7<\/span> This assumption creates a significant security vulnerability. If a majority of block producers were to collude, they could create a block with invalid transactions, and traditional light clients would blindly accept the corresponding header as valid, as they lack the data to check for themselves.<\/span>7<\/span> This establishes the critical need for a new mechanism that can empower light clients with stronger, trust-minimized security guarantees, allowing them to verify data availability without shouldering the prohibitive costs of running a full node.<\/span>8<\/span><\/p>\n <\/p>\n <\/p>\n The Data Availability problem is inextricably linked to the <\/span>scalability trilemma<\/b>, which posits that it is difficult for a blockchain to simultaneously achieve decentralization, security, and scalability. In a traditional monolithic blockchain architecture, like that of Bitcoin or early Ethereum, all core functions\u2014execution, consensus, and data availability\u2014are handled by a single layer of nodes.<\/span>11<\/span> The most straightforward way to increase scalability (i.e., transaction throughput) in such a system is to increase the block size. However, this directly increases the hardware, storage, and bandwidth requirements for running a full node.<\/span>1<\/span> As these requirements rise, fewer participants can afford to run full nodes, leading to a centralization of network validation and a potential compromise of security and decentralization.<\/span>3<\/span> This trade-off places a practical limit on the data throughput of monolithic chains.<\/span><\/p>\n The nature of the Data Availability problem fundamentally transforms when moving from monolithic to modular architectures. What begins as a challenge of storage and bandwidth evolves into a critical security and liveness vulnerability. In a simple monolithic chain, the consequence of data unavailability is straightforward: a node that cannot download the block data rejects it.<\/span>4<\/span> The problem appears to be primarily one of economic and performance costs associated with bandwidth and storage.<\/span>1<\/span><\/p>\n However, the advent of <\/span>Layer 2 (L2) rollups<\/b> as a primary scaling solution has placed the DA problem at the forefront. Rollups function by executing transactions off-chain and then posting batches of transaction data to a Layer 1 (L1) chain for security and settlement.<\/span>2<\/span> This makes the L1 a “bulletin board” for rollup data, and the availability of this data is paramount.<\/span>5<\/span><\/p>\n The critical importance of DA for rollups is reflected in its cost; data-posting fees on the L1 constitute the vast majority\u2014often cited as over 95%\u2014of a rollup’s operational expenses.<\/span>18<\/span> This high cost has driven an architectural paradigm shift towards <\/span>modular blockchains<\/b>. This approach unbundles the core functions of a blockchain, creating specialized layers for execution, settlement, and data availability.<\/span>11<\/span> This has led to the emergence of dedicated <\/span>Data Availability Layers (DALs)<\/b>, such as Celestia, which are designed specifically to provide a highly scalable and cost-effective solution for rollups to publish their transaction data.<\/span>1<\/span><\/p>\n This unbundling represents a significant evolution in blockchain architecture, creating a new, competitive market for what can be termed “verifiable bandwidth.” Initially, rollups were forced to use expensive and inefficient mechanisms like Ethereum’s CALLDATA for data availability, treating the L1 as a monolithic provider of all services.<\/span>2<\/span> The prohibitive cost created a market opportunity for specialized solutions.<\/span>5<\/span> Projects like Celestia, and Ethereum’s own future with Danksharding, are not merely offering cheaper storage; they are offering a new commodity: data throughput with a cryptographic guarantee of <\/span>verifiability<\/span><\/i> by light clients. This decouples the security of data availability from a specific execution environment, fostering a modular stack where a rollup can choose its execution layer, settlement layer, and data availability layer independently. This fosters competition based on cost, security, and performance, but also introduces new complexities in cross-layer security assumptions.<\/span>20<\/span> The core product is no longer just “blockspace,” but “secure, verifiable data space.”<\/span><\/p>\n The same principles apply to <\/span>sharded blockchains<\/b>. In a sharded architecture, the blockchain is split into multiple parallel chains (shards) to increase throughput.<\/span>3<\/span> No single node is expected to validate all shards; instead, nodes typically run a full node for one or a few shards and act as light clients for the others. The security of this system depends on the ability of any node to challenge an invalid block on any shard by generating a fraud proof. This, once again, is entirely contingent on the guaranteed availability of every shard’s data.<\/span>3<\/span><\/p>\n <\/p>\n <\/p>\n To solve the Data Availability problem for light clients without forcing them to download entire blocks, a novel technique known as Data Availability Sampling (DAS) was developed. DAS leverages a combination of data redundancy through erasure coding and probabilistic verification through random sampling. This approach fundamentally alters the security model, enabling resource-constrained nodes to achieve extremely high confidence in a block’s data availability by downloading only a few kilobytes of data.<\/span><\/p>\n <\/p>\n <\/p>\n Data Availability Sampling is a mechanism that allows light clients to verify that all data for a block has been published to the network with a high degree of probability, without downloading the entire dataset.<\/span>4<\/span> The core process is straightforward: a light node conducts multiple rounds of random sampling, requesting small, randomly selected portions of the block’s data from the network.<\/span>4<\/span><\/p>\n Each time a requested sample is successfully retrieved and verified, the light node’s confidence that the complete dataset is available increases.<\/span>4<\/span> The logic behind this is statistical. As will be detailed, erasure coding forces a malicious block producer to withhold a large fraction of the block’s data (e.g., over 50%) to make it unrecoverable. Withholding such a large portion of the data makes it statistically very likely that at least one of a small number of random sample requests will fail.<\/span>22<\/span><\/p>\n If a light node successfully completes a predetermined number of sampling queries\u2014for example, 30\u2014it can reach a statistical confidence level (e.g., 99.9999999%) that the data is available.<\/span>15<\/span> At this point, it considers the block’s data to be available and accepts the corresponding header.<\/span>4<\/span> This statistical leverage is the foundation of DAS, providing a scalable and secure verification method for clients that cannot afford to download and process every transaction.<\/span>10<\/span><\/p>\n The combination of erasure coding and random sampling creates a powerful asymmetric security model that heavily favors the defender (the light client) over the attacker (the malicious block producer). To achieve their goal of making data unrecoverable, an attacker using a standard 1-to-2 erasure code must withhold more than 50% of the encoded data chunks.<\/span>15<\/span> The defender’s goal is simply to detect this withholding. The probability of any single random sample request landing in the available portion of the data (less than 50%) is less than 0.5. For s independent samples, the probability of the attacker successfully fooling the defender\u2014meaning all s samples are successfully retrieved\u2014is less than $0.5^s$. This probability decreases exponentially with each additional sample.<\/span>15<\/span> For just 15 samples, the chance of being fooled is less than 1 in 32,000. For 30 samples, it is less than one in a billion. This means the attacker must expend a massive effort (withholding more than half of a potentially multi-megabyte block), which is probabilistically trivial to detect with a minuscule effort from the light client (downloading a few tiny, kilobyte-sized samples). This asymmetry renders data withholding attacks economically and practically infeasible, provided a sufficient number of light clients are actively sampling the network.<\/span><\/p>\n <\/p>\n <\/p>\n The statistical power of DAS is entirely dependent on the properties of <\/span>erasure coding<\/b>, a technique used to add redundancy to data so that it can be recovered even if parts of it are lost.<\/span>14<\/span> The most common type of erasure code used in this context is the <\/span>Reed-Solomon (RS) code<\/b>.<\/span><\/p>\n The mathematical foundation of RS codes lies in the properties of polynomials. The process begins by taking the original block data and splitting it into $k$ chunks. These $k$ chunks are then used to define a unique polynomial, $P(x)$, of degree less than $k$. This can be done by treating the data chunks as the coefficients of the polynomial or, more commonly, by treating them as evaluations of the polynomial at specific points (e.g., $P(0) = \\text{chunk}_0, P(1) = \\text{chunk}_1, \\dots, P(k-1) = \\text{chunk}_{k-1}$).<\/span>14<\/span><\/p>\n The <\/span>encoding<\/b> process involves extending this data by evaluating the polynomial $P(x)$ at additional points. For example, the polynomial can be evaluated at $n$ distinct points, where $n > k$, to create an extended set of $n$ data chunks. A common configuration is to set $n = 2k$, effectively doubling the size of the original data.<\/span>22<\/span> These additional chunks are often referred to as “parity data”.<\/span>22<\/span><\/p>\n The critical property of polynomials that underpins RS codes is that a unique polynomial of degree < k can be fully reconstructed from any $k$ of its evaluation points.<\/span>23<\/span> This means that to recover the original $k$ data chunks, a node only needs to successfully download <\/span>any<\/span><\/i> $k$ chunks from the extended set of $n$ chunks.<\/span><\/p>\n This has a profound security implication for DAS. To launch a successful data withholding attack and make the original data unrecoverable, a malicious actor must prevent honest nodes from gathering at least $k$ chunks. This requires the attacker to withhold more than $n-k$ chunks. In the common $n=2k$ scenario, the attacker must withhold more than $k$ chunks\u2014that is, more than 50% of the extended data.<\/span>15<\/span> This dramatically raises the difficulty of an attack compared to a non-erasure-coded system, where withholding even a single chunk would make the data incomplete.<\/span><\/p>\n <\/p>\n <\/p>\n While a one-dimensional (1D) RS code provides the necessary redundancy for DAS, a more sophisticated construction known as the <\/span>2D Reed-Solomon encoding scheme<\/b> offers significant advantages, particularly for the generation of fraud proofs. This scheme, notably implemented by Celestia, organizes the data in a two-dimensional matrix.<\/span>25<\/span><\/p>\n The construction process is as follows:<\/span><\/p>\n To commit to this data structure in the block header, a cryptographic commitment scheme is used. Specifically, a separate Merkle root is computed for the data in each of the $2k$ rows and each of the $2k$ columns. The final block data commitment, included in the block header, is the Merkle root of these $4k$ individual row and column roots.<\/span>25<\/span><\/p>\n The primary motivation for this more complex 2D scheme is the generation of <\/span>efficient fraud proofs for incorrect encoding<\/b>. A DAS system must defend against not only data withholding but also against a malicious producer who correctly publishes all data chunks but has generated the parity data incorrectly. An honest node that downloads enough chunks could detect this, but it needs a way to prove the fraud to light clients.<\/span><\/p>\n The choice of a 2D encoding scheme is not a minor optimization but a critical design decision that directly enables the practical viability of a fraud-proof-based DAS system by managing the size of these proofs. A DAS system requires a mechanism to handle maliciously <\/span>encoded<\/span><\/i> data, not just withheld data, and this is accomplished via fraud proofs.<\/span>25<\/span> Light clients are, by definition, resource-constrained. A fraud proof that is as large as the original data block itself would defeat the purpose of being a light client, as they would be forced to download a massive proof.<\/span><\/p>\n In a 1D RS scheme applied to $k^2$ data chunks, proving that the encoding was done incorrectly would require providing all $k^2$ original data chunks so that a verifier could re-compute the encoding and spot the error. This results in a fraud proof of size $O(k^2)$.<\/span>25<\/span> In contrast, with the 2D scheme, an incorrectly encoded row or column can be proven fraudulent by providing only the $k$ original data chunks for that <\/span>single<\/span><\/i> row or column. The verifier can then re-encode just that one dimension and show that the resulting parity data does not match what was published. This reduces the fraud proof size to $O(k)$, a quadratic improvement.<\/span>25<\/span> For a block with original data arranged in a 128×128 matrix, this is the difference between a proof of roughly 2 MB and one of only 16 KB. Without the 2D scheme, a security model based on fraud proofs for incorrect encoding would be impractical for the very clients it is designed to protect, revealing a deep causal link between the abstract mathematical structure of the erasure code and the concrete economic feasibility of the light client security model.<\/span><\/p>\n <\/p>\n <\/p>\n While erasure coding and random sampling form the mechanical core of DAS, they are insufficient on their own. A complete and secure system requires additional cryptographic and protocol-level frameworks to enforce the rules and ensure the integrity of the entire process. These frameworks primarily consist of fraud proofs, which act as the enforcement layer to penalize malicious behavior, and polynomial commitment schemes, which provide a robust method for verifying the authenticity of individual data samples. The interplay between these components defines the overall security model of a given DAS implementation.<\/span><\/p>\n <\/p>\n <\/p>\n Fraud proofs are a necessary complement to any data availability system that relies on optimistic assumptions.<\/span>7<\/span> DAS provides a powerful probabilistic guarantee that the data required for verification is <\/span>available<\/span><\/i> to be downloaded by full nodes. However, DAS itself does not say anything about the <\/span>validity<\/span><\/i> of the transactions within that data. Fraud proofs are the mechanism by which full nodes, after downloading and executing the available data, can alert light clients to any invalidity they discover.<\/span>7<\/span> This combination allows the system to eliminate the honest-majority assumption for block validity, replacing it with a much weaker assumption that at least one honest full node is online to monitor the chain and generate proofs when necessary.<\/span>7<\/span><\/p>\n There are two primary types of fraud proofs relevant to DAS systems:<\/span><\/p>\n The lifecycle of a codec fraud proof provides a clear example of this enforcement mechanism in action. The process, based on the scheme detailed by Al-Bassam et al., unfolds as follows <\/span>26<\/span>:<\/span><\/p>\n <\/p>\n <\/p>\n When a light client performs a random sample, it receives a small chunk of data and a proof (e.g., a Merkle proof) that this chunk belongs to the block. While Merkle proofs are effective, a more powerful cryptographic primitive known as a <\/span>polynomial commitment scheme (PCS)<\/b> can offer stronger guarantees and a more integrated security model. The most prominent PCS in this context is the <\/span>Kate-Zaverucha-Goldberg (KZG) commitment scheme<\/b>1.2. Scaling Bottlenecks in Monolithic and Modular Architectures<\/b><\/h3>\n
\n
Part II: Core Mechanics of Data Availability Sampling<\/b><\/h2>\n
2.1. The Principle of Probabilistic Verification<\/b><\/h3>\n
2.2. Erasure Coding for Data Redundancy: Reed-Solomon Codes<\/b><\/h3>\n
2.3. The 2D Reed-Solomon Encoding Scheme<\/b><\/h3>\n
\n
Part III: Security and Verification Frameworks<\/b><\/h2>\n
3.1. Fraud Proofs: The Enforcement Layer<\/b><\/h3>\n
\n
\n
3.2. Polynomial Commitments: Ensuring Sample Integrity<\/b><\/h3>\n