Author: 100y.eth Source: mirror Translation: Shanooba, Golden Finance

After a long wait, Avail Mainnet finally went live on July 23, 2024. As the name suggests, Avail is a Data Availability (DA) layer project. Many people may ask, "Isn't Avail just another DA project like Celestia or EigenDA?" However, this is not the case.

From Avail's roadmap, it can be seen that Avail is not just a DA project, but a vertically integrated unified layer. Although there are already many articles in the community introducing Avail, this article will focus on the advantages of Avail compared to other DA projects. If you are interested in learning the basics of Avail, please refer to the following articles:

• Avail: Blockworks's encryption infrastructure unified
• Redacted Research's $AVAIL and the unity of Web3

1. Minimized trust interoperability and fixed Settlement layer

Compared with other DA layers, Avail's most significant advantage is its fixed settlement layer, called Avail Nexus, which supports interoperability with minimal trust between aggregations.

1.1 Why do we need a unified proof system for the hub-and-spoke model?

To achieve a secure bridge, it is crucial to understand the specification chain and the validity of execution on the opponent's network. Sovereign aggregations sharing the same DA layer publish transaction data on the same DA layer, making it easy to understand the specification chain of the opponent's network. However, it is not easy to verify the validity of execution on the opponent's network by only sharing the DA layer.

Therefore, methods for achieving trust-minimized Cross-Chain Interaction message passing between sovereign Rollups have been discussed, with the most notable being the IBC message passing between Rollups based on the Cosmos SDK. In IBC, trust-minimized bridge is achieved through light client verification of the counterpart network's block headers and Merkle proofs.

However, what about the sovereignty aggregation that does not use the Cosmos SDK? They still need to verify the execution validity of the counterpart network through the light client. Differences in Virtual Machine, proof schemes (fraud proof and validity proof), or zk proof systems may make it extremely challenging to build a minimal trust bridge verification system.

In addition, if the bridge between sovereign aggregations is done in a peer-to-peer manner rather than a central radiation model, the bridge system will become fragmented. Each new channel requires a new system, and there may be multiple types of wrapped tokens, resulting in interoperability issues even among tokens of the same type.

Therefore, in order to ensure the security and seamless user experience of bridge between the aggregation of the same DA layer, it is necessary to use a unified system to verify the execution and adopt a hub-and-spoke bridge model for sharing a single settlement layer.

1.2 Using Nexus

This is actually what Avail Nexus does. Avail Nexus is a zk-based sovereign aggregation built on Avail, serving as a fixed Settlement layer of the Avail ecosystem. Avail Nexus handles 1) sequencer auctions and 2) proof aggregation, enabling the aggregation in the Avail ecosystem to achieve trust-minimized Cross-Chain Interaction message delivery quickly and efficiently.

Avail Nexus will aggregate and verify various types of proofs from multiple rollups, and then merge them into a concise proof. Not only validity rollups, optimistic rollups can also participate in Avail Nexus. Optimistic rollups can submit their receipts and state roots to Nexus, and if no fraud proof is provided during the challenge period, they will be included in the Nexus state.

The aggregated proof will eventually be submitted to Avail DA and Ethereum. Due to the lack of an execution layer in Avail DA, a module will be added in the future for proof of validation. The state information of Rollups on Avail Nexus is verified on the Ethereum network, and its security assumptions are the same as validiums that use Ethereum as the settlement layer.

2. Using KZG Commitment Scheme for Fast Verification

Avail DA adopts the KZG commitment scheme for validity proof, allowing light clients to quickly and succinctly verify data availability. In addition, due to the homomorphic properties of the KZG commitment, the correctness of erasure coding can be verified without fraud proof, eliminating the latency caused by challenge periods.

2.1 ELI5: KZG Commitment

In cryptography, a commitment is a method of committing a piece of data at a certain moment and revealing it later to prove the original data. Commitments are often used for compressing or hiding data. The two key properties of a commitment are binding and hiding.

• Binding: Once data is submitted, it cannot be changed, ensuring integrity.
• Hidden: The original data cannot be inferred from the commitment.

A common commitment scheme in the Block chain is the Merkle tree, which compresses information into a single value that does not leak the original data and can easily verify whether specific data is included in the Merkle tree.

KZG polynomial commitment scheme commits to a polynomial whose data can be translated into a polynomial with a single commitment value of fixed size. The advantage of KZG commitment is that validators can easily prove the inclusion of specific data with very small KZG proof (O(1)). This is a significant advantage compared to Merkle trees, where proof size grows logarithmically with data size (O(logN)).

2.2 KZG's Commitment in Avail

Let's take a closer look at the data storage method and the process of validating data availability in Avail DA. When a user (rollup) sends transaction data to Avail, the data is arranged into a two-dimensional matrix. Then, redundant data is generated using erasure coding, effectively doubling the original data.

