The trajectory of blockchain development over the last decade has been defined by a relentless struggle against the Scalability Trilemma, a conceptual framework positing that a decentralized network can simultaneously maximize only two of three properties: decentralization, security, and scalability.<\/span>1<\/span> As adoption of networks like Ethereum grew, the limitations of the monolithic architecture\u2014where a single chain handles execution, settlement, consensus, and data availability\u2014became painfully apparent. In this legacy model, every full node must download, verify, and store every transaction. This redundancy, while ensuring robust censorship resistance and security, imposes a severe ceiling on throughput. If block sizes are increased to accommodate global-scale transaction volumes, the hardware requirements for running a node skyrocket, inevitably centralizing the network into the hands of a few data center operators and compromising the very decentralization that gives the network its value.<\/span>3<\/span><\/p>\n The industry’s response has been a paradigm shift toward modularity. The modular blockchain thesis advocates for unbundling the core functions of a blockchain into specialized layers. Execution is offloaded to high-throughput rollups (Layer 2s), which process transactions off-chain and post succinct proofs to the main chain. However, this shift exposed a new, more fundamental bottleneck: Data Availability (DA).<\/span>2<\/span><\/p>\n The Data Availability problem is distinct from the problem of long-term data storage. Storage is concerned with retrievability of historical data (e.g., “What was the state of the ledger five years ago?”). Data Availability, by contrast, is a real-time publishing guarantee that answers a critical question: “Has the data required to verify the latest block been published to the network right now?”.<\/span>5<\/span><\/p>\n In the context of Layer 2 rollups, this guarantee is existential. Rollups achieve scalability by performing computation off-chain and submitting a cryptographic summary (a state root) to the Layer 1 (L1).<\/span><\/p>\n Thus, the security of any rollup is strictly bounded by the capacity of its underlying Data Availability layer. Prior to recent upgrades, Ethereum rollups were forced to use calldata\u2014a storage space in the Ethereum Virtual Machine (EVM) designed for function arguments\u2014to publish transaction batches. This method was inefficient and prohibitively expensive, with over 90% of rollup transaction fees often attributed to the cost of posting data to Ethereum.<\/span>4<\/span> This economic reality created a “data tax” that prevented decentralized applications from achieving the cost structures necessary for mass adoption.<\/span><\/p>\n To solve the DA bottleneck, blockchain architects faced a paradox: how can the network verify that a massive block of data (potentially gigabytes in size) is available without every node downloading the entire block? The solution lies in shifting the verification model from <\/span>replication<\/span><\/i> (everyone downloads everything) to <\/span>sampling<\/span><\/i> (everyone downloads a tiny piece).<\/span><\/p>\n Data Availability Sampling (DAS) allows nodes to verify data availability with high probabilistic certainty by downloading random chunks of the block.<\/span>9<\/span> However, simple sampling is insufficient; a malicious actor could hide a single critical transaction (a “1-of-N” attack), invalidating the entire block while evading detection by random sampling. To mitigate this, the data must be “erasure coded”\u2014a technique that extends the dataset with redundant parity data, such that the entire dataset can be reconstructed from a subset of the chunks.<\/span>5<\/span><\/p>\n If a block is erasure-coded such that any 50% of the chunks can reconstruct the whole, an attacker must withhold at least 50% of the data to make the block unavailable. The probability of a light node randomly sampling chunks and <\/span>not<\/span><\/i> detecting this massive withholding approaches zero exponentially with each sample taken.<\/span><\/p>\n The implementation of DAS requires a cryptographic commitment scheme to ensure that the erasure coding is performed correctly\u2014that the extended data is mathematically consistent with the original data. While Merkle trees have served as the industry standard for commitments, they are inefficient for this specific purpose due to logarithmic proof sizes and the complexity of proving erasure coding correctness. The industry has thus coalesced around a more advanced primitive: Kate-Zaverucha-Goldberg (KZG) commitments.<\/span>12<\/span><\/p>\n KZG commitments, introduced by Aniket Kate, Gregory M. Zaverucha, and Ian Goldberg in 2010, are a class of polynomial commitment schemes that offer properties uniquely suited to the constraints of blockchain scalability: constant-sized proofs and homomorphic properties.<\/span>12<\/span> Understanding KZG requires a deep dive into the underlying algebra of elliptic curves and polynomials.<\/span><\/p>\n At the core of the KZG scheme is the representation of data as a polynomial. Any vector of data $D = (d_0, d_1,…, d_{n-1})$ can be transformed into a polynomial $P(x)$ of degree $n-1$. This is typically achieved using Lagrange interpolation, constructing a polynomial that passes through specific points. For efficiency, these points are often chosen to be the roots of unity $\\omega$ in a finite field, such that $P(\\omega^i) = d_i$.<\/span>13<\/span><\/p>\n Once the data is encoded as a polynomial $P(x)$, the problem of proving data integrity becomes a problem of proving properties about the polynomial. The “magic” of KZG is that it allows a prover to commit to this entire polynomial using a single elliptic curve point (typically 48 bytes), regardless of the polynomial’s degree (i.e., the size of the dataset).<\/span><\/p>\n KZG commitments rely on pairing-friendly elliptic curves, such as BLS12-381. A pairing is a bilinear map $e: \\mathbb{G}_1 \\times \\mathbb{G}_2 \\rightarrow \\mathbb{G}_T$, where $\\mathbb{G}_1$ and $\\mathbb{G}_2$ are additive groups of points on an elliptic curve, and $\\mathbb{G}_T$ is a multiplicative target group. The critical property of this map is bilinearity:<\/span><\/p>\n <\/p>\n $$e(a \\cdot P, b \\cdot Q) = e(P, Q)^{ab}$$<\/span><\/p>\n <\/p>\n This property allows the verifier to perform multiplication in the exponent, which is essential for checking polynomial equations “in the encrypted domain” without knowing the secret parameters.12<\/span><\/p>\n Unlike Merkle trees, which use public hash functions, KZG requires a Structured Reference String (SRS). This SRS is generated via a “Trusted Setup” ceremony, often referred to as the “Powers of Tau.”<\/span><\/p>\n The setup involves generating a secret scalar $\\tau$ (tau) and computing a sequence of points:<\/span><\/p>\n <\/p>\n $$SRS = \\{ G \\cdot \\tau^0, G \\cdot \\tau^1, G \\cdot \\tau^2,…, G \\cdot \\tau^d \\}$$<\/span><\/p>\n <\/p>\n where $G$ is the generator of the group and $d$ is the maximum degree of the polynomials to be committed. Crucially, the value $\\tau$ must be destroyed immediately after the setup. If an attacker possesses $\\tau$, they can construct a polynomial $P'(x)$ such that $P'(\\tau) = P(\\tau)$, allowing them to forge commitments and proofs\u2014a catastrophic security failure known as “toxic waste”.17<\/span><\/p>\n To mitigate this risk, modern trusted setups utilize Multi-Party Computation (MPC). The secret is generated sequentially by thousands of participants. Participant 1 contributes randomness $s_1$, Participant 2 contributes $s_2$, and so on. The final secret is $\\tau = s_1 \\cdot s_2 \\cdot… \\cdot s_n$. For the setup to be secure, only <\/span>one<\/span><\/i> participant needs to be honest and destroy their contribution. The Ethereum EIP-4844 ceremony, for instance, involved over 140,000 contributions, making the probability of collusion statistically negligible.<\/span>18<\/span><\/p>\n The mechanics of the scheme operate in three stages:<\/span><\/p>\n To commit to a polynomial $P(x) = \\sum_{i=0}^{n} p_i x^i$, the prover computes a linear combination of the SRS elements:<\/span><\/p>\n <\/p>\n $$C = \\sum_{i=0}^{n} p_i (G \\cdot \\tau^i) = G \\cdot \\sum_{i=0}^{n} p_i \\tau^i = G \\cdot P(\\tau)$$<\/span><\/p>\n <\/p>\n The result $C$ is a single group element that binds the prover to the polynomial $P(x)$.12<\/span><\/p>\n To prove that the polynomial evaluates to $y$ at a specific point $z$ (i.e., $P(z) = y$), the prover utilizes the polynomial remainder theorem. If $P(z) = y$, then the polynomial $P(x) – y$ is divisible by $(x – z)$. The prover computes the quotient polynomial:<\/span><\/p>\n <\/p>\n $$Q(x) = \\frac{P(x) – y}{x – z}$$The proof (or witness) $\\pi$ is the commitment to this quotient polynomial:$$\\pi = G \\cdot Q(\\tau)$$<\/span><\/p>\n The verifier knows the commitment $C$, the point $z$, the value $y$, and the proof $\\pi$. They must check that the relationship $P(\\tau) – y = Q(\\tau)(\\tau – z)$ holds. Since they do not know $\\tau$, they use the pairing function:<\/span><\/p>\n <\/p>\n $$e(C – G \\cdot y, H) \\stackrel{?}{=} e(\\pi, H \\cdot \\tau – H \\cdot z)$$<\/span><\/p>\n <\/p>\n where $H$ is the generator of $\\mathbb{G}_2$. If the equality holds, the verifier is cryptographically convinced that $P(z) = y$.12<\/span><\/p>\n The superiority of KZG over Merkle trees in the context of Data Availability lies in succinctness and homomorphic properties.<\/span><\/p>\n The constant proof size is particularly critical for Data Availability Sampling (DAS). In a Merkle-based system, as the block size grows, the branches required to prove the inclusion of a sample grow, consuming valuable bandwidth. In a KZG-based system, the proof for any sample\u2014or even a batch of samples\u2014remains a single, tiny group element. This efficiency is the cornerstone of Ethereum’s Danksharding roadmap.<\/span>13<\/span><\/p>\n The theoretical advantages of KZG commitments were translated into practical reality with the implementation of EIP-4844, also known as Proto-Danksharding, included in the Dencun upgrade of March 2024. This upgrade marked the official beginning of Ethereum’s transition from a monolithic execution layer to a modular data settlement layer.<\/span>8<\/span><\/p>\n EIP-4844 introduced a new transaction type (Type 3) that carries “blobs” (Binary Large Objects). Unlike calldata, which is accessible to the EVM and stored permanently, blobs are ephemeral data chunks stored on the consensus layer (Beacon Chain) and are inaccessible to smart contracts. The EVM can only access a “versioned hash” of the blob’s KZG commitment.<\/span>13<\/span><\/p>\n Blob Specifications:<\/b><\/p>\n A critical economic innovation of EIP-4844 is the separation of the fee market. Historically, all Ethereum transactions competed for the same “gas,” causing L2 data costs to spike whenever there was high demand for NFT mints or DeFi swaps on L1. EIP-4844 introduces “Blob Gas,” a multidimensional fee market that operates independently of standard execution gas.<\/span><\/p>\n The price of blob gas adjusts dynamically based on supply and demand, targeting an average of 3 blobs per block. If usage exceeds this target, the price increases exponentially; if it falls below, the price decays. This mechanism ensures that rollups have a predictable and generally low-cost environment for data availability, insulated from the congestion of the execution layer. Research indicates that this mechanism reduced L2 data costs by over 90% immediately following implementation, commoditizing blockspace and driving the marginal cost of L2 transactions toward zero.<\/span>10<\/span><\/p>\n While the blob data itself is inaccessible to the EVM, rollups\u2014particularly ZK-rollups\u2014need a way to prove that specific data was included in a committed blob. To facilitate this, EIP-4844 includes a point_evaluation precompile. This precompile allows a smart contract to verify a KZG proof. A contract can provide a commitment $C$, a point $z$, a value $y$, and a proof $\\pi$, and the precompile will verify that $P(z) = y$ fundamentally linking the ephemeral data layer to the persistent execution layer.<\/span>13<\/span><\/p>\n Proto-Danksharding (EIP-4844) alleviated the immediate cost bottleneck but did not solve the fundamental scalability constraint: every validator must still download every blob to verify its availability. To scale from the current ~0.375 MB per block to the target of 16 MB\u201332 MB (Full Danksharding), the network must adopt Data Availability Sampling (DAS).<\/span><\/p>\n Full Danksharding envisions a network where no single node downloads the entire block. Instead, verification is a collective effort derived from the statistical probability of successful sampling.<\/span><\/p>\n To make this secure, the system utilizes <\/span>2D Erasure Coding<\/b>. The data in a block is arranged into a matrix.<\/span><\/p>\n This architecture fundamentally changes the relationship between bandwidth and throughput. In a monolithic chain, throughput is capped by the bandwidth of a single node. In a Danksharded chain, throughput scales with the <\/span>number<\/span><\/i> of nodes. As more nodes join the network and perform sampling, the total bandwidth capacity of the network increases, allowing for larger blocks and higher throughput.<\/span>8<\/span><\/p>\n Transitioning directly from Proto-Danksharding to Full Danksharding is a monumental engineering challenge involving complex 2D erasure coding schemes and massive P2P networking upgrades. The intermediate step, currently in development, is <\/span>PeerDAS (EIP-7594)<\/b>.<\/span><\/p>\n PeerDAS (Peer Data Availability Sampling) introduces the concept of distributed custody without the full complexity of the 2D matrix. In PeerDAS:<\/span><\/p>\n PeerDAS allows the network to safely increase the blob target from 3 to potentially 64 or higher, scaling throughput by an order of magnitude while maintaining the decentralization requirement that nodes can run on consumer hardware.<\/span>22<\/span><\/p>\n The primary bottleneck for Full Danksharding is not cryptography, but networking. Propagating 32 MB blocks every 12 seconds requires immense bandwidth.<\/span><\/p>\n These challenges are being addressed through optimizations in the libp2p layer and new sub-protocols designed specifically for high-volume data sharding.<\/span>22<\/span><\/p>\n The modular thesis has given rise to a competitive landscape of specialized Data Availability layers, each taking a distinct philosophical and technical approach to solving the DA problem. The three primary contenders\u2014Celestia, Avail, and EigenDA\u2014represent different trade-offs in the design space.<\/span><\/p>\n Celestia acts as a sovereign Layer 1 blockchain optimized exclusively for data availability and ordering.<\/span><\/p>\n Avail (formerly Polygon Avail) is a sovereign chain that prioritizes immediate cryptographic guarantees.<\/span><\/p>\n EigenDA is not a standalone blockchain but a set of smart contracts and a data availability committee (DAC) secured by Ethereum validators via EigenLayer.<\/span><\/p>\n1.1 defining the Data Availability Problem<\/b><\/h3>\n
\n
1.2 The Transition from Replication to Sampling<\/b><\/h3>\n
2. Mathematical Foundations of KZG Commitments<\/b><\/h2>\n
2.1 Polynomial Representation of Data<\/b><\/h3>\n
2.2 The Role of Elliptic Curve Pairings<\/b><\/h3>\n
2.3 The Trusted Setup: Powers of Tau<\/b><\/h3>\n
2.4 Commitment, Evaluation, and Verification<\/b><\/h3>\n
\n
\n
\n
2.5 Advantages Over Merkle Trees<\/b><\/h3>\n
\n\n
\n Feature<\/b><\/td>\n Merkle Trees<\/b><\/td>\n KZG Commitments<\/b><\/td>\n<\/tr>\n \n Proof Size<\/b><\/td>\n Logarithmic $O(\\log n)$ – grows with data size.<\/span><\/td>\n Constant $O(1)$ – fixed size (e.g., 48 bytes) regardless of data size.<\/span><\/td>\n<\/tr>\n \n Verification Cost<\/b><\/td>\n Low (hashing).<\/span><\/td>\n Moderate (Elliptic curve pairings).<\/span><\/td>\n<\/tr>\n \n Setup<\/b><\/td>\n Transparent (no trusted setup).<\/span><\/td>\n Requires Trusted Setup (MPC).<\/span><\/td>\n<\/tr>\n \n Data Extension<\/b><\/td>\n Requires Fraud Proofs for incorrect encoding.<\/span><\/td>\n Inherently proves correct encoding via polynomial binding.<\/span><\/td>\n<\/tr>\n \n Sampling Efficiency<\/b><\/td>\n Lower; requires branch data for every sample.<\/span><\/td>\n Higher; proof is constant, enables batching.<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n 3. Ethereum’s Modular Evolution: EIP-4844 and Proto-Danksharding<\/b><\/h2>\n
3.1 The Architecture of Blob-Carrying Transactions<\/b><\/h3>\n
\n
3.2 The Blob Gas Market<\/b><\/h3>\n
3.3 The Point Evaluation Precompile<\/b><\/h3>\n
4. The Road to Full Danksharding: Scaling via Sampling<\/b><\/h2>\n
4.1 The Mechanics of Sampling and Erasure Coding<\/b><\/h3>\n
\n
4.2 PeerDAS: The Bridge to Scalability<\/b><\/h3>\n
\n
4.3 Networking Constraints and Challenges<\/b><\/h3>\n
\n
5. Comparative Analysis of Data Availability Layers<\/b><\/h2>\n
5.1 Celestia: The Optimistic Approach<\/b><\/h3>\n
\n
5.2 Avail: The Validity Proof Approach<\/b><\/h3>\n
\n
5.3 EigenDA: The Restaking Approach<\/b><\/h3>\n
\n