How does AvailDA Scale?
Last updated
Last updated
Erasure coding is the process of creating redundancy in data so that the original data is easily recoverable even if parts of it is missing. In Avail, we use erasure coding to make it very hard for malicious data publishers to hide parts of data.
High Level: A type of validity proof that makes it simple for even a light client to independently generate their own mathematically verified data availability guarantees.
Analogy: A KZG commitment scheme is essentially a cryptographic envelope. When a sheet full of data is inserted into the envelope and sealed, a unique serial number is created and placed on top—we call this committing to the value. Once sealed, the data cannot be changed or tampered with but anyone can verify its existence by scanning the signature. If the data is changed, the digital signature changes and the previous signature is no longer valid.
Data availability sampling is a method used by light clients to confirm the availability of data without downloading complete blocks, allowing them to verify with 99.99% certainty that all data in a block is available by sampling just ~1% of it. Through this method, light clients engage in several rounds of random sampling for small chunks of block data. With each successful round, confidence that the data is available grows. When the light client achieves a set confidence threshold, they recognize the block data as accessible.
The Avail light client is a node that lets users access blockchains by downloading the bare minimum amount of data required to verify its existence. It plays a vital role in ensuring the availability and correctness of data within the Avail network. Avail LCs are suitable for low-resource environments like phones and smartwatches and offer roughly comparable security to full nodes. As the number of light clients grows and more data availability sampling (DAS) occurs, the coverage offered by the light client network expands, eventually becoming large enough to collectively sample larger blocks. Unlike monolithic blockchain designs which reduce the amount of blockspace available as demand increases, Avail’s LCs can help scale blockspace with demand, future-proofing appchains and rollups.
Avail uses a hybrid consensus model based on Polkadot’s BABE and GRANDPA that produces high finality and liveness. This model equips Avail with network resilience and enables it to withstand temporary network partitions and a substantial number of node failures.
GRANDPA functions as the finality gadget, ensuring transaction accuracy and security, and enables the simultaneous finalization of multiple blocks. GRANDPA validators vote on a block that they consider best and their votes are applied transitively to all previous blocks. After two-thirds of the GRANDPA authorities have voted for a particular block, it is considered final, greatly speeding up the finalization process, even after long-term network partitioning or other networking failures. As soon as more than 2/3 of validators attest to a chain containing a certain block, all blocks leading up to that one are finalized at once.
BABE serves as the block production engine, prioritizing quick transaction processing (liveness) by coordinating with validator nodes to identify new block producers. BABE assigns block production slots to validators according to stake and using a randomness cycle. BABE execution happens in sequential non-overlapping phases known as epochs. Each epoch is divided into a predefined number of slots. During each slot, only some of the validators can produce a block. Validators are selected based on a verifiable random function (VRF).