Compare Avail DA, Celestia, EigenDA, and Ethereum EIP-4844 to help you easily choose a data availability layer.

Source: Avail

Choosing the right data availability layer is a difficult, confusing, and time-consuming process with many factors to consider. In this guide, we will cut through the noise and compare Avail DA, Celestia, EigenDA, and Ethereum EIP-4844 to help you make a more informed decision.

1. Performance

1.1 Data Throughput and Scalability

In this section, we compare the current data availability throughput and discuss the ability of different DAs to increase throughput over time.

Avail DA

Avail currently has a throughput of 2MB per block. Avail DA supports scalable block space, allowing throughput to grow as the demand for data availability capacity increases. Benchmark tests have successfully increased throughput to 128MB per block, a 64-fold increase over the current throughput, without sacrificing network activity or propagation.

The goal is to achieve a throughput of 16MB per block on Ethereum.

Celestia

Celestia's current throughput is also very close to 2MB per block (1,973,786 bytes) and can be increased to 8MB through on-chain governance. The current hardcoded limit is 100MB per block, which is 50 times higher than today's throughput levels. Celestia supports scalable block space and states that its future goal is to achieve 1GB blocks.

EigenDA

Eigen's publicly available test data shows a throughput of 15MB per second. EigenDA can achieve this level of throughput due to its architecture. Unlike other solutions discussed in this article, EigenDA is a Data Availability Committee (DAC) rather than a publicly verified blockchain.

DACs avoid some of the verification requirements achieved by more robust blockchain-based solutions like Avail DA, Celestia, and Ethereum. This allows DACs like EigenDA to achieve higher throughput while introducing trust assumptions. These aspects are discussed in more detail in sections 1.2, 2.3, 2.5, and 2.6.

EigenDA can increase throughput, but since it is not a blockchain, it is not suitable for scalable block space. However, it does indicate a goal to increase throughput to 1GB per second.

Ethereum EIP-4844

Among all DA providers, Ethereum has the lowest data throughput. This makes sense, as the demand for new data availability solutions stems from the need to scale Ethereum's throughput.

With the rollout of the danksharding prototype, the next significant milestone for increasing Ethereum's DA capacity is complete Danksharding. This upgrade will increase the number of blobs per block from 6 to 64, resulting in a throughput of approximately 8.2MB per block, which is about 10 times higher than the EIP-4844 level. This upgrade is expected to take several years to implement, with the ultimate goal of achieving 16MB per block on Ethereum.

1.2 Block Time and Time Required for DA Finality

While the previous section explored DA throughput capabilities, block time and the time required for finalizing DA guarantees are also important factors to consider when deciding which data availability solution to use. This is because just because a block is finalized does not necessarily mean that the DA guarantee is finalized.

The time required for DA finality determines the speed of finality within the system, as other applications or users can only confidently proceed to the next step once the DA finality time is guaranteed and irreversible. The time required to provide DA guarantees depends on how the DA layer is implemented, which we will explore below.

Avail DA

Avail has a block time of 20 seconds, with blocks finalizing in about 2 blocks (i.e., 40 seconds). Avail DA uses a validity-proof-based architecture, allowing it to provide DA finality when blocks are completed. This also means that Avail DA's finality time is approximately 40 seconds, about 15 times faster than Celestia.

Celestia

Celestia creates and finalizes blocks within 15 seconds. However, because Celestia's implementation is based on fraud-proof architecture, the block finality time does not depend on block time but rather on the challenge period. Once this challenge period has passed without a valid fraud proof being mentioned, Celestia can provide DA finality time, which takes about 10 minutes.

EigenDA

Since EigenDA is not based on its own blockchain, the assessment in this section is based on the block time and settlement time of EigenDA smart contracts completed on Ethereum. As EigenDA is a DAC, it cannot allow anyone to publicly verify whether the data is indeed available. EigenDA can only provide the ability to check whether members agree to retain data via Ethereum smart contracts. This may be acceptable for certain use cases, but it also carries the risk of asset loss or freezing.

