Five features you need to know that make Avail unique.

On July 23, 2024, after a long wait, the Avail mainnet was finally launched. As the name suggests, Avail is a data availability (DA) layer project. Many might think, "Isn't Avail just another DA project like Celestia or EigenDA?" However, this is not the case.

A look at Avail's roadmap reveals that Avail is more than just a DA project; it is a vertically-integrated unification layer. While there are already numerous articles in the community explaining Avail, this article will focus on Avail's strengths compared to other DA projects. For those interested in learning the basics of Avail, please refer to the following articles:

• Avail: A Unification of Crypto Infrastructure by Blockworks

• $AVAIL & the Unification of Web3 by Redacted Research

Avail's most significant advantage over other DA layers is its enshrined settlement layer, called Avail Nexus, which supports trust-minimized interoperability among rollups.

For secure bridging, it is essential to know both the canonical chain of the counterparty network and the validity of execution. Sovereign rollups sharing the same DA layer publish transaction data on the same DA layer, making it easy to know the canonical chain of the counterparty network. However, sharing the DA layer alone does not make it easy to verify execution validity on the counterparty network.

Thus, methods for enabling trust-minimized cross-chain messaging among sovereign rollups have been discussed, the most notable being IBC messaging among Cosmos SDK-based rollups. In IBC, trust-minimized bridging is achieved by verifying the counterparty network's block headers and Merkle proofs through a light client.

But what about sovereign rollups that do not use the Cosmos SDK? They still need to verify the execution validity of the counterparty network through a light client. Differences in VMs, proof schemes (fraud proof vs. validity proof), or zk proof systems can make it extremely challenging to build a verifying system for trust-minimized bridging.

Furthermore, if bridging between sovereign rollups is done in a point-to-point manner instead of a hub-and-spoke model, the bridging system becomes fragmented. Each new channel requires a new system, and numerous types of wrapped tokens may arise, causing fungibility issues even among the same type of tokens.

Thus, for safety and a seamless user experience in bridging among rollups sharing the same DA layer, it is necessary to verify execution with a unified system and adopt a hub-and-spoke bridging model sharing a single settlement layer.

This is actually what Avail Nexus does. Avail Nexus is a zk sovereign rollup built on Avail, serving as the enshrined settlement layer for the Avail ecosystem. Avail Nexus handles both 1) sequencer auctions and 2) proof aggregation, enabling the rollups within the Avail ecosystem to achieve trust-minimized cross-chain messaging quickly and efficiently.

Avail Nexus aggregates and verifies various types of proofs from multiple rollups, then consolidates them into a single succinct proof. Not only validity rollups, but even optimistic rollups can participate in Avail Nexus. Optimistic rollups can submit their receipts and state roots to Nexus, and if no fraud proofs are presented during the challenge period, they are included in the Nexus state.

The aggregated proof is eventually submitted to both Avail DA and Ethereum. Since Avail DA lacks an execution layer, a module will be added in the future to verify the proof. Rollups on Avail Nexus, having their state information verified on the Ethereum network, operate under the same security assumptions as validiums using Ethereum as a settlement layer.

Avail DA employs the KZG commitment scheme for validity proofs, allowing light clients to verify data availability quickly and succinctly. Additionally, due to the homomorphic properties of KZG commitments, there's no need for fraud proofs to verify the correctness of erasure coding, eliminating delays caused by challenge periods.

In cryptography, a commitment is a method to commit to a piece of data at one point and reveal it later, proving the original data. Commitments are often used to compress or hide data. The two key properties of commitments are binding and hiding.

• Binding: Once data is committed, it cannot be changed, ensuring integrity.

• Hiding: The original data cannot be inferred from the commitment.

A common commitment scheme in blockchain is the Merkle tree, which compresses information into a single value that does not reveal the original data, and easily verifies whether specific data is included in the Merkle tree.

The KZG polynomial commitment scheme commits to a polynomial. Data can be transformed into a polynomial, which has a single commitment value of fixed size. The advantage of the KZG commitment is that a verifier can easily prove the inclusion of specific data with a very small-sized KZG proof (O(1)). This is a significant benefit compared to the Merkle tree, where the proof size grows logarithmically (O(logN)) with the data size.

Let's delve into how data is stored in Avail DA and the process of verifying data availability. When a user (rollup) sends transaction data to Avail, the data is arranged into a two-dimensional matrix. Erasure coding is then used to generate redundant data, effectively doubling the original data.

