Avail Data Availability Integration

Avail Integration (Data Availability)

Data Availability is one of the least understood yet critically important problems in blockchain. The DA problem looks simple: a block producer publishes a block header but withholds the data. Full nodes cannot verify transactions they don't see. Light clients without full data don't know if the block is correct. Avail solves exactly this problem—not transaction execution, not consensus on their correctness, but the guarantee that data is published and available.

What is Avail and Why Not Just Ethereum Calldata

Ethereum was used as a DA layer for rollups through calldata (pre-EIP-4844) and now through blob transactions (EIP-4844, proto-danksharding). But Ethereum as a DA layer has limitations:

Cost: even after EIP-4844 with blob transactions, Ethereum DA is expensive compared to specialized DA solutions. Target 3 blobs per block (~375KB), max 6 blobs—clearly insufficient for scaling rollups.

Lack of DAS: Ethereum has not yet implemented full Data Availability Sampling. Without DAS light nodes cannot independently verify data availability—they trust full nodes.

Avail vs Ethereum DA:

Erasure Coding in Avail is the key mechanism. Data is expanded 2x through Reed-Solomon coding, split into cells, forming a 2D matrix. KZG polynomial commitments for each row and column. A light node can verify availability with high probability by downloading only randomly selected cells (~30–50 cells from thousands). This is DAS (Data Availability Sampling).

Integration Architecture

Case 1: Rollup Uses Avail as DA

Standard scheme for sovereign rollup or validium:

Rollup Sequencer → batch transactions → encode → submit to Avail
                                                        ↓
                                               Avail block includes data
                                                        ↓
                                               Avail light clients verify DAS
                                                        ↓
                                               Rollup settlement layer gets DA attestation

Avail DA submission via official SDK:

import { initialize } from 'avail-js-sdk';

async function submitBatchToAvail(batchData: Uint8Array): Promise<SubmitResult> {
  const api = await initialize(AVAIL_RPC_URL);
  const account = new Keyring({ type: 'sr25519' });
  const keyPair = account.addFromMnemonic(AVAIL_MNEMONIC);

  // app_id identifies your rollup/application
  // data is indexed by app_id for efficient retrieval
  const result = await api.tx.dataAvailability
    .submitData(batchData)
    .signAndSend(keyPair, { app_id: YOUR_APP_ID });

  return {
    blockHash: result.blockHash,
    txHash: result.txHash,
    dataRoot: await getBlockDataRoot(api, result.blockHash)
  };
}

App ID is a critical concept in Avail. Each rollup or application registers a unique App ID. Data is filtered by App ID on retrieval. This allows your rollup's light node to do DAS only on its own data, not downloading the full block.

Case 2: Validium with Ethereum Settlement

Validium is a ZK rollup where data is stored off-chain (not on Ethereum). Avail is used instead of Ethereum calldata. Settlement (proof verification) remains on Ethereum.

User transactions → Prover (zkEVM/zkVM) → ZK proof
                                              ↓
                         Avail ← batch data  Ethereum ← ZK proof + data root
                              ↓                              ↓
                         DAS verification    State transition verified

For Ethereum settlement the contract needs to verify that data is actually in Avail. Avail provides Avail Bridge—a set of smart contracts on Ethereum for on-chain verification of Avail attestations:

// Simplified: verification of DA attestation on Ethereum
interface IAvailBridge {
    struct MerkleProofInput {
        bytes32[] dataRootProof;
        bytes32[] leafProof;
        bytes32 rangeHash;
        uint256 dataRootIndex;
        bytes32 blobRoot;
        bytes32 bridgeRoot;
        bytes32 leaf;
        uint256 leafIndex;
    }

    function verifyBlobLeaf(MerkleProofInput calldata input) external view returns (bool);
}

// In settlement contract of rollup:
function finalizeBlock(
    bytes32 stateRoot,
    bytes calldata zkProof,
    IAvailBridge.MerkleProofInput calldata daProof
) external {
    // 1. Verify that block data is in Avail
    require(availBridge.verifyBlobLeaf(daProof), "DA not available");

    // 2. Verify ZK proof of state transition
    require(verifier.verifyProof(zkProof, stateRoot), "Invalid proof");

    // 3. Update state root
    currentStateRoot = stateRoot;
    emit BlockFinalized(stateRoot);
}

