Avail

Architecture

ConsensusAn agreement on the latest and correct state of a blockchain. Unlike L1 blockchains which coordinate participating nodes with consensus rules, rollups rely on L1s for reaching consensus by checking the state of the rollup smart contract deployed thereon.

Avail implements a Nominated Proof-of-Stake (NPoS) Sybil resistance mechanism, combined with the BABE/GRANDPA consensus protocol. BABE handles blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. production by assigning block production slots according to validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier’ 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 livenessLiveness refers to the ability of a system to respond to requests and to process them in a timely manner. In the context of L2s, it refers to the ability of settling transactions, proofs and state roots to the base layer., secondary block producers are pre-determined and can step in if necessary, preventing any slot from being skipped. FinalityStrongest confirmation rule that can be given on the ordering of transactions. On Ethereum, a transaction is finalized when the corresponding epoch becomes final, which currently takes around 15 mins from transaction inclusion. A rollup transaction can be said to be final when the corresponding data is published to L1 and its ordering cannot be reverted. If outputs, i.e. state diffs are published, then also a proof proving their correctness must be verified to consider the transaction final. is achieved through GRANDPA, a GHOST-based finality gadget that provides finality through consecutive rounds of validators voting.

BlobsThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally.

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 (KZGA polynomial commitment scheme that allows a prover to compute a commitment to a polynomial, with the properties that this commitment can later be opened at any position: the prover shows that the value of the polynomial at a certain position is equal to a claimed value. KZG is widely used as it’s applicable both for univariate and k-variate polynomials, is efficient for batch proofs, and is able to generate many proofs at once relatively fast. It is also proof generation time efficient: the time for prover to commit to a polynomial is linear on the degree of the polynomial.) 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 treeA hash-based data structure in which each leaf node is a hash of a block of data, and each non-leaf node is a hash of its children. The root of the tree is a cryptographic fingerprint of the entire data structure. Merkle trees (Merkle Patricia Tries) are used in Ethereum to efficiently store key-value pairs., where the leaves represent the data blobs.

Data AvailabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. 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 HashA fixed-length fingerprint of variable-size input, produced by a hash function. Table (DHT) within a light clients peer-to-peer (P2P) networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes.. If the randomly selected cells are not available via DHT, the light clientSometimes labelled interchangeably as a “node”, they are tasked with processing transactions and managing the blockchains's state. They run the computations for each transaction according to the rollup's virtual machine and protocol rules. If comparing to Ethereum clients, these would be execution clients such as Geth, as opposed to consensus clients. resorts to RPC calls to the Avail nodeA software client that participates in the network.(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 L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. 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.

Architecture

The Vector bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. is a data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. 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 VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contracts.
By default, Vector operates asynchronously, handling requests in a fulfillment-based manner. First, zero-knowledgeA cryptographic technology and sub-discipline of cryptography that allows an individual to prove that a statement or computation is true without revealing any additional information. proofs of Avail blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. 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 operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. with local proving, allowing for self-generating the proofs. Once a proving request is received, the off-chain proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. 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.