Thread by @0xPolygon

1/ We are extremely excited to announce Avail - an important component of a completely new way on how future blockchains will work. #Avail is a general-purpose, scalable data availability-focused blockchain targeted for standalone chains, sidechains & off-chain scaling solutions.

2/ #Avail provides a robust data availability layer by using an extremely secure mathematical primitive - DA checks using erasure codes. We use KZG polynomial commitments to create a 2D DA scheme.

🌐 Learn more: bit.ly/2UarzfW

3/ Benefits of #Avail:

- Avoids encoding fraud proofs,
- No honest majority assumptions,
- No reliance on honest full node peers to gain data availability confidence

4/ #Avail provides a common data availability layer that can be used by varying execution environments such as standalone chains, sidechains, and off-chain scaling solutions.

5/ In the long term, it will enable a wide variety of experimentation on the execution environment side and eventual implementation, without teams & projects having to bootstrap their own security. Chains created using @0xPolygon SDK, @cosmos SDK or @substrate_io will benefit.

6/ #Avail decouples the transaction execution and validity from the consensus layer so that the consensus is only responsible for

a) ordering transactions &
b) guaranteeing their data availability

7/ Key objectives of #Avail:

7(a) Enable standalone chains or sidechains with arbitrary execution environments to bootstrap validator security without needing to create & manage their own validator set by guaranteeing transaction data availability

7(b) Layer-2 solutions such as Validiums to offer increased scalability throughput by using #Avail as an off-chain data availability layer

8/ We have been working on #Avail in stealth since the end of 2020 and currently it is at devnet stage. A testnet is in the works.

9/ More details about the problem, architecture, and the solution including references to the codebase can be found in the reference document - bit.ly/2U9a2Va

10/ #Avail solves this problem by taking a different approach - instead of verifying the application state, it concentrates on ensuring the availability of the transaction data posted and also ensures transaction ordering.

11/ A block that has consensus is considered valid only if the data behind that block is available. This is to prevent block producers from releasing headers without releasing the data, which would prevent clients from reading the txns necessary to compute the state of the
apps.

12/ #Avail reduces the problem of block verification to data availability verification, which can be done efficiently with constant cost using data availability checks. Data availability checks utilize erasure codes, which are used heavily in data redundancy design.

13/ Data availability checks require each light client to sample a very small number of random chunks from each block in the chain. A set of light clients can collectively sample the entire blockchain in this manner.

14/ This leads to an interesting consequence: the more non-consensus nodes that are present in the network, the greater the block size you can have securely. This is a useful property, as it means non-consensus nodes also contribute to the throughput & security of the network.

15/ In the KZG commitment based scheme that #Avail uses, there are 3 main features:

1) Data redundancy so that it is hard for the block producer to hide any part of the block.
2) Fraud proof free guarantee of correct erasure coding

15 (cont.)/

3) Vector commitments that allow full nodes to convince transaction inclusion to light nodes using succinct proof.

🌐 Learn more: bit.ly/2UarzfW

Here's the reference document - bit.ly/2U9a2Va

16/ For more information regarding #Avail, please join our Discord server - bit.ly/3jmOkb2 or 📧 email us at [e-mail]

17/ We would love to have your thoughts, opinions & feedback on the system and help us in improving it as we go ahead.

Also, feel free to drop in by our Discord server to chat - bit.ly/3jmOkb2