Avail is a modular blockchain designed to solve the data availability problem by taking data off-chain and proving that the data is actually available. Data availability chains like Avail are an emerging area in the blockchain space. Not everyone is familiar with these concepts, but they are gaining traction as developers need to scale their systems increases.
In this article, well list the facts about Avail, including some of the most common misconceptions, to gain a clearer understanding of the data availability benefits Avail provides developers.
1. Is Avail a data storage solution?
No, Avail is a blockchain that ensures data availability. It can prove that data exists on the blockchain, even if it is not currently stored on the blockchain.
Data availability differs from data storage in that it focuses on providing proof of data availability without requiring complete data retrieval, whereas data storage involves the actual storage and retrieval of the entire data.
Data availability plays a vital role in the data integrity and security of blockchain networks by ensuring that all participants can access and verify the existence of necessary data. It prevents the hiding of malicious transactions and potential damage to the credibility of the entire system.
Data availability is the ability of a node to download the data contained in all blocks propagated through the peer-to-peer network. It refers to users’ confidence that the data required to verify blocks is indeed available to all network participants.
On the other hand, decentralized storage blockchains such as Arweave, IPFS, Filecoin, and Sia enable end-users to store and retrieve files directly on the blockchain. Unlike data availability chains, these storage chains focus on explicitly retrieving the complete data requested by the user.
2. Is Avail a single blockchain?
No, Avail is a modular data availability (DA) layer that offers many advantages over on-chain data availability. Modular blockchains typically separate data availability, transactions, and consensus processing—breaking them into more manageable components that can be developed and maintained independently.
Meanwhile, a Layer 1 single blockchain like Ethereum is designed to do it all, including execution, settlement, consensus, and data availability. Handling all tasks simultaneously affects the efficiency of the above functions, ultimately leading to transaction bottlenecks and increased fees.
Additionally, a single blockchain relies on the availability of on-chain data. Improving network throughput to improve blockchain performance is one of the core challenges facing single blockchains. To increase overall system throughput, you need to create larger chunks, increase chunk frequency, or improve chunk spreading to transfer more data. As single blockchains attempt to scale, this reliance on on-chain data availability is inefficient and expensive.
For example, a full node on Ethereum L1 must download a copy of all data in every block. This can be a lot of data, especially for large chunks. Therefore, the availability of on-chain data may make blockchain scaling difficult as the amount of data required to process increases with the number of blocks. If the data is not available, the block is discarded.
Avail uses erasure coding and KZG polynomial commitment to ensure data availability is guaranteed with high confidence. By using these two features, light clients (nodes that allow users to obtain tiny data through data availability sampling) can verify data availability without downloading the entire blockchain, providing greater efficiency.
3. Is Avail a Data Availability Council (DAC)?
Avail is not a Data Availability Council (DAC). In addition to their permissioned and often centralized nature, DACs also suffer from some serious security vulnerabilities because they rely on the honest majority assumption. DAC is a group of nodes responsible for off-chain data availability, and it is believed that the majority of nodes in the committee are honest. This assumption and reliance on a small number of nodes is risky. For example, block producers can disrupt the entire chain by withholding transaction data, thereby preventing users from withdrawing funds.
Additionally, DAC does not suffer any loss if a data withholding attack is attempted. In other words, nodes have no financial incentive to act honestly.
Avial is different, it runs as an independent blockchain with its own verification nodes, block producers and consensus mechanism. While DAC typically involves a limited number of participants (as few as 5), Avail plans to have hundreds of nodes working together to ensure network security.
Data availability on Avail does not rely solely on validators, as any light client can also contribute to keeping data available. Light clients can determine data availability on their own through random data sampling without having to trust an honest majority. Even if a full node goes down or attempts are made to censor data, blocks can be rebuilt from light nodes.
4. Are full nodes the only participants supporting the Avail network?
No, we have light clients, full nodes, and validators supporting the Avail network.
As a modular blockchain, all network participants in Avail are redefined. In Avail, validators accept transactions and create blocks. Once the block is created, if the data is not available, the light client is able to recognize this. Although they exist in Avail, full nodes play a supporting role to maintain high redundancy, which is a huge difference from the key role played by full nodes in traditional monolithic architectures.
In traditional monolithic blockchains, light clients have their limitations - they rely on full nodes to provide accurate data. This can be risky because compromised nodes may provide incorrect information. They may still need to download large amounts of data. This can be resource intensive and limits their usability on devices with limited computing power.
Avails light clients are different; they can overcome the limitations of traditional light clients by using certain techniques, including data availability sampling (DAS), erasure coding, and KZG polynomial commitments.
Erasure coding ensures redundancy and resilience to data loss by replicating and distributing data in an mxn matrix. KZG promises to make efficient sampling of data possible. The light client then randomly fetches cells from the matrix and can immediately verify the availability of the data by sampling just a few cells. This eliminates the need to download the entire database, significantly reduces resource requirements, and enables light clients to verify blockchain state even if they do not have the powerful hardware resources to perform the computation. They can use lightweight devices such as mobile phones and browser-based wallets.
Incorporating light clients into everyday wallets is a future development direction with huge potential. This will allow users to easily and conveniently verify the blockchain state without having to run a full node themselves. This will also make blockchain technology more accessible to a wider user base.
5. Is Avail part of Polygon?
Avail is no longer part of Polygon. Avail is a completely independent network. But we have a close history with Polygon.
The Avail project was launched internally at Polygon Labs in late 2020 by co-founder Anurag Arjun. During that time, the Avail team began working on solving data availability issues.
Avail has always been compatible with different types of blockchains, including standalone chains, sidechains, and off-chain scaling solutions. However, the Avail team envisions maintaining neutrality and flexibility, allowing the project to focus on a broader range of rollup solutions beyond Ethereum and Polygon.
This transition occurs in March 2023. Avail is now fully committed to providing data availability for all types of rollups and blockchains, not just those specific to Polygon or Ethereum.
The road ahead
Avail envisions a future where blockchain technology is more scalable, flexible, and open to developers. To enable this, Avail is developing a powerful consensus and data availability layer to provide raw block space to the modular chain. This will allow developers to build rollups and appchains that are more scalable, flexible, and easy to use.
