First Published Oct 12, 2023, up to date as of Oct 3, 2024.
Selecting the right data availability layer can be a difficult, confusing and time consuming process. There’s a lot to consider and you want to make sure you make the right decision. In this guide we cut through the noise and put the DA layers side-by-side to compare their features and benefits, and help make your decision easier.
Whether you’re comparing features, or focussed on performance, we’ve broken down the benefits of Avail DA, Celestia, EigenDA and Ethereum EIP-4844 in this side-by-side comparison.
This blog is being actively maintained. To request an update to values and/or references in this post please make contact via this thread.
Contents
- Performance
- Key Features
1. Performance
1.1 Data Throughput & Scalability
In this section we compare the current data availability throughput, and discuss the ability for each DA to increase throughput over time.
Avail DA
Avail’s current throughput is 2MB per block, which is live on mainnet. Avail DA supports expandable blockspace enabling throughput to grow as demand for data availability capacity increases. Benchmarks have successfully increased throughput up to 128MB/block, a 64X improvement on the current throughput, without sacrificing network liveness or propagation.
Celestia
Celestia’s current throughput is also very close to 2MB per block (1,973,786 bytes), live on mainnet and can be increased to 8MB through on-chain governance. The current implementation has a hard-coded limit of 100MB per block, a 50X improvement on today’s throughput levels. Celestia supports expandable block space and has stated ambitions to achieve 1GB blocks in the future.
EigenDA
Eigen has shared tests showing throughput of 15MB per second. EigenDA can achieve this level of throughput because of its architecture. Unlike the rest of the solutions in this comparison, EigenDA is a Data Availability Committee (DAC) and not a publicly verified blockchain.
DACs remove some of the verification requirements implemented by more robust, blockchain based solutions like Avail DA, Celestia and Ethereum. This enables DACs like EigenDA to reach higher throughput while introducing trust assumptions. These are discussed in more detail in sections 1.2, 2.3, 2.5 and 2.6.
EigenDA can increase throughput, but because it is not a blockchain, expandable blockspace is not applicable. It does however have stated ambitions of increasing throughput up to 1GB per second.
Ethereum EIP-4844
Ethereum’s data throughput is the lowest of all the DA providers compared. This makes sense as the requirement for new data availability solutions arose from the need to scale throughput on Ethereum.
With proto-danksharding now live, the next major milestone for increasing Ethereum’s DA capacity is full Danksharding. This upgrade would see the number of blobs per block increase from 6 to 64, resulting in throughput of ~8.2MB per block and a ~10x improvement on EIP-4844 levels. This upgrade is still expected to be a few years away from implementation and the eventual goal is to reach a throughput of 16MB per block on Ethereum.
1.2 Block Time & Time to DA Finality
While the previous section explored the DA throughput capacity, both the block time and time it takes to finalize a DA guarantee is an important factor to consider when deciding which data availability solution to use. This is because once a block is finalized it doesn’t necessarily mean that the DA guarantee is finalized.
The DA finality guarantee is what determines the speed of finalization within your system, as other applications or users can only move forward with confidence, when the DA finality is guaranteed and irreversible. The time it takes to provide a DA guarantee comes down to how the DA layer has been implemented which we explore below.
Avail DA
Avail’s block time is 20 seconds and blocks are finalized in around 2 blocks, or 40 seconds. Avail DA uses an architecture based on validity proofs which enables it to provide DA finality when blocks are finalized. This results in a data availability finality time of ~40 seconds. This is around 15x faster than the next fastest solution, Celestia.
Celestia
Celestia creates and finalizes blocks in 15 seconds. Celestia’s implementation uses an architecture based on fraud proofs meaning that DA finality is not reached when blocks are finalized. Instead, the DA finality is subject to a challenge period. Once this challenge period has passed, with no valid fraud proofs being presented, Celestia can then provide DA finality which takes ~10 mins.
EigenDA
As EigenDA is not based on a blockchain of its own, the values in this section are based on the block time and settlement time for EigenDA smart contracts to finalize on Ethereum. Because EigenDA is a DAC it is unable to provide the ability for anyone to publicly verify that the data is in fact available. EigenDA can only offer the ability to check that members have agreed to keep the data available via Ethereum smart contracts. This might be ok for some use cases but can result in lost or frozen assets.
Members of the Data Availability Committee running the EigenDA software promise to keep data available on behalf of the network. When they receive the data, they sign a message to say they have stored it. The signatures from committee members are collected together to create a certificate which is then sent to Ethereum. The certificate is finalized in around 15 minutes.
EigenDA relies on economic guarantees only, by penalizing misbehavior through slashing. The rest of the DA providers in this comparison also provide economic guarantees in addition to publicly verifiable data availability guarantees.
Ethereum EIP-4844
The average block time for Ethereum is 12 seconds, and block finality is 15 minutes. The DA guarantee is finalized on Ethereum at the same time as the block is finalized, producing a data availability guarantee in ~15 minutes.
2. Key Features
2.1 Data Availability Sampling (DAS)
Data Availability Sampling is an incredibly powerful feature for a data availability solution to provide. It acts like a window into the blockchain, making it possible to check and verify DA guarantees from low powered devices, such as a user’s phone or even from within the browser. This level of end user verification makes it possible to build a network where users, spread out all over the world, can independently check that the data required to reconstruct the blockchain is available at any time.
The way this works is the system will sample random chunks of data, check to see if the data is available and then calculate a confidence score of whether or not the rest of the data is available. With each successive sample, DAS enables the system to increase its confidence level. On Avail DA for example, a confidence level close to 100% can be achieved within 8-30 samples.
Avail DA & Celestia
Both Avail and Celestia support Data Availability Sampling from light clients which are small enough to run almost anywhere. This provides end-users with the ability to independently verify data availability from within an app on their phone without needing to download the entire block.
Avail DA and Celestia also leverage DAS to form a P2P network of light clients that helps support larger blocks. However, Avail DA is the only DA layer capable of sampling from its P2P network, adding further resilience.
Ethereum & EigenDA
Ethereum’s full Danksharding roadmap intends to support DAS. EigenDA does not currently support DAS, but suggests it can be supported in the future.
2.2 Erasure Coding
Erasure coding is a widely used technique in computing to protect data. It adds more resilience to the data by making a copy, dividing it into chunks and then spreading out and storing those chunks in different locations. This way, if a particular piece of data is damaged, it doesn’t matter all that much, as there’s multiple copies of the data stored in different locations to rebuild the entire dataset. It’s also a very useful component to help enable Data Availability Sampling.
Ethereum with EIP-4844 does not support erasure coding, but plans to support it with full danksharding.
2.3 Network Decentralization
The level of decentralization you require may depend on your intended use case. If you are looking to secure billions of dollars in funds, then network decentralization would be a very high priority feature. If however you wanted to keep track of a user's movements in an on-chain game, then you probably don’t need the same level of decentralization.
In this section we are weighing up the level of decentralization in terms of the number of validator nodes supported and the rules enforced through the consensus mechanism.
Avail
The Avail blockchain is able to achieve a good level of network decentralization because it uses Nominated Proof-of-Stake (NPoS). NPoS has a built-in mechanism which automatically guarantees that the stake is spread out evenly across validators. This avoides validator centralization risks and makes it harder for anyone to take control of the network. NPoS spreads stake among validators with something called the Phragmén election algorithm. The Avail blockchain is currently live on mainnet with an active validator set that’s expected to grow to 1,000.
Celestia
Celestia’s blockchain provides good decentralization guarantees too but is more prone to validator centralization risks because it adopts a delegated proof-of-stake (DPoS) system. The design of Delegated Proof-of-Stake rewards validators with more tokens the higher their stake, resulting in a concentration of stake and voting power among a handful of validator nodes. This is further exacerbated among more nascent DPoS based blockchains like Celestia’s. Celestia currently has 100 validators.
EigenDA
EigenDA has poor decentralization characteristics. Within EigenDA’s Data Availability Committee, the operators form a trusted committee who promise to make transaction data available. However, end users and applications have no way of independently verifying this for themselves. The only guarantee they have is the economic guarantee formed by the risk of slashing. The EigenDA architecture also currently has a centralized component which plays a very important role known as the disperser.
Ethereum
Ethereum achieves the highest decentralization with over 1 million validators. Ethereum adopts delegated proof-of-stake (DPoS) which does introduce validator centralization risks which have become more prominent with the introduction of liquid staking providers and centralized exchanges managing large percentages of the total stake.
2.4 Full Node Dependency
Historically, running a blockchain full node was the only way to independently verify the correctness of a blockchain’s state. This is what made global consensus possible. However, as time goes by, and blockchains become larger, it gets increasingly more difficult for anyone to simply run a full node.
Avail DA & Celestia
Both Avail DA and Celestia have made significant improvements on the traditional light client architecture, by enabling light clients to independently check and verify if data is available. This reduces the reliance on full-nodes as a source of truth, because light clients can verify whether or not data is available themselves. The computational requirements for running a light client are extremely low, meaning that users can verify DA guarantees from within an app, on their laptops, phones or other low powered devices.
Ethereum
Ethereum has high dependency on full nodes. Although light clients exist in Ethereum, they are entirely reliant upon full nodes as they cannot verify that data is available without relying on them.
2.5 Proof Mechanism
Proofs are used to efficiently verify whether or not data is available in the system. This substantially reduces the resources required to generate data availability guarantees.
Validity proofs require more effort to produce but are fast and efficient to verify. Avail DA, EigenDA and Ethereum all use KZG commitments and validity proofs, however they utilize them in different ways.
Avail
Avail validators generate a KZG commitment for each block when adding new blocks to the Avail blockchain. These KZG commitments can be verified by light clients through data availability sampling as soon as DA finality is reached. This is a unique and powerful combination, particularly for ZK rollups. This is because both the execution proof and DA proof can be verified very quickly from a handheld device, without requiring a challenge period.
Celestia
Celestia is the only data availability layer in this comparison to use fraud proofs. This approach takes a more optimistic perspective, assuming data is valid and available unless proven otherwise by a fraud-proof. Celestia utilizes secure hash functions, which are faster to generate than KZG commitments, however the challenge period needs to pass before providing a data availability guarantee to applications and users.
EigenDA
In EigenDA, the Disperser collects data blobs and sends them to Operator nodes. Rollups can run their own disperser or use a dispersal service. The Disperser is currently a centralized component of Eigen’s architecture. The disperser also generates a KZG commitment and sends it with the data chunks to Operator nodes. When the Operator nodes receive the data chunk from the disperser, they verify the KZG commitment before signing and returning an attestation to the Data Availability Committee.
Ethereum
In Ethereum, data blobs are submitted and a KZG commitment is generated over the data submitted. When it comes time to check if the data is available, the EVM checks a versioned hash of the KZG commitment to verify the data is available. Ethereum does not yet support Data Availability Sampling, but intends to as part of the full Danksharding roadmap. KZG commitments play a key role in enabling DAS.
2.6 Consensus Mechanism
Reaching consensus is what enables the blockchain to keep operating and producing new blocks. When it comes to consensus mechanism design, there is a fundamental decision between achieving liveness and safety. Liveness ensures transactions keep getting processed and the network remains operational, while safety ensures that transactions are accurate and secure.
All of the Data Availability Layers in the comparison use different consensus mechanisms, however there are some similarities and differences which we discuss below.
Avail DA & Ethereum
While the consensus mechanisms used by Avail and Ethereum are different, they do have some similarities. Both separate the role of producing blocks and finalizing them.
Producing blocks is what maintains liveness, and enables transactions to continue. Finalizing blocks is the process of all nodes agreeing to a particular block and committing it to the blockchain.
This design choice adds some resilience to the network, enabling it to continue operating while consensus is being finalized among the validator nodes.
Celestia
Celestia uses Tendermint for its consensus protocol, which has single slot finality. This means that blocks are finalized as soon as consensus is reached, which is usually around 15 seconds. The tradeoff with Tendermint based chains is that they can be halted when more than one third of the operators or validators go down.
EigenDA
Collectively the EigenDA Operators form a trusted Data Availability Committee, a group of nodes that attest to data being available. End users and applications have no way of independently verifying this for themselves.
Conclusion
We hope this guide has helped make your decision on which DA layer to choose easier. If you see an opportunity to improve or update any information in this post, please make contact via this forum.
