It's the age of data availability in Web3 and modular blockchains! In today's article, we're diving into Avail. Avail is a modular blockchain that maintains a record of transactions and verifies the accessibility of the data. Avail's primary objective is to enhance the availability and organization of blockchain transaction data. It offers solutions that can be seamlessly integrated into various execution environments, enabling different types of blockchains to offload their data availability responsibilities while maintaining complete control over their respective chains.
As a data availability layer, blockchains can focus on what they do best while letting Avail take charge of the data availability challenges, enabling a faster and more scalable web3 ecosystem and new blockchain use cases. It proposes a new design with a basic consensus layer that only establishes agreement on the order of transaction data and its content without dealing with its validity. This leads to fast, highly scalable, and adaptable transactions supporting any blockchain.
Is There A Data Availability Problem?
So, let’s start from the beginning. “Traditional” blockchains - if there even is such a thing - are monolithic, which means they’re continuously spreading their processing power over different tasks—creating one big hiccup: limited data availability. To maintain a blockchain, multiple kinds of nodes collaborate. While blockchain nodes vary, there are usually three main types: block producers, light nodes, and full nodes.
- Block producers: block producers, also known as "miners" on Proof-of-Work (PoW) networks or "validators" on Proof-of-Stake (PoS) blockchains, are responsible for gathering and preserving transactions within the network, as well as generating new blocks.
- Light nodes: light nodes download and keep track of the header part of a block. Block headers contain a summary of the information in the block body. As a result, since they only have access to the headers, light nodes cannot participate in the verification process and must rely on the assumption that block producers are trustworthy.
- Full nodes: full nodes validate blocks by obtaining all block information from the block producers and comparing it to the consensus rules. This is done by downloading the block data and verifying its authenticity and compliance with the established consensus rules.
Creating a data availability (DA) layer that can efficiently store many transactions is a crucial goal for blockchain networks. One approach to increasing scalability is to heighten the block size and reduce the block time, allowing more transactions to be stored within the same time frame. However, this method can also have a downside. As the blockchain network scales at a rapid pace, the size of the ledger increases, and the hardware requirements for setting up a full node become more demanding, which can lead to some inefficiencies and potential centralization. As the number of full nodes decreases, it fundamentally undermines the network's decentralization, which is why blockchain technology was created. For this reason, many blockchain networks choose to limit scalability by limiting block size.
Light nodes, which do not download the entire blockchain data, have a similar level of security to full nodes through fraud proofs. If a malicious block producer inserted an invalid transaction into the block body, a light node would not detect it since it only verifies the block header. However, a full node would detect the invalid transaction since it downloads the entire block data. If the full node creates fraud-proof, a light node can know the malicious behavior without downloading the whole block.
However, this becomes a problem when a block producer purposely drops an invalid transaction from a block. A full node could detect the missing data, recognize the block as invalid, and will no longer follow that blockchain. On the other hand, light nodes that do not have access to the block body data can not generate fraud-proof and would not realize the blockchain is invalid and will continue to follow it. This phenomenon where data is inaccessible due to data omission and light nodes unintentionally forking away from full nodes is called a data availability problem. In other words, to answer the question that starts this paragraph, yes, there is indeed a problem with data availability. As blockchain networks scale and layer2 and rollup solutions become more common, solving for data availability is even more critical. While the above is only one example, many more occurrences end in a data availability problem.
Introducing Avail
Avail offers a strong data availability layer by utilizing a highly secure mathematical primitive: data availability checks that use erasure codes with a key innovation. With this, it employs Kate polynomial commitments to establish a 2D data availability scheme that eliminates the need for fraud proofs, doesn't depend on honest majority assumptions, and doesn't rely on honest full nodes to confirm the data availability.
Avail provides a common data availability layer for multiple execution environments, such as standalone chains, sidechains, and off-chain scaling solutions. Avail can be implemented and experimented with by various execution environments, enabling increased scalability and guaranteeing transaction data availability without these having to build their own security from scratch. Polygon SDK, Cosmos SDK, or Substrate-based chains can benefit from using Avail for this purpose. It separates the transaction execution and validity from the consensus layer, making the consensus responsible for ordering transactions and ensuring their data availability.
Avail focuses on ensuring that transaction data is available and properly ordered rather than verifying the current state of the application. A block that is agreed upon by the network is considered valid only if the data behind it can be accessed. This prevents block producers from releasing only the block headers without the data, making it impossible for clients to read the transactions and understand how the application's state changes.
Avail simplifies block verification by focusing on data availability. This can be done with minimal computational cost using a method called data availability checks, which are built upon erasure codes. Erasure codes are a widely used technique in data storage and protection.
Avail’s Consensus Mechanism
There has been a long-standing issue in maintaining data availability (DA) solutions through a central group of individuals known as a DAC or data availability committee. A DAC is responsible for posting signatures back to the main chain and ensuring that off-chain data is readily available. The problem with this approach is that data availability becomes a trusted service that relies on a small group of committee members who are responsible for storing and honestly reporting the data.
Avail is a new solution that is not a DAC but an actual blockchain network with its own consensus mechanism, validator nodes, and block producers. Traditional proof-of-stake systems require block producers to hold tokens (stake) on-chain to produce blocks rather than computational resources (work).
In systems with many network maintainers, they commonly form off-chain pools to increase profits by reducing reward variance. This centralization problem can be alleviated by including pools on-chain, which allows token holders to support network maintainers that they believe best represent them and the interests of the network. This also distributes the power among validators, assuming the right voting and election mechanisms are in place. The overall stake on the network is allocated through a one-to-many or many-to-many relationship instead of just relying on a one-to-one relationship, where trust is put in the "highest staked" validators.
Avail uses NPoS with a modification in block verification. Validators and nominators are still involved. Additionally, light clients can also contribute to data availability on Avail. Its consensus requires that two-thirds plus 1 of the validators must reach a consensus for a block to be considered valid.
Stakin on Avail
Our technical commitment to the Web3 ecosystem has also led us to be one of the early testers of Avail, where Stakin is running infrastructure. In addition to providing technical support, Stakin supports the development of Avail and the ecosystem through education and governance efforts. If you’d like to sustain our efforts or have any questions, please feel free to stake with our validator or contact us.
For more information about Stakin, visit the Website, Twitter, Blog, or join the Telegram and Discord community.
DISCLAIMER: This is not financial advice. Staking, delegation, and cryptocurrencies involve a high degree of risk, and there is always the possibility of loss, including the failure of all staked digital assets. Additionally, delegators are at risk of slashing in case of security or liveness faults on some protocols. We advise you to do your due diligence before choosing a validator.