Because the data is expanded to twice its size, a malicious block producer would have to hide more than half of the data to keep it concealed, making detection highly probable during the data availability sampling process. The data in each row is transformed into a polynomial, and a KZG polynomial commitment for this data is included in the block header. Here's what KZG commitment enables:

1. Light clients can quickly and easily verify data availability: If a light client wants to check whether specific data is included in a block, the full node can provide a very small KZG proof(O(1)), thanks to the KZG commitment.

2. No need for fraud proofs to verify the correctness of erasure coding: In Celestia, fraud proofs are used to verify the correctness of erasure coding, which can cause delays due to the challenge period. Because KZG commitment is homomorphic, the correctness of erasure coding can be quickly verified by checking if the commitments of the erasure-coded data match the erasure-coded commitments.

Most blockchain networks typically focus on either safety or liveness in their consensus mechanisms. Avail DA, built on the substrate (Polkadot SDK), uses BABE and GRANDPA for its consensus mechanisms, providing a balance of both liveness and safety similar to Ethereum.

BABE is Avail's block production engine responsible for liveness. Every slot (20 seconds), a primary author is chosen via VRF to produce a block. There can be multiple authors or none at all within a slot. If multiple authors are selected, a race starts, and the block propagated the most becomes part of the canonical chain. If no primary author is chosen, a secondary author selected via a round-robin method produces the block.

GRANDPA acts as a finality gadget similar to Ethereum's Casper FFG but differs in that it finalizes the canonical chain rather than individual blocks, leading to a faster finalization process. In a synchronous environment, more than two-thirds of the nodes need to be honest for finality, and in an asynchronous setting, it can handle up to one-fifth Byzantine nodes.

Avail Fusion allows tokens from other ecosystems to contribute to the crypto-economic security of the Avail ecosystem. Protocols like EigenLayer, Babylon, Symbiotic, and Karak are gaining attention for leveraging the vast security of BTC and ETH. With the implementation of Avail Fusion, the security level of the Avail ecosystem is expected to be significantly enhanced. A common criticism of Optimium and Validium is their weakened security due to reliance on external DA layers. Avail DA with Avail Fusion could mitigate these criticisms.

Interestingly, rollup tokens on Avail can also be utilized within Avail Fusion. One of the biggest gaps in rollup tokenomics is the lack of utility beyond governance. Avail Fusion can address this by using rollup tokens for crypto-economic security, thus enhancing their productivity and accelerating the ecosystem’s incentive flywheel.

However, one concern is the distribution of rewards. If tokens from other ecosystems are used in consensus and receive block rewards, the relative rewards for AVAIL stakers might decrease. Therefore, a sophisticated design for the staking and reward ratios of external ecosystem tokens will be necessary when introducing Avail Fusion.

Tokenomics is both the most promising area and a chronic issue in the crypto industry. While tokens can serve as the lubricant that ensures a protocol functions smoothly, poor design or lack of utility can turn them into a detriment.

Fortunately, Avail offers a diverse range of uses for the AVAIL token through its concept of a unification layer, which integrates multiple layers and features internally, unlike many other protocols:

• Governance

• DA fees

• Avail DA security

• Staking to participate in the sequencer pool in Nexus

• Staking to participate in the proof aggregator pool in Nexus

• Bridging fees

Considering the functionalities of each layer and the token utilities, Avail can be seen as a combination of a DA layer, a decentralized sequencing layer, and a ZKP aggregation layer. This highlights the immense potential growth of the Avail ecosystem.

While the modular ecosystem has advanced significantly within Ethereum, modular ecosystems outside of Ethereum are still immature in terms of interoperability and security. Avail, through Avail DA, Avail Nexus, and Avail Fusion, offers effective solutions to these issues, making it an ideal modular ecosystem.

Just like the ongoing infrastructure vs. app debate, even if Avail builds the perfect infrastructure, the real challenge will be to create a dynamic ecosystem. However, there is little need for concern. According to the Avail ecosystem page, Avail is already integrated to many rollup SDKs, including Arbitrum Orbit and Polygon CDK. Numerous RaaS platforms like Conduit and AltLayer also support Avail DA, and a total of 32 rollup networks are set to onboard onto Avail DA.

In recent years, the modular ecosystem has become more diverse and extensive. Numerous modular projects (e.g., rollups, DA layers) are entering the market, and to survive in this competitive environment, a project must have unique strengths. Avail, with its concept of a unification layer, performs functions such as DA, sequencing, ZKP aggregation, and restaking, securing a unique position in the market. Therefore, Avail's upcoming journey would be definitely one to watch with excitement.

Disclosure: I’m holding an investment position in Avail. This article is provided solely for informational purposes and should not be construed as financial advice.

