Search

Search for projects by name

Avail logoAvail

  • Type
    Public blockchain
  • Total value secured
    $0.00
  • Economic security
    $95.11 M

  • Duration of storage
  • Used by
  • Select a bridge
    No bridge
    $0.00
    Vector
    $0.00


    Risk summary
    Avail

    Avail is a public blockchain and data availability network combining erasure coding, KZG polynomial commitments, and data availability sampling.

    Risk analysis
    Economic security
    Staked assets

    There are staked assets on the DA layer that can be slashed in case of a data withholding attack. A dishonest supermajority of validators must collude to finalize a block with missing or invalid data. The invalid block would be added to the chain but rejected by honest full nodes.

    Fraud detection
    DAS

    The DA layer uses data availability sampling (DAS) to protect against data withholding attacks. However, the block reconstruction protocol, which enables the minimum number of light nodes to collectively reconstruct the block, is still under development.

    Technology

    Architecture

    Avail architecture

    Consensus

    Avail implements a Nominated Proof-of-Stake (NPoS) Sybil resistance mechanism, combined with the BABE/GRANDPA consensus protocol. BABE handles block production by assigning block production slots according to validators’ stake and using a Verifiable Random Function (VRF). At the start of each epoch, nodes run the Block-Production-Lottery algorithm to assign block production slots and share the results with other nodes. Slots are randomly assigned, meaning multiple validators might be selected for the same slot (with a ‘race’ determining who gets to propose the block) and some slots may remain empty. To ensure liveness, secondary block producers are pre-determined and can step in if necessary, preventing any slot from being skipped. Finality is achieved through GRANDPA, a GHOST-based finality gadget that provides finality through consecutive rounds of validators voting.

    Blobs

    Data submitted to the Avail blockchain through submitData transactions is organized into a data matrix, with each block data divided into equal-sized cells. This matrix is erasure coded using Reed-Solomon (RS) codes and committed using Kate-Zaverucha-Goldberg (KZG) polynomial commitments. Each block header on Avail includes two types of attestations: KZG polynomial commitments of the submitted data and the root of a Merkle tree, where the leaves represent the data blobs.

    Data Availability Sampling (DAS)

    Avail ensures data availability through a data availability sampling (DAS) mechanism, which involves both Light clients and App clients. Light clients sample the data matrix by requesting data cells, and for each cell they then check the KZG polynomial openings against the commitments in the block header. Light clients first attempt to fetch cells using a Kademlia-based Distributed Hash Table (DHT) within a light clients peer-to-peer (P2P) network. If the randomly selected cells are not available via DHT, the light client resorts to RPC calls to the Avail node(s) to obtain the data. Cells retrieved this way are then shared back into the DHT network, enhancing the overall availability of block data. After gathering the data, the light client verifies the cells and calculates a confidence level, which is stored locally for reference. App clients focus on data specific to a given application ID. They reconstruct entire rows of the data matrix by requesting and assembling any missing cells from the network.

    Erasure Coding Proof

    Avail uses Kate-Zaverucha-Goldberg (KZG) polynomial commitments as validity proofs of erasure-coded data. Light clients verify the commitments by checking the KZG polynomial openings against the commitments in the block header.

    L2s Data Availability

    L2s can post application-specific data blobs to the Avail blockchain through submitData transactions. Each transaction contains an application ID that identifies the L2 and adheres to a size limit based on the Avail blockchain’s block size. App-specific data can be reconstructed by app clients, which request and assemble missing cells from the network to complete the data reconstruction process.

    • Funds can be lost if a dishonest majority of Avail validators finalizes an unavailable block, and there aren't light nodes on the network verifying data availability, or they fail at social signaling unavailable data.

    • Funds can be lost if a dishonest majority of Avail validators finalizes an unavailable block, and the light nodes on the network cannot collectively reconstruct the block.

    1. Avail Documentation
    2. Avail Light Client - Source Code
    3. Avail App Client - Source Code
    No bridge

    The risk profile in this page refers to L2s that do not integrate with a data availability bridge.

    Risk analysis

    There is no committee attesting to the availability of data.

    Without the bridge, users cannot react in time to malicious actions by the sequencer.

    The relayer does not contribute to the DA bridge liveness since data availability attestations are not integrated in the scaling solution’s proof system.

    Technology

    No DA bridge is selected. Without a DA bridge, Ethereum has no proof of data availability for this project.