FAQs

Avail aims to revolutionize the blockchain space by providing a trust-minimized and secure base layer focused on data availability. This base layer serves as the foundation for next-generation, trust-minimized applications and blockchains.

Traditional monolithic blockchains like Ethereum have faced scaling challenges due to handling multiple operations like Execution, Settlement, Ordering, and Data Availability on a single chain.

Avail adopts a modular approach, separating these core operations into different layers for greater scalability and flexibility. This allows Avail to provide a robust base layer designed to meet the needs of next-generation trust-minimized applications and rollups. Avail supports both traditional rollup designs like optimistic rollups and zk rollups, as well as new designs like sovereign rollups.

Avail is a blockchain-based platform focused on creating a general-purpose data availability layer, addressing key challenges such as scalability, governance, and decentralization. By enabling technologies like Validiums and Sovereign Rollups, Avail significantly reduces costs, enhances efficiency, and unlocks significant improvements in blockchain scalability.

• Designed to Scale: In Avail, block space can be added as demand grows (we call this elastic block size), with minimal impact to existing users (who do not need to download block data from other apps)
• No Execution Requirements: Avail is platform-agnostic. Applications/Rollups are free to use any execution environment, EVM, WASM, or even custom logic embedded into the application chain
• Data Blob Indexing: Avail simplifies data indexing by tying all transaction data to an application ID.
• Erasure Encoding: Adds redundancy to the data, making it harder for nodes to suppress information.
• KZG Polynomial Commitments: Ensures that the data has a footprint in the Avail block header.
• Decentralized Network of Validators: Avail aims to support up to 1,000 external validators to reduce centralization risks.
• Validity Proofs: Allows light clients to guarantee state correctness and data availability immediately after finalizing.

• Trust-Minimized Data Availability: Avail provides a secure and decentralized solution for data availability.
• Data Attestation Bridge: Allows for attestation to Ethereum and other EVM-compatible chains, proving that data is available.

Avail’s light client network ensures high data availability through Data Availability Sampling. As more light clients join the network, Avail can support bigger blocks, unlocking significant scaling potential for blockchains.

While an off-chain execution-based architecture (rollups) improves throughput, it is still limited by the amount of data that the main chain like Ethereum can handle. This is because although the execution is off-chain, the verification or dispute resolution is strictly on-chain. The transactional data is submitted as calldata on Ethereum to ensure that the data is available for future reconstruction. This is extremely important.

In case of optimistic rollups, the operator may submit invalid transactions and then suppress parts of the block to the world. This way, the other full nodes in the system will not be able to verify whether the submitted assertion is correct. Due to lack of data, they will not be able to produce any fraud-proof/challenge to show that the assertion is indeed invalid.

In the case of Zero-knowledge rollups, the ZKP soundness ensures that accepted transactions are valid. However, even with such guarantees, not revealing the data backing a transaction can have serious side effects. It may lead to other validators not being able to calculate the current state of the system.

In short, The DA layer guarantees that all necessary data is available for reconstructing the state of a rollup. Data Availability is not Data Storage. Data availability is the assurance that full nodes have been able to access and verify the full set of transactions associated with a specific block.

If you and I were to send 1 ETH back and forth to each other 100 times, we don’t need a record of all 100 transactions to be confident over who holds the ETH now. So long as we are confident that all transactions are valid, and we know who has the ETH now, we can still be confident about who the ETH’s current owner is. Theoretically, we could even drop the first 99 transactions. This is a key difference between data availability and data storage.

To learn more about the data availability problem check out this blog post that covers this in detail: blog.availproject.org

Both Optimistic and ZK Rollups have a need for data availability.

In the case of optimistic rollups, by ensuring the availability of data, the entire rollup block can be shared, allowing honest nodes in the network to verify the block’s validity and report any fraudulent activity using “Fraud Proofs”, hence ensuring the safety of the network.

In zkRollups, while data availability isn’t strictly required for rollup execution, it’s crucial for preventing the rollup from becoming inoperational. In the event that zkRollup validators cease producing blocks, it should be possible for new validators to replace them and resume block production. However, if the transactions within the zkRollup block are not made public, new validators won’t be able to reconstruct the chain’s state. This, in turn, would prevent them from producing new blocks and ultimately result in a frozen chain. To prevent this scenario, publishing all transactions is necessary to enable new validators to reconstruct the state, thereby maintaining an unfrozen chain.

Avail light clients, like other light clients, only download the headers of the blockchain. However, they additionally perform data availability sampling: a technique that randomly samples small sections of the block data and verifies they are correct. When combined with erasure coding and KZG polynomial commitments, Avail clients are able to provide strong (nearly 100%) guarantees of availability without relying on fraud proofs, and with only a small constant number of queries.

KZG commitments, introduced by Aniket Kate, Gregory M. Zaverucha, and Ian Goldberg in 2010, provide a way to commit to polynomials in a succinct manner. Recently, polynomial commitments came to the forefront, being primarily used as commitments in PLONK-like zero knowledge constructions.

In Avail’s construction, we use KZG commitments for the following reasons:

• It allows us to commit to values in a succinct manner to be kept inside the block header.
• Short openings are possible which helps a light client verify availability.
• The cryptographic binding property helps us avoid fraud proofs by making it computationally infeasible to produce incorrect commitments.

In the future, we might use other polynomial commitment schemes, if that gives us better bounds or guarantees.

Avail has not yet released any information regarding Tokenomics.

When this information becomes available, it will be added here.

Avail is a base modular layer for other blockchains to build on top, most notably rollups. These rollups could be validity proof-based, optimistic (fraud-proof based) or simply pessimistic rollups (all state transitions are re-executed). Avail provides consensus and data availability as a service at scale to rollups.

In other words, Avail provides raw blockspace to modular chains:
It makes sure data is sequenced, packaged into blocks, and published.
It segregates tx data on a per-app (rollup) basis, so multiple rollups can publish transactions but query only their own.
Avail will have a robust validator set of up to/around 1,000 that will sign off on published blocks, but that do not interpret the transaction data contained in those blocks.
Each rollup built on Avail is empowered to define how to interpret its own transactions. They can be completely custom (e.g., anything from EVM bytecode to app-specific state machines without a VM at all).

So you can think of it as a specialised Layer 1 on which Layer 2 rollups will work. The novel component is Data Availability Sampling light clients.

Avail will also be used to power Validiums / Optimistic chains which use Ethereum for settlement and will use Avail for data availability.

Both are data availability focused layers with different implementation tradeoffs. The biggest difference is that Celestia uses fraud proofs for DA whereas Avail uses validity proofs. Using either technique has some pros and some cons.

But ultimately both provide a valuable new ordering and data availability capability with random data sampling via light clients that enables a new class of scaling solutions – popularly termed sovereign rollups/chains.

Both us and them want to push forward the category of modular blockchains. Currently tooling for modular blockchains is at a pretty early stage and I suspect we will collaborate a lot in the future in bringing the tooling and the modular ecosystem at par with what is available on monolithic chains for developers.