Introduction

With the rapid development of blockchain technology, monolithic blockchains face serious scalability and interoperability challenges. Leading platforms like Ethereum experience skyrocketing transaction fees during periods of high user demand, significantly hampering decentralized applications’ adoption. To address these issues, developers have been continually seeking innovative solutions, and the emergence of Avail offers a new direction for solving these problems. Following the Cancun upgrade, transaction costs in the Ethereum ecosystem have dropped significantly, and modular technology has become a key narrative in blockchain development. In the first half of the year, modular blockchains like Celestia and EigenDA led the trend, and on July 23rd, Avail took a major step forward in the modular field by launching the Avail DA mainnet.

As one of the core projects in modular blockchains, Avail, EigenDA, and Celestia serve similar areas. However, each has its unique characteristics in terms of infrastructure, execution models, and token economic designs.

Team Background

Avail originated from Polygon and became an independent, neutral entity in 2023. Before data availability (DA) became a focal point in the industry, Anurag Arjun had collaborated with others to develop the Plasma chain, aiming to solve Ethereum’s scalability issues. Although this chain helped Polygon generate $19 billion in revenue, it ultimately did not become the ideal scaling solution. Throughout this process, Anurag realized that all blockchains would eventually face the same challenge—data availability. Approximately 80% of Rollup transaction costs are related to DA, leading him to envision the creation of a cost-effective DA layer that could solve scalability issues for multiple blockchains.

This idea was not unique to Anurag; many Layer 1 (L1) blockchain projects also attempted to position themselves as DA layers. Ethereum, for instance, is exploring DA solutions through the Rollup approach, while other L1 projects are innovating in this space. Anurag believes that an L1 blockchain specifically designed for DA offers distinct advantages.

During his time at Matic, Anurag met Prabal Banerjee, the current co-founder of Avail, who was pursuing a Ph.D. in cryptography and security. Prabal later joined the team as a researcher, and together, they dedicated themselves to building a scalable DA layer. With the rise of Zero-Knowledge Proof (ZK) technology, the two integrated blockchain designs based on validity proofs. Leveraging Anurag’s experience building a billion-dollar protocol at Polygon, they advanced the development of solutions to address data availability challenges.

From Monolithic to Modular

Source: Avail Official Documentation

As competition for underlying computational resources intensifies, Ethereum’s monolithic architecture—which handles execution, settlement, ordering, and data availability (DA) on a single chain—has increasingly revealed its limitations, particularly in terms of scalability. This has prompted the industry to reevaluate the monolithic model and explore new solutions.

Rollups introduced a modular architecture by moving execution off-chain, which alleviated congestion on Layer 1 (L1) networks, reduced transaction costs for users, and enhanced transaction throughput. Although this architecture significantly improved on-chain efficiency, Ethereum’s limited block space remains a bottleneck, and as demand grows, this issue may resurface. Currently, decentralized applications (Dapps) rely on L1 for data transmission and settlement, while Rollups use L1 to manage these processes. While Rollups have optimized the use of block space, block space itself remains a scarce resource.

Analyzing L1 transactions of Ethereum Rollups reveals that DA costs account for 90% of Rollup expenses, making it the largest source of expenditure. Most of this cost comes from paying L1 fees to publish transaction data.

Similar to how Rollups offload execution off-chain, Avail’s architecture allows data availability to be moved to a dedicated layer. Avail provides developers with a flexible, user-friendly, and secure DA layer that addresses scalability, governance, and decentralization challenges.

Avail’s Modular Architecture

Avail aims to accelerate Web3’s unification by leveraging its modular technology stack, which integrates data availability, aggregation, and shared security. Rollups that use Avail to publish off-chain transaction data will form systems like Validium (for Optimistic Rollups, this is called Optimium). Validiums and Sovereign Rollups can rely on Avail for low-trust data availability and ordering services.

Here is an overview of how Avail supports Validiums and Sovereign Rollups:

1. Transaction Submission: Like most existing Rollups, transaction data is batched, and the state root is submitted to Avail DA (Data Availability). Each batch is associated with a unique application ID to represent the Rollup’s origin.
2. Data Expansion and Erasure Coding: Transactions submitted to Avail DA undergo erasure coding. The data block is split into n original chunks and expanded into 2n chunks. Any n chunks from the 2n set can be used to reconstruct the original data, ensuring redundancy and fault tolerance.
3. Commitment Creation: Avail DA applies KZG polynomial commitments to the redundant data, ensuring its integrity through cryptographic proofs. These commitments ensure that the stored data is accurate and tamper-proof.
4. Block Propagation: Validators receive blocks containing KZG commitments and regenerate them to verify their accuracy. The validity of the block is then decided by consensus.
5. Light Client Network: Light clients use Data Availability Sampling (DAS) to verify the integrity of block data. This is done by performing KZG polynomial opening verification on the block headers’ commitments, removing the need to reconstruct the full KZG commitment or rely on fraud proofs.
6. Proof Verification: Light clients execute proof verification using cell-level proofs generated from the data matrix. This ensures that data is available and correct without requiring the client to download or verify the full block.

