Avail
Funds can be lost if
- a dishonest supermajority 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,
- a dishonest supermajority of Avail validators finalizes an unavailable block, and the light nodes on the network cannot collectively reconstruct the block.
Funds can be lost if
Avail is a public blockchain and data availability network combining erasure coding, KZG polynomial commitments, and data availability sampling.
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.
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.
The committee requires an honest minority (less than 1/3) of members (or the network stake) to prevent the DA bridge from accepting an unavailable data commitment. Participation in the committee is permissionless, based only on stake requirements and an honest majority of validators processing the new operator’s request to join the active set.
There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed.
The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity.
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 supermajority 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 supermajority of Avail validators finalizes an unavailable block, and the light nodes on the network cannot collectively reconstruct the block.
Vector is a data availability bridge using Zero-Knowledge proofs to verify Avail data availability attestations on Ethereum.
The committee requires an honest minority (less than 1/3) of members (or the network stake) to prevent the DA bridge from accepting an unavailable data commitment. Participation in the committee is permissionless, based only on stake requirements and an honest majority of validators processing the new operator’s request to join the active set.
There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed.
The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity.
Architecture
The Vector bridge is a data availability bridge that facilitates data availability commitments to be bridged between Avail and Ethereum.
The SP1 Vector bridge is composed of three main components: the Vector contract, the Succinct Gateway contracts, and the Verifier contracts.
By default, Vector operates asynchronously, handling requests in a fulfillment-based manner. First, zero-knowledge proofs of Avail block ranges are requested for proving. Requests can be submitted either off-chain through the Succinct API, or onchain through the requestCall() method of the Succinct Gateway smart contract.
Alternatively, it is possible to run an SP1 Vector operator with local proving, allowing for self-generating the proofs.
Once a proving request is received, the off-chain prover generates the proof and relays it to the Vector contract. The Vector contract verifies the proof with the corresponding verifier contract and, if successful, stores the data commitment in storage.
By default, Vector on Ethereum is updated by the Succinct operator at a cadence of approximately 1.5 hours.
Funds can be lost if the DA bridge accepts an incorrect or malicious data commitment provided by 2/3 of Avail validators.
Funds can be frozen if excluding L2-specific DA fallback - the permissioned relayers are unable to submit DA commitments to the Vector contract.
The system consists of the following permissions on Ethereum:
- A Gnosis Safe with 4 / 7 threshold.
- Can change the configuration of Vector - can freeze the Vector contract and update the list of authorized relayers.
- Can upgrade the implementation of Vector.
Those are the participants of the AvailMultisig.
Those are the participants of the SuccinctGatewaySP1Multisig.
Can change the configuration of SuccinctGatewaySP1 - can verify proofs for the header range [latestBlock, targetBlock] proof.
Can change the configuration of Vector - can call commitHeaderRange() to commit block ranges to the Vector contract.
The system consists of the following smart contracts on Ethereum:
The Vector bridge contract that accepts and stores Avail data availability commitments on Ethereum.
Upgrade delay: No delay
The current deployment carries some associated risks:
Funds can be lost if the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades.
Funds can be frozen if the bridge contract is frozen by the Guardian (AvailMultisig).