What is Avail?
Avail is solving fundamental scaling problems and addressing the fragmentation experienced today by users interacting across different ecosystems.
Avail solves these problems from first principles, solving scalability with a validity-proof-based DA layer leveraging data availability sampling and a network of light clients. This provides a solid foundation with scalable blobspace for networks of rollups to be built on top and can be leveraged by other blockchain ecosystems too.
Avail Nexus is a permissionless verification hub that will unify rollups and other blockchains (not just those built within the Avail ecosystem), leveraging Avail DA as the root of trust and provide users with a unified experience.
Then, Avail Fusion will provide unified economic security, securing the unification layer.
Together the Avail Stack will re-define the way rollups and blockchains communciate and co-ordinate across the entire blockchain ecosystem
What is the Avail Trinity?
- Avail DA - A data availability layer, designed to scale blockchains.
- Avail Nexus - A permissionless verification hub for zk proof aggregation.
- Avail Fusion - a unified economic security layer
Is Avail DA the same as Celestia?
Celestia is doing amazing work and they have helped move the industry forward. The level of responsiveness we need to enable a unified web3 ecosystem relies upon a validity proof based modular DA construction. Avail was designed from the ground up, leveraging first principles thinking to enable a unification layer for web3, and it achieves this by leveraging validity proofs on the DA layer and DAS.
Is Avail DA the same as Eigen DA?
Avail is building a unification layer for web3 which is why we needed to build Avail DA from the ground up. Eigenlayer is doing great work, and their restaking model helped inspire our Fusion Security model, albeit with some important modifications for our use case.
Is Avail pivoting away from DA?
We have always been building towards a unified web3. Avail DA has been the primary focus for the team so far, however it was built using first principles thinking to identify how a modular DA layer could lay the foundation for a unified web3. The design choices that went into building Avail DA were done so with the unification thesis in mind.
Is Avail Fusion the same as restaking?
The inspiration for Fusion came from:
- Eigenlayer, that is pioneering the restaking of ETH in services that operate independently of Ethereum’s consensus mechanism or full validator set
- Babylon Chain, that is creating a platform that allows the use of BTC (Bitcoin) for security across different blockchain networks
- Osmosis, that pioneered mesh security that allows a chain to borrow economic security from other chains
Fusion is a construction that is similar to, but also different from these approaches. It borrows economic security from other assets, but penalizes both safety and liveness failures in the Avail consensus.
Is Avail Nexus the same as Polygon AggLayer, zkSync Hyperchain, Optimism Superchain or similar efforts?
Avail Nexus is actually complementary to such efforts and would take aggregated execution proofs from each of these ecosystems as input to power the Nexus. Of course, Nexus will have its own proof aggregation engine that will allow composability of these proofs along with custom zk rollups and other sovereign chains building on Avail DA. The core attribute of Nexus is the combination of execution proofs and DA proofs. The former comes from the rollups/ecosystems. The latter need to be verified using DAS, which is where Avail DA shines. The Nexus construction is optimal on a specialised DA layer that implements DAS with validity proofs.
Together, Nexus aims to unify and coordinate the rollup centric future.
How does the technology work?
Avail lays a foundation for a unified web3 experience by providing the fundamentals needed to connect chains across different ecosystems. Avail’s use of validity proofs make DA proof verification simple and scalable. It also provides a robust and permissionless intersection point for different chains to coordinate via responsive proof aggregation. Only a common DA layer can provide shared security over which inter-rollup trust minimized communication can work. Different chains can coordinate via Avail Nexus and leverage its sequencer selection mechanism for inclusion. Fusion Security takes the native assets of the most mature ecosystems such as BTC, ETH and others, and allows them to contribute to the Avail consensus and economic security.
The initial launch (Avail DA) will allow any developer to plug into the infrastructure maintained by the Avail DA validator network and harness cutting-edge zero knowledge and KZG Polynomial commitments to ensure immediate and reliable data integrity for their blockchains, paving the way for Nexus and a unified web3.
What are some of the Key Features of Avail DA?
- 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.
What are the benefits for Sovereign Rollups and Validiums in using Avail DA?
- 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.
What is Data Availability?
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.
Why do rollups require data availability?
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.
What is data availability sampling?
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.
What is a light client?
Light clients allow users to interact with a blockchain network without having to sync the full blockchain while maintaining decentralization and security. Generally, they download the blockchain headers, but not the contents of each block. Avail (DA) light clients additionally verify that block contents are available by performing Data Availability Sampling, a technique where small random sections of a block are downloaded.
What are the popular use cases of Light Clients?
There are many use cases that today rely on an intermediary to maintain a full node, such that end users of a blockchain do not communicate directly with the blockchain but instead through the intermediary. Light clients have until now not been a suitable replacement for this architecture because they lacked data availability guarantees. Avail solves this issue, thus enabling more applications to directly participate on the blockchain network without intermediaries. Although Avail does support full nodes, we expect most applications will not need to run one, or will need to run fewer.
How is erasure coding used to increase data availability guarantees?
Erasure coding is a technique that encodes data in a way that spreads out the information over multiple ‘shards’, such that the loss of some number of those shards can be tolerated. That is, the information can be reconstructed from the other shards. Applied to the blockchain, this means that we effectively increase the size of each block, but we prevent a malicious actor from being able to hide any part of a block up to the redundant shard size. Since a malicious actor needs to hide a large part of the block in order to attempt to hide even a single transaction, it makes it much more likely that random sampling would catch the large gaps in the data. Effectively, erasure coding makes the data availability sampling technique much more powerful.
What are KZG commitments?
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.
Since Avail DA is used by multiple applications, does that mean chains have to download transactions from other chains?
No. Avail headers contain an index that allows a given application to determine and download only the sections of a block that have data for that application. Thus, they are largely unaffected by other chains using Avail at the same time or by block sizes.
The only exception is data availability sampling. In order to verify that data is available (and due to the nature of erasure coding), clients sample small parts of the block at random, including possibly sections that contain data for other applications.
Is DA guaranteed by Avail DA?
If you use Avail as the Data Availability layer for your app/rollup/blockchain, you will inherit the security and guarantees of the Avail network and blockchain.
Avail runs on a nominated proof-of-stake blockchain network built using the Polkadot SDK which helps to reduce the risk of validator centralization, and is working towards supporting up to 1,000 external validators in the active set.
What are the costs of a typical data-centered transaction on Ethereum vs Avail today, and is that expected to change?
If you use Avail for DA instead of Ethereum you get a ~90% cost reduction with respect to publishing data which is millions of dollars a month for e.g. Optimism, Arbitrum etc. at the time of writing.
Ethereum is working on EIP-4844 to bring these costs down and later full-danksharding. Avail has already implemented many of the core features such as Data Availability Sampling which are still projected to be years away for Ethereum. We also assume demand for blockspace will outstrip Ethereum’s capacity as Rollups become more prevalent over time.
To see how Avail compares with other DA solutions check out this post.
What are some example apps that run or will run on Avail DA?
The Web3 game engine from Paima Studios will run on Avail. There’s also a lot of integrations with the major L2s underway which would enable any appchain or rollup to begin using Avail as the DA layer. Avail’s a general purpose DA solution so many integrations with Avail are possible.
Technically, any Blockchain app could run on it and it can support apps across different ecosystems i.e. multiple VMs. You could have an app running on EVM and one running on SVM and they could both work on Avail for example.
What process would I use to integrate my app with Avail?
If you’re building an app from scratch there are a number of Rollup-as-a-Service providers you can use which allow you to spin up a new chain using Avail as the DA layer, such as:
If you’re building within one of the Major L2s there’s a number of different ways to integrate Avail’s DA layer into your system. You can also get started by referring to our documentation.
How can I get involved?
- Use Avail DA for your chain
- Run a Validator
- Run a light client
- Join Discord
- Follow us on X
- Join the Avail Uncharted Technical Contributor’s program