Since Avail employs validity proofs rather than fraud proofs, light clients can immediately verify data availability and correctness after state finalization. The light client network also ensures high data availability through data availability sampling. As more light clients join, the sampling capability improves, allowing the network to support larger blocks. These light clients can even run on laptops or mobile devices, enhancing the network’s efficiency.

Source: Avail Official Documentation

Technical Features

Light Client Use Cases

Currently, many blockchain applications rely on intermediaries to maintain full nodes, with users interacting indirectly through these intermediaries rather than directly connecting to the blockchain. Due to the lack of guaranteed data availability, light clients have not yet become the ideal alternative to traditional architectures. Avail addresses this issue by enabling applications to interact directly with the blockchain network without relying on intermediaries.

Although Avail supports the operation of full nodes, most applications do not need to run full nodes, or only require a minimal number of nodes to function smoothly. This significantly reduces the resource requirements for participation in the blockchain network and enhances decentralization by allowing more participants to interact with the chain directly through lightweight infrastructure.

Data Availability Sampling (DAS)

Similar to traditional light clients, Avail’s light clients only need to download block header data. Additionally, they perform random sampling of portions of the block data to verify its availability through data availability sampling (DAS). By combining erasure coding with KZG polynomial commitments, light clients can ensure nearly 100% data availability without relying on fraud proofs, requiring only a small and fixed number of queries.

Erasure Coding and Data Availability

Erasure coding works by splitting the data into fragments, restoring the original content even if some parts of the data are lost. In blockchain applications, even if malicious actors attempt to hide parts of the data, the system can still recover it from other fragments. This mechanism significantly improves the reliability of data availability sampling and further strengthens the system’s resistance to data tampering.

KZG Commitments

KZG commitments, developed by Aniket Kate, Gregory M. Zaverucha, and Ian Goldberg in 2010, are an efficient polynomial commitment method that has gained widespread adoption in zero-knowledge proof systems in recent years. In Avail’s architecture, KZG commitments offer the following advantages:

• They allow concise commitment to values recorded in the block header.
• Light clients can verify data availability through these commitments.
• The cryptographic binding properties of KZG commitments make it nearly impossible to generate false commitments, significantly reducing the need for fraud proofs.

Avail’s Unified Layer

Avail is building the “Unified Layer,” a comprehensive technology stack starting with the foundational data availability (DA) layer, the Nexus unified layer, and an additional security layer called Fusion. With its scalable data availability layer, Avail aims to support the entire Web3 ecosystem. Using validity proofs based on KZG polynomial commitments, Avail ensures real-time, reliable data availability, allowing rollups to grow, interconnect, maintain security, and adapt.

Avail DA

Source: Avail Official Documentation

Avail DA is an underlying architecture specifically optimized for data availability. It utilizes the GRANDPA and BABE consensus algorithms, setting it apart from other data availability layers. This design gives Avail DA high scalability, ensuring reliable data guarantees at low costs through Data Availability Sampling (DAS) and validity proofs.

At its core, Avail DA prioritizes and publishes transactions while allowing users to verify block data availability without downloading the entire block. One of Avail DA’s defining features is its data-agnostic nature. It supports a variety of execution environments, including EVM, WASM, and custom new runtimes, providing a versatile foundation for a wide range of blockchain applications.

Avail Nexus

Source: Avail Official Documentation

Avail Nexus, the second pillar of the Avail ecosystem, is a permissionless framework designed to unify the Web3 ecosystem. It connects both internal and external blockchains, using Avail DA as a trusted foundation and acting as a validation hub. Nexus integrates a ZK-coordinated Rollup system, which consolidates proof aggregation, a verification layer, a sequencer selection mechanism, and a slot auction system. Nexus periodically submits aggregated proofs to Ethereum and the Avail DA layer for verification, ensuring the reliability of cross-chain operations.

Avail Fusion

Source: Avail Official Documentation

Avail Fusion, the third pillar, provides additional security for the Avail ecosystem and the broader Web3 space. The core concept behind Fusion is that a unified system requires unified security at an economic level. Fusion Security enhances Avail’s consensus by leveraging native assets from established ecosystems like BTC and ETH, contributing security to the Avail consensus. This marks the first attempt to use external tokens to achieve consensus across blockchains.

