Data Availability for Blockchains with Avail

Jan 16, 2023 6 min read
Data Availability for Blockchains with Avail

Polygon MATIC's key project for data availability - Avail - An Introduction and Deep Dive

In this article, we’re diving into data availability for blockchains with one of Polygon’s key projects: Avail. Avail is a modular blockchain that maintains a record of transactions and verifies the accessibility of the data. The goal of Avail is to make blockchain transaction data more available and organized. Avail is a key component of Polygon’s vision for modular chain design and future web3 interoperability. Any execution environment can use Avail, including different types of blockchains, and offload their data availability while still retaining full control over their chain.

As a data availability layer, it enables blockchains to 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 be aware of 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-mentioned is only one example, many more occurrences end in a data availability problem; you can read more about those here.

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 that can be used across 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.

First Published by Avail

As you can see in the image above, Avail focuses on making sure 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 is changing.

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, it is common for them to 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.

This is achieved through a method called delegation or nomination, commonly referred to as DPoS (delegated proof of stake) or NPoS (nominated proof of stake). Polygon's scaling solutions, including Avail, have adopted these enhanced mechanisms.

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

Stakin has been operating on Polygon testnet since 2019 and has a high track record in offering reliable and secure infrastructure for the network. We’ve been running a Mainnet validator since 2020 with an excellent track record of uptime and security. Our technical commitment to the network has also led us to be one of the early testers of upcoming Polygon ecosystem networks, including Avail, where Stakin is running infrastructure. In addition to providing technical support, Stakin also supports the development of Polygon and the Polygon 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.

Join the conversation

Success! Your account is fully activated, you now have access to all content.
Success! Your billing info has been updated.
Your billing was not updated.