Интеграция с 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 per block (~375KB), max 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 секунд. Это acceptable для большинства 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 с низким throughput — overhead интеграции не оправдан, EIP-4844 blobs достаточно
• Нужна Ethereum-native security для данных (Ethereum AS DA, не только settlement)
• Команда незнакома с Substrate-based экосистемой (Avail built on Substrate)

Этапы интеграции