Fusion supports two types of asset staking: established cryptocurrencies and emerging Rollup tokens. Currently, Fusion’s prototype includes two staking modules: one operating on the Avail blockchain and another for asset conversion staking. It’s important to note that the first public prototype of Avail Fusion is still under development.

Node Types in Avail

Although Avail’s architecture differs from traditional monolithic blockchains, it still supports various types of nodes, including full nodes, light clients, archive nodes, and validator nodes.

• Full Node: Full nodes are responsible for downloading and verifying the correctness of blocks, but they do not participate in the consensus process. While full nodes provide additional redundancy and resilience to the system, they are not essential for network functionality.
• Validator Node: Validator nodes are crucial in generating blocks, determining which transactions to include, and maintaining the order. These nodes help the network reach a consensus.
• Light Client: Light clients allow users to interact with Avail’s data availability (DA) layer without running a full node or relying on remote peer nodes. They achieve this by performing Data Availability Sampling (DAS) on every newly created block, ensuring data availability without downloading the entire block.
• RPC Node: RPC nodes provide an API for remote interaction, acting as a gateway for developers and external users to interact with the Avail network.

Light clients monitor confirmed blocks on the Avail network and perform DAS on pre-designated data units within each new block. Upon successful verification, the system calculates the certainty of a subset of data units within the block, based on the confidence level required by the user.

Economic Model

Token Distribution

With the launch of the Avail DA mainnet, the team airdropped AVAIL tokens to eligible users, with a total supply of 10 billion tokens. The distribution breakdown is as follows:

• 6% for airdrops and public allocation
• 30% for ecosystem development
• 23.88% for community and research
• 14.12% allocated to investors
• 20% allocated to core contributors

Source: Avail Official Documentation

Staking

The AVAIL token serves multiple purposes, including ecosystem governance and liquid staking. While the official governance framework has not been fully detailed, anyone can stake AVAIL across Avail’s infrastructure to earn staking rewards.

For staking, Avail adopts the Nominated Proof-of-Stake (NPoS) consensus mechanism, inherited from the Substrate ecosystem. Staking plays a critical role in this system, as users stake AVAIL tokens to enhance network security and earn rewards. The more tokens staked, the more secure the network becomes, as the cost to attack the network increases with the amount of staked tokens.

Staking applications include:

• Avail DA Staking: Users can stake AVAIL tokens to validators or nomination pools to secure the network and support different applications, such as Web3 games and DeFi platforms. Stakers earn rewards for their contributions.
• Avail Nexus Staking: Sequencers are required to stake AVAIL tokens to participate in transaction submission and ordering. High-performing sequencers are rewarded while underperforming ones are penalized.
• Avail Fusion Staking: Besides AVAIL tokens, users can stake other major crypto assets like BTC and ETH to enhance network security, with stakers earning rewards.

It’s important to note that users who wish to unstake their tokens must undergo a 28-day unbonding period, during which their AVAIL tokens cannot be used or transferred.

Challenges

Rollup Competition Risk

Avail’s growth could be challenged by large, general-purpose rollups that have established ecosystems and internal interoperability solutions. These rollups may eventually no longer rely on external interoperability systems, which could diminish the value of Avail Nexus. However, the surge in application-specific rollups and the high degree of fragmentation users face make this scenario less likely.

Competition in DA Solutions

With multiple data availability (DA) solutions, such as Celestia and EigenDA, and Ethereum’s upcoming EIP-4844, which introduces “blobs” as a data publication option, competition in the DA layer is intensifying. Rollups’ sensitivity to data publishing costs and the fierce competition between DA solutions may drive them to prefer established DA systems or rely on Ethereum’s native data availability, especially once full danksharding is implemented. This could potentially impact the adoption of Avail’s DA solution.

Shared Security Risk

The shared security model provided by Avail Fusion relies on staking multiple assets alongside the AVAIL token, which may raise concerns among users about the security of these various assets. Some developers may prefer to derive security from a single, well-established asset like ETH or BTC rather than depending on multiple tokens. Additionally, developers may shift towards DA solutions with stronger economic security if Avail Fusion fails to offer sufficient security.

Competition from Value-Added Service Ecosystems

Other restaking or shared security products may develop value-added service ecosystems catered to rollups. For instance, EigenLayer could offer decentralized sequencing, data availability, and fast finality services, making it more competitive. These additional features may attract developers seeking a more comprehensive and secure solution.