Members of the data availability committee running EigenDA software commit to keeping data available on behalf of the network. When data is received, the committee signs a message indicating that they have stored the data. The signatures of the committee members are collected to create a certificate, which is then sent to Ethereum. This process is completed in about 15 minutes.

EigenDA punishes misconduct through economic measures, while other DA providers primarily rely on publicly verifiable data availability guarantees.

Ethereum EIP-4844

Ethereum's average block time is 12 seconds, with block completion taking 15 minutes. DA guarantees on Ethereum are completed simultaneously with block confirmations, meaning Ethereum generates data availability guarantees in about 15 minutes.

2. Key Features

2.1 Data Availability Sampling (DAS)

Data availability sampling is a very powerful feature offered by data availability solutions. It acts like a window into the blockchain, allowing low-power devices (such as users' phones or even within a browser) to check and verify DA guarantees. This level of end-user verification can build a network where users around the world can independently check whether the data needed to reconstruct the blockchain is available at any time.

The way it works is that the system samples random data blocks, checks for data availability, and then calculates a confidence score for the remaining data availability. Through continuous sampling, DAS enables the system to increase its confidence. For example, on Avail DA, 8-30 samples can achieve nearly 100% confidence.

Avail DA and Celestia

Both Avail and Celestia support data availability sampling from lightweight clients that are small enough to run almost anywhere. This provides end users with the ability to independently verify data availability in mobile applications without downloading the entire block.

Avail DA and Celestia also utilize DAS to form a P2P network of lightweight clients to help support larger blocks. However, Avail DA is the only DA layer that can sample from its P2P network, thereby increasing further resilience.

Ethereum and EigenDA

Ethereum's complete Danksharding roadmap aims to support DAS. EigenDA currently does not support DAS but may support it in the future.

2.2 Erasure Coding

Erasure coding is a widely used data protection technique in computing. It first creates copies and divides them into blocks, then disperses and stores them in different locations to enhance data resilience. This way, if a data block is damaged, it is less critical because multiple copies of the data are stored in different locations to reconstruct the entire dataset. Erasure coding is a very useful component in helping achieve data availability sampling.

Currently, Ethereum at the EIP-4844 stage does not support erasure coding. However, according to the roadmap, Ethereum plans to support it through complete danksharding.

2.3 Decentralized Network

In general, the degree of decentralization required may depend on the user scenarios you anticipate. If you expect to handle billions of dollars in funds, then network decentralization will be a very prioritized feature. However, if you want to track user actions in on-chain games, you may not need the same level of decentralization.

In this section, we will measure the degree of decentralization based on the number of supported validator nodes and the rules executed through the consensus mechanism.

Avail

The Avail blockchain can achieve good network decentralization because it uses Nominated Proof-of-Stake (NPoS). NPoS has built-in mechanisms to automatically ensure that stakes are evenly distributed among validators. This avoids the risk of validator centralization and makes it harder for anyone to manipulate the network. NPoS uses an algorithm called the Phragmén election algorithm to distribute stakes among validators. The Avail blockchain is currently running on the mainnet, and its active validator set is expected to grow to 1,000.

Celestia

Celestia's blockchain also provides good decentralization guarantees but is more susceptible to validator centralization risks because it employs a Delegated Proof-of-Stake (DPoS) system. The design of DPoS means that the higher the stake of a validator, the more tokens they receive, leading to stakes and voting power being concentrated in a few validator nodes. This situation is exacerbated in emerging DPoS-based blockchains like Celestia, which currently has 100 validators.

EigenDA

EigenDA has weaker decentralization characteristics. In EigenDA's data availability committee, operators form a trusted committee that commits to providing transaction data. However, end users and applications cannot independently verify this. Their only authority is the economic guarantees formed to mitigate risks. The EigenDA architecture currently has a centralized component that plays a very important role, called the disperser.

Ethereum

Ethereum achieves the highest level of decentralization, with over 1 million validators. However, as Ethereum adopts Delegated Proof-of-Stake (DPoS), this effectively introduces the risk of validator centralization, which becomes more pronounced with the introduction of liquid staking providers and centralized exchanges managing large total stakes.

2.4 Full Node Dependency

Historically, running a full node on a blockchain was the only way to independently verify the correctness of the blockchain state. This made global consensus possible. However, over time, blockchains have become larger, making it increasingly difficult for anyone to simply run a full node.

Avail DA and Celestia

Both Avail DA and Celestia have made significant improvements to traditional lightweight client architectures, allowing lightweight clients to independently check and verify data availability. This reduces the reliance on full nodes as a source of truth, as lightweight clients can verify data availability themselves. The computational requirements for running lightweight clients are extremely low, meaning users can verify DA guarantees on applications, laptops, phones, or other low-power devices.

Ethereum

Ethereum has a high dependency on full nodes. While lightweight clients exist in Ethereum, they rely entirely on full nodes, as they cannot verify data availability without depending on full nodes.

2.5 Proof Mechanisms

Proofs are used to efficiently verify whether data is available in the system. This significantly reduces the resources required to generate data availability guarantees.

Validity proofs require more effort to generate but are quick and efficient to verify. Avail DA, EigenDA, and Ethereum all use KZG commitments and validity proofs, but they use them differently.

Avail

Avail validators generate a KZG commitment for each block when adding new blocks to the Avail blockchain. Once DA finality is reached, lightweight clients can verify these KZG commitments through data availability sampling. This is a unique and powerful combination, especially for ZK Rollups, because both execution proofs and DA proofs can be verified very quickly from handheld devices without a challenge period.

Celestia

Celestia is the only data availability layer in this comparison that uses fraud proofs. This approach takes a more optimistic view, assuming that data is valid and available (unless proven otherwise by a fraud proof). Celestia uses secure hash functions that generate faster than KZG commitments, but it requires a challenge period before providing data availability guarantees to applications and users.

EigenDA

In EigenDA, the disperser collects data blocks and sends them to running nodes. Rollups can run their own dispersers or use disperser services. The disperser is currently a centralized component of the Eigen architecture. The disperser also generates KZG commitments and sends them along with data blocks to the running nodes. When running nodes receive data blocks from the disperser, they verify the KZG commitments and then sign and return the proof to the data availability committee.

Ethereum

In Ethereum, data blocks are submitted, and KZG commitments are generated for the submitted data. When data availability needs to be checked, the EVM checks the version hash of the KZG commitment to verify data availability. Ethereum does not yet support data availability sampling but intends to include it as part of the complete Danksharding roadmap. KZG commitments play a key role in implementing DAS.

2.6 Consensus Mechanisms

Reaching consensus is key to the ongoing operation of a blockchain and the generation of new blocks. In the design of consensus mechanisms, there is a fundamental trade-off between liveness and security. Liveness ensures that transactions continue to be processed and the network remains operational, while security ensures that transactions are accurate and safe.

All the data availability layers mentioned in this article use different consensus mechanisms, but there are some similarities and differences, which we will discuss below.

Avail DA and Ethereum

Although Avail and Ethereum use different consensus mechanisms, they do share some similarities. Both separate the roles of block generation and block finalization.

Block generation can remain active, allowing transactions to continue. Block finalization is the process by which all nodes agree on a specific block and submit it to the blockchain.

This design choice adds some resilience to the network, allowing it to continue operating while reaching consensus among validator nodes.

Celestia

Celestia uses Tendermint as its consensus protocol, which has single-slot finality. This means that once consensus is reached, the block is finalized, which typically takes about 15 seconds. The downside of Tendermint-based chains is that they may stop if more than one-third of operators or validators fail.

EigenDA

The operators of EigenDA collectively form a trusted data availability committee, which is a group of nodes that prove data availability. End users and applications cannot independently verify this.

Conclusion

We hope this guide helps you make a more informed decision about which DA layer to choose. If you would like to improve or update any information in this article, please contact us through the forum.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。