Data availability layers have emerged as a salient part of modular architecture, acting as a pluggable component to drive costs down and scale blockchains. The core function of a DA layer is to ensure that chain data is available and accessible to all network participants. Historically, each node had to download all transaction data to verify that the data was available — an extremely inefficient and costly task. This is how most blockchains currently work, and is a barrier to scalability since the amount of data required to verify increases linearly with block size. The end user suffers here: data availability costs represent 90% of the transaction costs a user incurs to transact on a rollup (the cost for rollups to send transaction data to Ethereum is $1300-$1600/mb today).
The introduction of data availability sampling (DAS) fundamentally changed this architecture. With DAS, light nodes can confirm that the data is available by participating in rounds of random sampling of block data rather than having to download each entire block. Once multiple rounds of sampling are completed — and a certain confidence threshold is reached that the data is available — the rest of the transaction process is safe to occur. This way, a chain can scale its block size yet maintain easy data availability verification. And considerable cost savings are also achieved: these emerging layers can reduce DA costs by up to 99%.
Beyond enabling much higher throughput, data availability layers are also meaningful for improving interoperability. Cheap DA will inevitably fuel a Cambrian explosion of new custom rollup chains, made increasingly simple to deploy with rollup-as-a-service providers like Caldera, AltLayer, and Conduit. However, as an ecosystem of L2s and L3s emerges, they will be fragmented by default. Getting users on a new platform is already hard — it gets much worse if there’s limited interoperability, liquidity, and network effects. With a unified DA layer serving as a foundation for each of these networks, the flow of funds becomes much more simplified and attracts a broader user base.
Avail, EigenDA, and Celestia are the main characters in the DA ecosystem — each serving the same space but taking slightly different approaches regarding infrastructure stack, execution, and go-to-market.
In terms of technical architecture, Avail, Ethereum, and EigenDA use KZG commitments, while Celestia uses fraud proofs to confirm blocks are encoded correctly. Generating KZG proofs — though a very rigorous way to prove DA — causes more computational overhead for block producers, especially as the block size increases. Celestia, on the other hand, assumes that the data is available implicitly via their fraud proof scheme. In exchange for having no computational “work” to complete, the system must wait a set amount of time for a fraud proof dispute period before nodes can confirm that the block is encoded accurately. Both KZG proofs and fraud proofs are experiencing rapid tech advances; their tradeoffs may continue to grow in complexity, and it’s unclear yet if one mechanism will be strictly dominant over the other.
For Avail, their architecture with KZG commitments allows them to be well-suited to zk constructions — this is an area where Celestia may face difficulties due to their reliance on optimistic proofs if zk dominates in the future. Additionally, Avail’s p2p network of light clients can support the network even if all of the full nodes are down; in Celestia’s architecture, light clients cannot operate without full nodes. Both Avail and Celestia use erasure coding under DAS, which sections the data off into shards, adds redundancy, and allows for the reconstruction of that data to verify it.
In contrast to Celestia and Avail’s stacks, EigenDA plays off of Ethereum’s existing infrastructure. EigenDA inherits the same finality time as Ethereum if data needs to get sent to rollup contracts to prove the data is available. However, if the rollup fully uses EigenLayer, finality can be achieved much faster.
For consensus, Avail uses BABE + GRANDPA inherited from Polkadot’s SDK alongside nominated proof-of-stake (NPoS). NPoS serves to nominate a set of validators that a delegator is willing to see elected, while BABE dictates who will propose the next block, and GRANDPA acts as the block finalization algorithm.
Celestia uses Tendermint for consensus, allowing users to stake their $TIA (the network’s native token) for a portion of the validator’s staking rewards. Though Celestia is able to achieve fast finality with Tendermint, there’s a waiting period for actual data availability guarantees (users must have time to submit fraud proofs) because of their optimistic architecture.
EigenDA does not have consensus itself, but instead has two mechanisms to ensure the validity of data availability:
Proof of custody. This is essentially an economic security mechanism that ensures that nodes are storing the data, but doesn’t actually guarantee that that data is served to everyone in the network. Nodes are slashed if they don’t comply, e.g. if they cannot prove that they have the data.
Sufficient decentralization. Ensuring that the operator set remains decentralized and collusion-resistant is crucial for the network to run correctly. With a large and independent validator set, serving the data becomes a competition where many market players are willing to participate. At this scale, it’s extremely difficult to collude.
An interesting point worth mentioning is that Celestia’s active validator set is composed of the top 100 validators by staked tokens, and this threshold may decrease in the future. Further, each of their validators stores the entire dataset. EigenDA will optimize for each node (potentially millions in the future) storing a small portion of the data — in this case, if enough nodes are honest, the data can be reconstructed. The full origins of (and more detail on) EigenDA can be found in Sreeram’s recent thread.
To wrap it up, Avail made a helpful comparison of the core components of the dominant DA layers.
There’s also an emerging discussion around the tradeoffs of each of these designs. David Hoffman noted that Celestia is an entire blockchain in and of itself — a complex stack that requires much more than pure DA. EigenDA, on the other hand, is just a set of smart contracts, but has a reliance on Ethereum that Celestia and Avail do not.
The Celestia team argues that a token is necessary for security, and EigenDA will eventually need one since it’s impossible to slash off-chain data availability on-chain. They contend that in order to ensure that the nodes are honest, that the data is available, and to punish malicious nodes, the network must be able to be verified with an incentive structure including a native token. Here, Nick White of Celestia brings up this critique of EigenDA: restaked validators that withhold data cannot get slashed unless the source chain is forked — which is extremely unlikely since this is Ethereum.
Branding-wise, EigenDA is an extremely Ethereum-aligned product. The EigenLayer team is building with EIP-4844 and danksharding in mind — in Sreeram’s words, EigenDA is constructed as “the only ETH-centric data availability layer.” He explains that a data availability layer, by definition, is a modular product, but that other DA “layers” are actually blockchains themselves.
Packaging a DA layer into a blockchain does come with clear benefits for rollups running natively on them, primarily in the form of security guarantees. However, Sreeram mentions that his team’s goal in building EigenDA is to create a product that provides just data availability services to the Ethereum ecosystem started from first principles — a true “layer” that adjoins the Ethereum ecosystem. He notes that a separate consensus isn’t needed here, since Ethereum-based rollups already rely on the network for ordering and consensus. (Sreeram explained this eloquently in the recent Bankless episode.)
Avail is built with validity proofs and DAS, which allows for a high degree of flexibility and interoperability ecosystem-wise. Their architecture establishes a base for a scalable framework that is designed to enable services across many different platforms. This “unopinionated” stance allows for greater interoperability and flow of funds, and also appeals to non-Ethereum-centric ecosystems. The ultimate goal here is to take ordered transaction data from all chains, and aggregate it to Avail, making them the coordination hub for all of web3. To kick off the network, Avail recently launched a Clash of Nodes campaign alongside their incentivized testnet, allowing users to run validators and light clients and compete in network challenges.
Celestia’s ecosystem is composed of RaaS providers, shared sequencers, cross-chain infrastructure, and more, across ecosystems including Ethereum, Ethereum rollups, Cosmos, and Osmosis.
Each of these design choices, both technical and marketing-wise, comes with interesting tradeoffs. Personally, I’m not certain that the data availability category will be a winner-take-all or commoditized market — rather, an oligopoly-style market may exist where projects opt for the DA layer that best suits their needs. Depending on the type of protocol, teams may optimize for interoperability, security, or a preference towards one ecosystem or community. If custom use-case rollups explode as anticipated, they won’t hesitate to integrate a DA layer — and there will be more than one robust option to choose from.
This technology — and the modular narrative in general — is still relatively new, with Celestia just recently going live and Avail and EigenDA reaching mainnet in the coming months. However, the technical progress to date on modularism has been exceptional (many of these concepts were just ideas a few years ago!). By inherently refining the way we build and use blockchains, DA layers will undoubtedly become one of the core technologies of this cycle and beyond.
Thank you to Joey Krug, Kydo, Scott, and many others for informing my thinking on this piece. Cover photo from Vitalik. If you’re thinking about these designs, or anything in crypto really, I’d love to talk — my DMs are open.