Five features you need to know that make Avail unique.

On July 23, 2024, after a long wait, the Avail mainnet was finally launched. As the name suggests, Avail is a data availability (DA) layer project. Many might think, "Isn't Avail just another DA project like Celestia or EigenDA?" However, this is not the case.

A look at Avail's roadmap reveals that Avail is more than just a DA project; it is a vertically-integrated unification layer. While there are already numerous articles in the community explaining Avail, this article will focus on Avail's strengths compared to other DA projects. For those interested in learning the basics of Avail, please refer to the following articles:

• Avail: A Unification of Crypto Infrastructure by Blockworks

• $AVAIL & the Unification of Web3 by Redacted Research

Avail's most significant advantage over other DA layers is its enshrined settlement layer, called Avail Nexus, which supports trust-minimized interoperability among rollups.

For secure bridging, it is essential to know both the canonical chain of the counterparty network and the validity of execution. Sovereign rollups sharing the same DA layer publish transaction data on the same DA layer, making it easy to know the canonical chain of the counterparty network. However, sharing the DA layer alone does not make it easy to verify execution validity on the counterparty network.

Thus, methods for enabling trust-minimized cross-chain messaging among sovereign rollups have been discussed, the most notable being IBC messaging among Cosmos SDK-based rollups. In IBC, trust-minimized bridging is achieved by verifying the counterparty network's block headers and Merkle proofs through a light client.

But what about sovereign rollups that do not use the Cosmos SDK? They still need to verify the execution validity of the counterparty network through a light client. Differences in VMs, proof schemes (fraud proof vs. validity proof), or zk proof systems can make it extremely challenging to build a verifying system for trust-minimized bridging.

Furthermore, if bridging between sovereign rollups is done in a point-to-point manner instead of a hub-and-spoke model, the bridging system becomes fragmented. Each new channel requires a new system, and numerous types of wrapped tokens may arise, causing fungibility issues even among the same type of tokens.

Thus, for safety and a seamless user experience in bridging among rollups sharing the same DA layer, it is necessary to verify execution with a unified system and adopt a hub-and-spoke bridging model sharing a single settlement layer.

This is actually what Avail Nexus does. Avail Nexus is a zk sovereign rollup built on Avail, serving as the enshrined settlement layer for the Avail ecosystem. Avail Nexus handles both 1) sequencer auctions and 2) proof aggregation, enabling the rollups within the Avail ecosystem to achieve trust-minimized cross-chain messaging quickly and efficiently.

Avail Nexus aggregates and verifies various types of proofs from multiple rollups, then consolidates them into a single succinct proof. Not only validity rollups, but even optimistic rollups can participate in Avail Nexus. Optimistic rollups can submit their receipts and state roots to Nexus, and if no fraud proofs are presented during the challenge period, they are included in the Nexus state.

The aggregated proof is eventually submitted to both Avail DA and Ethereum. Since Avail DA lacks an execution layer, a module will be added in the future to verify the proof. Rollups on Avail Nexus, having their state information verified on the Ethereum network, operate under the same security assumptions as validiums using Ethereum as a settlement layer.

Avail DA employs the KZG commitment scheme for validity proofs, allowing light clients to verify data availability quickly and succinctly. Additionally, due to the homomorphic properties of KZG commitments, there's no need for fraud proofs to verify the correctness of erasure coding, eliminating delays caused by challenge periods.

In cryptography, a commitment is a method to commit to a piece of data at one point and reveal it later, proving the original data. Commitments are often used to compress or hide data. The two key properties of commitments are binding and hiding.

• Binding: Once data is committed, it cannot be changed, ensuring integrity.

• Hiding: The original data cannot be inferred from the commitment.

A common commitment scheme in blockchain is the Merkle tree, which compresses information into a single value that does not reveal the original data, and easily verifies whether specific data is included in the Merkle tree.

The KZG polynomial commitment scheme commits to a polynomial. Data can be transformed into a polynomial, which has a single commitment value of fixed size. The advantage of the KZG commitment is that a verifier can easily prove the inclusion of specific data with a very small-sized KZG proof (O(1)). This is a significant benefit compared to the Merkle tree, where the proof size grows logarithmically (O(logN)) with the data size.

Let's delve into how data is stored in Avail DA and the process of verifying data availability. When a user (rollup) sends transaction data to Avail, the data is arranged into a two-dimensional matrix. Erasure coding is then used to generate redundant data, effectively doubling the original data.