Case 3: Sovereign Rollup

Sovereign rollup uses Avail for DA and ordering, but settlement and fork choice are its own. No dependency on Ethereum or another settlement layer.

Rollup light nodes subscribe to Avail DA:

// Example: Avail light client for sovereign rollup (Rust)
use avail_light::LightClient;

async fn sync_rollup_blocks(app_id: u32) -> Result<()> {
    let light_client = LightClient::new(AVAIL_BOOTSTRAP_NODES).await?;

    // DAS verification: client verifies data availability
    // by downloading only random cells, not the full block
    light_client.subscribe_app_data(app_id, |block_data| {
        // Decode rollup transactions from Avail block
        let txs = decode_rollup_transactions(&block_data)?;

        // Apply to rollup state machine
        rollup_state_machine.apply_transactions(txs)?;

        Ok(())
    }).await?;

    Ok(())
}

Avail Nexus and Fusion

Avail is developing ecosystem beyond base DA layer:

Avail Nexus is a proof aggregation layer. It collects ZK proofs from different rollups, aggregates them via recursive proofs (Plonky2/SuperNova), sends one aggregated proof to Ethereum. Reduces L1 settlement cost for each individual rollup.

Avail Fusion is a restaking mechanism. ETH and other assets can provide economic security to Avail through restaking. Goal is to inherit security from more capitalized assets.

For integration: if building a rollup now—Nexus is interesting for reducing settlement costs, but is in early stage.

Practical Integration Aspects

Data Retrieval

Publishing data to Avail is half the task. You need to be able to retrieve it:

// Get data by app_id and block range
async function retrieveRollupData(
  api: ApiPromise,
  appId: number,
  fromBlock: number,
  toBlock: number
): Promise<AppData[]> {
  const results: AppData[] = [];

  for (let blockNum = fromBlock; blockNum <= toBlock; blockNum++) {
    const blockHash = await api.rpc.chain.getBlockHash(blockNum);
    const block = await api.rpc.chain.getBlock(blockHash);

    // Filter extrinsics by app_id
    const appExtrinsics = block.block.extrinsics.filter(ext => {
      const appId = extractAppId(ext);
      return appId === appId;
    });

    if (appExtrinsics.length > 0) {
      results.push({
        blockNumber: blockNum,
        blockHash: blockHash.toString(),
        data: appExtrinsics.map(ext => ext.method.args[0] as Bytes)
      });
    }
  }

  return results;
}

Performance and Cost

Block submission latency is ~20 seconds for Avail blocks. This is acceptable for most rollup use cases, but if rollup wants sub-second UX, soft confirmation from sequencer until DA finality is needed.

Batch size optimization is important. Avail has extrinsic size limits. Need to batch rollup transactions optimally: batches too small → high per-transaction cost, batches too large → delay.

Cost in AVAIL tokens requires a payment mechanism. Options: rollup holds AVAIL and pays, rollup users pay in native token which converts, or fee abstraction through gas sponsorship.

DA Monitoring

// Verify that data is actually available after submission
async function verifyDataAvailability(
  blockHash: string,
  appId: number
): Promise<boolean> {
  // Request confidence from Avail light client network
  const confidence = await getDAConfidence(blockHash, appId);

  // Confidence > 99.99% means data is available with high probability
  // (mathematically: attacker cannot hide data if DAS passes)
  return confidence > 99.99;
}

When to Choose Avail

Good fit:

• Building validium: want Ethereum-level security for proof verification, but cheaper to store data off-chain
• Sovereign rollup without Ethereum dependency
• Need full DAS implementation (Ethereum doesn't have it yet)
• High data throughput where Ethereum blobs would be bottleneck

Not a fit:

• Small rollup with low throughput—integration overhead not justified, EIP-4844 blobs sufficient
• Need Ethereum-native security for data (Ethereum AS DA, not just settlement)
• Team unfamiliar with Substrate-based ecosystem (Avail built on Substrate)

Integration Phases