As the data volume doubles, malicious Block producers must hide more than half of the data in order to conceal it, so this behavior is highly likely to be detected during the data availability sampling process. The data in each line is converted into a polynomial, and the KZG polynomial commitment of this data is included in the Block Header. Here are the functionalities achieved by KZG commitment:

1. The light client can quickly and easily verify the availability of data: if the light client wants to check whether specific data is included in a certain block, thanks to the KZG commitment, the full Node can provide a very small KZG proof (O(1)).
2. Verification of erasure coding correctness without fraud proof: In Celestia, fraud proof is used to verify the correctness of erasure coding, which may cause latency due to challenge periods. Since KZG commitments are homomorphic, the correctness of erasure coding can be quickly verified by checking if the commitment of erasure coding data matches the erasure coding commitment.

3. Implementing Security and Liveness with BABE and GRANDPA

Most Blockchain networks typically focus on the security or liveliness of their Consensus Mechanism. Avail DA, built on top of Polkadot SDK, uses BABE and GRANDPA as its Consensus Mechanism, providing a balance of liveliness and security similar to Ethereum.

3.1 Blind Assignment for Blockchain Extension (BABE)

BABE is Avail's Block production engine, responsible for ensuring liveness. In each slot (20 seconds), a primary author is selected through VRF to produce a Block. There can be multiple authors or no author within a slot. If multiple authors are selected, a competition begins, and the Block with the most propagations becomes part of the canonical chain. If no primary author is selected, a secondary author chosen through a round-robin method will produce the Block.

3.2 GHOST-based recursive ancestor-derived prefix protocol (GRANDPA)

GRANDPA acts as a finality gadget, similar to Casper FFG in Ethereum, but differs in that it finalizes a canonical chain rather than an individual Block, thus speeding up the finalization process. In synchronous environments, over two thirds of Nodes need to be honest to establish finality, while in asynchronous settings it can handle up to one fifth Byzantine Nodes.

4. An ecosystem with strong encryption economic security

(Avail Fusion | Source: Avail)

Avail Fusion allows tokens from other ecosystems to contribute to the encryption security of the Avail ecosystem. Protocols such as EigenLayer, Babylon, Symbiotic, and Karak are followed due to the immense security of BTC and ETH. With the implementation of Avail Fusion, the security level of the Avail ecosystem is expected to significantly improve. A common criticism of Optimium and Validium is that their security is weakened by relying on external DA layers. Avail DA with Avail Fusion can alleviate these criticisms.

Interestingly, rollup Tokens on Avail can also be used in Avail Fusion. One of the biggest drawbacks of rollup Tokenomics is the lack of practicality outside of governance. Avail Fusion can address this issue by implementing encryption economic security using rollup Tokens, thereby increasing its productivity and accelerating the incentive flywheel of the ecosystem.

However, a question worth following is the distribution of rewards. If Tokens from other ecosystems are used for Consensus and receive Block Rewards, the relative rewards for AVAIL stakers may decrease. Therefore, when introducing Avail Fusion, a complex design is needed for the stake and reward ratio of external ecosystem Tokens.

5. Various Token Utilities

Tokenomics is the most promising area in the encryption industry and a long-standing issue. Although tokens can act as a lubricant to ensure the smooth operation of protocols, poor design or lack of practicality may make them detrimental.

(Source: Avail)

Fortunately, Avail provides multiple uses for AVAIL Token through the concept of a unified layer, which sets it apart from many other protocols as it integrates multiple layers and functions internally.

• Governance
• DA Fee
• Provide DA security
• Participate in the Nexus sequence pool by staking
• Participate in the proof aggregation pool in Nexus 01928374656574839201
• Transition Fee

Considering the functionality and Token utility of each layer, Avail can be seen as a combination of the DA layer, Decentralization sorting layer, and ZKP aggregation layer. This highlights the huge potential rise of the Avail ecosystem.

6. Final Thoughts

Although the modular ecosystem within the Ethereum network has made significant progress, the modular ecosystem outside of Ethereum is still immature in terms of interoperability and security. Avail provides effective solutions to these issues through Avail DA, Avail Nexus, and Avail Fusion, making it an ideal modular ecosystem.

Just like the ongoing battle between infrastructure and applications, even if Avail builds perfect infrastructure, the real challenge is to create a dynamic ecosystem. However, there is nothing to worry about. According to the Avail Ecosystem page, Avail has already been integrated into many aggregation SDKs, including Arbitrum Orbit and Polygon CDK. Many RaaS platforms such as Conduit and AltLayer also support Avail DA, and a total of 32 aggregation networks will join Avail DA.

In recent years, the modular ecosystem has become more diverse and extensive. Many modular projects (such as rollup, DA layer) are entering the market, and in order to survive in this competitive environment, projects must have unique advantages. Avail, with its concept of a unified layer, performs functions such as DA execution, sorting, ZKP aggregation, and restake, occupying a unique position in the market. Therefore, the upcoming journey of Avail is definitely worth looking forward to.