Because the data is expanded to twice its size, a malicious block producer would have to hide more than half of the data to keep it concealed, making detection highly probable during the data availability sampling process. The data in each row is transformed into a polynomial, and a KZG polynomial commitment for this data is included in the block header. Here's what KZG commitment enables:

1. Light clients can quickly and easily verify data availability: If a light client wants to check whether specific data is included in a block, the full node can provide a very small KZG proof(O(1)), thanks to the KZG commitment.

2. No need for fraud proofs to verify the correctness of erasure coding: In Celestia, fraud proofs are used to verify the correctness of erasure coding, which can cause delays due to the challenge period. Because KZG commitment is homomorphic, the correctness of erasure coding can be quickly verified by checking if the commitments of the erasure-coded data match the erasure-coded commitments.

Most blockchain networks typically focus on either safety or liveness in their consensus mechanisms. Avail DA, built on the substrate (Polkadot SDK), uses BABE and GRANDPA for its consensus mechanisms, providing a balance of both liveness and safety similar to Ethereum.

BABE is Avail's block production engine responsible for liveness. Every slot (20 seconds), a primary author is chosen via VRF to produce a block. There can be multiple authors or none at all within a slot. If multiple authors are selected, a race starts, and the block propagated the most becomes part of the canonical chain. If no primary author is chosen, a secondary author selected via a round-robin method produces the block.

GRANDPA acts as a finality gadget similar to Ethereum's Casper FFG but differs in that it finalizes the canonical chain rather than individual blocks, leading to a faster finalization process. In a synchronous environment, more than two-thirds of the nodes need to be honest for finality, and in an asynchronous setting, it can handle up to one-fifth Byzantine nodes.

Avail Fusion allows tokens from other ecosystems to contribute to the crypto-economic security of the Avail ecosystem. Protocols like EigenLayer, Babylon, Symbiotic, and Karak are gaining attention for leveraging the vast security of BTC and ETH. With the implementation of Avail Fusion, the security level of the Avail ecosystem is expected to be significantly enhanced. A common criticism of Optimium and Validium is their weakened security due to reliance on external DA layers. Avail DA with Avail Fusion could mitigate these criticisms.

Interestingly, rollup tokens on Avail can also be utilized within Avail Fusion. One of the biggest gaps in rollup tokenomics is the lack of utility beyond governance. Avail Fusion can address this by using rollup tokens for crypto-economic security, thus enhancing their productivity and accelerating the ecosystem’s incentive flywheel.

However, one concern is the distribution of rewards. If tokens from other ecosystems are used in consensus and receive block rewards, the relative rewards for AVAIL stakers might decrease. Therefore, a sophisticated design for the staking and reward ratios of external ecosystem tokens will be necessary when introducing Avail Fusion.

Tokenomics is both the most promising area and a chronic issue in the crypto industry. While tokens can serve as the lubricant that ensures a protocol functions smoothly, poor design or lack of utility can turn them into a detriment.

Fortunately, Avail offers a diverse range of uses for the AVAIL token through its concept of a unification layer, which integrates multiple layers and features internally, unlike many other protocols:

• Governance

• DA fees

• Avail DA security

• Staking to participate in the sequencer pool in Nexus

• Staking to participate in the proof aggregator pool in Nexus

• Bridging fees

Considering the functionalities of each layer and the token utilities, Avail can be seen as a combination of a DA layer, a decentralized sequencing layer, and a ZKP aggregation layer. This highlights the immense potential growth of the Avail ecosystem.

While the modular ecosystem has advanced significantly within Ethereum, modular ecosystems outside of Ethereum are still immature in terms of interoperability and security. Avail, through Avail DA, Avail Nexus, and Avail Fusion, offers effective solutions to these issues, making it an ideal modular ecosystem.

Just like the ongoing infrastructure vs. app debate, even if Avail builds the perfect infrastructure, the real challenge will be to create a dynamic ecosystem. However, there is little need for concern. According to the Avail ecosystem page, Avail is already integrated to many rollup SDKs, including Arbitrum Orbit and Polygon CDK. Numerous RaaS platforms like Conduit and AltLayer also support Avail DA, and a total of 32 rollup networks are set to onboard onto Avail DA.

In recent years, the modular ecosystem has become more diverse and extensive. Numerous modular projects (e.g., rollups, DA layers) are entering the market, and to survive in this competitive environment, a project must have unique strengths. Avail, with its concept of a unification layer, performs functions such as DA, sequencing, ZKP aggregation, and restaking, securing a unique position in the market. Therefore, Avail's upcoming journey would be definitely one to watch with excitement.

Disclosure: I’m holding an investment position in Avail. This article is provided solely for informational purposes and should not be construed as financial advice.