Інтеграція з Avail (Data Availability)

Інтеграція з Avail (Data Availability)

Data Availability — одна з найменш розуміваних, але критично важливих проблем у блокчейні. Проблема DA виглядає просто: блок-продюсер публікує заголовок блока, але утримує дані. Повні ноди не можуть верифікувати транзакції, які не бачать. Light клієнти без повних даних не знають, чи коректний блок. Avail вирішує саме цю проблему — не виконання транзакцій, не консенсус щодо їхної коректності, а гарантія що дані опубліковані і доступні.

Що таке Avail і чому не просто Ethereum calldata

Ethereum використовувався як DA layer для rollups через calldata (до EIP-4844) і тепер через blob transactions (EIP-4844, proto-danksharding). Але у Ethereum як DA layer є обмеження:

Вартість: навіть після EIP-4844 з blob transactions, Ethereum DA дорогий порівняно зі спеціалізованими DA рішеннями. Target 3 blobs на блок (~375KB), макс 6 blobs — явно недостатньо для масштабування rollups.

Відсутність DAS: Ethereum досі не реалізував повноцінний Data Availability Sampling. Без DAS light ноди не можуть самостійно верифікувати доступність даних — вони довіряють повним нодам.

Avail vs Ethereum DA:

Erasure Coding в Avail — ключовий механізм. Дані розширюються 2x через Reed-Solomon кодування, розбиваються на ячейки, формується 2D матриця. KZG polynomial commitments для кожного рядка і стовпця. Light нода може з високою ймовірністю верифікувати доступність, скачавши тільки випадково вибрані ячейки (~30–50 ячеек з тисяч). Це й є DAS (Data Availability Sampling).

Архітектура інтеграції

Випадок 1: Rollup використовує Avail як DA

Стандартна схема для суверенного rollup або validium:

Rollup Sequencer → batch transactions → encode → submit to Avail
                                                        ↓
                                               Avail block включає дані
                                                        ↓
                                               Avail light clients верифікують DAS
                                                        ↓
                                               Rollup settlement layer отримує DA attestation

Avail DA submission через офіційний 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 ідентифікує ваш rollup/application
  // дані індексуються за app_id для ефективного 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 — критичний концепт в Avail. Кожен rollup або application реєструє унікальний App ID. Дані фільтруються за App ID при retrieval. Це дозволяє light ноді вашого rollup робити DAS тільки по своїм даним, не скачуючи весь блок.

Випадок 2: Validium з Ethereum settlement

Validium — це ZK rollup де дані зберігаються off-chain (не на Ethereum). Вместо Ethereum calldata використовується Avail. Settlement (proof verification) залишається на Ethereum.

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

Для Ethereum settlement контракт потрібно верифікувати що дані дійсно в Avail. Avail надає Avail Bridge — набір смарт-контрактів на Ethereum для on-chain верифікації Avail attestations:

// Спрощено: верифікація DA attestation на 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);
}

// У settlement контракті rollup:
function finalizeBlock(
    bytes32 stateRoot,
    bytes calldata zkProof,
    IAvailBridge.MerkleProofInput calldata daProof
) external {
    // 1. Верифікуємо що дані блока в Avail
    require(availBridge.verifyBlobLeaf(daProof), "DA not available");

    // 2. Верифікуємо ZK proof state transition
    require(verifier.verifyProof(zkProof, stateRoot), "Invalid proof");

    // 3. Оновлюємо state root
    currentStateRoot = stateRoot;
    emit BlockFinalized(stateRoot);
}

Випадок 3: Sovereign Rollup

Суверенний rollup використовує Avail для DA і ordering, але settlement і fork choice — власні. Нема залежності від Ethereum або іншого settlement layer.

Rollup light ноди підписуються на Avail DA:

// Приклад: Avail light client для 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 верифікація: клієнт сам верифікує доступність даних
    // скачуючи тільки випадкові ячейки, не весь блок
    light_client.subscribe_app_data(app_id, |block_data| {
        // Декодуємо rollup транзакції з Avail блока
        let txs = decode_rollup_transactions(&block_data)?;

        // Застосовуємо до rollup state machine
        rollup_state_machine.apply_transactions(txs)?;

        Ok(())
    }).await?;

    Ok(())
}

Avail Nexus і Fusion

Avail розвиває екосистему за межами base DA layer:

Avail Nexus — proof aggregation layer. Собирає ZK proofs від різних rollups, агрегує їх через recursive proofs (Plonky2/SuperNova), відправляє один агрегований proof на Ethereum. Знижує вартість L1 settlement для кожного окремого rollup.

Avail Fusion — механізм restaking. ETH і інші активи можуть забезпечувати економічну безпеку Avail через restaking. Мета — успадкувати security від більш капіталізованих активів.

Для інтеграції: якщо будуєте rollup зараз — Nexus цікавий для зниження settlement costs, але знаходиться на ранній стадії.

Практичні аспекти інтеграції

Data Retrieval

Надіслати дані в Avail — половина задачі. Потрібно вміти їх отримувати:

// Отримання даних за app_id та 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);

    // Фільтрація extrinsics за 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;
}

Продуктивність і вартість

Block submission latency — Avail блоки ~20 секунд. Це приємне для більшості rollup use cases, але якщо rollup хоче sub-second UX, потрібна soft confirmation від sequencer до DA finality.

Batch size optimization — Avail лімит на extrinsic size. Потрібно батчити rollup транзакції оптимально: батчи занадто малі → висока вартість per transaction, батчи занадто великі → задержка.

Вартість в AVAIL токенах — потрібен механізм оплати. Варіанти: rollup сам держить AVAIL і платить, користувачі rollup платять у native token який конвертується, або fee abstraction через газ-спонсорство.

Моніторинг DA

// Верифікація що дані дійсно доступні після submission
async function verifyDataAvailability(
  blockHash: string,
  appId: number
): Promise<boolean> {
  // Запрошуємо confidence від Avail light client network
  const confidence = await getDAConfidence(blockHash, appId);

  // Confidence > 99.99% означає що дані доступні з високою ймовірністю
  // (математично: злоумішленник не може сховати дані якщо DAS пройшов)
  return confidence > 99.99;
}

Коли вибирати Avail

Підходит:

• Будуєте validium: хочете Ethereum-level security для proof verification, але дешевше зберігати дані off-chain
• Sovereign rollup без залежності від Ethereum
• Потрібна повна реалізація DAS (Ethereum поки не має)
• Високий throughput даних, де Ethereum blobs будуть вузьким місцем

Не підходить:

• Невеликий rollup з низькою пропускною здатністю — overhead інтеграції не виправданий, EIP-4844 blobs достатньо
• Потрібна Ethereum-native security для даних (Ethereum AS DA, не тільки settlement)
• Команда незнайома з Substrate-based екосистемою (Avail побудований на Substrate)

Етапи інтеграції